In this lesson, you will examine how the Continuous Integration and Delivery process works.
Overview of the CI/CD Process
| Step | Description |
|---|---|
| 1. Code Change | Create a code change based on the latest version of your source code main line. |
| 2. Voter Build and Tests | Build and test each code change before merging it with the main line. |
| 3. Merge into the Main Line | Integrate your code change into the main line to create a new basis for further development. |
| 4. CI Build and Tests | Build your code change to check the build integrity of the main line. |
| 5. Acceptance Tests | Execute acceptance tests to ensure that your software can be deployed to production anytime. |
| 6. Manual Deployment to Production | Consciously decide on when to release a specific software version. |
Note
Remember: The Continuous Delivery concept expands on the one of Continuous Integration. It adds 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 Using Version Control: A source code management system manages 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 integrated into the main line risks 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. They "vote" for the changes 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.
Note
Collaboration tools (For example, GitHub, GitLab, or Gerrit Code Review) collect the feedback of human code reviewers together with the voter build and test results.
Integrating a code change leads to a new main line version, is a basis for further development. Adhere to the Commit Early and Often principle: 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 is the same as that for voter builds: The change is built and tested to a suitable extent to check the main line's build integrity. 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 must not only be successfully integrated into the main line but also be of such high quality that it could be released and deployed to production after each change. 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 tests the last successful CI build on each date.
- 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.
6. Manual Deployment to Production
A change can be deployed to the production system if it has successfully passed all acceptance tests. 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.
Summary
You are now able to describe each of the six steps of the CI/CD process and choose different ways to apply them.