Непрерывная доставка обновлений

Клиент

Неткэт — CMS для сайтов, лендингов и интернет-магазинов. На этой платформе работают 15 000 сайтов. Клиенты Неткэта — разработчики и дизайн-студии, которые делают сайты для своих заказчиков.

Проблема

Разработчики Неткэта медленно исправляли ошибки, о которых клиенты писали в службу поддержки. Клиенты ждали две недели или месяц, пока появлялось обновление Неткэта с исправлением ошибок. Всё это время сайты и интернет-магазины работали нестабильно, а их владельцы теряли клиентов и деньги.

Каждое обновление платформы было масштабным и болезненным. В них разработчики исправляли ошибки, на которые жаловались клиенты, и внедряли новые функции. В этих функциях иногда скрывались новые проблемы, и клиенты опять писали в поддержку. Неткэт попал в замкнутый круг.

Было: 2 недели на сборку обновления

Мы изучили, как разработчики создают обновления платформы и нашли две проблемы. Первая — у разработчиков не было четкого процесса проверки кода перед внедрением в платформу. Вторая — разработчики собирали обновления вручную. Давайте подробнее.

Хаос в проверке кода. Каждый из разработчиков писал свою часть обновления и отдавал ее на проверку коллегам. Если они видели ошибки, то исправляли не копию кода, а рабочую версию. Один исправлял одну часть, другой — другую, третий — правил исправления первого. Возникала неразбериха. Разработчик не понимал, кто и что исправил и какая часть кода правильная. Такая проверка только вредила, потому что в коде появлялись новые ошибки.

Беспорядок в данных. У разработчиков не было одного места, где хранилась информация о проекте, ошибках и задачах. Они собирали информацию в багтрекере, внутренней документации и на площадках для обсуждения задач. Часто разработчики теряли важные данные, были не в курсе о планах коллег или делали лишнюю работу, которую уже взял кто-то другой.

Много изменений в обновлениях. В одном обновлении платформы разработчики исправляли старые ошибки и внедряли новые функции. Они сами тестировали эти функции, как умели, но не учитывали все сценарии работы клиента с ними. Поэтому вместе с обновлением в платформе появлялись новые ошибки.

Ручная сборка обновлений. Разработчики сначала писали код обновления, а потом еще неделю или две собирали куски кода в один продукт. Из-за ручной сборки часто выходили сломанные обновления. Они не устанавливались или давали ошибку на моменте запуска. А это приносило новую волну негатива от клиентов.

Стало: сборка обновления за минуту

Система контроля версий. Мы перевели работу разработчиков на Гит. Это система, которая помогает управлять проектом на уровне кода. На базе Гита работает несколько программ для совместной разработки кода, мы выбрали Гитхаб.

По принципу работы Гитхаб похож на гуглдок, только для разработчиков. В нем удобно хранить информацию о проекте и работать над кодом месте с другими разработчиками в реальном времени.

В Гитхабе разработчики работают в ветках — копиях кода обновления. Они правят код в текущей ветке или создают новые ветки. Текущая ветка — это основной код обновления, новая ветка — копия кода.

Если разработчики правят код в текущей ветке, все изменения сразу попадают в готовое обновление. Хозяин кода видит старый код и исправленную версию, понимает свои ошибки и в любой момент может вернуться к прежней редакции кода.

Создать новую ветку это как сделать копию гуглдока и работать только с ней. Разработчики редактируют копию кода и пишут в ней новые функции. В готовое обновление эти изменения сразу не попадают. Когда разработчик доделал свою часть и протестировал код, он внедряет его в готовое обновление.

Инструкция для разработчиков. Мы написали для разработчиков пошаговое руководство, как работать с кодом, исправлять в нем ошибки и внедрять изменения в готовый продукт. По этой инструкции работает команда разработки Неткэта и учатся новички.

Тестовые площадки. Мы создали тестовые площадки для проверки обновлений. Перед сборкой обновление автоматически разворачивается на тестовой машине, а разработчики проверяют его и исправляют ошибки.

Скрипт автоматической сборки. Вместе с разработчиками Неткэта мы написали скрипт для автоматической сборки обновлений. Он собирает обновление за одну-две минуты. Скрипт вытаскивает все последние версии кода и патчи из Гита, тестирует их, заливает обновления в нужные места продукта и делает дистрибутивы.

Результат

Обновления в Неткэте перестали быть проблемой. Вот, что получилось в итоге:

• внедрили регламент работы с кодом, убрали беспорядок в разработке и уменьшили количество ошибок в готовом обновлении;

• сократили время доставки обновлений до одного-двух дней;

• сократили количество негативных отзывов от клиентов.