8 Continuous integration

 

This chapter covers

  • Achieving fast feedback with continuous integration
  • Differentiating between integration workflows
  • Defining continuous integration workflows
  • Ensuring the integrity of artifacts
  • Creating a release for your continuous deployment workflows
  • Setting up a continuous integration workflow

Continuous integration (CI) is a DevOps practice, in which you regularly merge code changes into the central repository and run automated builds and tests to check the correctness and quality of the code. CI aims to provide rapid feedback and identify and correct defects as soon as possible. CI relies on the source code version control system to trigger builds and tests at every commit.

CI is composed of a set of steps that delivers the output artifacts we need to run a system in production. Which set of steps are required depends on the programming language and tools you are using as well as the platforms you are targeting with your product. In this chapter, we will lay out the generic set of steps each CI process typically entails and how you can set up GitHub actions to trigger on each commit and deliver this as a set of artifacts that can be picked up in a subsequent process of continuous deployment (CD), where you deploy the product to preferably a production environment (covered in chapter 9).

8.1 GloboTicket: A sample application

8.2 Why continuous integration?

8.3 Types of CI

8.3.1 Using a branching strategy: GitHub Flow

8.3.2 CI for integration

8.3.3 CI for quality control

8.3.4 CI for security testing

8.3.5 CI for packaging

8.4 Generic CI workflow steps

8.4.1 Getting the sources

8.4.2 Building the sources into artifacts

8.4.3 Testing the artifacts

8.4.4 Test result reporting

8.4.5 Using containers for jobs

8.4.6 Multiple workflows vs. multiple jobs: Which to choose?

8.4.7 Parallel execution of jobs

8.5 Preparing for deployment

8.5.1 Traceability of source to artifacts

8.5.2 Ensuring delivery integrity: The software bill of materials