Стандартизированный CI/CD: единый пайплайн, но слишком много ручной работы

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

Это Уровень 2 в модели зрелости CI/CD: Стандартизированный. Ваша организация перешла от хаоса, где каждый делал что-то своё. Появился общий пайплайн. Есть единообразие. Но всё ещё много ручной работы, которая замедляет доставку.

Как выглядит стандартизация

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

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

Диаграмма ниже показывает типичный поток пайплайна на этом уровне, где ручные шаги выделены красным.

flowchart TD A[Commit] --> B[Build] B --> C[Automated Tests] C --> D[Deploy to Staging] D --> E{Manual QA} E -->|fail| C E -->|pass| F{Manual Approval} F -->|deny| G[Change Rejected] F -->|approve| H{Manual Deploy to Prod} H --> I[Production] style E fill:#f99,stroke:#333,stroke-width:2px style F fill:#f99,stroke:#333,stroke-width:2px style H fill:#f99,stroke:#333,stroke-width:2px

Узкое место утверждений

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

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

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

Ручное тестирование всё ещё существует

Ещё один признак Стандартизированного уровня — не всё тестирование автоматизировано. Модульные тесты и интеграционные тесты могут выполняться в пайплайне. Но для определённых сценариев QA всё ещё нужно зайти в стейджинг, вручную пройти тест-кейсы и написать отчёт.

Это создаёт цикл. Разработчик пушит изменение. Автоматические тесты проходят. Но QA должен вручную проверить функциональность. Если они находят проблему, изменение возвращается разработчику. Разработчик исправляет, пушит снова, и QA повторяет ручное тестирование. Каждая итерация занимает время.

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

Развёртывание всё ещё ручной шаг

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

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

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

Документация есть, но полезна ли она?

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

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

Хорошая сторона: единообразие

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

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

Плохая сторона: всё ещё медленно

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

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

Практический чеклист для Уровня 2

Если вы на этом уровне, вот что стоит проверить:

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

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

Следующий шаг: самообслуживание

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

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

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

Вывод

Стандартизированный пайплайн — хорошее начало, но это не финишная черта. Если у вашей команды есть общий пайплайн, но вы всё ещё боретесь с медленными утверждениями, ручным тестированием и плановыми развёртываниями, вы на Уровне 2. Пайплайн готов. Процесс — нет. Теперь задача — убрать ручные шаги, которые замедляют вашу доставку.