Настраиваем конвейер на GitLab CI или Jenkins, поднимаем хранилище артефактов Nexus и секретов Vault. Изменение кода превращается в собранную и проверенную версию, а выкладка на тестовый и рабочий контуры происходит без ручных шагов. Если что-то пошло не так, система возвращается к предыдущей версии, а не восстанавливается из резервной копии.
Ручное обновление выглядит безобидно, пока шагов немного. Потом оказывается, что нужно собрать проект, скопировать файлы, не забыть про миграцию базы, перезапустить службу в правильном порядке и поменять один параметр в конфигурации — а помнит всё это один человек. Стоит ему уйти в отпуск, и обновление откладывается. Стоит ошибиться в порядке шагов — и система лежит, пока идёт восстановление.
Конвейер превращает эту последовательность в код: те же самые действия выполняются одинаково каждый раз, в любое время и любым участником команды. Релиз перестаёт быть событием, ручные ошибки исчезают вместе с ручными шагами, а возврат к предыдущей версии становится обычной операцией, а не спасательной работой.
При изменении кода проект собирается сам: зависимости подтягиваются, артефакт или образ контейнера формируется и помечается версией. Сборка на машине разработчика перестаёт отличаться от рабочей.
Каждая версия воспроизводима и хранится в реестре.
Прогоняем то, что есть: автоматические тесты, проверку стиля кода, сборку без ошибок, поиск известных уязвимостей в зависимостях. Не прошло — дальше по конвейеру не идёт.
Если тестов нет, начинаем хотя бы с проверки успешной сборки.
Разделяем среды: разработка, тестирование, рабочая система. На тестовый контур выкладка идёт автоматически, на рабочий — по подтверждению ответственного.
Проверять обновление на живых данных — плохая идея.
Настраиваем поэтапное обновление с проверкой работоспособности и автоматический возврат к предыдущей версии, если проверка не прошла. Откат — часть процедуры, а не аварийный сценарий.
Возможность вернуться проверяем до первого рабочего релиза.
Выносим пароли, ключи и строки подключения из репозитория в защищённое хранилище. Конвейер подставляет значения при выкладке, разработчик видит только имя переменной.
Смена пароля перестаёт требовать пересборки приложения.
Включаем в конвейер обновление структуры базы: изменения применяются в заданном порядке, перед этим снимается резервная копия, а сами миграции пишутся совместимыми с прошлой версией.
Самая частая причина невозможного отката — необратимая миграция.
Автоматизация меняет не столько скорость, сколько предсказуемость. Ниже привычные ситуации до и после настройки конвейера.
| Ситуация | Ручная выкладка | С конвейером |
|---|---|---|
| Обновление рабочей системы | Последовательность шагов по памяти или по документу, который давно не обновляли | Одна процедура, описанная кодом и выполняемая одинаково каждый раз |
| Что-то сломалось после релиза | Разбор на живой системе, при неудаче — восстановление из резервной копии | Возврат к предыдущей версии как штатное действие конвейера |
| Проверка изменений | Смотрят на рабочей системе, потому что тестовая отличается | Тестовый контур поднимается из того же артефакта, что и рабочий |
| Кто может выложить | Один человек, который знает все настройки | Любой участник с правами, действия фиксируются в истории |
| Пароли и ключи | Лежат в конфигурации рядом с кодом или передаются в переписке | Хранятся отдельно, подставляются при выкладке, доступ разграничен |
| Что именно сейчас работает | Определяется по датам файлов на сервере | Видно версию, автора изменений и время выкладки |
Отдельная польза, о которой редко говорят: конвейер документирует процесс сам по себе. Чтобы понять, как система попадает на сервер, достаточно прочитать его описание в репозитории.
Выкладка делается вручную, тестового контура нет. Начинаем с описания текущих шагов в виде скрипта, добавляем сборку и выкладку на тестовую среду, затем на рабочую по подтверждению.
Конвейер есть, но половина шагов всё равно делается руками, а откат не проверялся ни разу. Разбираем, что мешает, и доводим процесс до состояния, в котором ему можно доверять.
Приложение делал подрядчик, а обновлять его приходится вам. Описываем развёртывание, поднимаем тестовый контур и добавляем резервную копию с проверкой перед каждым обновлением.
Если систему разрабатываем мы, конвейер появляется в проекте с первых недель: контуры готовы раньше, чем первая версия, и релизы идут через них с самого начала.
Контейнеры, из которых одинаково поднимаются тестовый и рабочий контуры.
Подробнее →
Проверка после релиза и логи, по которым видно, что пошло не так.
Подробнее →
Сервисы и порталы, которые мы сразу проектируем под автоматическую выкладку.
Подробнее →Да. Даже без тестов автоматизация убирает главный источник проблем — расхождение в ручных шагах. Начинаем с воспроизводимой сборки, выкладки на тестовый контур и проверки того, что сервис поднялся и отвечает. Тесты можно добавлять постепенно, начиная с самых важных сценариев, и конвейер к этому уже готов.
Обычно тот, что уже есть у команды: встроенные конвейеры системы контроля версий или отдельный сервер сборки. Менять инструмент ради инструмента смысла нет — важнее описать процесс. Если выбора ещё не было, предлагаем вариант, который вы сможете обслуживать сами, а не только мы.
Только если вы этого хотите. Чаще делаем так: на тестовый контур обновление уходит автоматически при каждом изменении, а на рабочий — по подтверждению ответственного. Сама процедура при этом одинаковая, разница лишь в том, кто нажимает кнопку и когда.
Конвейер проверяет, поднялась ли новая версия и отвечает ли сервис. Если проверка не прошла, обновление отменяется и возвращается предыдущая версия — она хранится готовой к запуску. Дальше разбираемся спокойно, по логам, а не в режиме аварии на работающей системе.
Отдельные физические серверы — нет. Обычно достаточно виртуальных машин на существующем оборудовании или на нашей инфраструктуре: тестовая среда нагружена слабее рабочей. Важно другое — чтобы состав сервисов и версии совпадали, иначе проверка теряет смысл.
Да, это частая задача. Разбираемся, из чего состоит система и как она запускается, описываем развёртывание, поднимаем тестовый контур и добавляем резервную копию перед обновлением. Если внутри есть решения, которые мешают автоматизации, скажем об этом прямо и предложим, что можно сделать без переписывания.
Расскажите, как сейчас обновляется система и что чаще всего идёт не так. Разберём процесс и предложим, с чего начать — обычно это проще и дешевле, чем кажется.
Конвейер сборки и выкладки — инструмент простой по идее и требовательный к дисциплине. Он даёт результат, когда команда договорилась о правилах, и почти не даёт, когда правила есть, но их обходят «в порядке исключения».
Первый шаг — не выбор инструмента, а описание текущего процесса. Мы садимся и по шагам разбираем, что происходит от изменения кода до работающей системы. Обычно уже на этом этапе находятся вещи, о которых знал один человек: параметр, который меняют вручную, служба, которую нужно перезапустить второй, файл, который не попадает в сборку. Конвейер потом просто закрепляет то, что стало понятным.
Мы всегда настраиваем и проверяем возврат к предыдущей версии до того, как через конвейер пойдёт первый рабочий релиз. Причина простая: пока откат не проверен на практике, он существует только в теории, и убеждаться в этом в момент аварии — дорого. Отдельно смотрим на изменения в базе данных: необратимая миграция превращает откат приложения в бессмысленную операцию, поэтому такие изменения планируются совместимыми с обеими версиями.
Тестовая среда, собранная «примерно так же», создаёт ложную уверенность. Проверка проходит успешно, а на рабочей системе всплывает разница в версии библиотеки или в настройке сервера. Поэтому контуры мы поднимаем из одних и тех же артефактов, а различия сводим к данным и доступам. Проще всего это делается на контейнерах, но достижимо и без них — просто требует аккуратности.
Пароли, ключи и строки подключения в коде — привычная и опасная практика: они попадают в историю изменений, копируются вместе с проектом и остаются доступными всем, кто когда-либо имел к нему отношение. Правильная схема проще, чем кажется: значения лежат в защищённом хранилище, конвейер подставляет их при выкладке, у тестовой и рабочей среды они разные. Заодно появляется возможность сменить пароль, не трогая код.
Автоматический релиз ускоряет доставку изменений, в том числе неудачных. Поэтому конвейер имеет смысл только вместе с мониторингом: после обновления система проверяет, что сервис отвечает и ошибок не прибавилось, а команда видит состояние в реальном времени. Если проверка не проходит, выкладка отменяется автоматически, не дожидаясь звонков пользователей.
Сборка требует ресурсов, артефакты — хранилища, контуры — серверов и разграниченного доступа. Мы готовим эту часть в том же проекте: виртуальные машины, реестр артефактов, права, резервные копии и защищённое подключение для администрирования. Дальше конвейер можно вести самим или передать нам вместе с сопровождением.
