В этой статье я хочу рассказать о нашем боте для релизов. У нас много очень разных проектов, начиная от микросервисов backend(a), заканчивая приложением для win 10.Все хотят что-то выкатывать на прод, и нужно каким-то образом менеджерить этот процесс, не допуская одновременных релизов критических частей системы. Также необходимо иметь подробный лог всех всех релизов, чтобы в случае чего иметь возможность восстановить последовательность событий и найти релиз, который привел к неблагоприятным последствиям.
Все началось вот с такого крика души:
"Количество разработчиков растет, компания развивается и процесс выгрузки становится все сложнее и запутаннее. Очереди на «добро» скапливаются. Разработчик должен следить нет ли у кого вмерженной и невыгруженной задачи, хотя б на одном из сервисов перед ним и ждать когда, блокировка снимется. Если он еще не получил «добро», то периодически пинать добродавателей, т.к. сообщения с просьбой добра теряются в чатике. А выгрузиться хочется быстрее, потому, что если ты не выгрузишься сегодня, например, то завтра уже кто-то другой может вмержиться и не посмотреть, что предыдущий тег не выгружен => выгрузить незаметно для себя два — и все сломается. Это все превращается в маленький кошмар."
Довольно долго мы решали вопросы, кто когда выгружаться в специальном чатике в Slack. Чтобы выгрузить свой релиз нужно было попросить «добро» на это действие, после чего один из «добродавателей» проверял все признаки хорошо выполненной задачи, а именно:
- было ли проведено review кода
- есть ли замечания от QA
- видел ли заказчик задачи результат на тестовом стенде
- есть ли документация по выгрузке
- есть ли документация, как откатывать, если релиз не удался
- и т.д.
После чего добродаватель оценивал возможность этого релиза прямо сейчас, например, настоятельно не рекомендуется выгружать что-то на backend, если сетевики ведут работы в одном из ДЦ и порвали связность (оно, конечно, должно отработать штатно, но зачем искушать судьбу). Когда «добро» получено, можно приступать к релизу согласно документации. Как правило для любого backend релиза нужен админ, который дергает волшебный рубильник и код раскладывается по серверам, в зависимости от задачи может измениться структура БД да вообще многое может измениться. Какие-то релизы делаются нажатием одной кнопки, какие-то запуском нескольких скриптов со сложными миграциями БД, очисткой кешей и прочими радостями. После чего админ наблюдает за графиками в zabbix, а разработчик просматривает содержимое логов, убеждаясь, что его функционал работает как надо и откатывать не придется.
Со временем объем информации в синхронизационном чате стал огромным и понять, что сейчас происходит, стало практически невозможно. И тогда мы решили создать бота, который был систематизировал процесс релиза.
Задача для бота была поставлена следующая:
- Проверять признаки хорошо выполненной работы
- Менеджерить очередь запросов на релизы
- Менеджерить ресурсы админов
- Уведомлять инициатора релиза, обо всех изменениях статуса по его релизу
- Вести полный лог релизных действий компании
- Изменять статус тикета в баг трекере после успешной выгрузки
После пары-тройки недель у нас появился dobrobot и мы начали обучать его командам.
Запрос разрешения на выгрузку
@dobrobot dobro #<номер задачи в баг трекере>
@dobrobot dobro <ссылки на wiki с документацией по релизу>
@dobrobot dobro <ссылка на версию(группа задач)>Если в релизе не нужен админ, например, отправить новую версию iOS приложения в AppStore, в команде dobro указывается параметр no_need_admin
После того как инициатор релиза послал боту команду dobro в релизном чате появляется следующая надпись.
А тем, кто отвечает за разрешения на релиз приходит уведомление, что появился новый запрос на выгрузку.
Если тикет не удовлетворяет формальным признакам хорошо выполненной задачи, инициатор выгрузки получит сообщение от бота.
Просмотр очереди релизов
@dobrobot queueРезультат работы команды, номера задач кликабельны.
Разрешение на выгрузку
@dobrobot accept <Номер в очереди>После того как добродаватель отправляет боту команду accept, в релизном чате появляется следующая надпись.
Участие в выгрузке админа
Если выгрузке требуется поддержка администратора, то бот отправляет админам уведомление, о том что появилась новая релизная задача, прошедшая валидацию. Один из администраторов может отметиться командой:
@dobrobot here <номер в очереди>После чего в релизном чатике появляется уведомление о том, что админ найден.
Начало выгрузки
@dobrobot dep start <номер в очереди>После чего в релизном чатике появляется уведомление о том, что работы по релизу начались.
Завершение выгрузки
@dobrobot dep finish <номер в очереди>
Вместо итогов
Такое несложное нововведение позволило нам лучше понимать, что и когда выгружается, какие работы сейчас ведутся на боевой инфраструктуре, что в свою очередь привело к повышению безопасности при релизных работах зависимых компонентов, а также предотвращению конфликтов.
Комментарии (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, но они занимаются релизами конкретных проектов. А тут же речь про все проекты компании. Такого зверя готового мы не нашли.