Начните с одного небольшого изменения завтра утром
Вы только что прочитали о CI/CD, пайплайнах доставки, внутренних платформах и непрерывном улучшении. Звучит отлично. Но когда вы смотрите на свою команду, разрыв между прочитанным и тем, что вы делаете на самом деле, кажется огромным.
Возможно, ваш процесс сборки до сих пор запускается на ноутбуке разработчика. Возможно, ваш чек-лист релиза хранится в чьей-то голове. Возможно, ваше стейджинг-окружение настолько далеко от production, что деплой ощущается как игра в рулетку. Возможно, у вас вообще нет команды — только вы и идея.
Этот разрыв нормален. Каждая команда, которая сейчас стабильно поставляет изменения, начинала именно там, где вы. Они не проснулись однажды утром с идеальным пайплайном, который деплоит десять раз в день с нулевым количеством сбоев. Они строили его по одному небольшому изменению за раз.
Настоящая отправная точка
У большинства команд нет проблемы с доставкой, требующей глобального редизайна. У них есть один шаг в текущем процессе, который причиняет больше всего боли. С этого шага и нужно начинать.
Посмотрите, как ваша команда поставляет изменения сегодня. От момента, когда кто-то пишет код, до момента, когда пользователи начинают использовать новую версию, перечислите каждый шаг. Будьте честны о том, что происходит на самом деле, а не о том, что должно происходить.
- Кто запускает сборку?
- Как вы узнаете, что сборка прошла успешно?
- Что происходит, если тест падает?
- Кто решает, что деплоить безопасно?
- Как вы на самом деле выкатываете новую версию в production?
- Как вы узнаете, что она работает, после того как она там?
Где-то в этом списке есть шаг, который зависит от того, что один человек не забудет что-то сделать. Где-то есть шаг, который невозможно повторить дважды одинаково. Где-то есть шаг, который заставляет людей нервничать перед каждым релизом.
Выберите этот шаг. Всего один.
Как выглядит одно изменение
Допустим, сборка все еще запускается на машине разработчика. Когда этот разработчик в отпуске, никто не может собрать проект. Когда они используют немного другую версию библиотеки, сборка ведет себя иначе. Когда у их ноутбука разряжается батарея в середине сборки, команда ждет.
Вот минимальный пример того, как может выглядеть такой скрипт:
#!/bin/bash
set -e
echo "Клонирование репозитория..."
git clone https://github.com/your-org/your-app.git
cd your-app
echo "Установка зависимостей..."
npm install
echo "Запуск сборки..."
npm run build
echo "Сборка выполнена успешно!"
Сохраните это как build.sh, добавьте в ваш репозиторий и запускайте с общего сервера или CI-сервиса. Теперь любой может запустить воспроизводимую сборку.
Одно изменение: перенесите эту сборку на общий сервер или простой CI-сервис. Не обязательно что-то навороченное. Один скрипт, который забирает код, запускает сборку и сообщает об успехе или неудаче, уже лучше, чем сборка на ноутбуке. Теперь любой может ее запустить. Теперь результат виден всем. Теперь сборка воспроизводима.
Или, возможно, проблема в другом. Возможно, сборка автоматизирована, но деплой все еще представляет собой ручную последовательность SSH-команд, которые знает только один человек. Одно изменение: запишите эти команды в скрипт, добавьте в репозиторий и запускайте из CI-системы. Теперь деплой документирован, воспроизводим и больше не зависит от памяти.
Или, возможно, проблема в том, что стейджинг никогда не соответствует production. Одно изменение: используйте один и тот же скрипт деплоя для обоих окружений. Если скрипт работает на стейджинге, но падает на production, разница между окружениями становится видимой и исправимой.
Ни одно из этих изменений не требует новой платформенной команды. Ни одно не требует покупки дорогих инструментов. Ни одно не требует, чтобы все согласовали полный рабочий процесс. Они просто требуют выбрать один болезненный шаг и сделать его немного лучше.
Эффект снежного кома
Вот что происходит после этого первого изменения: вы это чувствуете. Следующий релиз становится чуть менее стрессовым. Следующая сборка не требует сообщения в Slack с вопросом, у кого подходящий ноутбук. Следующий деплой не требует демонстрации экрана, чтобы кто-то мог наблюдать за вводом команд.
Это чувство заставляет вас захотеть исправить следующий шаг. И следующий. Не потому, что вам кто-то сказал, а потому, что вы попробовали, каково это, когда часть процесса доставки становится предсказуемой. Вы хотите больше этого.
Именно так происходит реальное внедрение CI/CD. Не через грандиозный план. Не через шестимесячную миграцию платформы. Через серию небольших, практических улучшений, которые накапливаются со временем.
Быстрый способ найти свой первый шаг
Прежде чем закрыть эту статью, сделайте следующее:
- Откройте репозиторий вашего приложения.
- Запишите каждый шаг от коммита кода до деплоя в production так, как это происходит на самом деле сегодня.
- Отметьте шаг, который причиняет больше всего боли — тот, который чаще всего дает сбой, занимает больше всего времени или сильнее всего зависит от неписаных знаний.
- Решите, что конкретно вы можете сделать завтра, чтобы сделать этот шаг немного лучше. Не идеально. Лучше.
Это ваша отправная точка.
Что такое CI/CD на самом деле
После всех глав, диаграмм и обсуждений пайплайнов, платформ и управления, вот основная истина: CI/CD — это не об инструментах. Это не о том, чтобы иметь идеальную диаграмму пайплайна. Это не о том, чтобы соответствовать тому, что делает FAANG-компания.
CI/CD — это способность вашей организации продолжать поставлять изменения — в код приложения, схемы базы данных и инфраструктуру — безопасно и постоянно улучшать этот процесс с каждой поставкой.
Эту способность нельзя купить. Ее нельзя установить. Ее нельзя настроить консультантом за две недели. Она строится, одно небольшое изменение за раз, людьми, которые решают, что сегодняшний релиз будет чуть менее болезненным, чем вчерашний.
Начните завтра утром. Выберите один шаг. Сделайте его лучше. И повторите.