Continuous integration/continuous deployment (CI/CD) is a modern development process designed to streamline the software delivery product life cycle (SDLC) by merging changes frequently and deploying those changes often. CI addresses the issues that arise in enterprise software development where multiple programmers are working on the same code base or when a single product is managed with multiple code branches.

Take a look at the following diagram:

In the preceding example, there are three target environments: Development, User Acceptance Testing (UAT), and Production. The Development environment is the initial environment where all the changes made to an application are tested together. The UAT environment is used by the Quality Assurance (QA) team to verify the system is working as intended before the changes are moved to a customer-facing environment, referred to in the diagram as Production. The code base has been broken into three matching branches: the trunk which all changes by the development team are merged into, UAT, which is used to deploy to the UAT environment, and the Production code base, which is used to deploy into the Production environment. 

The CI pattern is applied by creating a new build when the code base changes. After a successful build, a suite of unit tests is run against the build to ensure existing functionality has not been broken. If a build is not successful, the development team investigates and either fixes the code base or the unit test so the build then passes. 

Successful builds are then pushed to a target environment. The Trunk might be set to push a new build automatically once a day to the Integration environment, while the QA team has requested less disturbance in the environment, so a new build is only pushed once a week after office hours. Production might require a manual trigger to coordinate new releases as to announce the new features and bug fixes in a formal release.

The trigger to cause a merge between environments and therefore a build to be pushed to an environment, or released, might differ. In our illustration for the Development environment, we have a set of automated tests that are run against new builds automatically. If the tests are successful, then the merge is automatically performed from the Trunk to the UAT code base. The merge between UAT and Production code bases is only performed once the QA team has signed off or accepted the changes in the UAT environment.

Each enterprise will tailor the CI/CD process to fit their particular SDLC and business requirements. A public-facing website, for example, might require a rapid SDLC to stay competitive in the market, whereas an internal application might require a more conservative approach to limit the disruption caused by changing functionality without staff training.

Regardless, suites of tools have been developed to manage the CI/CD process within an organization. Azure DevOps, for example, helps to manage this process by allowing for a pipeline to be built to handle when builds are created and when they are released to environments, including both manual and automated triggers.