- 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
Fix Broken Builds Immediately
A broken build is anything that prevents the build from reporting success. This may be a compilation error, a failed test or inspection, a problem with the database, or a failed deployment. When operating in a CI environment, these problems must be fixed immediately; fortunately, in a CI environment, each error is discovered incrementally and therefore is likely very small. Some projects have a penalty for breaking the build, such as throwing some money in a jar or placing the picture of the last developer to break the build on the company's large-screen monitor (just kidding; hopefully no one is doing this). The project culture should convey that fixing a broken build is a top project priority. That way, not just some but every team member can then get back to what they were doing.