Deploying your web application is certainly not the most interesting activity of your day. But what if it could be simple, reliable and fun?
Using a Slack bot to deploy your app is actually fun and it brings a lot of perks to the table.
Why?
Aside from the fun to talk to your bot through your preferred chat app, the main benefit is that there is finally a single source of trust for your deployments. If you’re using software engineering good practices, your code should be versioned, your database schema should be versioned, your infrastructure should be versioned… so you know exactly what code is deployed on what infrastructure. But what about the code that deploys the rest of the code (whatever it is: shell script, fabric, ansible, salt, puppet, chef, anything…)? Sure it is also versioned. But this code is not deployed on your servers, it’s executed on a developer|ops|devops machine. Has the code been modified? Is the working directory dirty? Is it the latest available version? You never know. Unless all the deployments are executed from a single machine that cannot be accessed through SSH (only deployed to) and that everybody uses. Yes, I’m talking about your Slack bot.
Besides knowing exactly how your deployments are made, another essential point is communication. Everybody on the team needs to know when a deployment starts, when it ends and what has been deployed. Everybody also needs to know the deployment history. What is currently deployed? Did someone perform a rollback? Just use a Slack bot, and you get all that for free.
There are other smaller perks too. You don’t need your computer with you for emergency support. You can restart a Docker container or perform a rollback right from your phone. You just need the mobile Slack app! It’s also really easy to handle deployment permissions. Just invite the right people to the authorized channel!
Did I mention it’s a lot of fun to write a Slack bot?
Why a bot, why not just a slash command?
Slack custom slash commands are a great way to trigger an event through a web hook and print the results in Slack. For instance I added to our Serenytics team a command /srn-active-users that returns the last active users on our web app. We could use this to deploy our stack. But a bot is actually a better solution, for two main reasons.
You can have a conversation with a bot. You can’t have a conversation with a slash command. And I think this is a killer feature to perform deployments. Why? Because you first ask your bot to deploy your app. It answers with the list of new commits available since the last deployment, and asks you if you want to proceed. Then you can validate the changes before going on. And it’s just great.
Technically, another benefit from using a bot is that you don’t need to deploy a new server somewhere with a domain, an API, an SSL certificate, authentication… a simple daemon script is enough.
What deploying actually looks like in Slack
Here is the Slack transcript of one of our own actual deployment. Our bot is called Nestor and I’m deploying our frontend application on our AWS servers.
Example bot code
Here is the skeleton of the Slack bot we use at Serenytics. It’s a complete running script where you just have to fill in the blanks: your slack token and the actual deployment code. I use shell commands and Docker Cloud python client in our case.
If you want to know more about Slack bots, go there.
Give us a shout if you want more details about integrating git history or deploying on Docker Cloud.
Top comments (0)