Streamline your hotfix integration with automated main merging

The author, Nina Tan, is a software developer at Bandwidth who works on the user interface for the Bandwidth App, our global communications platform. Check out Bandwidth’s open positions if you’d like to work with Nina and the team. Join the BAND!

Automating merging a hotfix back into main

Production hotfixes can be tense. If you’re dealing with a customer-impacting bug, you might feel the gaze of other teams staring you down while you identify and fix the bug, ensure backwards compatibility, and finally deploy the fix.

POV: You hit deploy, watch the build go green, smoke test, and let out a sigh of relief. You shut your laptop, pack up, and go home knowing that you ensured the health of our codebase and satisfaction of our customers…

BUT WAIT!

If your organization employs a Gitflow-type branching strategy, you know there is one final piece of the puzzle—merging the hotfix you just deployed back into main. This critical step ensures that the newly deployed hotfix changes aren’t overwritten when the release engineer deploys the next release. But to be perfectly honest, this can easily be missed which would introduce a regression. That’s why our team determined an automated solution would reduce the risk of inconsistencies and strengthen our deployment reliability.

So we devised a solution: automating the opening of a pull request (or PR) to merge the hotfix changes into main. This will ensure the release engineer doesn’t have to remember this task themselves for every hotfix.

With the support of dev leadership, I took on the challenge of automating this process and leveling up my GitHub Actions knowledge. I had tweaked actions before, but this automation would involve adding logic, new Github Actions jobs and scripting to our CI/CD pipeline.

We deploy our software based on Github tags. When a PR is merged into a hotfix branch, the newly built tag’s name will need to contain the phrase “hotfix.” This tag is then used as the tag that is deployed to production.

The deploy action is where the bulk of my work fell. During the deployment job, I added a logic step that checks if the tag being deployed contains the phrase “hotfix” AND that it is deploying to production. If both these conditions are true, then the action will create a new branch from the tag (creating a new branch was necessary as tags can’t be used to open PRs).

Next, the action uses the GitHub CLI tool to create a new pull request from that hotfix branch to be merged into main.

open-hotfix-pr:
   needs: [check-user, deploy, make-new-branch-from-tag]
   if: ${{ contains(github.event.inputs.targetEnv, 'production') && contains(github.event.inputs.version, 'hotfix') }}
     - name: Create Pull Request
       id: create-pull-request
       uses: actions/checkout@v4
       with:
         repository: Bandwidth
     - run: |
         PR_LINK=$(gh pr create -B main -H ${{needs.make-new-branch-from-tag.outputs.pr}} 
          --title 'Merge ${{github.event.inputs.version}} branch into main' 
          --body 'This PR will merge the hotfix changes from ${{github.event.inputs.version}} into main.' 
          --label 'needs forge review')

The logic I added to our GitHub Action to open a pull request if the most recently deployed version tag contained the word ‘hotfix’

The action populates the pull request with the title and description pertaining to the recently merged hotfix tag, and our ‘needs-forge-review’ label is added to alert our team that the PR needs to be reviewed. (⚒️ Forge is our team name.)

An example of a pull request that is automatically created after a hotfix tag is merged to production

Finally, as an added bonus, I created an automated notification using a Slack webhook which is triggered by the pull request being created. This alerts our team via a Slack channel that we need to approve the PR to get it merged in:

An automated message sent to our Slack channel, letting us know that it needed team approvals

At this point, reviewing and approving the PR is simple. We know these changes are needed in the main branch and that the code has already been tested and reviewed during the hotfix process.

Automating this step alleviates a small load from the release engineer during the urgent process of implementing a hotfix. We’ve also reduced the chance of inconsistencies thanks to this automation, making for smoother deployment reliability. Leading and implementing this project also allowed me to level up my GitHub Actions skills!

Thanks to this new process, after our release engineers bravely exit the hotfix battle, they can close their laptops knowing that their hard work is on its way to being merged into the main branch in the morning.