After several iterations on our pipelines, we got to a point where everything is working smoothly, and most of the new improvements are related to optimization, like reducing 1 minute per step by reducing Docker image sizes, or something else that can be considered a real improvement for our flow.

As we are a Super International Team, some of the team members start work earlier than others. This is not an issue for us, as we are more focused on the value we add to the business than counting how much time we spend sitting in front of the computer. The other day during our daily meeting, I overheard a conversation about who was responsible for deploying the feature environments. These envs are removed every day to avoid unexpected costs, and it looked like they were having a hard time deciding who needed to deploy the environment every morning. To make the story short, they came to an agreement and made it work.

In the meantime, I was in the background trying to understand how to make everyone’s life easier, as maybe other non-technical users might need to validate a feature but the Developer is not around. This is not something that happens often, but I figured out that our deployments might be sped up with this as well.

My proposal was simple: creating a command on Slack that allows users to deploy feature branches when required.

Why Slack?⌗

Why not? It is easy for me to access our pipeline and deploy the branch as I built it, but for non-technical users it will be complex, and they will not perform those actions too often. Also, Slack is the app we use every day for communication, and everyone is used to it.

You might be thinking that allowing all the users on Slack to use a command and deploy as many environments as they want would be a mess, and indeed it would be. To avoid any complications, only the users in a certain channel can execute the command. The channel is private, and only the ones that really need access to it are invited.

To create the Slash command on Slack, you would need to create an App first and then create the command. When creating the command, it asks for a name, the webhook which is going to handle the request, a short description, and a hint for Slack.

After setting everything, the command preview will be similar to the following image:

Usually these improvements are not a priority for the business, but the value for the team is high. Based on that statement, “wasting” time on creating a backend to manage the requests is out of scope, and what I did is use a Low Code app that I’ve been using for my personal automations. In this case I used N8N, but there are so many like Zapier, Make, Pipedream or Node-RED.

By drag and droping a few predefined tasks, I was able to build the backend required and also manage some exceptions like the wrong project is selected, the branch doesn’t exist, or if the command was executed in a channel that is not allowed.

N8N is a cool way to manage small workflows in a short time, and the best thing is that it is fully dockerized, which makes it fast to install and then create the workflow. About security, you can rest assured because an attacker would need the specific endpoint and also the Slack signature of the app that is validated as well.

The options for these types of tools are unlimited. We also have an early fraud detection backend based on our payment gateway provider, and the fraud notifications are processed by N8N and also notify the team in charge.

To sum up, this is a quick and easy way to add value to your projects by empowering the team to take actions based on their requirements. Asking a Developer to deploy an environment might not sound like too much, but the real problem here is not how much it takes for Devs to deploy the environment, but the time that it takes to recover the same pace and focus lost when they receive the request. This is not something I made up, please feel free to take a look on this post:

[!cite] It takes 23 minutes to get into a flow state