Как я улучшил процесс релиз-инжиниринга и снизил риски 🚀 Вы когда-нибудь задумывались, какой маршрут проходит код от строки в редакторе до стабильного запуска в продакшене? Давайте об этом поговорим!

Релиз-инжиниринг – это сложный процесс подготовки и выпуска обновлений программного обеспечения в продакшн, благодаря которому конечный продукт работает стабильно и без сбоев.

Кто этим занимается? Релиз-инженер – специалист, который отвечает за организацию и контроль процесса выпуска обновлений, чтобы каждое изменение доходило до продакшена без проблем.

Как это работало раньше У нас был большой поток изменений и множество акторов, поэтому изменения группировались в пачки и выпускались по фиксированному календарю дежурств. Каждый день дежурил новый релиз-инженер из разных команд, за исключением пятницы.

«Никаких деплоев в пятницу!»

👀 Процесс выглядел так: - Релиз-инженер собирал изменения и формировал релиз. - Проводились различные проверки, после чего запускался деплой. - В течение релиза инженер следил за метриками и, при возникновении ошибок, производил откат изменений. - Если всё проходило успешно – поздравляем, изменения успешно выкачены на продакшн!

🛑 Проблема, с которой столкнулись Недавно у нас резко сократился штат сотрудников – да, такое бывает. Поскольку руководство гильдией релиз-инженеров оказалось на мне, пришлось оперативно оптимизировать процесс под новые реалии.

🔑 Ключевые моменты, указывающие на необходимость смены модели: - Резкое сокращение количества акторов и изменений, текущая модель с ежедневными дежурствами становится неэффективной. - DORA-метрики показали, что частота релизов и их длительность позволяют нам уменьшить размер пачек.

В такой ситуации текущая модель перестаёт быть рациональной. Это особенно заметно, когда релиз-инженер, который раньше дежурил раз в месяц, теперь вынужден дежурить каждую неделю.

Последствия старой модели: 🔥 Рост нагрузки – увеличение частоты дежурств перегружает инженеров. ⬇️ Сокращение командного ресурса – меньше времени остается на разработку. ⚠️ Снижение количества изменений – релизные пачки становятся менее эффективными. 👀 Человеческий фактор – усталость и стресс повышают вероятность ошибок.

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

Преимущества новой модели: 📉 Снижение уровня риска: Локальный контроль позволяет команде лучше понимать свой код и оперативно реагировать на проблемы. 💪 Рост ответственности: Принцип "You build it, you run it" становится реальностью – каждый владеет своим кодом. 🤝 Увеличение вовлечённости: Команды мотивированы, поскольку от их работы напрямую зависит качество выпускаемой фичи. ⏰ Сокращение времени на координацию: Локальные решения позволяют быстрее принимать оперативные решения без долгих согласований.

Вывод Изменив процесс релиз-инжиниринга, мы смогли снизить риски, повысить стабильность продакшена и увеличить вовлечённость команд. Теперь каждая команда отвечает только за свои изменения, а зона принятия решений стала компактнее.

А как бы вы оптимизировали этот процесс в текущей ситуации? Делитесь идеями в комментариях!👇