Simple version of CICD Workflow

Above is my simple version of CICD workflow that I use as a guidance in day to day work. A bit explanations on how to use it.

The workflow has six stages and seven scenarios.

Six Stages:

1. Commit Change: When user commit changes to code repository.
2. Build Binary: When CI server builds the binary to include the latest changes.
3. Deploy UAT: When CI server deploys the binary to UAT environment.
4. Test UAT: When test plan is running against the UAT environment.
5. Deploy PROD: When CI server deploys the binary to PROD environment.
6. Test PROD: When test plan is running against the PROD environment.

According to your definition of CICD, its workflow may cover different stage:

Continuous Integration & Continuous Deployment : stage 1, 2, 3, (4). This ensures the latest codes are deployed to UAT environment automatically. And ideally, there is a automated test after the UAT deployment.

Continuous Integration & Continuous Delivery : stage 1, 2, 3, 4, 5, 6 . This follows ‘pass on green’ principle to automate the end to end process.  And it requires complex and very reliable automation test plans which may include unit test, regression test and capacity test.

Seven Scenarios:

1. Failed commit: Many VCS supports push or commit check. This is to ensure the changes meet certain criteria. e.g code of conduct, security checks. The commit will fail if it does not pass the checks.
2. Failed build: Most likely the change breaks the build, it could be syntax or logical error, or dependencies that could not be satisfied.
3. Failed UAT deployment: The new binary failed to run in the UAT environment. It could be caused by the associated deployment script does not work with the new binary, or some configurations are missed in the UAT environment that the new binary relies on.
4. Failed UAT test: The new UAT version failed to pass the test, it could be caused by the bugs or performance degradation that the new changes introduce in.
5. Failed PROD deployment: One of the golden rules of CICD is to only build binary once for each version, but deploy it multiple times. This is to ensure the exact same binary running in different environments, and the only difference is the configuration. e.g environment variables’ values, credentials… So if the deployment is successful in UAT, but failed in PROD. Then there is a big possibility that the configuration is not right.
6. Failed PROD test: Less likely but still possible. Additionally, some tests only can be done in PROD. So for some cases you never know until you test it in PROD. The techniques to minimize the risks are in stage ‘Deploy PROD’, e.g blue-green deployment, canary release, dark release.
7. Successful delivery: Only when the latest codes run smoothly in production, then we can call it is a successful delivery.