Как перейти к непрерывному развертыванию

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

Sten Pittet Sten Pittet

Рекомендуем также заглянуть в наше руководство по началу работы «Непрерывное развертывание в Bitbucket Pipelines».

«Всем выйти из рабочей среды! Я сейчас создам релиз!»

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

Непрерывное развертывание решает эту проблему путем автоматической поставки в рабочую среду каждого изменения, отправляемого в главный репозиторий. Это радикальный подход, который сильно отличается от того, когда на подготовку и проверку каждого релиза тратится несколько дней. Однако непрерывное развертывание дает несколько преимуществ:

  • Релизы становятся меньше по размеру и проще для понимания.
  • Никому не приходится бросать работу, чтобы выполнить развертывание, потому что все автоматизировано.
  • Цикл обратной связи с клиентами ускоряется: новые возможности и улучшения ПО поступают в рабочую среду по мере готовности.

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

Непрерывное развертывание и непрерывная поставка

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

Непрерывная поставка и непрерывное развертывание

Автоматическая поставка изменений в рабочую среду требует наличия надежной культуры непрерывной интеграции (CI), поэтому мы настоятельно рекомендуем сперва внедрить непрерывную поставку. Подробнее об этих двух подходах читайте в следующих статьях.

Переход от непрерывной поставки к непрерывному развертыванию

Развивайте культуру непрерывной интеграции

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

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

Убедитесь, что у вас хорошее покрытие тестами (и сами тесты тоже хорошие)

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

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

Внедрите мониторинг в режиме реального времени

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

Для отслеживания базовых показателей производительности и получения предупреждений о неисправностях можно использовать такие инструменты, как Nagios, или такие сервисы, как New Relic.

Проверка тестов, выполняемых после развертывания

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

Убедитесь, что эти тесты не просто ищут статическую страницу и ожидают получить успешный ответ. Рекомендуется использовать тест, который поможет убедиться, что все сервисы рабочей среды (база данных, микросервисы, сторонние сервисы) работают правильно.

Команда контроля качества должна включаться в работу как можно раньше

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

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

Забудьте про традиционные примечания к релизу

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

При таком положении вещей больше нет смысла писать примечания к релизу и отправлять их клиентам с каждой новой версией. Вместо этого примите новый подход и объявляйте только об основных возможностях, которые важны клиентам. Отчеты о багах и небольшие запросы на усовершенствование можно просто обрабатывать в системе заявок. Например, Jira может уведомлять всех наблюдателей заявки об ее закрытии или обновлении.

Альтернативный подход к новым проектам: развертывание в рабочей среде перед написанием кода

Начиная работать над новой базой кода, можно сделать кое-что интересное. Вы можете начать с создания своего конвейера непрерывного развертывания — до того, как появятся пользователи и готовые функции (это похоже на разработку, управляемую тестированием). Сначала вы будете поставлять пустую платформу. Затем, по мере продвижения разработки, новые возможности начнут появляться автоматически. Вам останется только держать рабочую среду закрытой до тех пор, пока вы не будете готовы открыть ее для своих клиентов.

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

Накапливайте знания и делитесь опытом!

Понятно, что решиться на переход к непрерывному развертыванию сложно. Внезапно открываются все границы, и код отправляется прямо к клиентам за считаные минуты или часы (жуть!). Поэтому важно инвестировать в тесты и автоматизацию: это обеспечит вам уверенность в сборках. Переход дается легко при наличии новой базы кода, однако для сложных устаревших баз может потребоваться другая стратегия.

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