Ваш первый шаг в CI/CD: что сделать завтра утром

Вы прочитали об уровнях зрелости CI/CD. Вы понимаете теорию. Теперь вы сидите за столом и думаете, что делать в понедельник утром. Ответ — не устанавливать инструмент и не перепроектировать весь пайплайн. Ответ гораздо проще.

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

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

Найдите болевую точку

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

Вот пример того, как может выглядеть такой поток для типичной команды:

flowchart TD A[Ноутбук разработчика] -->|ручной push| B[Репозиторий кода] B -->|ручная сборка| C[Сборочный сервер] C -->|ручной деплой| D[Staging] D -->|ручное тестирование| E{Успешно?} E -->|да| F[Production] E -->|нет| A style C fill:#f96,stroke:#333 style D fill:#f96,stroke:#333

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

Напишите чек-лист релиза

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

  • Что должно быть проверено перед выходом новой версии?
  • Как это проверить?
  • Что делать, если что-то пошло не так?

Держите его коротким. Хороший чек-лист для небольшой команды может выглядеть так:

  • Новая версия прошла базовые тесты?
  • База данных готова к изменениям?
  • Мы сообщили об изменениях другим командам?
  • Мы знаем, как откатиться, если что-то сломается?

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

Назначьте одного ответственного за релиз

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

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

Почему эти маленькие шаги важны

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

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

Эти шаги также формируют привычку думать о доставке как о процессе. Многие команды сразу прыгают к инструментам. Они устанавливают Jenkins или GitHub Actions и начинают строить пайплайны, не понимая текущего потока. Результат — автоматизация, которая зеркалирует сломанные процессы. Сборки работают быстрее, но релизы всё равно проваливаются, потому что никто не проверил миграцию базы данных.

Начав с потока и чек-листа, вы автоматизируете правильные вещи. Вы автоматизируете проверки, которые имеют значение, а не те, которые легко заскриптовать.

Что дальше

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

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

Так CI/CD растет органически. Он начинается с понимания текущего процесса, а не с установки инструмента. Он начинается с чек-листа, а не с конфигурации пайплайна. Он начинается с одного ответственного человека, а не с команды платформенных инженеров.

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

Завтра утром сделайте три вещи:

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

Это ваш первый шаг. Он ничего не стоит. Он занимает один час. И он дает вам фундамент, который не заменит ни один инструмент.