![](https://habrastorage.org/getpro/habr/post_images/644/cd6/cca/644cd6cca6d2d41a3620627a24b40b62.png)
Все хотят что-то выкатывать на прод, и нужно каким-то образом менеджерить этот процесс, не допуская одновременных релизов критических частей системы. Также необходимо иметь подробный лог всех всех релизов, чтобы в случае чего иметь возможность восстановить последовательность событий и найти релиз, который привел к неблагоприятным последствиям.
Все началось вот с такого крика души:
"Количество разработчиков растет, компания развивается и процесс выгрузки становится все сложнее и запутаннее. Очереди на «добро» скапливаются. Разработчик должен следить нет ли у кого вмерженной и невыгруженной задачи, хотя б на одном из сервисов перед ним и ждать когда, блокировка снимется. Если он еще не получил «добро», то периодически пинать добродавателей, т.к. сообщения с просьбой добра теряются в чатике. А выгрузиться хочется быстрее, потому, что если ты не выгрузишься сегодня, например, то завтра уже кто-то другой может вмержиться и не посмотреть, что предыдущий тег не выгружен => выгрузить незаметно для себя два — и все сломается. Это все превращается в маленький кошмар."
Довольно долго мы решали вопросы, кто когда выгружаться в специальном чатике в Slack. Чтобы выгрузить свой релиз нужно было попросить «добро» на это действие, после чего один из «добродавателей» проверял все признаки хорошо выполненной задачи, а именно:
- было ли проведено review кода
- есть ли замечания от QA
- видел ли заказчик задачи результат на тестовом стенде
- есть ли документация по выгрузке
- есть ли документация, как откатывать, если релиз не удался
- и т.д.
После чего добродаватель оценивал возможность этого релиза прямо сейчас, например, настоятельно не рекомендуется выгружать что-то на backend, если сетевики ведут работы в одном из ДЦ и порвали связность (оно, конечно, должно отработать штатно, но зачем искушать судьбу). Когда «добро» получено, можно приступать к релизу согласно документации. Как правило для любого backend релиза нужен админ, который дергает волшебный рубильник и код раскладывается по серверам, в зависимости от задачи может измениться структура БД да вообще многое может измениться. Какие-то релизы делаются нажатием одной кнопки, какие-то запуском нескольких скриптов со сложными миграциями БД, очисткой кешей и прочими радостями. После чего админ наблюдает за графиками в zabbix, а разработчик просматривает содержимое логов, убеждаясь, что его функционал работает как надо и откатывать не придется.
Со временем объем информации в синхронизационном чате стал огромным и понять, что сейчас происходит, стало практически невозможно. И тогда мы решили создать бота, который был систематизировал процесс релиза.
Задача для бота была поставлена следующая:
- Проверять признаки хорошо выполненной работы
- Менеджерить очередь запросов на релизы
- Менеджерить ресурсы админов
- Уведомлять инициатора релиза, обо всех изменениях статуса по его релизу
- Вести полный лог релизных действий компании
- Изменять статус тикета в баг трекере после успешной выгрузки
После пары-тройки недель у нас появился dobrobot и мы начали обучать его командам.
![](https://habrastorage.org/getpro/habr/post_images/e6a/575/738/e6a575738250dfbc0d68b38d3f137aaf.gif)
Запрос разрешения на выгрузку
@dobrobot dobro #<номер задачи в баг трекере>
@dobrobot dobro <ссылки на wiki с документацией по релизу>
@dobrobot dobro <ссылка на версию(группа задач)>
Если в релизе не нужен админ, например, отправить новую версию iOS приложения в AppStore, в команде dobro указывается параметр no_need_admin
После того как инициатор релиза послал боту команду dobro в релизном чате появляется следующая надпись.
![](https://habrastorage.org/getpro/habr/post_images/66f/25f/d8d/66f25fd8d928ed909a762e6c3a5f1312.png)
А тем, кто отвечает за разрешения на релиз приходит уведомление, что появился новый запрос на выгрузку.
Если тикет не удовлетворяет формальным признакам хорошо выполненной задачи, инициатор выгрузки получит сообщение от бота.
![](https://habrastorage.org/getpro/habr/post_images/12b/bfa/e28/12bbfae28397d55bbb67095906fbd229.png)
Просмотр очереди релизов
@dobrobot queue
Результат работы команды, номера задач кликабельны.
![](https://habrastorage.org/webt/mo/t6/04/mot604lpxamsqlh-6_9i3x4rpbq.png)
Разрешение на выгрузку
@dobrobot accept <Номер в очереди>
После того как добродаватель отправляет боту команду accept, в релизном чате появляется следующая надпись.
![](https://habrastorage.org/getpro/habr/post_images/5d8/c35/148/5d8c351483c39c86d5c939f1974397cc.png)
Участие в выгрузке админа
Если выгрузке требуется поддержка администратора, то бот отправляет админам уведомление, о том что появилась новая релизная задача, прошедшая валидацию. Один из администраторов может отметиться командой:
@dobrobot here <номер в очереди>
После чего в релизном чатике появляется уведомление о том, что админ найден.
![](https://habrastorage.org/getpro/habr/post_images/768/a07/5c5/768a075c5de0043b26e1922f8370e130.png)
Начало выгрузки
@dobrobot dep start <номер в очереди>
После чего в релизном чатике появляется уведомление о том, что работы по релизу начались.
![](https://habrastorage.org/getpro/habr/post_images/692/280/5a5/6922805a5d6cb20ac0b6a9439397264d.png)
Завершение выгрузки
@dobrobot dep finish <номер в очереди>
![](https://habrastorage.org/webt/rz/qe/df/rzqedfsbefic7p4kg4g7pdgrjdc.png)
Вместо итогов
Такое несложное нововведение позволило нам лучше понимать, что и когда выгружается, какие работы сейчас ведутся на боевой инфраструктуре, что в свою очередь привело к повышению безопасности при релизных работах зависимых компонентов, а также предотвращению конфликтов.
Комментарии (13)
at_wrike
06.12.2017 11:36Я правильно понимаю, что у вас происходит по несколько релизов в день?
1 задача = 1 релиз?eross Автор
06.12.2017 11:38Иногда несколько десятков релизов в день. Чаще всего — да. Одна задача — один релиз. Однако, бывают релизы из 2-3 задач.
at_wrike
06.12.2017 11:49А можете рассказать как проверяется задача перед релизом?
Для каждой задачи поднято свое окружение (например задача по беку) или они проверяются на каком-то общем «предрелизном»?
Просто меня немного смущают настолько частые релизы, так как код, по факту, проверяется на проде, так как нельзя предусмотреть всех изменений, которые внесли другими, уже одобренными, задачами. И вот хотелось бы узнать как часто у вас бывают, связанные с такой ситуацией, проблемы, и не думали ли вы пойти в сторону одного/двух релизов в день?eross Автор
06.12.2017 12:21Перед релизом задача проходит ревью, потом тестирование в тестовой среде, потом нажимается волшебная кнопка в jenkins, которая делает rebase, потом прогоняет тесты, потом ставится тег. И уже потом релиз
at_wrike
06.12.2017 12:46Может ли возникнуть ситуация, когда на мою таску поставили тег готовности к релизу, а кто-то, пока моя задача стояла в очереди, зарелизил задачу, которая сломала мою ветку? И я об этом узнаю только после того, как мой код окажется на проде? И не получится ли так, что все тесты гонялись на неактуальной версии кода?
Ничего страшного, что в статье про бота мы обсуждаем процесс деплоя?)eross Автор
06.12.2017 12:58у нас в backend(е) нет develop ветки. Разработчики выделяют свои ветки из мастера, так же у разработчиков нет прав на merge своей ветки в master, это делать только jenkins с обязательным прогоном тестов. То есть для каждой из веток тесты будут проведены правильно. Мы стараемся не мариновать уже смеренные задачи в master(e). И разработчик практически сразу после успешного прохождения тестов и успешного мержа отправляет запрос на выгрузку и ждет свободного админа, кто бы ему выгрузил код. И наш бот помогает нам как в раз в том что бы понять кто раньше захотел зарелизиться. Без него можно было прошептавших ошибиться и выгрузить последний тег, минуя тот которые еще не выгружен.
Вероятность того о чем вы говорите не нулевая, я говорю о том что может выгружено сразу 2 задачи вместо одной (при этом прогон тестов будет корректный), но есть очень много механизмов, которые не допускают этой ситуации.
eross Автор
06.12.2017 12:24Бизнес требует от нас больше чем 1-2 релиза в день. Так что нам приходится соответствовать. Код проверяется долго с помощью unit тестов, функциональных тестов и нагрузочных. Ну и к тому же мы предусматриваем процедуру отката и процедру плавных релизов на часть аудитории.
tankomazzz
А существующие решения рассматривали? Если да, то какие и почему отклонили (было бы интересно почитать, возможно даже отдельным текстом)
eross Автор
У нас много систем для автоматизации релизов, типа Jenkins и Capistrano, но они занимаются релизами конкретных проектов. А тут же речь про все проекты компании. Такого зверя готового мы не нашли.