Continuously controlled integration for Agile development

From the Agility and Project Leadership Blog
by
Bridging the gap between traditional and agile project management and leadership.

About this Blog

RSS

Recent Posts

It’s the Product Owner, stupid!

Is Walmart going Agile? Not really…

Are PMI-ACP credentialed project managers really the highest paid?

It's more about having agility rather than being Agile

Agile is not enough! Be Anti-FrAgile

Email Notifications off: Turn on


For Agile software development, I'm a big advocate of XP's practice of continuous integration. This is the practice where a developer checks in code which triggers an automated system to compile and build the code into the system.  One of my early projects was to implement an automated build system for a .Net/C# platform using open source software such as Cruise Control, that worked in conjunction with a custom make file that got triggered during check in to compile and build the code.  There were three development systems these builds got deployed to: development, staging and production environments.

For Agile software development, I'm a big advocate of XP's practice of continuous integration.  This is the practice where a developer checks in code which triggers an automated system to compile and build the code into the system.  One of my early projects was to implement an automated build system for a .Net/C# platform using open source software such as Cruise Control, that worked in conjunction with a custom make file that got triggered during check in to compile and build the code.  There were there development systems these builds got deployed to: development, staging and production environments.
 
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.For Agile software development, I'm a big advocate of XP's practice of continuous integration. This is the practice where a developer checks in code which triggers an automated system to compile and build the code into the system.  One of my early projects was to implement an automated build system for a .Net/C# platform using open source software such as Cruise Control, that worked in conjunction with a custom make file that got triggered during check in to compile and build the code.  There were three development systems these builds got deployed to: development, staging and production environments.
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.
For Agile software development, I'm a big advocate of XP's practice of continuous integration.  This is the practice where a developer checks in code which triggers an automated system to compile and build the code into the system.  One of my early projects was to implement an automated build system for a .Net/C# platform using open source software such as Cruise Control, that worked in conjunction with a custom make file that got triggered during check in to compile and build the code.  There were there development systems these builds got deployed to: development, staging and production environments.
 
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.
For Agile software development, I'm a big advocate of XP's practice of continuous integration. This is the practice where a developer checks in code which triggers an automated system to compile and build the code into the system.  One of my early projects was to implement an automated build system for a .Net/C# platform using open source software such as Cruise Control, that worked in conjunction with a custom make file that got triggered during check in to compile and build the code.  There were three development systems these builds got deployed to: development, staging and production environments.
 
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.
Posted on: November 02, 2012 02:33 PM | Permalink

Comments

Please Login/Register to leave a comment.

ADVERTISEMENTS

"The good die young, because they see it's no use living if you have got to be good."

- John Barrymore

ADVERTISEMENT

Sponsors

>