8.1 CI/CD и поставка

Обзор и мотивация

Непрерывная интеграция и непрерывная поставка (CI/CD) это соединительная ткань между написанием кода и безопасным предъявлением его пользователям. Непрерывная интеграция означает, что каждое изменение часто сливается в общую основную линию, затем автоматически собирается и тестируется, так что проблемы интеграции всплывают в течение минут, а не в конце долгого цикла выпуска. Непрерывная поставка означает, что каждое изменение, прошедшее конвейер, держится в готовом к развёртыванию состоянии, так что выпуск в производство становится бизнес-решением, а не инженерной суетой. Непрерывное развёртывание идёт на шаг дальше и выпускает каждое прошедшее изменение автоматически, без человеческого барьера.

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

Корпоративный и государственный контексты добавляют ещё одно измерение: проверяемость и контроль изменений. Регуляторам, специалистам по безопасности и аудиторам нужны свидетельства того, что изменения были рецензированы, протестированы и утверждены и что артефакт, работающий в производстве, именно тот, что был собран и проверен. Хорошо спроектированный конвейер CI/CD превращает эти обязательства соответствия из бумажного бремени в автоматический побочный продукт обычного инженерного рабочего процесса. При хорошем исполнении поставка становится одновременно быстрее и безопаснее, а это результат, важнейший для руководства.

См. также: глава 8.4 (платформенная инженерия и опыт разработчика), глава 8.5 (автоматизация тестов и процессов) и глава 7.4 (продуктовая аналитика и эксперименты) о флагах функций (переключателях времени выполнения, открывающих функциональность пользователям без повторного развёртывания) и практиках экспериментов, которые делает возможными прогрессивная поставка (постепенный выпуск изменения с автоматическим мониторингом его метрик здоровья).

Ключевые принципы

Интегрируйте малые изменения часто; долгоживущие ветки враг непрерывной интеграции.
Собирайте артефакт один раз и продвигайте тот же самый артефакт через каждую среду.
Сделайте конвейер авторитетным барьером: если он зелёный, изменение готово к отгрузке; если красный, работа останавливается, пока это не исправят.
Беспощадно оптимизируйте быструю обратную связь, чтобы разработчики оставались в потоке, а дефекты ловились, пока контекст свеж.
Автоматизируйте всё повторяющееся, включая тесты, проверки безопасности, подготовку и развёртывание.
Воспринимайте определения конвейеров как код под контролем версий и рецензией, а не как настройку консоли щелчками.
Проектируйте безопасные, обратимые выпуски, чтобы любое развёртывание можно было быстро отменить.
Разделяйте развёртывание (установку кода) и выпуск (открытие его пользователям) с помощью флагов функций.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы	Лучше всего подходит
Непрерывная поставка (ручной барьер выпуска)	Бизнес контролирует время; сильно для регулируемых окон выпуска	Требует дисциплины для сохранения основной линии пригодной к отгрузке	Корпорации с окнами изменений
Непрерывное развёртывание (полностью автоматическое)	Самая быстрая обратная связь; наименьшие партии	Требует зрелых тестов и наблюдаемости	Команды с высоким доверием и частотой
Сине-зелёное	Мгновенный откат; простая ментальная модель	Удваивает цену среды во время переключения	Критичные сервисы, нуждающиеся в быстром откате
Канареечное + прогрессивная поставка	Ограничивает радиус поражения; основано на данных	Сложно строить; нужны хорошие метрики	Крупномасштабные пользовательские системы
Флаги функций	Разделяют развёртывание и выпуск	Долг флагов, если не убирать	Команды, безопасно отгружающие незавершённую работу

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

Вопросы для обсуждения с командой

