Управление релизами

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

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

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

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

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

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

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

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

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