Чему меня научили шесть разных организаций о CI/CD

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

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

Первый паттерн: все начинают с одних и тех же потребностей

Независимо от организации, каждой команде нужно три вещи:

• Способ отправлять изменения туда, где пользователи могут к ним получить доступ
• Уверенность, что эти изменения ничего не сломают
• Способ исправлять проблемы, когда они неизбежно возникают

Небольшой стартап удовлетворяет эти потребности простым пайплайном и базовым мониторингом. Регулируемая компания добавляет шаги утверждения и аудиторские следы. SaaS-компания с несколькими командами строит сервисный каталог и golden paths. Мобильная команда внедряет поэтапные развертывания и удаленную конфигурацию. Команда, работающая с устаревшими базами данных, создает безопасные стратегии миграции. Инфраструктурная команда добавляет управление для infrastructure-as-code и обнаружение дрейфа.

Это не разные подходы. Это одни и те же ответы на одни и те же вопросы, просто с разным уровнем сложности.

Второй паттерн: риск определяет, сколько безопасности вам нужно

Чем больше последствия ошибки, тем больше средств защиты вы добавляете.

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

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

Третий паттерн: автоматизация — это не цель

Автоматизация — это инструмент для сокращения повторяющейся ручной работы. Никто не автоматизирует ради самой автоматизации.

Стартап автоматизирует развертывание, потому что устал заходить на серверы каждый раз. Регулируемая компания автоматизирует аудиторские следы, потому что вручную записывать каждое решение невозможно. SaaS-компания автоматизирует golden paths, потому что не может обучать каждую новую команду с нуля. Мобильная команда автоматизирует поэтапные развертывания, потому что управлять тысячами устройств по одному нереально. Команда с устаревшими базами данных автоматизирует миграции, потому что ручные изменения слишком рискованны. Инфраструктурная команда автоматизирует обнаружение дрейфа, потому что проверять инфраструктуру вручную в масштабе непрактично.

Автоматизация решает конкретную боль. Если у вас еще нет этой боли, пока не автоматизируйте.

С чего начинает каждая организация

Разница не в том, что они в итоге строят. Разница в том, с чего они начинают и что ставят в приоритет в первую очередь.

Стартап начинает с максимально простого пайплайна. Он добавляет средства защиты только тогда, когда что-то начинает болеть.

Регулируемая компания начинает с соответствия требованиям. Затем она выясняет, как ускорить процесс, не теряя соответствия.

SaaS-компания с несколькими командами начинает с согласованности между командами. Затем она добавляет гибкость в согласованных границах.

Мобильная команда начинает с контроля распространения. Затем она строит наблюдаемость для мониторинга эффектов своих релизов.

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

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

Как применить это к вашей команде

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

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

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

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

Краткий практический чеклист

Прежде чем проектировать следующий пайплайн или добавлять очередной инструмент, задайте эти вопросы:

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

Конкретный вывод

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