Streamlining Software Release Process: A Case Study

Automating releases transforms them from error-prone, anxiety-inducing events into confident, one-click routines that teams like to perform

I helped a product team streamline their software release process.

From 16 manual actions per release to making 1-2 releases daily with a single Slack command. But most importantly, the team isn't afraid to make a release anymore.

A case study 👇

The release process is initiated via Slack command

Team uses Gitflow, and we don't want to change it. For release automation, we focus on 3 main Gitflow branches:

• main: production code

• develop: ongoing work

• release/*: code of specific version, to be merged into main

Example of gitflow team uses

In the team context, deploy and release are almost the same. Deployed work is instantly available to end customers.

In a team, deploy relates to a single service, while release means deploying all 3 maintained services.

The product consists on 3 services, each of them is autonomous deployment unit

The team follows 4 steps to initiate and complete the release process, whether it is manual or automatic:

• 🚀 Initialize the release

• ✅ Wait for the green light to proceed

• ⚙️ Push all changes to the main branches

• 🏁 Wait for deployments and inform everyone

🚀 To initialize the release, we create a release branch and open a pull request to *main* for each service.

The Slack command sends a webhook to trigger an automation. The automation performs GitHub operations. The pull request workflow updates a version in package.json.

Run command, run scenario, open pull-requests

✅ After initialization, we wait for QA approval and code review before merging pull requests to ensure they are mergeable.

QA approves via Slack thread, saving the approving person for history. An approve triggers automation to merge PRs or enable auto-merge if needed.

Approve, run scenario, auto-merge

⚙️ When a pull request is merged and changes are pushed to the *main* branch, we create a git tag with a version number. The GraphQL API doesn't support GitHub releases yet 🙁

We then open a back-merge PR to ensure all release changes are incorporated into the *develop* branch.

After merge run CD pipeline, make GitHub release

🏁 Once the deployment is complete, we will provide all the necessary information.

If it was the last service in the queue, we will notify everyone of the successful release and clean up everything to prepare for the next release in the future.

When all done inform the team

After automation, the team makes releases with one Slack command, requiring pull request reviews for merging.

In this example, we count 16 manual steps for 3 services. More repositories will mean more manual work.

Most importantly, automation eliminates human errors, ensures consistency in steps, and removes the fear of releases.

After a few iterations and improvements, the team can confidently make a release from their phone, knowing it will function just as before.

In a real project where this automation is implemented, there are absolutely no issues related to incorrect deployments or releases.

It's running smoothly for almost 2 years, and people are happy with it.