Continuous Integration

Continuous Integration (CI) is a software engineering practice in which developers are required to regularly (at least daily) merge their code changes into a central/shared repository. Each check-in is then verified by an automated build, allowing teams to detect problems early.

Grady Booch first named and proposed CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating code more than once per day.

CI not only could be used in Agile or Extreme Programming but traditional development approaches, such as the Waterfall model can also get benefitted from using CI methods for the construction stage.

Continuous integration software tools can be used to automate the testing and build a document trail. CI keeps the entire development team in sync, removing the delays due to integration issues. When used properly, continuous integration provides various benefits, such as constant feedback on the status of the software, as code changes are immediately tested and reported on, when they are added to a larger code base. Continuous Integration also improves Software Quality and Reduces Risk.Continuous integration entails both an automation component (e.g. a CI or build service) and a cultural component (e.g. learning to integrate frequently).

Continuous integration (CI) vs. continuous delivery (CD) vs. continuous deployment

Continuous integration, requires developers to integrates/merge their work/changes regularly (at least daily or, preferably, multiple times a day) with the main branch of source code or a central/shared repository. Continuous delivery, another DevOps practice, picks up where continuous integration ends, focuses on automating the delivering of any validated changes to the applications (like updates, bug fixes, even new features) to users as quickly and safely as possible. Continuous deployment is the migration of changes into a selected environment like production. It streamlines the process using automated testing to validate code base changes, and ensures the automation of pushing code changes to different environments. Continuous deployment aims at minimizing the lead time between development and the change being available to live user.

CI-CD Process

Typical CI-CD process gets improved with DevOps implementation.

CI-CD Process

Issues with traditional Integration & Build Process
Please leave a feedback on thisx

In the past, developers on a team might work in isolation for an extended period of time and only attempt to merge their changes to the master branch once their work was completed. This batched process made merging accumulated code changes difficult and time-consuming. This is compounded when small bugs accumulate for a long time without correction. These factors combined made it harder to deliver updates to customers quickly. With continuous integration, developers frequently commit codes to a shared repository using a version control system such as Git. Prior to each commit, developers may choose to run local unit tests on their code as an extra verification layer before integrating. A continuous integration service detects commits to the shared repository, and automatically builds and runs unit tests on the new code changes to immediately surface any functional or integration errors. If necessary, partially completed features can be disabled before commit, such as by using feature toggles. Organizations using CI typically use a build server to implement continuous processes of applying quality control like in addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes (if required).


Continuous Delivery expands upon Continuous Integration by deploying all code changes to a testing environment and/or a production environment after the build stage. With continuous delivery, code changes are automatically built, tested, and prepared for a release to production. DevOps play a very important role in achieving Continuous Integration (CI) and Continuous Delivery (CD).

Practices of Continuous Integration:
Please leave a feedback on thisx

  • Maintain a Single Source Repository
  • Automate the Build
  • Make Your Build Self-Testing
  • Everyone Commits To the Mainline Every Day
  • Every Commit Should Build the Mainline on an Integration Machine
  • Fix Broken Builds Immediately
  • Keep the Build Fast
  • Test in a Clone of the Production Environment
  • Make it Easy for Anyone to Get the Latest Executable
  • Everyone can see what’s happening
  • Automate Deployment

For the success of CI setup it is very important that team understand and make the habit of frequently check-in code, and resolve any broken build ASAP.

As there are different development track used across the organizations, selecting right combination of tools for these tracks, domain, culture, infrastructure and environment are sometimes tricky.

  • Mainframe track
  • .Net track
  • Java track,
  • other tracks

Here is sample toolchain that is used for mainframe track

Here is sample toolchain that is used for .net track

NOTE: As the my intention is to give high-level prospective, i have just mentioned some well known or widely used tool. I have intentionally left tool suggestions for some of the steps. Those are are involved in engineering transformation could better decide the most suitable tools based on tracks, domain, culture, infrastructure and environment.

@Mohammad Sami -Agile Transformation Coach

Also check my blog on Continuous Delivery (CD): Continuous Delivery (CD) is the process that moves codes from Test environment to Acceptance environment to Prod environment, taking out dependency from human being and reassign dependency on process with high degree of automation where releasing software becomes routine. Please see my blog on Continuous Delivery.

Also check my blog on Liquid Delivery: The term “Liquid“ represent the continuous flow of something. In the context of application delivery it is called “Liquid Delivery“. “Liquid“ is more than just a new approach to application development. It’s the foundation upon which you can build your business for future growth and competitive advantage. In the new order, the ability to roll out business capabilities continuously will be the difference between companies that can evolve and ones that stagnate. Please see my blog on “Liquid Delivery”.

NOTE: Please note that due to some technical issues we have lost users comments until February 2022. My apologies. Please do comment and share your thoughts in the comments below

5 1 vote
Article Rating

You may also like...

5 1 vote
Article Rating
Notify of

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x