Automating deployments made easy with Gitlab and Slack
The problem: Waiting for CI-pipelines to pass
It all started with the hassle of waiting for Gitlab pipelines to complete for live deployments.
Our development workflow at VIDA is as follows:
- Working on a feature branch
- Creating a merge request
- Wait for a code and QA review
- Merge the feature branch into the develop branch
- Wait about 20 minutes for the staging pipelines to succeed, to see a pre-production environment on our staging system.
- Subsequently we create another merge request from develop to main and have to wait for another 20 minutes for the completion of the production pipelines.
- At the end we manually hit the button for the deploy job in the Gitlab UI.
This workflow has many advantages, such as separate review and staging environments for extensive testing and ensuring that we can close merge requests often.
But, given that the pipelines can take 10–20 minutes to pass, a developer might have to wait up to 40 minutes to see changes in the production environment. And during this time we typically wouldn’t just sit and watch the pipeline process — developers would start working on a new feature on a new branch. This means we would sometimes forget to check if a pipeline completed or failed. This meant that the whole flow took even longer and involved many slack messages within the product team to point to pipelines which have finished running.
This flow and the CI pipelines have their raison d’être, but we knew we could make this process much smoother and save a lot of time.
In addition to this developer pain point, we also needed to make the whole release process more transparent to team members outside the product team. Nobody really wants to check the status of dozens of issues every day to then know what went live so they can tell our customers about it.
To tackle this problem, we first started writing proper change logs, so the team could see a summary of what went live with each merge request. Thanks to my colleague
, who just wrote this article on how we implemented these change logs, we had a solid base.Our idea wasn’t to change the entire flow, instead we just wanted to automate the process as much as possible with tools the team was already familar with. Here´s what we did:
The tools: Gitlab to manage code and pipelines, Slack for communication
We are Gitlab and Slack power-users. Of course we could introduce yet another tool which would do the job above, or use Jenkins, or whatever.
But introducing new tools always brings additional complexity, unknown shortcomings which can be painful to discover, additional SaaS costs, and finally, adoption time within the team can be quite long.
We chose to continue working with apps/tools we already use in our daily business. And since Gitlab and Slack both have a very well documented and mature API, we decided to combine those in a Node service which handles everything for us.
My vision was to keep it as simple as possible — a Slack message that tells us about a new available version, including the change log. This message also needed to contain a button to trigger the deployment to production and a warning in case the backend production system ran an older version than the frontend needed.
And this is what the Slack message — posted directly on our main VIDA product channel — looks like:
The new and improved workflow
The service is integrated into our workflow and now looks like this:
- As soon as a merge request to staging got merged, the pipeline from will create the the change log, update the version and creates a git tag.
- A Gitlab webhook will tell us about the created git tag, so we can fetch all required information we want to display in the Slack message.
- After we send out the Slack message, the service is listening for the deploy action ( → the big red button we have to press to deploy).
- Once the deploy is initiated, the service will create the main merge request, approve it (which will trigger the pipeline), and trigger the deploy job once it’s ready. Also, the deploy button will be removed from the Slack message, so nobody can execute the same deploy again and a thread message will let us know that the deploy is in progress.
- After the deploy job is completed, the Slack message will again be updated and a rollback button will be added and a thread message will let us know that the deploy was completed. The rollback button will trigger a pipeline which will rollback to the previous release. This is really handy in case we discover that the new version has introduced a bug in production.
And that’s it.
Conclusion
From now on, every team member at VIDA can:
- see a deployable version and its changes,
- execute the deployment with just two clicks and no need to wait.
All of this is in Slack, which means we don´t have to navigate the Gitlab UI.
This new workflow immediately started saving us time and reduced the amount of context switching the development team needed to do to check on pipeline status.
Having these messages written directly into our main slack channels means the team stays in synch much better.
Furthermore, the Gitlab Slack bot can be continuously built out to also manage code reviews and makes bug tracking much easier — more on this in an upcoming blog post.
