Good Bot for Slack

In this article I want to talk about our bot for releases. We have a lot of very different projects, ranging from microservices backend (a), ending with the application for win 10.

Everyone wants to roll something out on the prod, and you need to somehow manage this process, preventing simultaneous releases of critical parts of the system. It is also necessary to have a detailed log of all all releases, in which case to be able to restore the sequence of events and find a release that led to adverse consequences.

It all started with such a cry of the soul:

"The number of developers is growing, the company is developing and the unloading process is becoming more complicated and confusing. Queues for "good" accumulate. The developer must monitor whether anyone has a dead and unloaded task, although he would have to wait for one of the services in front of him to block it. If he has not yet received "good", then periodically kick the well-wishers, because messages asking for goodness are lost in the chat room. And you want to unload faster, because if you do not unload today, for example, then tomorrow someone else may take a breath and not see that the previous tag has not been unloaded => unload two unnoticed for yourself - and everything will break. It all turns into a little nightmare. "

For quite some time, we have been solving the issues of who when to unload in a special chat room in Slack. To unload your release, you had to ask for "good" for this action, after which one of the "well-wishers" checked all the signs of a well-completed task, namely:

• was a review of the code
  
• are there any comments from QA
  
• Did the customer see the results on the test bench
  
• Is there any unloading documentation?  
  
• is there any documentation on how to roll back if the release failed
  
• etc.
  

After that, the well-wisher evaluated the possibility of this release right now, for example, it is strongly recommended not to upload something to the backend if networkers are working in one of the DCs and breaking connectivity (of course, it should work properly, but why tempt fate). When the "good" is received, you can proceed to release according to the documentation. As a rule, for any backend release you need an admin that pulls the magic switch and the code is laid out on servers, depending on the task, the database structure can change, but in general a lot can change. Some releases are made with the click of a button, some by launching several scripts with complex database migrations, clearing caches and other joys. After which the admin monitors the charts in zabbix, and the developer looks at the contents of the logs, making sure

Over time, the amount of information in the synchronization chat became huge and it became almost impossible to understand what was happening now. And then we decided to create a bot that systematized the release process.

The task for the bot was set as follows:

• Check for signs of a job well done
  
• Manage the release request queue
  
• Manage admin resources
  
• Notify the initiator of the release, about all changes in the status of its release
  
• Keep a complete log of the company's release actions
  
• Change ticket status in bug tracker after successful upload
  

After a couple of weeks, we got a dobrobot and we started to train him in teams.

Request for permission to upload

@dobrobot dobro #<номер задачи в баг трекере> 
@dobrobot dobro <ссылки на wiki с документацией по релизу>
@dobrobot dobro <ссылка на версию(группа задач)>

If the release does not need an admin, for example, to send a new version of the iOS application to the AppStore, the no_need_admin parameter is specified in the dobro command.

After the release initiator sent the dobro command to the bot, the following message appears in the release chat.



And those who are responsible for release permissions receive a notification that a new upload request has appeared.

If the ticket does not satisfy the formal attributes of a well-completed task, the unloading initiator will receive a message from the bot.

View Release Queue 

@dobrobot queue

The result of the team, the task numbers are clickable.

Unload Permit

@dobrobot accept <Номер в очереди>

After the follower sends the accept command to the bot, the following message appears in the release chat.

Participation in unloading admin

If the unloading requires administrator support, the bot sends a notification to administrators that a new release task has been validated. One of the administrators can check in with the command:

@dobrobot here <номер в очереди>

After that, a notification appears in the release chat that the admin has been found.

Start unloading

@dobrobot dep start <номер в очереди>

After that, a notification appears in the release chat that the work on the release has begun.

Unload Completion

@dobrobot dep finish <номер в очереди>

Instead of totals

This simple innovation allowed us to better understand what and when it is being unloaded, what work is currently being done on the combat infrastructure, which in turn has led to increased security during release work of dependent components, as well as conflict prevention.