This chapter covered CI/CD in Docker with a sample deployment workflow configured in Jenkins. Every part of the process I demonstrated ran in Docker containers: the Git server, Jenkins itself, the build agents, the test agents, and the local registry.

You saw that it is straightforward to run your own development infrastructure with Docker, giving you an alternative to hosted services. It's also straightforward to use these services for your own deployment workflow, whether it's full CI/CD or separate workflows with a gated manual step.

You saw how to configure and run the Gogs Git server and the Jenkins automation server in Docker to power the workflow. I used multi-stage builds for all the images in my latest cut of the NerdDinner code, which means that I can have a very simple Jenkins setup with no need to deploy any toolchains or SDKs.

My CI pipeline was triggered from a developer pushing changes to Git. The build job pulled the source, compiled the application components, built them into Docker images, and ran a local deployment of the app in Docker. It then ran end-to-end tests in another container, and if they passed, it tagged and pushed all the images to the local registry.

I demonstrated a manual deployment step with a job that the user initiates, specifying the built version to be deployed. This job pushes the built images to the public Docker Hub and deploys an update to the public environment by deploying the stack on a Docker Swarm running in Azure.

There are no hard dependencies on any of the technologies I used in this chapter. The process I implemented with Gogs, Jenkins, and the open source registry can just as easily be implemented with hosted services like GitHub, AppVeyor, and Docker Hub. All the steps of this process use simple PowerShell scripts and can be run on any stack that supports Docker.

In the next chapter I'll step back to the developer experience and look at the practicalities of running, debugging, and troubleshooting applications in containers.