Опишите процесс выпуска релиза на предыдущем проекте.

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

Вот смотри, у нас тут как в хорошем бандитском кино — всё по понятиям, по ГитФлоу. Начинается вся движуха, когда фичи в develop накопились, как говна за баней.

*Шаг первый: Создание релизной ветки (`release/).** Отdevelopотпочковываем ветку, типаrelease/v1.2.0. Это как отдельный кабинет, где мы эту версию доводим до ума, а не до пизды. Тут версию вpackage.json` или где у вас прописываем — семантическое версионирование, блядь, святое! Мажорная, минорная, патч — не хуй собачий. И сразу гоняем ВСЕ автотесты, чтоб понять, что мы ничего не сломали. Регресс, сука, он такой.

Шаг второй: Стабилизация и обкатка. Дальше — самое интересное. Выкатываем это добро на staging. Это такая песочница, максимально похожая на прод, но где можно накосячить без последствий. Тут уже подключаются тестировщики — они начинают тыкать во все дырки, гонять smoke-тесты и критические сценарии. Иногда ещё перфоманс или секьюрити проверки подключаем, если чувствуем, что накосячили с памятью или дыру в безопасности оставили.

Шаг третий: Контролируемый въезд в прод. А вот тут уже без хуйни. Нельзя просто взять и выкатить всё на 100% юзеров — это пиздец, а не стратегия.

• Canary-релиз: Сначала пускаем новую версию, условно, на 5% трафика. На своих, на смелых. И смотрим, блядь, в Grafana или Datadog — не полетели ли ошибки вверх, не выросла ли задержка. Если метрики зелёные — ок.
• Постепенный rollout: Если канарейка не сдохла, начинаем потихоньку увеличивать процент. С 5% до 25, потом до 50, потом до 100. И всё это время мониторим, как сумасшедшие. А ещё у нас есть feature flags — волшебные переключатели. Если новая фича начала ебать мозг пользователям, мы её можем вырубить одной кнопкой, даже не откатывая весь релиз. Красота, ёпта!

Шаг четвёртый: План "Б" — откат. А если всё-таки пиздец? У нас же стратегия blue-green или просто быстрый откат к предыдущему Docker-образу. Нажал кнопку — и трафик потек обратно на старую, стабильную версию. Главное — не паниковать и не начинать всё руками чинить в панике.

Вот, смотри, как это в конфиге GitLab CI выглядит, простенько:

stages:
  - test
  - deploy-staging
  - approval
  - deploy-prod

deploy-prod:
  stage: deploy-prod
  script:
    - kubectl set image deployment/my-app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  only:
    - master
  when: manual # Тут самый сок — без ручного подтверждения ни хуя не полетит!

Видишь эту строчку when: manual? Это священная кнопка "Выпустить". Без её нажатия даже самый ебучий скрипт не сработает. Последний рубеж, где можно сказать: "Стоп, а давайте ещё раз проверим".

Ну и после того как всё уехало: Расслабляться рано. Упираемся глазами в графики, слушаем пользователей в чатах поддержки. Если что-то пошло не так — проводим короткий пост-мортем: "Ребята, какого хуя мы тут обосрались и как сделать, чтобы в следующий раз не обосраться?". Вот и весь цикл, в рот меня чих-пых. Автоматизировано, но с человеческим надзором в ключевых местах, чтоб не было мудацких сюрпризов.