How We're Implementing Trunk-Based Development

As of early 2020, we at True Engineering formulated a "Shared Engineering" strategy, in which we are developing our base of approaches and standards and unifying workflow. In the first stage, we have developed universal requirements for project management and moved all teams to work in the Azure DevOps tracker. We are also gradually transforming the testing process and introducing Software Developer in Test functions to the teams.

Implementing a Trunk-Based-Development (TBD) methodology is the next phase of our transformation. 

Key components of TBD

• All releases are mandatorily made in the Trunk or Master branch. New features are developed in separate, short-lived branches, so-called Feature Branches. A developer creates a branch, writes code for one or two days and returns the branch back to the Master.
• It is fundamentally important to always keep the Master branch functional and stable. This is where feature toggles (FT) – special switches in the code that display/hide elements of the solution or application – come in. They are embedded into the code during development and are controlled through a special portal. This way, we can hide unstable and incomplete features from the user while the finalization is in progress, and it won't affect the overall performance of the application. 
• Automated testing and continuous Code Review are two more mandatory components of TBD. If all the changes in a fetch-branch are completed, they need to be promptly merged into Master, so code review should be a priority task. As for autotesting, strictly speaking they are not suitable for all tasks and you don't need to cover 100% of code with them (we discussed this in detail in our experience with SDET practices). A test scenario is written for each particular task during the planning stage.  For tasks where autotest is relevant, the code is merged into Master only after it is passed. 

Task decomposition and Short-lived branches

All code branches, except for the main branch, should have a short lifetime, a few days at most. This can be achieved by fine decomposition: a branch will be small if it solves a small problem. Correct task setting at the planning stage plays a very important role, so we stick to the INVEST task decomposition principle and introduce a task hierarchy.

INVEST decomposition defines what a user story should be:

• Independent, i.e., free from outside control
• Negotiable, i.e., written in plain language
• Valuable, i.e., to be of worth
• Estimable, i.e., it can be estimated
• Small, compact, no more than 40 hours of development
• Testable, i.e., testable in a broad sense

Each of the planned tasks should tested for compliance with all the bullet points above. If at least one of them falls out, the task should be decomposed anew. 

Continuous supply and TBD

The ultimate goal of all our internal changes is to accelerate and optimize the standard stages of creating IT solutions.

We have carefully analyzed our development process and found several points of loss of time and quality: they can arise from deficiencies in a particular stage or from problems between different stages. 

• Insufficient analytics and decomposition;
• Assembling releases from multiple tasks;
• Regression testing;
• Long wait for Code Review;
• Losses on the merger of big changes;
• Lack of feedback from consumers.

In order to optimize this process, we are moving from manual software delivery to the practice of so-called "Continuous Delivery" (CD). This is a reliable, controlled and fully automated process with clearly measurable risks that:

• Accounts for losses at each stage;
• Accounts for losses at transitions between stages;
• Can be assembled automatically based on tracker metrics.

How we implement TBD into the work of the teams

First of all, we are of the opinion that the implementation of the TBD methodology only makes sense in actively growing products. If at this stage of the project we are releasing one edit per month and maintaining support, TBD is not relevant. 

In general, we do not consider the transition to TBD as a separate task, we try to act comprehensively and include in our projects several platform practices at once; this includes the transition to a single tracker Azure DevOps, the addition of SDET features in teams, and the implementation of TBD, among other things. 

Our projects are now at different stages of transition to TBD, from project to project the current status may vary quite a lot. But, in any case, in each of them we try to implement important components of CD and TBD, such as proper task decomposition, autotest writing and requirements testing.