Agile Interventions for the Branching Strategy
The source code branching strategy may be adversely affecting team velocity and code quality. The problem is branches have inherent overhead, waste and risk. Branches mean more code review and code conflict resolution sessions, increased process complexity, more build CPU and storage consumption and a few gotchas.
A good Agile intervention is to ensure teams maintain autonomy and control over how they work. Teams can better balance the costs and risks of using branches to meet the demands and limitations of their specific situations. Development organizations can enforce this principle through thoughtful automation of the code branching strategy.
Implement CLDP pipeline automation around the most efficient branching strategy and let teams design how to get their code into that pipeline.
The most efficient branching strategy is a single, eternal, protected branch. Protected here means to prevent history rewrites and direct commits. Each deployment artifact generated from the eternal, protected integration branch runs thru all of the quality gates defined in the SDLC. If a problem is discovered all of the people whose changes are impacted are notified together to ensure they collaborate to resolve the issue immediately. Everyone working on the same integration branch must collaborate to ensure integrations are successful.?
The last, best time to tell a team they have bad code is before they merge it into an integration branch. The pull request review branch is a great place to “shift left” critical tests from the SDLC. Proactively block merges that would violate an SDLC quality gate. This reinforces the Agile principles of quality by requiring all code changes to be production worthy. If a team needs more overhead to achieve production worthy code enable them to create integration branches and deploy to isolated environments. Less stable work should not impact the rest of the organization’s productivity.?
The following diagram illustrates another branching strategy using protected integration branches to target specific validation processes in the SDLC. A change must be merged into each integration branch in order to move through the SDLC quality gates.
Four branches like this will cause the build server to run the same validations 8 times wasting valuable CPU cycles on the pipeline infrastructure. And the code reviews and conflict resolution sessions become more prohibitive in the higher branches because they accumulate changes over increasingly longer periods of time.?
I’ve experienced gotcha’s with these kinds of strategies. When a problem is found, say, in the uat branch the fix is usually completed in that branch. The developer then “forgets” to merge the change into the lower integration branches, which can have unknown consequences and may not be easy to discover. Also, requiring teams to keep track of which code is on which server makes it harder for them to quickly validate their own work.
领英推荐
Another problem with multi branch SDLC pipelines is they often rely on builds being idempotent, meaning multiple builds of the same code generate identical deployment artifacts. Hot fixes are a common use case for this scenario. When a deployment artifact is released to production that did not go thru all of the SDLC quality gates there is a risk it does not have the code you expect. Teams often use pre-release or snapshot versions to update transient dependencies automatically by chaining builds together, which is very efficient. However, idempotent builds require the team to update each project in the dependency graph to get the code change into the deployment artifact, which can quickly become a lot of extra work in a complex code base with many transient dependencies. The SDLC should not depend on idempotent builds unless explicitly confirming the artifacts are identical in the validation processes.
Agile principles compel teams to focus on completing one thing before moving on to another. Long validation processes introduce overhead and give teams a false sense of progress. For example, running user acceptance testing just before a release to validate the changes that have accumulated over many sprints can uncover defects that are difficult to find and fix. Similarly, delaying integration testing to a subsequent sprint allow teams to take on more work than they can actually finish in the sprint. This additional work lingers in branches increasing the risk of code conflicts and hard to find bugs.
A good Agile intervention is to ensure all validation processes for a code change can be completed within a team’s sprint. One strategy to help with this is to treat all integration branches in your SDLC the same as the highest quality branch. If validation processes are bottlenecks to finishing a story in a sprint then move those processes into the sprint and do them all the time. If that is not possible, then move some tests sooner in the SDLC and consider removing tests that are duplicative or not increasing confidence in product quality.?
Shorter validation cycles will improve overall quality faster than exhaustive, longer processes. If the longer validation cycles are still required push the validation work as close to where changes are introduced, which we know reduces the cost of software development(1).
From an Agile perspective we want to enable teams to move small changes through the entire SDLC as quickly and efficiently as possible. So whether a team used one branch or four is not as important as enabling each team to define the most efficient path for themselves with a nudge from the automation toward the more efficient process. Just in time feedback helps improve quality and productivity. And as we learned from Kent Beck’s book Extreme Programming XP (1999) if something improves our ability to deliver valuable, working software, do it to the extreme.?
Tags: #sdlc #branchingstrategy #scalingagile #agileinterventions #shiftleft
Resources