Долгое время я относился к автоматизации сборки и деплоя примерно как к ремонту в съёмной квартире: вроде и надо, но жалко времени, ведь и так всё работает. Работало оно, правда, ровно до того момента, пока в пятницу вечером я не забыл скопировать на прод один конфиг. Полтора часа ругани, откат вручную, холодный чай и твёрдое решение, что больше так не живу. Именно тогда я начал разбираться с CI/CD, и, честно говоря, до сих пор жалею, что не сделал этого двумя годами раньше.
Опишу точку, из которой я стартовал, потому что уверен, что многие узнают себя. Сборка проекта запускалась у меня на ноутбуке командой, которую я держал в заметках и иногда путал. Тесты гонялись в лучшем случае перед релизом, а в худшем — уже после него, когда пользователи присылали скриншоты с ошибками. Деплой состоял из последовательности ручных шагов: залить архив по FTP, распаковать, не забыть про миграции, обновить переменные окружения, почистить кэш. Каждый шаг был маленькой лотереей, а каждый деплой — источником тревоги. Я всерьёз планировал рабочий день вокруг выкладки версии и старался не делать её позже шести вечера.
Первый пайплайн я собрал максимально примитивный, и это было правильное решение. Всего три шага: установка зависимостей, прогон тестов, сборка артефакта. Никаких деплоев, никаких окружений, никаких секретов. Просто чтобы на каждый push в репозиторий у меня появлялся отчёт, что код в принципе живой. Заняло это один вечер, и уже на следующий день пайплайн поймал ошибку, которую я бы точно пропустил глазами. После этого включать автоматический деплой на тестовый стенд было уже не страшно, а почти приятно.
Дальше пошло по накатанной. Сначала в пайплайн переехали линтеры и проверка типов, потом я добавил сборку контейнерного образа, затем автоматический деплой на стейджинг и только через пару месяцев, когда научился доверять системе, на продакшен с ручным подтверждением. Отдельная радость — секреты, которые перестали жить в чужих конфигах и чьих-то переписках: они просто лежат в защищённом хранилище и подставляются на нужном шаге.
Теперь про цифры, ради которых всё затевалось. Раньше на рутинные операции вокруг кода — сборку, прогон тестов, выкладку, разбор последствий кривых деплоев — у меня уходило от двенадцати часов в неделю, причём часть этого времени приходилась на вечера и выходные. Сейчас на то же самое уходит полтора-два часа, и это в основном просмотр результатов и решение по выпуску. Освободившиеся десять часов я честно потратил не на новые задачи, а на нормальный сон и чтение кода коллег, и именно это, кажется, дало больше всего пользы проекту.
Если вы только думаете начинать, вот что я советую по своему опыту. Начинайте с самого скучного и короткого пайплайна, буквально из двух-трёх шагов, и не пытайтесь сразу нарисовать идеальную архитектуру доставки. Сделайте так, чтобы пайплайн работал быстро: если он бежит двадцать минут, вы начнёте его игнорировать, а если три минуты, будете запускать по любому поводу. Заведите привычку никогда не обходить пайплайн вручную, даже когда очень хочется выпустить мелкую правку в обход, потому что одно исключение легко превращается в десять. И обязательно сделайте откат таким же автоматическим, как деплой, иначе первый же неудачный релиз вернёт вас к ручному копированию файлов по ночам. И не бойтесь начинать без модных инструментов: даже простейшая связка из репозитория и запуска скрипта по коммиту уже меняет жизнь.
Главный вывод для меня оказался не техническим, а психологическим. CI/CD не про экономию минут на командах, он про исчезновение страха перед выпуском. Когда деплой становится скучной фоновой операцией, а не событием с замиранием сердца, ты начинаешь выпускать чаще, мельче и спокойнее, и код от этого почему-то становится лучше. Странно, но факт: я стал программировать больше именно после того, как перестал вручную таскать архивы на сервер.
А расскажите, как было у вас? Что вас подтолкнуло заняться автоматизацией, какие первые шаги в пайплайне дали самую ощутимую экономию времени и что из этой затеи оказалось сложнее всего? Буду рад почитать ваши истории, особенно удачные провалы, они обычно полезнее глянцевых успехов.
Опишу точку, из которой я стартовал, потому что уверен, что многие узнают себя. Сборка проекта запускалась у меня на ноутбуке командой, которую я держал в заметках и иногда путал. Тесты гонялись в лучшем случае перед релизом, а в худшем — уже после него, когда пользователи присылали скриншоты с ошибками. Деплой состоял из последовательности ручных шагов: залить архив по FTP, распаковать, не забыть про миграции, обновить переменные окружения, почистить кэш. Каждый шаг был маленькой лотереей, а каждый деплой — источником тревоги. Я всерьёз планировал рабочий день вокруг выкладки версии и старался не делать её позже шести вечера.
Первый пайплайн я собрал максимально примитивный, и это было правильное решение. Всего три шага: установка зависимостей, прогон тестов, сборка артефакта. Никаких деплоев, никаких окружений, никаких секретов. Просто чтобы на каждый push в репозиторий у меня появлялся отчёт, что код в принципе живой. Заняло это один вечер, и уже на следующий день пайплайн поймал ошибку, которую я бы точно пропустил глазами. После этого включать автоматический деплой на тестовый стенд было уже не страшно, а почти приятно.
Дальше пошло по накатанной. Сначала в пайплайн переехали линтеры и проверка типов, потом я добавил сборку контейнерного образа, затем автоматический деплой на стейджинг и только через пару месяцев, когда научился доверять системе, на продакшен с ручным подтверждением. Отдельная радость — секреты, которые перестали жить в чужих конфигах и чьих-то переписках: они просто лежат в защищённом хранилище и подставляются на нужном шаге.
Теперь про цифры, ради которых всё затевалось. Раньше на рутинные операции вокруг кода — сборку, прогон тестов, выкладку, разбор последствий кривых деплоев — у меня уходило от двенадцати часов в неделю, причём часть этого времени приходилась на вечера и выходные. Сейчас на то же самое уходит полтора-два часа, и это в основном просмотр результатов и решение по выпуску. Освободившиеся десять часов я честно потратил не на новые задачи, а на нормальный сон и чтение кода коллег, и именно это, кажется, дало больше всего пользы проекту.
Если вы только думаете начинать, вот что я советую по своему опыту. Начинайте с самого скучного и короткого пайплайна, буквально из двух-трёх шагов, и не пытайтесь сразу нарисовать идеальную архитектуру доставки. Сделайте так, чтобы пайплайн работал быстро: если он бежит двадцать минут, вы начнёте его игнорировать, а если три минуты, будете запускать по любому поводу. Заведите привычку никогда не обходить пайплайн вручную, даже когда очень хочется выпустить мелкую правку в обход, потому что одно исключение легко превращается в десять. И обязательно сделайте откат таким же автоматическим, как деплой, иначе первый же неудачный релиз вернёт вас к ручному копированию файлов по ночам. И не бойтесь начинать без модных инструментов: даже простейшая связка из репозитория и запуска скрипта по коммиту уже меняет жизнь.
Главный вывод для меня оказался не техническим, а психологическим. CI/CD не про экономию минут на командах, он про исчезновение страха перед выпуском. Когда деплой становится скучной фоновой операцией, а не событием с замиранием сердца, ты начинаешь выпускать чаще, мельче и спокойнее, и код от этого почему-то становится лучше. Странно, но факт: я стал программировать больше именно после того, как перестал вручную таскать архивы на сервер.
А расскажите, как было у вас? Что вас подтолкнуло заняться автоматизацией, какие первые шаги в пайплайне дали самую ощутимую экономию времени и что из этой затеи оказалось сложнее всего? Буду рад почитать ваши истории, особенно удачные провалы, они обычно полезнее глянцевых успехов.