Principles of Continuous Integration (CI)

Continuous integration is a practice in which developers integrate codes in a shared repository multiple times a day. Now think a group of developers is working on the same project. A developer changes the copy of the codebase. Now when other developers submit code changes to the source code repository, the changes made by the previous developer stop reflecting. With codes being constantly changed, infrequent commits take place, and testing becomes late. If a long branch of code is not checked, it may lead to integration conflicts. When the developer branch is re-integrated with the main branch, bugs can percolate in/ The main repository becomes so different from the developers; branches that merging the changes becomes a hellish affair. So, many principles are there for successful continuous integration like: 

• Commit code frequently – It is important to commit code to the version repository regularly and frequently. Integrating early and frequently is the main principle of continuous integration.  
• Maintaining a single source code repository – Use a source code management system to serve as the main source code repository. By using the source code management tools, you can keep the code in a centralized location from where developers can access the most updated version of the build mainline. The scripts, property files, schema, and libraries created by developers should be pushed to this centralized source code repository.  
• Stop committing broken codes – You should detest from committing codes that fail tests or are non-functional. Developers should practice maintaining a private build before checking and pushing the code into the centralized repository. Developers should run the integration builds in their local development environment after code testing to prevent integration failures.  
• Undertaking build automation – The build process should be automated in a CI environment. This would help to build and launch the system using a single command of build scripts. The build process should include everything from sourcing the database schema from the central repository and employing it in the production environment. The build tools like Ant, MS Build, and Ruby Rake helps in build automation.   
• Broken builds should be fixed as soon as possible – Mainline build can break anytime. For ensuring continuous integration, we need to ensure that the mainline build is fixed immediately. The most effective way of fixing it is to undo the latest commit from the mainline.  

• Inducing self-testing capabilities in the build – Apart from the automated build, the tests for the CI system must also be automated. Automated tests and methods like test-driven development and extreme programming can test a huge chunk of codes for bugs. For running tests in an automated manner, the tests should be written in a xUnit framework like NUnit or Junit. The CI system must ensure that 100% of the tests are passed before committing to the central code repository. Clogging the mainline with codes that have not passed all the automated tests will result in poor-quality software. Various coverage tools help in ensuring that every code is tested.  
• Ensuring build of every commit on an integration machine – The frequent build should happen on an integration machine, and the build should be successful for the commit to be considered done. Once a commit is successful, the CI server checks the source code on the integration machine and starts a build. A developer who has committed the latest code should be made responsible for checking the mainline build. The output/status of the build process should be notified through mail to one who has committed.  
• Making the latest executable version easily accessible to all In the CI process – The latest executable version of the code must be made accessible to all the developers on the project.  
• Automating the deployment – It is important to automate deployments with scripts that help fast the process and reduce errors. Provisions for rollback should be there as failure can occur anytime.