Parallel Development and Branching Patterns
The keys which open real SCM powered parallel development are branches. Branches are normally perceived as a necessary evil by many developers, but this is normally just because many version-control tools systematically discourage branch usage. And the reason behind this is not that branches are evil, but that tools are extremely bad dealing with them.
In fact, when most of us think on branching, we consider it just from the project management perspective: You create a branch to split a project, start maintenance, or support different code variants. Use just a few branches for very specific tasks.
But branches can also be used in a more tactical way to isolate changes and create detailed traceability. Branching patterns like branch-per-task or branch-per-developer (also known as "private branches" or "workspace branches") open new possibilities in the integration process. Commits don't have to be associated with delivering anymore, they can just be used as checkpoints, creating a safety net for developers, boosting both productivity and change freedom, which are practices totally aligned with the agile goals.
Achieving task independency through branching
Using mainline development on a single branch, as it is usually encouraged by continuous integration practitioners, ends up in situations like that in Figure 9.
What if each task were developed on each own branch? Then developers not only get an extra service from the version-control system. By creating intermediate check points when they need to instead of being forced to wait until the code is finished, they gain the possibility to actually decide what goes into a given release or not, while retaining changes under source control. Figure 10 shows an scenario where a developer switches from one branch to another, thereby avoiding unnecessary task dependency.
|
Benefit |
Description |
Associated Freeride practice |
|
Private sandboxes for developers |
Developers can perform changes with more freedom, and commit them to the version control without worrying about breaking the build. Intermediate history is kept helping self-documented code. |
The change flow is enforced. Developers feel free about making changes, experimenting with the code, and being able to decide later on whether the code hits the mainline or is just kept for future study. |
|
Task independency |
Tasks don't depend on each other due to the order they are carried out. |
Helps creating frequent releases: whatever is not stable enough won't be integrated. Last minute integration rushes are minimized. |
|
Real parallel development |
Changes are really developed in parallel, with full traceability. |
Boosts team productivity. |
|
Mainline stability |
The mainline can be much more stable than using continuous integration. |
Frequent usable releases. |
