Featured Whitepapers
- Forrester Research: Optimizing Globally Distributed Software Development Using Subversion
- An Integrated Approach to Requirements and Quality Management
- Continuous Testing With ElectricCommander
- Agile CMMI at a Large Investment Bank
- Realize Effective Distributed Development Via a Virtual Software Factory
- Build & Deployment Automation for the Lean Economy
Upcoming & Recent Webcasts
- A New Kind of Engineering
- Managing Change in Rugged COTS Systems Development
- Keeping Control of Costs and Schedules When Requirements Change
- Three Simple Things that Will Help You Adopt Agile in Your Enterprise
- Customer speak: Teams, Insights, Results with Quality Driven Software
- Build & Deployment Automation for the Lean Economy
Home 
Implementation Excellence Approaching Continuous Integration
Implementation Excellence Approaching Continuous Integration
Approaching Continuous Integration |
| Print | |
| Written by Mario Moreira | ||||
| Monday, 15 November 2004 16:00 | ||||
|
The term “continuous integration” is getting a bit of attention these days. It refers to the process of integrating often (or immediately) to reduce integration effort, complexity, and pain and to make changes more readily available to others. While the term “continuous” is catchy, it is not accurate in what the concept implies. In context to integration, the term “continuous” implies a process without interruption. 
In software development, while changes are not continuous, what is really meant is to integrate often or frequently. Thought should be applied to determine when and how frequent integrations should occur, to re-work the development process to support frequent integration, and to setup an infrastructure that can support this approach. This paper provides some useful guidance in establishing an environment where frequent (or continuous) integration may be possible. Understanding the Approach In general, continuous integration is the process when code is checked in and is immediately built in the integration stream to see if it can build with existing code. If the build is successful, then an automated set of tests are run to validate the changes. Once the build and test are successfully completed, the results are made available to the rest of the developers. The premise is that when you continuously integrate, you can continually encounter and overcome small manageable integration issues during development avoiding large time-consuming integration issues. Consideration should be given to whether a continuous integration approach is right for you. Most projects these days operate in the classical integration approach where changes are not frequently made, the changes may be quite large and include changes in numerous files, and other developers do not have to use these changes until they are ready. The continuous integration approach applies the changes to the public very frequently, the changes are typically small and precise (change only what exactly needs to be changed) where one or few files are changed, and the developers must be ready to accept the changes after they have been successfully built and tested. Effectively, the continuous integration approach is a cultural shift for many developers who, following the classical approach model, like to work securely in their static workspace and not have to consider other changes until they are ready for them. The issue with the classic is that the changes from developers are not applied very frequently, therefore integration (e.g., merging) may become a significant and often painful effort. The continuous integration approach reduces the significant integration effort, but requires a different development methodology whereby developers are working on smaller change requests and change sets which require less time to complete. With all of this in mind, how would a group change from the classical approach to the continuous integration approach? In order to start applying the continuous integration approach, consideration should be given to what needs to be in place to make this happen. First, there must be a development methodology in place to support this new concept. Second, there must an infrastructure in place that can support the continuous integration approach. Development Methodology When considering the continuous integration approach, give thought to the development methodology. Continuous integration is much more effective when the work is chunked into smaller task. The requirements should be precisely written to represent small changes. The software should be developed in small increments or iterations. Testing needs to be integrated into this process.
With this in mind, there needs to be an intelligent and conscious effort to select a development methodology that supports small increment or iterative development. Broadly, Agile ideas are best suited for applying continuous integration. Inversely, continuous integration is a key element of many Agile related methodologies. An example of such a methodology is Extreme Programming (XP). Extreme programming defines practice areas that include (but not limited too) planning for small releases, focusing on only the changes that are necessary, making the change requests small and manageable, building and testing continuously, working in small groups particularly in pairs of developers, and building several times a day so all developers have the same baseline of code. To see all 12 practices areas, visit http://www.xprogramming.com/what_is_xp.htm . Other Agile related methodologies include Scrum, DSDM (Dynamic System Development Method), RUP (Rational Unified Process), and RAD (Rapid Application Development). Development process The next step is to take the methodology selected and establish a development process. An example may be the Project Manager plans very discrete chunks of work (or change requests) that can be completed within a short period of time as prescribed by the development methodology. This methodology works best when the development tasks are assigned to specific developers targeting specific and non-overlapping functionality to reduce or avoid significant merging activities. When the developer receives a change request, he checks out the very specific pieces of code, makes the change, builds and unit tests, then checks the code into the integration stream. Upon check-in, an integration build immediate occurs that includes testing. If this build and test are successful, the other developers are notified of these changes and they may synchronize their workspace with these changes. Cultural shift Effectively, in order to apply continuous integration, an agile related methodology must be considered and changes to your development processes must be made to support this approach. Given the adversity to change in most organizations, this is not small task. It represents a significant shift in the development and build process. It really focuses on small but steady progress. Integration should happen frequently possibly more than once a day, but this will vary from project to project depending on the nature of the work. It is better to start with a new and small project that is appropriate for using agile methodologies. This way, there is no existing culture and methodology to overcome and training can be applied that teaches the developers the new approach. Infrastructure What needs to be in place to integrate continuously? First, we need a fast and centralized server to integrate, build, and test the code quickly. Second, a solid CM technology is needed. Third, we need a continuous integration technology that supports automated builds and testing. In addition, while having successful builds is important, the automated testing piece is critical so that the changes pass specific test criteria before it is make publicly available. Once these are in place, you can create a continuous integration environment.
Since continuous integration implies frequent building, it is important to have a fairly fast and powerful server to handle the constant builds. The central server approach is needed so that the Continuous Integration technology can monitor the CM repository (both technologies needing to reside on the same server) so that they can work effectively together. CM technology It is important to have a quality Configuration Management (CM) technology in place. In relation to continuous integration, the CM technology needs to be available on a centralized server. Good CM tools to consider (but not limited too) are AccuRev, ClearCase, Perforce, and SerenaVM. There is also CVS, the freeware CM tool. Continuous integration technology The Continuous Integration technology is needed to monitor the CM repository in real time and then initiate events (e.g., kicks off the build, tests, and reports on the results) when it notices changes to the repository. There are various tools maturing in this space. They include: Using CruiseControl.Net as an example, this technology tracks the project’s CM repository for changes (based on check-ins), then uses NAnt to do the build. When the build is done (whether successful or broken), an email notification is sent to the development team. This then may initiate some testing. Since continuous integration implies frequent building, it is important to have a fairly fast and powerful server to handle the constant builds. The central server approach is needed so that the Continuous Integration technology can monitor the CM repository (both technologies needing to reside on the same server) so that they can work effectively together. It is important to have a quality Configuration Management (CM) technology in place. In relation to continuous integration, the CM technology needs to be available on a centralized server. Good CM tools to consider (but not limited too) are AccuRev, ClearCase, Perforce, and SerenaVM. There is also CVS, the freeware CM tool. The Continuous Integration technology is needed to monitor the CM repository in real time and then initiate events (e.g., kicks off the build, tests, and reports on the results) when it notices changes to the repository. There are various tools maturing in this space. They include: Using CruiseControl.Net as an example, this technology tracks the project’s CM repository for changes (based on check-ins), then uses NAnt to do the build. When the build is done (whether successful or broken), an email notification is sent to the development team. This then may initiate some testing.
Summary
Mario Moreira is a Columnist for CM Crossroads Journal, a Director/Architect of Technology, an Author of CM publications, and has worked in the SCM field since 1986. He has experience with numerous SCM technologies and processes and has implemented SCM on over 100 applications/products, which include establishing global SCM infrastructures. He has an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience. Mario has released a new SCM book entitled, “Software Configuration Management Implementation Roadmap”. You can find it at amazon.com www.amazon.com This book includes step-by-step guidance for implementing SCM at the organization, application, and project level and includes helpful templates on CD to get started. You may reach Mr. Moreira by email at Mario.Moreira@cmcrossroads.com
Set as favorite
Bookmark
Email this
Hits: 9333 Trackback(0)Comments (1)
|
TrackBack URI for this entry
Subscribe to this comment's feed
 |
... Well Written Mario. I completely agree with the points mentioned by you for the agile practice of continous integration. Thanks for the article |
