Почему не стоит пытаться построить всё сразу

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

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

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

Это называется "большим взрывом" (big bang transformation). Название звучит монументально, но на практике это обычно заканчивается провалом. Слишком много вещей меняется одновременно. Слишком много переменных выходит из-под контроля. И когда что-то ломается, никто не знает, где искать, потому что всё новое.

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

Разница между этими двумя путями очевидна, если посмотреть на них рядом:

Почему постепенный подход работает лучше, чем "большой взрыв"

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

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

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

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

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

Как найти свой первый шаг

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

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

Вот несколько распространённых отправных точек:

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

Ключ в том, чтобы выбрать что-то достаточно маленькое, чтобы завершить за разумное время, но достаточно значимое, чтобы команда почувствовала улучшение.

Как выглядит типичный постепенный план

Постепенный план не означает, что вы планируете каждый шаг заранее. Это означает, что вы знаете своё направление и делаете один шаг за раз.

Типичная последовательность может выглядеть так:

1. Автоматизируйте сборку и развёртывание одного приложения. Всё остальное оставьте вручную.
2. Добавьте автоматизированные тесты для наиболее критичных путей этого приложения.
3. Расширьте пайплайн, включив в него миграции базы данных для этого приложения.
4. Примените тот же шаблон ко второму приложению, внося коррективы на основе полученного опыта.
5. Постепенно перенесите предоставление инфраструктуры в пайплайн.
6. Добавьте возможности мониторинга и отката.
7. Расширьте на остальные приложения.

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

Практический чек-лист для первого шага

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

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

Если вы можете ответить "да" на эти вопросы, вы готовы начать. Если нет, потратьте время на уточнение этих моментов.

Вывод

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