Какова ваша цель по времени обратной связи стадии коммита и что отрезается, когда набор перерастает десять минут? Медленная стадия коммита тихо убивает непрерывную интеграцию, потому что разработчики перестают ждать зелёного и начинают копить изменения. Решите число сейчас (эта глава отстаивает менее десяти минут) и решите механизм его удержания: параллельные исполнители, строгая пирамида тестов и перенос медленных интеграционных проверок на более позднюю стадию. В корпоративном масштабе это платформенное решение, поскольку сотни инженеров делят один конвейер, а каждая добавленная минута умножается на каждый коммит. Принесите на совещание реальные данные: нынешнюю длительность конвейера по p50 и p95, десять самых медленных тестов и как часто люди перезапускают, а не ждут. Если вы не можете назвать цель и защитить её числами, ваш конвейер дрейфует к пакетному процессу в костюме CI.
Какую стратегию развёртывания использует каждый сервис и кто подотчётен за этот выбор? Скользящее, сине-зелёное и канареечное не взаимозаменяемы: они по-разному меняют цену, скорость отката и сложность, а правильный выбор зависит от радиуса поражения сервиса. Сине-зелёное покупает мгновенный откат ценой удвоенной среды во время переключения, что стоит того для платёжной системы и расточительно для внутренней панели. Канареечное ограничивает экспозицию, но требует хороших метрик здоровья и большей инженерии конвейера. Для большого или регулируемого хозяйства оставление этого привычке каждой команды порождает несогласованность, всплывающую во время инцидента, поэтому согласуйте умолчания по ярусу сервиса и запишите решение. Принесите ваш каталог сервисов и пометьте каждый сервис его стратегией, путём отката и человеком, владеющим этим решением.
Как вы доказываете, что артефакт в производстве именно тот, что прошёл каждый барьер? Собрать один раз и продвигать тот же артефакт вся игра для проверяемости, и она ломается в момент, когда кто-то пересобирает для каждой среды или правит работающую машину. В корпоративной и государственной среде аудитор попросит вас проследить работающий бинарный файл до его коммита, рецензии и утверждений, и вы хотите, чтобы этот ответ занимал секунды, а не неделю. Решите, как вы это принуждаете: неизменяемые артефакты, подписанные образы, проверка подписи при развёртывании и конфигурация, внедряемая при развёртывании, а не запекаемая в отдельные сборки. Принесите на стол текущие пробелы, такие как любая стадия, пересобирающая, любой путь ручного исправления и любое место, где конфигурация раздваивает артефакт. Ответ определяет, являются ли ваши свидетельства соответствия побочным продуктом конвейера или ручной суетой перед каждым аудитом.
Когда основная линия краснеет, что на самом деле останавливается и как вы обращаетесь с ненадёжными тестами? Конвейер является авторитетным барьером, только если красная сборка действительно останавливает работу, однако многие организации тихо терпят сломанную основную линию и очередь перемежающихся отказов, приучая разработчиков перезапускать до зелёного и отгружать поверх отказов. Для большой команды эта гниль накапливается, потому что проигнорированная одной командой ненадёжность становится оправданием для всех обойти барьер, а доверие к конвейеру гораздо дешевле сохранить, чем восстановить. Взвесьте конкурирующие тяготения: строгое правило остановки линии защищает качество, но может блокировать сотни инженеров из-за одного плохого коммита, тогда как мягкая политика сохраняет пропускную способность и разъедает барьер. Принесите на обсуждение свидетельства: нынешнее время красной основной линии, число карантинных или ненадёжных тестов, долю перезапусков и как часто изменения сливаются поверх падающей проверки. В корпоративной и государственной среде назовите, кто владеет сортировкой ненадёжных тестов и у кого есть полномочия заморозить слияния, потому что барьер, за принуждение которого никто не отвечает, аудиторы найдут регулярно обходимым.
Каков ваш жизненный цикл флагов функций и кто отвечает за их вывод? Флаги позволяют разделять развёртывание и выпуск и скрывать незавершённую работу, но каждый флаг это ветка в вашем коде, которая сама не убирается, а неуправляемые флаги копятся в условную сложность, которой никто не смеет касаться. В большом хозяйстве этот долг опасен, потому что устаревший флаг может молча закрывать исправление безопасности или включать непротестированные пути кода в производстве, а человек, создавший его, нередко уже ушёл. Уравновесьте напряжение: флаги купили вам безопасную инкрементальную поставку, поэтому цель не меньше флагов, а дисциплинированный жизненный цикл с владельцем, ожиданием срока годности и инструментами, показывающими устаревшие. Принесите на совещание текущую опись: сколько флагов живо, насколько стар старейший, у каких нет владельца и не функционирует ли какой-либо долгоживущий флаг как постоянная конфигурация, принадлежащая в другом месте. Для регулируемых сред добавьте, кто может менять флаг в производстве и журналируется ли это изменение с той же строгостью, что и развёртывание, поскольку переключение флага это выпуск, даже когда конвейер никогда не запускается.
Где граница между непрерывной поставкой с человеческим барьером и полным непрерывным развёртыванием и кто задаёт пороги отката? Непрерывная поставка оставляет человека в контроле времени выпуска, что подходит законодательным окнам изменений и системам с высоким радиусом поражения, тогда как непрерывное развёртывание отгружает каждое прошедшее изменение автоматически и требует зрелых тестов, наблюдаемости и автоматического отката, чтобы быть безопасным. Для большой или регулируемой организации ответ редко единообразен: ваш маркетинговый сайт может развёртываться непрерывно, пока ядро платежей хранит документированный человеческий барьер, и проведение этой линии по ярусам сервисов предотвращает и ненужное трение, и безрассудную автоматизацию. Конкурирующие соображения скорость и размер партии против контроля и проверяемости плюс инженерная цена метрик здоровья, которых требует автоматический откат. Принесите свидетельства: долю неудачных изменений по сервису, среднее время восстановления, нынешний ритм выпусков и объективные сигналы (доля ошибок, задержка, насыщение), которым вы доверились бы для продвижения или отката без человека. В государственной и корпоративной среде привяжите каждый ярус к тому, кто владеет порогами отката и кто подписывает любой переход от выпуска с барьером к полной автоматизации, чтобы решение было намеренным, а не дрейфующим.

