How it works: Part 1

There are 2 main components to the deploybot-

• A Go-based backend that handles communication with slack (and github as well, more on that later)
• Bash scripts responsible for actual deployment on our servers.

To better understand the different parts of the backend, let us go through the flow of events while deploying a service-

• A club member sends a deploy message through one of our slack channels (without any other information), which is sent as a http request by slack to our servers after signing it with an access token.
• This request is routed to the appropriate http handler (deployCommandHandler in this case, refer to src/main.go), after which first the signature is verified, and then a dialog box is sent to the appropriate slack URL. This is a dynamic dialog, meaning when you interact with it, a request is sent to /slack/interactive/data-options which loads the dialog options such as git repos and servers available and sends it to slack.
• When the user submits the final deploy request with the selected options, the requestHandler invokes the deployGoRoutine (refer to src/deploy.go), which invokes the deploy.sh script along with the appropriate arguments. Post deployment, it sends a chat message to slack with a success/failure message, along with a link to the logs.

So far the working was fairly obvious - things get trickier when we get to what exactly the deploy.sh script does. In brief, the script clones the github repo of the project, decrypts the .env file for environment variables (git-secret is used for this purpose), builds images for all services in the project (docker-compose build), saves them into a private registry, and runs the project with a docker-compose up on the specified server. It then makes appropriate nginx entries to map the subdomain with the deployed service.

In the next section, we describe the current setup for DevClub and go into detail for each of these steps.