We'll try to define a minimum set of steps any continuous deployment pipeline should execute. Do not take them literally. Every company is different, and every project has something special. You will likely have to extend them to suit your particular needs. However, that should not be a problem. Once we get a grip on those, that are mandatory, extending the process should be relatively straightforward, except if you need to interact with tools that do not have a well-defined API nor a good CLI. If that's the case, my recommendation is to drop those tools. They're not worthy of the suffering they often impose.
We can split the pipeline into several stages. We'll need to build the artifacts (after running static tests and analysis). We have to run functional tests because unit testing is not enough. We need to create a release and deploy it somewhere (hopefully to production). No matter how much we trust the earlier stages, we do have to run tests to validate that the deployment (to production) was successful.
Finally, we need to do some cleanup at the end of the process and remove all the processes created for the Pipeline. It would be pointless to leave them running idle.
All in all, the stages are as follows.
- Build stage
- Functional testing stage
- Release stage
- Deploy stage
- Production testing stage
- Cleanup stage
Here's the plan. In the build stage, we'll build a Docker image and push it to a registry (in our case Docker Hub). However, since building untested artifacts should be stopped, we are going to run static tests before the actual build. Once our Docker image is pushed, we'll deploy the application and run tests against it. If everything works as expected, we'll make a new release and deploy it to production. To be on the safe side, we'll run another round of tests to validate that the deployment was indeed successful in production. Finally, we'll clean up the system by removing everything except the production release.
We'll discuss the steps of each of those stages later on. For now, we need a cluster we'll use for the hands-on exercises that'll help us get a better understanding of the pipeline we'll build later. If we are successful with the manually executed steps, writing pipeline script should be relatively simple.