Good bot for Slack

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



Everyone wants to roll out something on the prod, and we need to somehow manage this process, not allowing simultaneous releases of critical parts of the system. It is also necessary to have a detailed log of all releases in order to be able to restore the sequence of events and find the 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. The queues for" good "accumulate. The developer should see if anyone has an inherent and unloaded task, although at one of the services in front of him and wait for the lock to be removed. If he hasn’t received the “good” yet, then periodically kick in the virtues, because messages asking for good are lost in the chatika. And you want to unload faster, because if you don’t unload today, for example, then tomorrow someone else can hold on and do not see that the previous tag is not unloaded => unload unnoticed by two - and everything will break. This all turns into a small nightmare. "



For a long time, we have been deciding who to unload when in a special chat in Slack. To unload your release, you had to ask for “good” for this action, after which one of the “virtuosos” checked all signs of a well-executed task, namely:

• Whether the review code was conducted
  
  
• are there any comments from QA
  
  
• did the customer see the result on the test bench
  
  
• Is there any documentation for uploading?
  
  
• is there any documentation how to roll back if the release failed
  
  
• etc.
  
  

After that, the grantor was assessing the possibility of this release right now, for example, it is strongly not recommended to unload something on the backend, if networkers do work in one of the DCs and break connectivity (it should work properly, of course, 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 who jerks the magic switch and the code decomposes across the servers, depending on the task, the structure of the database can change, and in general, much can change. Some releases are made by pressing a single button, some running several scripts with complex database migrations, clearing caches and other joys. After that, the admin monitors the charts in zabbix, and the developer scans the contents of the logs, making sure that its functionality works as expected and does not have to roll back.



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



The task for the bot was set as follows:

• Check for signs of a job well done
  
  
• Manage queue release requests
  
  
• Admin Resources Management
  
  
• Notify the initiator of the release of all status changes on his release
  
  
• Keep a complete log of the release of the company
  
  
• Change ticket status in bug tracker after successful upload
  
  

After a couple of weeks, we got a dobrobot and we started teaching it commands.

Request for unloading permission

@dobrobot dobro #<    > @dobrobot dobro <  wiki    > @dobrobot dobro <  ( )> 

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



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







And those who are responsible for release permits receive a notification that there is a new request for upload.



If the ticket does not satisfy the formal characteristics of a well-executed task, the initiator of the upload will receive a message from the bot.

View Release Queue

 @dobrobot queue 

The result of the team, task numbers are clickable.

Unloading permit

 @dobrobot accept <  > 

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

Participation in admin unloading

If uploading requires administrator support, the bot sends a notification to the admins that a new release task has appeared that has been validated. One of the administrators can be noted with the command:

 @dobrobot here <  > 

After that, in the release chatika appears a notification that the admin is found.

Start unloading

 @dobrobot dep start <  > 

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

Completion of unloading

 @dobrobot dep finish <  > 

Instead of totals

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