Как менялись системы релизов

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

Минимальные простои, безопасный откат, но нужна двойная инфраструктура, а значит, удвоенные расходы.

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

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

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

Progressive delivery — логичное развитие канарейки. Здесь идея в том, что релиз — это не момент, а процесс. Выкатываем обновление сначала на минимальную аудиторию, мониторим метрики и только после зелёных сигналов расширяем охват.

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

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

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

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

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