Getting to Agile Codelines: Forces and Release Lines
Even when you know the right answer, it may not work for everyone.
In Hidden Potential, Adam Grant points out that implementation experts can be less than the best teachers; a lot of knowledge becomes implicit, and it’s hard to really see things from the perspective of a novice. (Which is why I think that teaching is often under-appreciated — but that’s another post). In the context of Software Configuration Management Patterns I can walk through the steps to make a code line more agile, but it’s sometimes hard to understand why someone might not want to move that way. Using technically precise wording while ignoring that words and names also come with some baggage, can lead you to walk past people’s concerns. I’ve been trying to do a better job at this as I update the pattern language. Release Line is an example.
The term “Release Line” brings images of staged codelines., long-lived “release candidate branches” and a slow delivery cadence, where you release “patches” while your “new feature” codelines evolve slowly. This was a traditional workflow. You can use a release line that way, but doing so makes it harder to deliver quickly. But a Release Line can also help you deliver frequently and (mostly) avoid patch releases if you use it correctly.
I say “mostly” because, while in an ideal world, you’d always release from the Main Line, there are circumstances where having a patch release makes sense:
Regulated software where the overhead of deploying an update is much less than new features
A time-critical release when there is a third party involved (say, an App Store, or a client)
Your process isn’t quite ready to always deploy from the Main Line
You can work around some of these issues with good use of feature flags, or having good testing discipline where your codlines are always ready, or you use feature flags to hide new features. But practically, not every team is there yet.
A Release Line (at least in the pattern language) is a way to keep track of the what has been (or is about to be) released. Providing for patch or hot-fix releases is an option (because sometimes that is the right answer) but it’s not the first option.
A software release process is subject to some forces, and a Release Line attempts to balance them:
Stability: More “pre-release” testing would seem to offer more assurance that the “release candidate” is error-free.
Speed: You want to release features and bug fixes to customers quickly,
Development Flow: Each additional codeline that is being maintained means that the team’s attention is divided
Stability and speed can seem at odds, and having both stability and speed can improve flow.
One approach to balancing these three forces is to:
Move in smaller steps (more frequent releases)
Add testing and quality earlier (unit testing, and more automation in general)
Have a process that allows you to recover from errors quickly.
Not every team is at the same point in the process, and it seems pragmatic to find a path that helps you to do better while acknowledging your current state.
But while you might have a branch called “release line” you’re not using the Release Line Pattern unless you have certain policies in place:
Limiting the number of “live” releases (ideally 1)
Having a regular, somewhat frequent release cadence (every week or two, or better)
Having automated testing practices in place to give you confidence about frequent releases.
Many people reading this might be saying, “Of course, that’s what you’d do! And we don’t even need the Release Line Tracking Branch!”
Others might think that releasing quarterly(or less often) and applying fixes to a branch is the only way to work. But approaches to software development have changed to make releasing frequently from the Main Line more feasible from a technical perspective “Release Prep Codeline” was a pattern in the original pattern language that was meant as a response to “code freeze” a common practice with some earlier tools which made branching a heavy weight process. A Code Freeze almost never (or maybe never?), makes sense now.
While it might seem that there is one right way to solve a software development problem, that’s not a helpful way to look at process change. Looking at problems and forces and finding a solution that balances the forces to help teams deliver value. In the end, there may be one approach that works — in the end state. But teams have to get there.