Explaining the Continuous Integration and Delivery Process Flow

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

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.

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.

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.

Note

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.

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.

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.

Hint

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

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.

Continuous Integration and Delivery Process Flows | SAP Help Portal

Continuous Integration Principles | SAP Help Portal