Одна большая боль нашего милого IT-рынка — релизы. Выкатываем новые фичи, а где-то в другом месте что-то отваливается.

Сегодня я не буду обсуждать мониторинг, тестирование или организацию процессов. Хочу сделать исторический экскурс — как за последние двадцать лет менялись системы релизов, и почему каждая новая итерация рождалась из боли.

1990-е – начало 2000-х. FTP и SSH

На заре всё было просто: есть сервер, есть доступ по FTP или SSH, и есть код, который надо «просто закинуть». Мы так делали. И вы так делали. Ошибки? Они уже на продакшене.

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

Особенности времени: никаких веток кода, никаких тестовых окружений, всё «боевое». Код в проде менялся в реальном времени, и правка одной строки в файле могла как починить баг, так и положить весь проект.

2000-е. CVS, SVN и «релизы по кнопке»

Когда команды подросли, стало понятно: хаос с FTP убивает проект. Пришли системы контроля версий. Сначала CVS, потом Subversion (SVN).

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

Проблемы? Конфликты кода при слиянии веток, разъехавшиеся окружения «у меня работает — на сервере нет» и ночные выкладки с кофе и пиццей.

2005–2010. Git и первые шаги CI/CD

Git родился в 2005 году, но в массовое использование в компаниях пришёл только к началу 2010-х, когда GitHub и GitLab сделали его доступным. Вместе с ним пришла мода на CI/CD — автоматическую сборку и деплой после коммита.

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

2010-е. Blue-green deployment

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

Плюсы: минимальные простои, безопасный откат. Минусы: нужна двойная инфраструктура, а значит, удвоенные расходы. Для стартапа — дорого, для крупной компании — must have.

Середина 2010-х. Канареечные релизы и feature flags

Канареечный релиз — когда новая фича выкатывается сначала на 1–5% пользователей. Если всё ок — увеличиваем процент, пока не получат все. Если нет — тихо откатываем, и никто, кроме «канареек», не заметил.

Вместе с этим в моду вошли feature flags — фичи выкатываются заранее, но выключены конфигом до нужного момента. Это позволяло тестировать код в продакшене без полного релиза и быстро включать/выключать функционал.

Сейчас. Progressive delivery, GitOps и «релизы без страха»

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

Progressive delivery — логичное развитие канарейки. Здесь идея в том, что релиз — это не момент, а процесс. Выкатываем обновление сначала на минимальную аудиторию, мониторим метрики (ошибки, время отклика, конверсии), и только после зелёных сигналов расширяем охват. Иногда это делается волнами: сначала внутренняя команда, потом 1%, потом 10%, 50% и только после этого 100%. Такой подход особенно ценен для продуктов с большой базой пользователей, где ошибка на продакшене стоит дорого — как в деньгах, так и в репутации.

Feature flags в 2020-е стали обязательным инструментом в арсенале. Они позволяют выкатывать код заранее, но держать фичу выключенной до нужного момента. Это удобно, если нужно «открыть» функционал к определённой дате, тестировать разные варианты интерфейса на живой аудитории или быстро реагировать на сбои — просто выключив флаг вместо отката целого релиза.

GitOps закрыл старую проблему «инфраструктура живёт отдельно от кода». Теперь и код, и конфигурация серверов, и пайплайны сборки лежат в одном репозитории. Любое изменение — через pull-реквест, с автоматической проверкой и прозрачной историей. Это упростило повторяемость окружений и сделало релизы более предсказуемыми. А в связке с Kubernetes, Terraform и ArgoCD всё стало максимально автоматизировано: пушишь изменения в репозиторий, и система сама раскатывает их на нужные окружения.

Релизы без страха — идеал, к которому все идут. Но правда в том, что даже с progressive delivery и GitOps проблемы всё равно бывают. Просто теперь они реже, их проще локализовать и быстрее откатывать. И да, ночных выкладок «все в офисе, пока не починим» стало заметно меньше. А значит, можно не только быстрее выкатывать продукт, но и жить в чуть более человеческом ритме.

Итог

Любой из этих методов может работать. Где-то старые схемы дешевле и проще, где-то без канареек и blue-green нельзя.

Мы для своих проектов остановились на Git с CI/CD — это наш компромисс между скоростью, безопасностью и экономикой. Он не решает все проблемы, но заметно снижает их количество и позволяет спать ночью, а не ждать три часа у консоли, пока выкатывается новая версия.