Building the CD process
So far, we've introduced the idea, benefits, and prerequisites concerning the CD process. In this section, we will describe the tools that will be used throughout this book and their place in the system as a whole.
Information
If you're interested in the idea of the CD process, have a look at the excellent book by Jez Humble and David Farley, called Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.
Introducing tools
First of all, the tool is always less important than understanding its role in the process. In other words, any tool can be replaced with another one that plays the same role. For example, Jenkins can be replaced with Atlassian Bamboo, and Chef can be used instead of Ansible. This is why each chapter will begin with a general description of why such a tool is necessary and its role in the whole process. Then, the tool will be described in comparison to its substitutes. This will give you the flexibility to choose the right one for your environment.
Another approach could be to describe the CD process at the idea level; however, I strongly believe that giving an exact example, along with the code extract – something that you can run by yourself – results in a much better understanding of the concept.
Information
There are two ways to read this book. The first is to read and understand the concepts of the CD process. The second is to create an environment and execute all the scripts while reading to understand the details.
Let's take a quick look at the tools we will use throughout this book. This section, however, is only a brief introduction to each technology – more details will be provided later in this book.
The Docker ecosystem
Docker, as the clear leader of the containerization movement, has dominated the software industry in recent years. It allows us to package an application in an environment-agnostic image and treats servers as a farm of resources, rather than machines that must be configured for each application. Docker was a clear choice for this book because it fits the (micro) service world and the CD process.
Docker entails several additional technologies, as follows:
- Docker Hub: This is a registry for Docker images
- Kubernetes: This is a container orchestrator
Information
In the first edition of this book, Docker Compose and Docker Swarm were presented as tools for clustering and scheduling multi-container applications. Since that time, however, Kubernetes has become the market leader and is used instead.
Jenkins
Jenkins is by far the most popular automation server on the market. It helps create CI and CD pipelines and, in general, any other automated sequence of scripts. Highly plugin-oriented, it has a great community that constantly extends it with new features. What's more, it allows us to write the pipeline as code and supports distributed build environments.
Ansible
Ansible is an automation tool that helps with software provisioning, configuration management, and application deployment. It is trending faster than any other configuration management engine and will soon overtake its two main competitors: Chef and Puppet. It uses an agentless architecture and integrates smoothly with Docker.
GitHub
GitHub is the best of all hosted version control systems. It provides a very stable system, a great web-based UI, and a free service for public repositories. Having said that, any source control management service or tool will work with CD, irrespective of whether it's in the cloud or self-hosted, and whether it's based on Git, SVN, Mercurial, or any other tool.
Java/Spring Boot/Gradle
Java has been the most popular programming language for years. That's why it will be used for most of the code examples in this book. Together with Java, most companies develop with the Spring framework, so we used it to create a simple web service to explain some concepts. Gradle is used as a build tool. It's still less popular than Maven, but it's trending much faster. As always, any programming language, framework, or build tool can be exchanged and the CD process would stay the same, so don't worry if your technology stack is different.
The other tools
Cucumber was chosen arbitrarily as the acceptance testing framework. Other similar solutions are FitNesse and Jbehave. For the database migration process, we will use Flyway, but any other tool would do, such as Liquibase.
Creating a complete CD system
You can look at how this book is organized from two perspectives.
The first one is based on the steps of the automated deployment pipeline. Each chapter takes you closer to the complete CD process. If you look at the names of the chapters, some of them are even named like the pipeline phases:
- The CI pipeline
- Automated acceptance testing
- Configuration management with Ansible
The rest of the chapters provide an introduction, summary, or additional information that's complementary to the process.
There is also a second perspective to the content of this book. Each chapter describes one piece of the environment, which, in turn, is well prepared for the CD process. In other words, this book presents, step by step, technology by technology, how to build a complete system. To help you get a feel of what we plan to build throughout this book, let's have a look at how the system will evolve in each chapter.
Note
Don't worry if you don't understand the concepts and terminology at this point. We will be learning everything from scratch in the corresponding chapters.
Introducing Docker
In Chapter 2, Introducing Docker, we will start from the center of our system and build a working application that's been packaged as a Docker image. The output of this chapter is presented in the following diagram:
Figure 1.8 – Introducing Docker
A dockerized application (web service) is run as a container on a Docker Host and is reachable as it will run directly on the host machine. This is possible thanks to port forwarding (port publishing in Docker's terminology).
Configuring Jenkins
In Chapter 3, Configuring Jenkins, we will prepare the Jenkins environment. Thanks to the support of multiple agent (slave) nodes, it can handle the heavy concurrent load. The result is presented in the following diagram:
Figure 1.9 – Configuring Jenkins
The Jenkins master accepts a build request, but the execution is started at one of the Jenkins Slave (agent) machines. Such an approach provides horizontal scaling of the Jenkins environment.
The CI pipeline
In Chapter 4, Continuous Integration Pipeline, we'll show you how to create the first phase of the CD pipeline: the commit stage. The output of this chapter is shown in the following diagram:
Figure 1.10 – The CI pipeline
The application is a simple web service written in Java with the Spring Boot framework. Gradle is used as a build tool and GitHub is used as the source code repository. Every commit to GitHub automatically triggers the Jenkins build, which uses Gradle to compile Java code, run unit tests, and perform additional checks (code coverage, static code analysis, and so on). Once the Jenkins build is complete, a notification is sent to the developers.
After this chapter, you will be able to create a complete CI pipeline.
Automated acceptance testing
In Chapter 5, Automated Acceptance Testing, we'll merge the two technologies mentioned in this book's title: Docker and Jenkins. This will result in the system presented in the following diagram:
Figure 1.11 – Automated acceptance testing
The additional elements in the preceding diagram are related to the automated acceptance testing stage:
- Docker Registry: After the CI phase, the application is packaged into a JAR file and then as a Docker image. That image is then pushed to the Docker Registry, which acts as storage for dockerized applications.
- Docker Host: Before performing the acceptance test suite, the application must be started. Jenkins triggers a Docker Host machine to pull the dockerized application from the Docker Registry and starts it.
- Cucumber: After the application is started on the Docker Host, Jenkins runs a suite of acceptance tests written in the Cucumber framework.
Clustering with Kubernetes
In Chapter 6, Clustering with Kubernetes, we replace a single Docker host with a Kubernetes cluster and a single standalone application with two dependent containerized applications. The output is the environment shown in the following diagram:
Figure 1.12 – Clustering with Kubernetes
Kubernetes provides an abstraction layer for a set of Docker hosts and allows simple communication between dependent applications. We no longer have to think about which machine our applications are deployed on. All we care about is the number of instances.
Configuration management with Ansible
In Chapter 7, Configuration Management with Ansible, we will create multiple environments using Ansible. The output is presented in the following diagram:
Figure 1.13 – Configuration management with Ansible
Ansible takes care of the environments and lets you deploy the same applications on multiple machines. As a result, we have a mirrored environment for testing and production.
In this chapter, we'll also touch on IaC and show you how to use Terraform if you use cloud environments.
The CD pipeline/advanced CD
In the last two chapters – that is, Chapter 8, Continuous Delivery Pipeline, and Chapter 9, Advanced Continuous Delivery – we will deploy the application to the staging environment, run the acceptance testing suite, and release the application to the production environment, usually in many instances. The final improvement is that we'll be able to automatically manage the database schemas using Flyway migrations that have been integrated into the delivery process. The final environment that will be created in this book is shown in the following diagram:
Figure 1.14 – The CD pipeline/advanced CD
I hope you are already excited by what we plan to build throughout this book. We will approach this step by step, explaining every detail and all the possible options to help you understand the procedures and tools. After reading this book, you will be able to introduce or improve the CD process in your projects.
