Choosing a Codeline Strategy for Agile Software Development
The wrong codeline strategy can slow you down, but the changing your strategy alone isn't enough on it's own to help you move more quickly.
Most Software Development Processes, agile or not, have the following elements:
Planning: Decide what to do
Execution: Write Code, etc
Delivery: Deployment, for example
Feedback: Stakeholders look at what you did
Iteration or cycle duration,
Number and kinds of feedback loops
Details about specific techniques, events, etc.
Least significant, but most obvious, is the different words used to describe shared concepts such as development iteration; Scrum uses “Sprint”, XP uses “Iteration.” If you are really good at continuous planning, you plan continuously, and the “iteration duration” is 0. But the concepts of plan, execution, deliver, review, still apply.
There are many resources on the different elements of agile methods:
Process: the overall arc of the process, including events and ceremonies that facilitate communication.
Planning: how to select work for a development iteration
Engineering Practices: Testing, continuous delivery, feedback
Some methods, such as Scrum, focus on the planning elements, and leave it to teams to find the technical practices that work for them. Others such as XP are engineering focused, and have a more basic approach to planning. This isn’t a flaw in either approach, just a difference in perspective, regardless of your approach, you need technical practices that keep your code agile, and a planning/project management approach to help keep you focused.
One common essential element of software development that not covered in depth is the place where work comes together: The codeline. A common word for code line is “branch,” but as I’ll explain later, “branch” carries some assumptions that I’d like to avoid having distract from the main thread). Agile methods need a code line model that supports:
Collaboration: multiple people on a team working towards a goal
Frequent Integration: being able to combine the work streams of each developer frequently so that we can ensure that they work together.
Frequent Delivery: being able to release software frequently so that we can deliver value, get feedback, and when needed, correct errors.
A code line is at the center of the release process and where work comes together.
Codelines are usually associated with branches in a version management system , and since most teams use some sort of version management, that’s a reasonable way to think of them. A more basic way to think about a Codeline is a parallel stream of software development, which, while usually backed by a branch, need not be.
If you never create branches in your version management system, changes you have made in a copy of the code sitting in a workspace on your development machine is a codeline. While having code in a workspace backed by a branch is a common practice, and one I’ll recommend (with certain caveats), it’s not essential.
Regardless of your approach, work isn’t useful until it is integrated into a codeline that can be delivered to someone who can use the software.
Those who favor rapid integration — in the extreme case not using branching and integrating quickly using a fail fast (and recover quickly) mindset believe all obstacles to integration are bad. This falls down when a team doesn’t have the structures in place to catch errors quickly and minimize the errors that you release.
For many teams, the answer lies between those extremes: an approach to using code lines that facilitates collaboration and reduces delays associated with integration. As you move to minimizing the time between the start of development, a codeline strategy that uses lightweight branching can help you accelerate your integration pace, while minimizing the risks of major failures.
Finding the best codeline process for your team involves:
Identifying your goals
Understanding the obstacles to reaching these goals
Finding the simplest codeline process that works in your current environment and working on improve the ecosystem around it to help your team move ever more quickly.
There are some common codeline and branching strategies people use. I’ll review those next. In many cases a Main Line based strategy is going to be the best approach to improving delivery but implementing an effective branching strategy takes more than just declaring that you will us it.