Improving the Release Management Process Using Script
This blog post is a successive article of the Software Release Management 2.0 post. So, if you didn’t check that one yet, I recommend you read it first as it gives a basis on the release and branching strategy for the script I will explain below.
Tech Stack for Release Management
- Gitlab
- Jenkins
- JIRA
- Slack
Recap of Branching Strategy
Steps of Branching Strategy after Development is Completed
- Reset “next” branch to the latest master.
git pull master
git checkout next
git reset — hard master
git push origin next - Rebase “master” to development branches.
git checkout <feature_branch>
git rebase master
git push -f - Merge development branches to “next”.
git checkout next
git merge origin/DEV-123 origin/DEV-234
git push origin next - Reset “beta” branch to new “next”.
git checkout beta
git reset — hard next
git push -f origin beta - Rebase “next” branch changes to prod.
git checkout prod && git pull — rebase origin beta
git push origin prod - Rebase “prod” branch changes to master.
git checkout master && git pull — rebase origin prod
git push origin master
These are the steps we use on the terminal when we release codes to production. When we want to add a new development branch to beta, we need to merge it to the “next” branch and reset beta after each merge. We also have some cases like, we remove some tasks from the test environment if these can not pass the test. In this case, we need to reset the next branch and merge all other ready branches to next and beta again.
To follow this process takes a long time for the release managers. As a result, we decided to write a script that does all these steps automatically. You run one command to merge branches to next and beta.
What are the Commands We Require?
- Update all the branches (next, beta, prod, master) with a command.
- Release selected branches to beta.
- Release beta changes to production and master.
All these commands need to work on Website and Orchestration Layer repositories. As we have different branch naming convention, we need to add one more code block to script to check on which repository we are running script.
Also, we have a setup to deploy branch changes to related environments automatically over Jenkins. Whatever we push to the “beta” branch will be deployed to the test environment and the same for the production environment with the “prod” branch.
Update all the branches
Updates next, beta, prod and master branches from remote. If you want to update orchestration layer branches, the script will ask you which website branches you want to update.
Command to run:$ atg pull
Release to Beta
Resets next and beta with Prod. Then pushes the source branches added. If there is a conflict with the “prod” branch, the script will exit, developers should rebase the “prod” to merge their changes. If there is a conflict between branches, release managers should fix the conflict and commit while script waits for them to continue.
Command to run:$ atg release beta DEV-123 DEV-234
Release to Prod
Pushes beta changes to prod and master. The script will ask for confirmation to push changes to prod, master and create a tag.
Command to run:$ atg release prod
Common Steps of Release Script
- Set config related to the repository.
- Show a logo to be cooler :P
- Show the configs to the user to prevent any branch mismatch.
- Stash current changes to prevent development loss.
- Fetch the latest origin from git.
Steps of Beta Release Script
- Rebase prod changes to branches one by one.
- Merge branches to next.
(In case of conflict, the script waits for the user to fix conflicts and push.) - Inform the user about diff between prod and next branches.
- Ask the user to get confirmation to push changes to beta.
Steps of Prod Release Script
- Rebase beta changes to prod.
- Ask the user to get confirmation to push changes to prod.
- Rebase prod changes to master.
- Ask the user to get confirmation to push changes to master.
- Ask the user to get confirmation to create a new tag and push.
Also, there is a config for JIRA and Slack on the script. If the release managers want to send a Slack message after release, they can create a webhook for their slack channel and send a message. By creating a JIRA authentication and adding it to config, release managers can update related tickets with a label automatically.
Benefits of Script
- Pull the latest changes of 4 branches with one command.
- Easy releases for test and production environments.
- Reset the “next” branch easily with a command.
- Visibility of related tasks over JIRA and Slack.
- To handover release manager responsibilities to any teammate easily.
Dependencies
- simple-git > For running git commands in node.js.
- readline-sync > To have a conversation with the user via terminal.
- @slack/webhook > To send a notification to a Slack channel.
- consola > Elegant Console Logger for Node.js and Browser
- figlet > Logo :)
- ora > To show an elegant terminal spinner between commands.