The pipeline will support full continuous integration. When developers push code to the shared source repository, that will trigger a build that produces a release candidate. The release candidates will be tagged Docker images that are stored in a local registry. The CI workflow deploys the solution from the built images as containers and runs an end-to-end test pack.

My sample pipeline has a manual quality gate. If the tests pass, the image versions are made publicly available on Docker Hub, and the pipeline can start a rolling upgrade in a public environment running on a remote Docker Swarm. In a full CI/CD environment, you can automate the deployment to production in your pipeline, too.

The stages of the pipeline will all be powered by software running in Docker containers:

• Source control: Gogs, a simple open source Git server written in Go
• Build server: Jenkins, a Java-based automation tool that uses plugins to support many workflows
• Build agent: The .NET SDK packaged into a Docker image to compile code in a container
• Test agent: NUnit packaged into a Docker image to run end-to-end tests against deployed code

Gogs and Jenkins can run in long-running containers on a Docker Swarm or on an individual Docker Engine. The build and test agents are task containers that will be run by Jenkins to perform the pipeline steps—then, they will exit. The release candidate will be deployed as a set of containers that are removed when the tests are completed.

The only requirement to set this up is to give containers access to the Docker API—both in the local and remote environments. On the local server, I'll use named pipes from Windows. For the remote Docker Swarm, I'll use a secured TCP connection. I covered securing the Docker API in Chapter 1, Getting Started with Docker on Windows, using the dockeronwindows/ch01-dockertls image to generate TLS certificates. You need to have local access configured so that the Jenkins container can create containers in development, and remote access so that Jenkins can start the rolling upgrade in the public environment.

The workflow for this pipeline starts when a developer pushes code to the Git server, which is running Gogs in a Docker container. Jenkins is configured to poll the Gogs repository, and it will start a build if there are any changes. All the custom components in the solution use multi-stage Dockerfiles, which are stored in the Git repository for the project. Jenkins runs docker image build commands for each Dockerfile, building the image on the same Docker host where Jenkins itself is running in a container.

When the builds complete, Jenkins deploys the solution locally as containers on the same Docker host. Then, it runs end-to-end tests, which are packaged in a Docker image and run as a container in the same Docker network as the application being tested. If all the tests pass, then the final pipeline step pushes these images as release candidates to the local registry, and the registry is also running in a Docker container.

When you run your development tools in Docker, you get the same benefits that you have when you run production workloads in Docker. The whole toolchain becomes portable, and you can run it wherever you like with minimal compute requirements.