If a build got broken due to a complier error or integrations tests did not pass (unit tests were done at the function level), the developer would receive a warning by email that she/he had to fix the error. This would only effect the development environment. It wasn’t till we reached the end of our iteration after all the code was checked in and integrations tests passed, that it would be deployed to the staging environment where system and UAT testing got done. Once this was all complete, it would go to the “production” environment. I have production in quotations as this was really a pre-production or “prototyping” environment.
So it was with interest that I read this post
from the Plastic SCM website about the difference between a “continuous” and “controlled” integration:
In a regular continuous integration scenario, all developers perform integrations and solve merge conflicts in code, which is perfectly acceptable on small, well-trained teams. Even agile teams can be affected by personnel rotation, though, or just new members joining, and it’s usually not a good idea to have a brand new developer mixing code he doesn’t yet understand.
In controlled integration a new role shows up: the integrator. The integrator is usually a seasoned team member who is familiar with the bulk of the code, the version control system, and the build and release process. The most important feature of the integrator is not that she knows all the code, which is not even necessary, but that she takes responsibility for the integration process. The integrator’s primary goal is creating a new stable baseline to serve as the base for development during the next iteration.
I have to agree with this and think it is an important distinction to make. For the automated test system I was in charge of, I played that role of Integrator that was tasked with setting the baseline for the development of the next iteration.
The illustration above shows an example of a mixture of a continuous and controlled process. For anyone tasked with deploying an Agile software development project and are utilizing continuous integration, I recommend looking at this model and ensuring you and your team recognize the difference and where to adopt one process or the other.