Continuous Delivery: “Trunk Based Development”
Years back with the limitation of Clearcase , the development team was tasked to transitioned from Clearcase to GIT which essentially is distributed version control system. The team was moving to a more agile model where the frequency of deployment were going to be from once in 6 months to monthly and eventually weekly based on a service pack or quick fixes required for a large eCommerce storefront. The though that envisioned this were certain ideas for development process to be rapid and agile and the team should be able to
1)Work with tasks which are closely related to each other.
2)Share their work rapidly and easily to each other even if it’s not yet complete.
3)Not to be afraid of committing their work into the code repository.
4)Committing and fetching changes to/from repository should be easy and fast.
Since the idea mooted was to move ot Git based model , but Git is merely a tool. It can be used in many different ways. In short there are two major development styles “Git flow” and “trunk-based development (TBD)”. But they are by large different for different kind of development and should be chosen based on what or how the releases are planned.
Trunk Based Development: In Trunk-based model , all developers work on a single branch with open access to it. Often it’s simply the master branch. They commit code to it and run it. It’s simple. In the Dev creates short-lived ‘feature’ branches. Once code on their branch compiles and passes all tests, they merge it straight to master. It ensures that development is truly continuous and prevents Dev from creating merge conflicts that are difficult to resolve. Thus in essence , the developers collaborate on code in a single branch called ‘trunk’ , resist any pressure to create so called long-lived development branches by thus avoiding merge hell and do not break the build. Though this can be done without Continuous Integration (CI) tool , for enterprise development you have to have CI linked to the trunk, enforcing multiple aspects of “that commit was good”.
When to use : when should the developer choose use the ‘trunk model. They should use these essentially for dev work that involves bug fixes.. Devs may, on their own dev desktop, do some multi-branch development (say with Git), but when they are “done” with a change or a bug fix, it should go back to the shared trunk. Also its only the ‘Release Engineers” or Scrum Master who commits to those branches. The ‘Release Engineer” with Dev may also “cherry-pick” individual commits to that branch if there is requirement. After a release is done and a new one is created, the branch is deleted.
Why not Long Ruining Branches : On the contrary, if long-running branch are in use, changes become isolated from the other branches, including trunk. CI builds still exists against that branch, but the changes are integrated within that branch, not against the code that the other teams are Committing. This is just deferring the impending trouble of long term merge work.
Summary: In TBD, the dev does full source code reviews. None of the dev has strict control over what is being modified in the source code . Developers are experienced since they write and commit clean code. Overall the trust level is high since they can introduce code straight into the master branch. On the other hand, if the team is not seasoned and has junior devs. one shouldn’t go with this method — choose Git flow instead. It will save you unnecessary worries.