As part of a major drive to push for faster "time to main" you might need to change things in the following five areas (that end up affecting how long people take to get their code checked into "trunk":
Branching Culture
Branches means merges, and merges take time. Branching culture in many places also mean "only merge when you feel you won't break things for anyone else" which effectively means many places use branches to "promote" code to the next stage of stability. This in turn means people might spend a lot of time "stabilizing for others" code before moving it onto the next branch (system testing the code locally, really).
Less branches - less time to main!
Binaries Sharing Culture
When working with multiple teams that depend on each other's outputs, moving binaries between the teams becomes a time consuming challenge. I've seen teams use shared folders, emails and even Sharepoint pages to share their binaries across development groups.
Find a simple way for teams to share and consume binaries easily with each other, and you've saved a world of hurt and time for everyone involved (for example: dependency stash).
Builds
If you're going to reduce the amount of branches, you probably will need gated builds to make sure people don't check in code that breaks compilation on the main branch (trunk). This would be the first level of a build (gated build per module). the second level would possibly an hourly (or faster) integration build that also runs full systematic smoke tests and other type
Also, if an integrated build does break, you will need to put fixing a red build as high priority for those who broke it, or those who have to adapt, before moving on to new features.
One more: you will probably need a cross-group build triage team that notices red builds as they occur and has the ability to find out what is causing a red build, and where to redirect the request-to-fix toward.
Testing Culture
You will need to automate a bunch of the manual testing many groups so they can run it in a gated build, and for the smoke and system tests at the integrated build level.
Coding culture
Developers will need to learn and apply feature toggles (code switches) or learn how to truly work incrementally to support new features on the main trunk, that take longer than a day or so to build, without breaking everyone's code.
There are two types of breakages that can occur on the main trunk (assuming gated builds took care of compile and module level unit and smoke tests):
- Unintended breakages : can usually be fixed easily directly on the trunk by the group that broke them, or by another group that needs to adapt to the new code.
- Intended breakages. These can be broken up into:
- short-lived intended breakages (such as group x has a new API change, they check it into main and expect group B to get it from main, adapt to it with a simple code change and check their stuff back into Main . this should usually be within an hour's work).
- Long lived intended breakages: you're working on a feature for the next month or so. In that case you either work fully incrementally on that new feature, or you enable feature toggles (a.k.a 'branch by abstraction').
Either way we are talking about teaching developers a new culture of coding.
Without this culture coding change , developers will always be afraid of working directly on main and you'll be back to private branches with everything they entail (a.k.a - 'long time to main').