Controlled Integration
Now I don't mean that continuous integration isn't controlled. When I refer to "controlled integration" as opposed to "continuous", I mean that the first one occurs frequently, but not all the time. It normally runs when a certain milestone is reached (the milestone could perfectly be a weekly or daily planned integration).
There is also another difference between continuous and controlled that refers to the roles involved in the process: In a regular continuous scenario, all developers perform integrations and solve merge conflicts in code, which is perfectly acceptable on small, well-trained teams. But even agile teams can be affected by personnel rotation or new members joining, and it is usually not a good idea to have new developers mixing code they don't yet understand.
In controlled integration, a new role is introduced -- the integrator. The integrator can be a seasoned team member who is familiar with a big part of the code and also pretty used to the version control system and the build and release process. But the most important feature that the integrator introduces in the process is not that he knows all the code, which is not even necessary, but he takes responsibility on the integration process. Creating a new stable well-known point to serve as the base for development during the next iteration is integrator's primary goal.
Figure 6 shows an scenario in which well-defined integration points are not present. In such an environment, mainline instability and code-and-fix are likely to appear because developers are starting their tasks from volatile points.
What a controlled integration process introduces is a set of well-known starting points that developers will use to work against. So, as in Figure 7, developers now will always start working against a well-known and stable baseline. For instance, between BL004 and BL005, everyone will start the new task again BL004 code, so nor unnecessary dependencies nor unstable developer working areas will affect the development process.
As a side effect of controlled integration, task-oriented development can be introduced. Now each task a developer works on is handled independently by the version-control system, implementing full parallel development and giving the team a more maneuverability during release creation.
Figure 8 highlights the differences between a task-oriented parallel development and serialized development processes. When task-oriented patterns are supported by the version control, a look to the branching hierarchy reflects how the development was indeed parallel, something that can only be imagined but not traced by serial development.
