Continuous Integration (CI) means that every change to the code is added to the project soon after its written, and then immediately tested for defects. This ensures that a defective code change is detected straight away and if anything “breaks” the product, it can be quickly fixed, either by rolling back the change or finding and correcting the error in the newly submitted code.
CI is considered one of the key Agile software development practices, originating from the so called Extreme Programming (XP) approach. It has become popular by virtue of presenting measurable benefits to both software vendors and customers in better quality, faster time-to-market, lower costs and decreased stress levels throughout the whole software development process.
Although continuous integration may seem like a major change in how to run software development, the process itself is fairly straightforward to follow. It is based on Automated Build Process, but instead of just running the automated build in a single developer’s own local machine, CI always involves the whole team or the whole project.
Continuous Integration normally requires 2 servers: one to store the source code of the project, and the other one to run the software that actually does the integration continuously by building the project automatically from the newest source code, and then executing the automated tests. Depending on the project setup, these servers can also reside in the same physical machine.
Each developer submits, or commits, the changes of the code they have been working on to the repository in source code management server, so that all other developers have access to the newest changes. This is normal version control practice that is a necessity for any professional software development project.
In continuous integration, the CI server monitors the source code repository for changes. In practice, this may mean either that the repository notifies the CI server when it changes and triggers the CI process, or that the CI server accesses the repository periodically and finds out if it has been changed in the meantime. The latter is called polling, and can be done with any interval, for example once every minute.
Once CI server gets information that the source code has been changed, it accesses the repository, downloads the changed files and integrates them in the CI server copy of the project code. Then the automated build is run and the result (success or failure) is recorded. After a successful build, a suite of the project’s automated tests is executed, and again the results are recorded, often using a 3-level scale of success, unstable (some problems detected) or failure (failing tests or other errors). Additionally, the CI server may also perform other tasks, like package the built product to be ready for deployment, or even actually deploy the software.
Conceptbux applies Continuous Integration to all our internal projects. When working with clients, we give the priority to client’s wishes and requirements regarding the software development process. If your own process allows the initial use of extra resources to set up Continuous Integration properly, we recommend you to apply it to your software development project with us. With successful Continuous Integration in place, we can work together to the next step, allowing your releases to be increasingly flexible with.