Explaining the Continuous Integration and Delivery Process Flow


After completing this lesson, you will be able to:

  • Describe the CI/CD process flow

The CI/CD Process Flow

In this lesson, you will have a closer look at how the Continuous Integration and Delivery process works.

Overview of the CI/CD Process

1. Code ChangeCreate a code change that is based on the latest version of your source code main line.
2. Voter Build and TestsBuild and test each code change before merging it with the main line.
3. Merge into the Main LineIntegrate your code change into the main line to create a new basis for further development.
4. CI Build and TestsBuild your code change to check the build integrity of the main line.
5. Acceptance TestsExecute acceptance tests to ensure that your software can be deployed to production anytime.
6. Manual Deployment to ProductionConsciously decide on when to release a specific software version.
Remember: The continuous delivery concept expands on the one of continuous integration. It adds the aspect that any change that has successfully passed the tests is immediately ready to be deployed to production, both from a technical and qualitative point of view.

1. Code Change

The first step in a CI/CD process builds on the principle Use Version Control: Use a source code management system to manage different versions and define a main line.

2. Voter Build and Tests

The second step in a CI/CD process is based on the principle Build Each Change: use so-called voter builds to automatically build and test each change that goes into the main line.

Each change that is integrated into the main line bears the risk of destabilizing it and affecting other developers who rely on its integrity. To protect the main line from erroneous code, you can use so-called voter builds that automatically build proposed changes, validate them, and provide feedback about the outcome. Thereby, they "vote" for the changes that are allowed to enter the main code.

3. Merge into the Main Line

If the code change has successfully passed the voter build and tests and meets all other prerequisites you have defined, it can be merged into the main line. Depending on the policies within the development team, this process is either triggered automatically or manually, for example, by the responsible developer, the reviewer, or the team architect.


Use collaboration tools (e.g., GitHub, GitLab, or Gerrit Code Review) to collect the feedback of human code reviewers together with the voter build and test results.

The integration of a code change leads to a new main line version, which serves as basis for further development. Make sure to adhere to the principle Commit Early and Often: integrate your changes into the main line frequently and in small bits.

4. CI Build and Tests

In the fourth step of a CI/CD process, you test your changes through an automated build.

Merging a code change into the main line automatically triggers the CI build. From a technical point of view, the build procedure equals the one for voter builds: The change is built and tested to a suitable extent to check the build integrity of the main line. After this step, the change is successfully integrated into the main line.

The following diagram illustrates this procedure:

Now, the development team can follow one of two options:

  • following the concept of Continuous Integration, the process starts over, again.
  • following the concept of Continuous Delivery, you can run additional tests and manually deploy the new main line version to production, if needed. See the following steps.

5. Acceptance Tests

In a Continuous Delivery scenario, the change does not only have to be successfully integrated into the main line but after each change, the product must be of such high quality that it could potentially be released and deployed to production. To ensure this quality, the change is deployed to an acceptance test system, which corresponds to the productive run-time system.

Acceptance tests are rather time-consuming and during their execution, the system must be stable and undisturbed by any additional changes. Therefore, not all changes are acceptance tested. Instead, there are two options on how to decide which of them to check:

  • implement an automation, which at a fixed time each date tests the last successful CI build.
  • The quality manager (or any other responsible person) consciously chooses the test candidates and manually triggers their acceptance testing.

Although you should automate your tests as far as possible, make sure to include some manual testing, as well.

6. Manual Deployment to Production

If a change has successfully passed all acceptance tests, it is ready to be deployed to the production system. As in most cases, a human (such as a release manager or application operator) must assume responsibility for the shipment and explicitly decide whether or not to release, the deployment to production is triggered manually. You can, however, use an automated framework to support this manual step.


You are now able to describe each of the six steps of the CI/CD process and choose different ways to apply them.

Log in to track your progress & complete quizzes