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 seems 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 on 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 or even actually deploy the software.
The final status of the build and tests is recorded as the resulting status, and if it failed, team members are notified so that the problem can be fixed as soon as possible. Other reports, such as performance measurements, can also be published. After finishing, the server is ready to start the next integration, once there are new changes available.
There is a large variety of Continuous Integration software products available. The choice of tools depends on the company's and developers' skills and experiences, as well as on customer requirements. Equally important is the development environment and also target environment(s): under which operating system(s) the product will function, what are the programming languages and frameworks used, and what software will be integrated in to the product.
At Polaris Technology, we mainly use two different CI tools: Microsoft's Team Foundation Server (TFS) for .NET projects which also have their source code stored in TFS, and the open source tool Jenkins CI for all types of projects, whose source code is mostly stored in Git repositories. We can recommend either one of these tools to our clients.
The advantages of continuous integration are many, but ultimately they are all related to the software quality.
When all new code is integrated and goes through tests, any breaking errors or other major defects are very probably caught quickly. This way such bugs can't stay hidden for long. Quick error detection enables fixes to be applied almost immediately, before errors could affect other modules of the system. Fixing software bugs early in the development is also much less costly than fixing them days or even weeks later, once QC or end user has found them in manual testing or in regular use. The fast feedback loop saves resources, cutting costs and leading to direct financial benefits.
Another key aspect of software quality is maintainability. Continuous Integration practice encourages developers to divide their work into smaller (and easier to understand) tasks and commits to avoid breaking the build and causing errors. This supports code review process and makes the resulting code easier to read and modify in the future. The more maintainable code is less likely to contain hidden bugs, and making changes to it later, for example adding features, will be faster. CI thus promotes savings also in the future.
Polaris Technology 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 Continuous Delivery.