Continuous Integration and Continuous Delivery

Continuous Integration and Continuous Delivery, or CI->CD as they are better known in the software industry, have become a fundamental component of the DevOps movement. The implementation of these practices varies across many organizations. The implementation varies due to a significant variance in CI/CD maturity and evolution.

Continuous Integration represents a foundation for a completely automated build and deployment solution and is usually the starting point in a CI/CD quest. Continuous Integration represents a specific set of development practices, which aim to validate each change to a source-controlled software system through automation. The specific practice of CI in many regards also represents mainline software development coupled with a set of basic verification systems to ensure the commit didn't cause any code compilation issues and does not contain any known landmines.

The general practice of CI is provided here:

1. A developer commits code changes to a source-control system mainline (Per Martin Fowler's invention of CI concepts) performed at least once a day. This is to ensure that code is collaborated on EVEN if they are incomplete.
2. An automation system detects the check-in and validates that the code can be compiled (syntax check).
3. The same automation system executes a set of unit tests against the newly updated code base.
4. The system notifies the committer if there are any identifiable defects related to the check-in.

If at the end of the CI cycle for a given commit there exist any identifiable defects, the committer has two potential options:

1. Fix the issue quickly.
2. Revert the change from the source control (to ensure the system is in a known working state).

While the practice of CI may sound quite easy, in many ways, it's quite difficult for development organizations to implement. This is usually related to the cultural atmosphere of the team and organization.

Continuous Delivery represents a continuation of CI and requires CI as a foundational starting point. Continuous Delivery aims to start by validating each committed change to a software system through the basic CI process described earlier. The main addition that Continuous Delivery offers is that, once the validation of the code change is completed, the CD system will deploy (install) the software onto a mock environment and perform additional testing as a result.

The Continuous Delivery practice aims to provide instant feedback to developers on the quality of their commit and the potential reliability of their code base. The end goal is to keep the software in a releasable form at all times. When implemented correctly, CI/CD provides significant business value to the organization and can help reduce wasted development cycles debugging complex merges and commits that don't actually work or provide business value.

Based on what we described previously, Continuous Delivery has the following basic flow of operations:

• User commits code to source-control mainline
• Automated CI process detects the change
• Automated CI process builds/syntax-checks the code base for compilation issues
• Automated CI process creates a uniquely versioned deployable package
• Automated CI process pushes the package to an artifact repository
• Automated CD process pulls the package onto a given environment
• Automated CD process deploys/installs the package onto the environment
• Automated CD process executes a set of automated tests against the environment
• Automated CD process reports any failures
• Automated CD process deploys the package onto additional environments
• Automated CD process allows additional manual testing and validation

Generally, the CI/CD process flow would look like this:

• Continuous Integration:

• Flow of Continuous Delivery:

• Components of Continuous Delivery: