␡
- 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
This chapter is from the book
What Prevents Teams from Using CI?
If CI has so many benefits, then what would prevent a development team from continuously integrating software on its projects? Often, it is a combination of concerns.
- Increased overhead in maintaining the CI system—This is usually a misguided perception, because the need to integrate, test, inspect, and deploy exists regardless of whether you are using CI. Managing a robust CI system is better than managing manual processes. Manage the CI system or be controlled by the manual processes. Ironically, complicated multiplatform projects are the ones that need CI the most, yet these projects often resist the practice as being "too much extra work."
- Too much change—Some may feel there are too many processes that need to change to achieve CI for their legacy project. An incremental approach to CI is most effective; first add builds and tests with a lower occurrence (for example, a daily build), then increase the frequency as everyone gets comfortable with the results.
- Too many failed builds—Typically, this occurs when developers are not performing a private build prior to committing their code to the version control repository. It could be that a developer forgot to check in a file or had some failed tests. Rapid response is imperative when using CI because of the frequency of changes.
- Additional hardware/software costs—To effectively use CI, a separate integration machine should be acquired, which is a nominal expense when compared to the more expensive costs of finding problems later in the development lifecycle.
- Developers should be performing these activities—Sometimes management feels like CI is just duplicating the activities that developers should be performing anyway. Yes, developers should be performing some of these activities, but they need to perform them more effectively and reliably in a separate environment. Leveraging automated tools can improve the efficiency and frequency of these activities. Additionally, it ensures that these activities are performed in a clean environment, which will reduce assumptions and lead to better decision making.