Что мы построили вместе: практическое понимание CI/CD

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

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

Этот пост описывает фундамент, который мы построили вместе в книге. Это не пересказ глав. Это карта того, как части соединяются, когда вы перестаёте относиться к CI/CD как к инструменту и начинаете воспринимать его как возможность.

Начните с деплоя, а не с пайплайна

Прежде чем автоматизировать что-либо, нужно понять, что на самом деле означает деплой. Деплой — это размещение новой версии чего-либо в среде, где пользователи могут до неё добраться. Звучит очевидно, но последствия — нет.

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

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

Диаграмма ниже показывает три параллельных трека и рекомендуемые стратегии:

flowchart TD subgraph Application A1[New Version] --> A2[Blue-Green Deploy] A2 --> A3[Switch Traffic] A3 --> A4[Rollback if needed] end subgraph Database D1[Change] --> D2[Gradual Migration] D2 --> D3[Small Reversible Steps] D3 --> D4[Rollback Scripts] end subgraph Infrastructure I1[Config Change] --> I2[Immutable Replace] I2 --> I3[Replace Entire Environment] I3 --> I4[No Patching] end A1 -.->|different strategies| D1 D1 -.->|different strategies| I1

Смысл не в том, чтобы запомнить эти стратегии. Смысл в том, чтобы осознать: деплой — это не единое действие. Это набор решений о том, как безопасно перемещать изменения, и эти решения зависят от того, что вы перемещаете.

Пайплайн как контракт, а не скрипт

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

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

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

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

Деплой — это не релиз

Одно из самых полезных различий в книге — разделение деплоя и релиза.

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

Это разделение позволяет использовать такие стратегии, как feature flags, canary releases и progressive delivery. Feature flags позволяют включать и выключать функциональность без повторного деплоя. Canary releases отправляют небольшой процент трафика на новую версию сначала. Progressive delivery постепенно увеличивает этот процент по мере наблюдения за метриками.

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

Platform Engineering как ускоритель

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

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

Ключевая идея здесь в том, что platform engineering — это не построение идеальной абстракции. Это снижение когнитивной нагрузки на команды, чтобы они могли сосредоточиться на доставке ценности. Если команда тратит два дня на настройку пайплайна, платформа не работает. Если они могут запустить новый сервис одним pull request'ом — платформа работает.

Управление как направляющие, а не шлагбаумы

Управление (governance) часто понимают неправильно — как слой, который замедляет работу. На практике управление в CI/CD — это установка границ, которые позволяют командам двигаться быстро, не ломая ничего.

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

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

Практический чеклист

Если вы строите CI/CD-возможности в своей организации, вот короткий чеклист для принятия решений:

  • Можете ли вы развернуть изменение в продакшн без ручных шагов?
  • Можете ли вы откатить деплой менее чем за пять минут?
  • Знаете ли вы разницу между стратегией деплоя и стратегией релиза?
  • Проходит ли каждое изменение одни и те же проверки, независимо от того, кто его сделал?
  • Может ли новый член команды развернуть своё первое изменение в первый день без запроса разрешений?
  • Есть ли у вас способ тестировать миграции базы данных до того, как они попадут в продакшн?
  • Рассматривается ли ваша инфраструктура как код, а не как снежинка-сервер?

Если вы ответили «нет» на любой из этих вопросов, вы знаете, на чём сосредоточиться дальше.

CI/CD — это возможность, которую нужно поддерживать

Самый важный урок из этого путешествия: CI/CD — это не проект, который вы завершаете. Это возможность, которую вы поддерживаете. Инструменты меняются. Команды растут. Требования сдвигаются. Практики, которые работают сегодня, могут не работать в следующем году.

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

Начните с одного изменения. Сделайте его безопасным. Затем сделайте его повторяемым. Затем сделайте его быстрым. Остальное последует.