A.k.a "Time to Trunk".
How do you measure your progress on the way to continuous integration(we're not even discussing delivery yet)? How do you know you are progressing towards the goal incrementally?
Assuming you're in an enterprise situation, showing a KPI over time can help drive a goal forward.
One of the KPIs I've used on a project was "Time to Main".
Let's start with the basic situation we'd like to fix, assuming multiple teams with bad architecture that causes many dependencies between the teams. See below chart:
In the chart above we have four teams and one main branch. Each team also has it's own private branch(es) structure. A usual cycle of crating an application version is:
- new NEO binaries distributed to the other teams. HAMMER is adapted and then send to the ORCA team. ORCA team produces binaries to the DAGON team which then produce ORCA+HAMMER+DRAGON components to the ADAM team.
Finally, they all merge to the main branch, in specific order.
Obviously, not the best situation in the world. There are many things we can do to make things better, but first, we need a way to measure that we ARE making things better.
One measure I like to use is "Time to Main" . How long does it take for a FULL version of all components that work with each other to get from developer's hands to MAIN?
In our case the answer starts with:
1 Day Hammer work + 3 days ORCA work + 3 days DRAGON work + 5 days ADAM work = 12 Days to Main.
But wait , there's more.
Many of the back and forth lines are actually branch merging actions. For large code bases, add a few hours per merge, which can add up to 2-3 days if not more. Total could be 14-16 days to Main, starting with team NEO publishing a new feature( in this case they are not in the same source control - as they are in a different company).
Note:
We are assuming that the timings mentioned here are "friction time" only. Time that is not used for code development, but the absolute necessary time developers need to feel confident to merge to MAIN . This might mean they run a bunch of manual or automated tests, debugging, installs. anything. It is time that will be spent whether there is or isn't major functionality being introduced, because the integration with the other components has a cost.
There are many things we can choose to do here:
- Ask all teams to work directly on main
- Create a "Dependency cache" from the continuous build on "Main" so everyone can access the binaries.
- Reduce manual testing with automation
- Etc..
No matter what we do, we can always ask ourselves "How does this affect time to main?" We can always measure that tie, and see if we are actually helping the system, or just implementing local efficiencies while Time to Main remains the same, or even increases.
From the Theory of Constraints, we can borrow the "Constraint" term. Time to main is our Constraint of actually having a shippable product increment we can demo, install or test at the system integration level. The more teams choose to use internal branches, the more time code has to wait until it sees "Main". Now we have a number that tells us if we are getting better or worse in our quest for continuous integration.