The Purpose of Continuous Integration
Continuous integration is a way to applying quality control by integrates pieces by pieces of effort into project. When embarking a change, the developer takes a copy of the current code base on which he works on. As other developers submit changed code to the code repository, this copy gradually cease to reflect the repository code. When the developer submits his code to the repository they must first update their code to reflect the changes in the repository since they took their copy. If a lot of changes have happen to the repository, the more work the developer must do before submitting their own changes. If the repository becomes so different from the copy the developer is working on it becomes what is called as “integration hell”, where the time it takes to integrate exceeds the time it took to make their original changes. In a worst-cast scenario, the developer may have to discard their changes and redo the work. In order to avoid “integration hell” the practice of continuous integration is used. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
One warning when adapting CI!
The focus of integration and automated builds leads to a false feeling of secure, as long as it builds and all tests passes people tend to be satisfied. But in order to gain all benefits that you strive for, like getting feedback on just work done these test isn’t enough. In order to be as productive as possible you need to really test as close to the development as possible. You will save a lot of time if you find a bug or mistake that you done today or this week, rather something someone may have done to the code base during the last 6 month.
Continuous integration is like one apple a day, it keeps the debug doctor away. But it doesn’t gain its full power if you also complements with frequent testing and verification of the system.