Pull to refresh
75.11
Онлайн-кинотеатр Иви
Мы открываем для людей многообразие мира кино

Бот добра для Slack

Reading time 3 min
Views 6.6K
В этой статье я хочу рассказать о нашем боте для релизов. У нас много очень разных проектов, начиная от микросервисов 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 <номер в очереди>



Вместо итогов


Такое несложное нововведение позволило нам лучше понимать, что и когда выгружается, какие работы сейчас ведутся на боевой инфраструктуре, что в свою очередь привело к повышению безопасности при релизных работах зависимых компонентов, а также предотвращению конфликтов.
Tags:
Hubs:
+20
Comments 13
Comments Comments 13

Articles

Information

Website
www.ivi.ru
Registered
Founded
Employees
501–1,000 employees