“Continuous Integration and Deployment is a software development practice where members of a team integrate and deploy their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.” – Martin Flower

Continuous Integration and Deployment is considered part of “DevOps” – Development and Operations. Therefore, like any new concept, it does have its origins and champions.

DevOps Has 4 Main Principles:

1. System Thinking
2. One Integrated Team (Dev + Ops = DevOps Team)
3. Automation
4. Continuous Feedback Cycle

DevOps Has 5 key Mindset Attributes:

1. Team Goals Vs Organizational Goals
2. Time to Market
3. Repeatability
4. Scalability
5. Size does not matter (organization/team size)

CI emerged as a best practice because software developers often work in isolation, and then they need to integrate their changes with the rest of the team’s code base. Waiting days or weeks to integrate code creates many merge conflicts, hard to fix bugs, diverging code strategies, and duplicated efforts. CI requires the development team’s code be merged to a shared version control branch continuously to avoid these problems. CI should be automated as stated in the 4 Principles.

CI aims to commit code frequently, reduce risks, reduce repetitive processes, generate deployable software, enable project visibility, and establish greater confidence.

Software projects involve lots of files that need to be orchestrated together to build a product. Keeping track of all of these is a major effort, particularly when there's multiple people involved. So, it's not surprising that over the years software development teams have built tools to manage all this. These tools - called Source Code Management tools, configuration management, version control systems, repositories, or various other names - are an integral part of most development projects.

CI keeps the master branch clean. Teams can leverage modern version control systems such as Git to create short-lived feature branches to isolate their work. A developer submits a “pull request” when the feature is complete and, on approval of the pull request, the changes get merged into the master branch. Then the developer can delete the previous feature branch. Development teams repeat the process for additional work. The team can establish branch policies to ensure the master branch meets desired quality criteria.

Teams use build definitions to ensure that every commit to the master branch triggers the automated build and testing processes. Implementing CI this way ensures bugs are caught earlier in the development cycle, which makes them less expensive to fix. Automated tests run for every build to ensure builds maintain a consistent quality.

A key part of doing a continuous build is that if the mainline build fails, it needs to be fixed right away. The whole point of working with CI is that you're always developing on a known stable base. It's not a bad thing for the mainline build to break, although if it's happening all the time it suggests people aren't being careful enough about updating and building locally before a commit. When the mainline build does break, however, it's important that it gets fixed fast.

Often the fastest way to fix the build is to revert the latest commit from the mainline, taking the system back to the last-known good build. Certainly, the team should not try to do any debugging on a broken mainline. Unless the cause for the breakage is immediately obvious, just revert the mainline and debug the problem on a development workstation.

Below are two visuals to illustrate the overall DevOps process followed by some popular tools:

Example of a Continuous Integration Workflow

CI Tools & Products to Consider When Setting Up a CI/CD Process