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