- A Day in the Life of CI
- What Is the Value of CI?
- What Prevents Teams from Using CI?
- How Do I Get to "Continuous" Integration?
- When and How Should a Project Implement CI?
- The Evolution of Integration
- How Does CI Complement Other Development Practices?
- How Long Does CI Take to Set Up?
- CI and You
- Commit Code Frequently
- Don't Commit Broken Code
- Fix Broken Builds Immediately
- Write Automated Developer Tests
- All Tests and Inspections Must Pass
- Run Private Builds
- Avoid Getting Broken Code
- Summary
- Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
How Do I Get to "Continuous" Integration?
It's often surprising to learn the level of automation of most development organizations. Developers spend most of their time automating processes for their users, yet don't always see ways to automate their own development processes. Sometimes teams believe their automation is sufficient because they've written a few scripts to eliminate some steps in the development process. The following is a typical scenario.
- Joan (Developer): …I already automated that. I wrote some batch scripts that drop and recreate the database tables.
- Sue (Technical Lead): That's great. Did you apply it to the CVS repository?
- Joan: No.
- Sue: Did you make it a part of the build script?
- Joan: No.
- Sue: So, if it's not a part of the CI system then it's not really automated yet… right?
CI is not just the process of gathering a few scripts together and running them all the time. In the preceding scenario, it's great that Joan wrote those automation scripts, but in order for them to actually add value to the end product, they must be added to the version control repository and made a working part of the build process. Figure 2-2 illustrates the steps to making a process continuous.
)
Figure 2-2 Getting to CI—"I Build So Consistently"
These steps can be applied one by one to virtually every activity you conduct on a project.
- Identify—Identify a process that requires automation. The process may be in the areas of compilation, test, inspection, deployment, database integration, and so on.
- Build—Creating a build script makes the automation repeatable and consistent. Build scripts can be constructed in NAnt for the .NET platform, Ant for the Java platform, and Rake for Ruby, just to name a few.
- Share—By using a version control system such as Subversion, you make it possible for others to use these scripts/programs. Now the value is being spread consistently across the project.
- Make it continuous—Ensure that the automated process is run with every change applied, using a CI server. If your team has the discipline, you can also choose to manually run the build with every change applied to the version control system.
Here is an acrostic to help you remember and communicate this: "I Build So Consistently"—for Identify, Build, Share, and Continuous.
Aim for incremental growth in your CI system. This is simple to implement, the team gets more motivated as each new item is added, and you can better plan what you need next based on what's working so far. Often, attempting to throw everything into a CI system immediately can be a bad move, just like refactoring a lot of code at once isn't the best approach when writing software. Get it to work first, get developers using it, and then add other automated processes as needed based on the project risks.