- 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
Commit Code Frequently
One of the central tenets of CI is integrating early and often. Developers must commit code frequently in order to realize the benefits of CI. Waiting more than a day or so to commit code to the version control repository makes integration time-consuming and may prevent developers from being able to use the latest changes. Try one or both of these techniques to commit code more frequently.
- Make small changes—Try not to change many components all at once. Instead, choose a small task, write the tests and source code, run your tests, and then commit your code to the version control repository.
- Commit after each task—Assuming tasks/work items have been broken up so that they can be finished in a few hours, some development shops require developers to commit their code as they complete each task.
Try to avoid having everyone commit at the same time every day. You'll find that there are usually many more build errors to manage because of the collisions between changes. This is especially troublesome at the end of the day, when people are ready to leave. The longer you wait to integrate with others, the more difficult your integration will prove to be.