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 š
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
More about Gitflow: atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
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.
More about the difference: streamlined.engineering/p/se5-deploy-release
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.
ā
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.
āļø 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.
š 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.
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.