The labs on this site need JavaScript to run. The same content is written out below.

Learn › Architecture and operations › Deployment and operations

CI/CD pipelines

You push code, and a machine checks and deploys it for you

Between changing code and getting it onto the production server, there are steps: build, test, package, and deploy. When people do these steps by hand, they skip some, or each person does them differently.

Conceptual model · A conceptual model (not checked against real tools)

Concepts in this lab

CI/CD

CI (continuous integration) means merging code changes often and automatically running a build and tests on every merge to find problems early. CD (continuous delivery or continuous deployment) means using an automated process to get verified code into a deployable state or to deploy it all the way to production. Automating the build, test, and deployment work that people used to do by hand reduces mistakes and shortens the release cycle.

Unit tests and integration tests

A unit test verifies the behavior of a single method or class in isolation from other parts. It runs fast and makes the cause of a failure easy to find. An integration test actually connects several components (such as the Spring container and a database) and verifies that they work together. It is closer to reality but slow. The usual approach is to have many unit tests and to keep integration tests focused on the core flows.

Code review and pull requests

A pull request (PR) is a request to merge the changes on a working branch into the base branch. Code review is the process in which other developers examine the changes before they are merged. It finds defects early, keeps the code consistent, and shares knowledge within the team.

Health check (liveness, readiness)

A periodic check of whether a server is healthy. Liveness checks whether the process is alive, so that it is restarted if there is a problem. Readiness checks whether the server is ready to take requests, so that traffic is not sent to a server that is not ready. This keeps requests from reaching a server while it is starting up or shutting down.

Rolling, blue-green, and canary deployments

Ways to deploy a new version without interrupting the service. A rolling deployment replaces servers with the new version a few at a time, in turn. A blue-green deployment prepares a complete, separate environment for the new version and then switches the traffic all at once. A canary deployment applies the new version to only some users first, checks that there are no problems, and then expands it gradually.

Try these

• Default settings — Deploying by hand. The tests are skipped, and an outage occurs in production.
• With CI — The same change is stopped at the test stage.
• Code that works only on my PC — It shows up only when you run it in a clean environment.
• A problem the tests cannot catch, CI only — A person deploys, and a person rolls back.
• A problem the tests cannot catch, CI/CD — The health check after deployment catches it, and it is rolled back automatically.
• When there is no problem — Compare how much work is left for people.

Running with the default settings

1. The developer builds on their own PC.
2. The developer was in a hurry and did not run the tests. Whether the tests get run depends on a person's memory and effort.
3. The built file is copied to the production server and the server is restarted. Only that developer knows what code was uploaded.
4. An existing feature went to production broken. You find out from reports from users. The developer has to find the cause, find the previous file, and upload it again.

Result of this run

• When you do it by hand, you can skip the checking steps, and nobody knows they were skipped. The problem is found in the most expensive place, production.
• What a pipeline filters out is limited to problems that tests and checks can confirm. A bug in a feature that has no tests passes even with CI.

Code

# The developer types this directly on their own PC
./gradlew build -x test      # skips the tests because of a rush
scp build/libs/app.jar prod-server:/app/
ssh prod-server "systemctl restart app"

# No record is left of who uploaded what code, or when

Assumptions of this model

This is a model made to explain the concept, and it is not a result checked by running real CI/CD tools. In "By hand", skipping the tests assumes a common accident; if you run the tests when working by hand, you can catch the same problem. The automatic rollback when the health check fails is the behavior you get when the pipeline and the deployment tool are configured that way. The workflow in the code is an example to show the structure; steps that real use needs, such as authentication and caching, are left out.

Previous lab: Gateway and gradual migration · Next lab: Deployment strategies