Взгляд по секторам

Стартап. Опирайтесь на управляемый CI/CD с первого дня: размещённый исполнитель, один конвейер, один неизменяемый образ и автоматическое развёртывание в промежуточную среду при слиянии. Не стройте инфраструктуру конвейера, которую потом придётся сопровождать. Флаги функций позволяют двум-трём инженерам безопасно сливать полуготовую работу и отгружать несколько раз в день, а развёртывание в производство в один щелчок плюс быстрое отключение флага это весь контроль изменений, который вам нужен, пока масштаб не потребует большего.

Малый бизнес. Без выделенного платформенного или релиз-инженера отдавайте предпочтение конвейеру, который даёт ваш хост исходного кода (встроенные Actions или эквивалент) и его стратегии развёртывания по умолчанию перед чем-либо заказным. Формулируйте выбор «покупать или строить» честно: управляемый конвейер и платформа хостинга со встроенным откатом стоят меньше человеко-часов, которые съест заказная установка. Сохраняйте существенное: собирать один раз, продвигать тот же артефакт и лёгкий откат, и пропустите механизмы прогрессивной поставки, пока объём этого не оправдает.

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

Государственный сектор. Правила закупок, законодательные окна изменений и публичная подотчётность формируют конвейер. Для значимых систем предпочитайте непрерывную поставку с документированным человеческим барьером выпуска полной автоматизации, классифицируйте рутинную работу как предварительно утверждённые стандартные изменения и держите мгновенный путь отката (сине-зелёный или автоматический канареечный) для сервисов, от которых граждане зависят в узкие годовые окна. Убедитесь, что конвейер записывает, кто утвердил каждое изменение, какие тесты прошли и какой артефакт был развёрнут, так что обязательства прозрачности и аудита выполняются обычным рабочим процессом, а не ручной бумажной работой.

