7 Defining Pipeline as Code for Microservices
This chapter covers
- Usage of Jenkins multi-branch pipeline plugin & GitFlow model.
- Defining multi-branch pipelines for Containerized Microservices.
- Triggering a Jenkins job on push events using GitHub webhooks.
- Exporting Jenkins jobs configuration as XML and cloning Jenkins jobs.
In the previous chapters, we covered how to deploy a Jenkins cluster on multiple cloud providers using automation tools: HashiCorp Packer and Terraform. In this chapter, we will define a Continuous Integration pipeline for Dockerized microservices.
In the first chapter of the book, we learned that continuous integration (CI) is continuously testing and building all changes of the source code before integrating them into the central repository. The workflow can be summarized in the following stages:
Figure 7.1. Continuous Integration Stages
Every change to the source code triggers the CI pipeline, which launches the automated tests. This comes with many benefits:
- Detecting bugs and issues earlier which results in a dramatic decrease in maintenance time and costs.
- Ensuring the code base continues to work and meets the specs requirements as the system grows.
- Improving team velocity by establishing a fast-feedback loop.
While automated tests come with multiple benefits, they’re extremely time-consuming to implement and execute. Therefore, we will use a testing framework based on the target service runtime and requirements.