Migration to a Trunk Based Model

TLDR

Migrated front-end repo from git-flow to a trunk based model; implemented a simpler release process.

My role

Tech lead of the team that "owns" and maintains the front-end codebase.

Reason

The primary purpose behind this migration was to facilitate simpler front-end "releases". The repo was previously using git-flow as the underlying branching model. This codebase is shared between teams, and collaborating across teams for preparing and managing a release was tricky. This complexity made deploying changes to production slow and error prone.

Furthermore, due to little to no transparency into the process (from a non developer's perspective), our product team did not have a lot of insight into what was being released, causing issues with coordination down the line with other teams like Customer Success, Marketing, etc.

Implementation

Since this migration was supposed to be two-fold: one from Bitbucket to Github, and the other from git-flow to a trunk based model, I set up a placeholder repo on Github, and incrementally added trunk based utilities to the repo.

Most of the functionality changes happened in our CICD process. I implemented a way to release changes in a developer friendly manner: given that the trunk is kept in a releasable state, a developer only needs to checkout to a release branch from the trunk, and push it. 2 "release slots" are always available for the developers: one corresponding to the last deployment on production, and the other for next release being planned. The CICD takes care of bumping up versions (via git tags).

Some changes were needed on the Github repo. These included setting up branch protection rules to ensure that the guidelines laid down by the trunk based model are being followed.

Given that transparency was an issue in the prior model, I implemented a system of notifications for changelogs. These changelogs are shared in a centralized channel, allowing everyone involved in front-end releases to easily access and review the specific changes being prepared for deployment.

In order to make the changelogs standardised, I set up committing standards for the repo following the conventional commits specification.

A neat trick that I learnt while trying to come up with a way to generate changelogs was to use git's built in capabilities to selectively list commits in a log command, and the triple dot range. I ended up using:

git log --cherry-pick --right-only --no-merges -n 50 <LAST_DEPLOYED_VERSION>...<NEW_VERSION>

Lastly, I set up walkthroughs and demos with developers and product owners to help them get acquainted with the new front-end release process.

Challenges

• I wanted the auto-versioning system to abstract away the complexity for the developers, implementing this entirely via git tags was a bit tricky
• The two-fold nature of the migration: to github and a change to the underlying model made it so that I couldn't incrementally test out most of the functionality till the day of the actual migration, which made things a bit complicated
• Inertia in ways of working is common; it took repeated explanations to bring everybody up to speed with how the new process worked

Impact

[Written on 2023-12-16] If followed correctly, this new model should let us organise and ship features faster than before, while also ensuring that all concerned parties are well aware of what's being shipped.