Примеры

Стартап. Стартап SaaS из четырёх человек подключает единый конвейер GitHub Actions, запускающий модульные тесты, собирающий один образ Docker и автоматически развёртывающий этот же образ в промежуточную среду при каждом слиянии в main. Развёртывание в производство в один щелчок, а основатели опираются на флаги функций, чтобы сливать полуготовую работу за флагом вместо поддержания ветки неделями. Когда плохой выпуск проскакивает, они отключают флаг за секунды и спокойно исправляют, что позволяет их крошечной команде отгружать несколько раз в день без выделенного специалиста по эксплуатации.

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

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

Бизнес-обоснование: мотивы, ROI и TCO

Отдача от вложений в CI/CD проявляется как сокращённое время выполнения изменений, меньшая доля неудачных изменений и более быстрое восстановление при инцидентах: метрики, которые исследования последовательно связывают и с эффективностью поставки, и с организационными результатами. Более быстрые, меньшие выпуски сокращают накладные расходы координации, съедающие инженерную мощность в масштабе, а автоматическая проверка сокращает дорогую, подрывающую моральный дух работу по тушению производственных дефектов.

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

Антипаттерны и ловушки

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

Модель зрелости

Уровень 1: Начальный. Сборки и развёртывания в основном ручные, стихийные и реактивные. Интеграция происходит поздно, выпуски редки и стрессовы, откат означает ручное повторное развёртывание старой версии, и нет общего понятия барьера конвейера.

Уровень 2: Развитие. Автоматические сборки и модульные тесты запускаются на каждый коммит, но практики различаются от команды к команде. Развёртывания скриптованы, но по-прежнему запускаются и контролируются вручную, некоторые среды согласованы, а артефакты могут всё ещё пересобираться для каждой стадии. Где конвейер существует, он нередко «снежинка», которую нельзя разделить.

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

Уровень 4: Управление. Поставка измеряется и контролируется относительно базовых значений. Организация отслеживает время выполнения изменений, частоту развёртываний, долю неудачных изменений и среднее время восстановления вместе с длительностью конвейера по p50 и p95, долями ненадёжных тестов и перезапусков и возрастом флагов функций. Пороги отката задаются по наблюдаемым данным доли ошибок, задержки и насыщения, барьеры принуждаются по свидетельствам, а не привычке, и у каждой метрики есть владелец, действующий при её отклонении от цели.

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

Идеи для обсуждения

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

Главные выводы

CI, CD и непрерывное развёртывание различны; выбирайте уровень автоматизации под вашу терпимость к риску и зрелость.
Собирайте артефакт один раз и продвигайте тот же артефакт через каждую среду.
Проектируйте конвейер как упорядоченные барьеры качества, оптимизированные для быстрой обратной связи, и воспринимайте его как авторитетное решение об отгрузке.
Выбирайте стратегии развёртывания намеренно и принимайте прогрессивную поставку с автоматическим откатом, чтобы ограничить радиус поражения.
Разделяйте выпуск и развёртывание флагами функций и управляйте долгом флагов.
В регулируемых средах фиксируйте свидетельства контроля изменений автоматически, а не через ручную бумажную работу.

Источники и дополнительное чтение

Jez Humble and David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps.
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
Gene Kim, Kevin Behr, and George Spafford, The Phoenix Project.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering.
Pete Hodgson, “Feature Toggles (Feature Flags)” (essay).
ITIL (Information Technology Infrastructure Library), change management guidance.

8.1 CI/CD и поставка

Обзор и мотивация

Ключевые принципы

Рекомендации

Проектируйте конвейер как ряд барьеров качества

Собирайте один раз, продвигайте везде

Сделайте конвейер точкой принуждения политики

Держите основную линию готовой к выпуску всегда

Выбирайте стратегии развёртывания намеренно

Принимайте прогрессивную поставку с автоматическим откатом

Обеспечьте управление релизами и контроль изменений для регулируемых сред