In the last edition of this newsletter, I wrote about the importance of source control in analytics development. I’ve seen, however, many analytics teams misusing source control systems (eg pushing directly to main without pull request). Today, I’d like to introduce trunk-based development methodology (TBM).
Atlassian defines trunk-based methodology as “…a version control management practice where developers merge small, frequent updates to a core “trunk” or main branch. Since it streamlines merging and integration phases, it helps achieve CI/CD and increases software delivery and organizational performance.”
The key principles of trunk-based development include:
-
All changes should be made on the main branch/trunk.
-
Changes should be small and frequent to minimize conflicts and simplify code review. As a rule of thumb, branches need to be merged at least once a day.
-
Continuous integration should be used to ensure code quality and helps developers with fast iterations. Fast builds are essential.
-
Code reviews should be mandatory for all changes and done synchronousely, so the code doesn’t wait for days.
-
Minimise, or even eliminate code freezes.
Many people, including myself, used gitflow methodology in the past. It works well but has some drawbacks:
-
gitflow usually has more longer lived branches that require more collaboration, slow down overall development and can cause merge hell
-
gitflow has more complex branching strategy with dedicated branches for dev/test/prod, hotfixes, etc. TBM simplifies with one single main trunk branch.
-
TBM encourages synchronous reviews, as oppose to gitflow, when developers have to wait for their PR to be approved
Trunk-based development can help teams to move quickly, reduce integration problems, and helps production releases flowing. However, it requires discipline, good communication and a solid CI/CD.
This article reflects my personal views and opinions only, which may be different from the companies and employers that I am associated with.