Continuous integration (CI) has received a lot of attention over the past several years and has been given quite the blogosphere treatment on how much it improves the quality of software.
If that is the case, why has it still not really taken hold in corporate environments or spread like wildfire through the software development community? I think many companies don't understand that CI's major benefit is that it can help reduce risk.
If you or your company are still on the fence about using CI, here's an overview of what it is and what it offers a company delivering software solutions to their customers.
What is CI?
CI is a process in which developers integrate their work constantly, build constantly, and test constantly so errors in code can be detected more quickly. CI includes five main steps and one pre-step.
Step 0: You must have a source code repository where code is versioned.
Most companies that produce software already use some sort of source code management (SCM) tool along the lines of Perforce. Without this pre-step in place, CI is likely impossible.
Step 1: Integrate work frequently, with each member integrating at least once daily.
I think this is a main sticking point because development teams are frequently understaffed and "siloed". To get teams to work together and make a habit of frequent, dependent check-ins of changes seems to be the Achilles heel of cooperative development. In order to make CI work, this culture-resistance must be overcome.
Step 2: Verify each integration with an automated build.
In order to achieve this step, there must be some sort of build framework in place. CruiseControl is likely the most popular open-source CI tool on the market, but there are plenty of utilities out there at varying prices.
In order to get this piece in place, research is required for what will fit your group the best. If you're in an enterprise environment, chances are, VB scripts are not going to cut it six months from now; you must evaluate this toolset with care.
Step 3: Integrate testing within each build.
In order to build effectively, it makes sense to have some sort of verification testing during the build. There are many testing frameworks available, such as FitNesse, NUnit, and MSTest. While writing initial build-level tests during the compilation of code certainly does not eliminate all bugs, this is really a coding basic and best practice.
This is another area to incorporate into a possibly culture-resistant environment. In understaffed organizations where software development is not the primary industry, the importance of spending the time up-front to write unit tests to run with each build is a hard sell. "Code it now and fix it later" is the main enemy of this particular step, which has been proven to be more costly in the long run.
Step 4: Show everyone what happened.
Regardless of the build and deployment framework you're using, seeing the history and a log of failures is crucial to rapid correction and redeployment. In silo groups where development is done in a vacuum, getting the development team to understand the importance of centralized and shared information is something that must be emphasized.
CruiseControl has a very clean dashboard and makes it easy to see the success or failure of each application and the log of choice (depending on what build script you chose to grab and compile it). In this case, the dashboard is just a Web page.
Step 5: Automate the deployment.
It is important to understand that "build" is not "deployment (release)". After an application is built, a deployment strategy of sorts should be crafted. Where are you releasing your successfully built application? How are you going to roll it back should it fail in a given environment? Using basic XCopy commands or another deployment script is something that should be fully considered.
Figure A shows the CI build process.
Figure A
Basic build process with CI
The value of CI
CI's greatest value is reducing risk. It allows teams to identify defects and fix them earlier in the software lifecycle, so problems are caught before a release occurs. This is accomplished by building changes as soon as they're made and giving the development team immediate feedback to the state of the change made.
Building often means the overall health of an application can be reviewed and action can be taken if needed. By automating the process and logging the successes or failures associated with them, builds can run the same way every single time and provide enough detail to see what happened.
This means variables in a manual build process are all but eliminated. By streamlining the build and the test process, CI enables more solid deployment, again reducing the complexity associated with problems arising from inconsistent build practices.
If CI has not been considered as a development practice or even from a business perspective in your organization, it is time to visit this concept and start making it a reality. Regardless of the size of a company, if software is being delivered, CI offers a lot to ensure good quality code is delivered to customers within an organization or outside of one.
Good, quality code means less maintenance, happier customers, and happier developers. That happens to translate well to the financial bottom line, even if there is more effort initially to put it into practice.
So… why is CI still not adopted?
A lot of companies may fail to realize how important basic software creation fundamentals really are, so adopting a concept that is very much a software quality issue and an integration best practice can take a back seat to user demands.
There is not a clear-cut way to easily show how changing a development team behavior translates to the bottom-line cost savings with quicker and more stable release cycles, so the path of least resistance is favored: just write some code and get it out the door.
It's also possible that programmers in certain environments are not accustomed to receiving feedback from any centralized process. They code, they check in, life is good, and they fix it later if something goes wrong. When these two realities coexist in the same environment, a change-resistant culture is likely adopted with one reinforcing and encouraging the other. This creates a vicious cycle.
At the core of these two extremes, I believe companies don't understand the risk factor and how CI helps to diminish it while increasing the visibility of the issues at hand.
Additional resources about CI
Martin Fowler, who is arguably the father of CI, covers this topic in more detail in this white paper on martinfowler.com.
Check out an excellent book entitled "Continuous Integration: Improving Software Quality and Reducing Risk". You can also download a chapter from this Jolt-award winning title.
Read the TechRepublic tutorial, Hunt down buggy .NET code faster with continuous integration, in which Tony Patton explains how you can use CI to automate the build process and provide instant feedback on .NET coding errors.