Skip to main content

Lesson: Continuous Integration & Delivery

What you'll learn

  • The difference between Continuous Integration (CI), Continuous Delivery, and Continuous Deployment — three terms that share the letters "CD" but mean different things.
  • The standard stages of a pipeline (build → test → package → deploy) and what an artifact is.
  • The two models for getting software onto a server: push deployment versus pull deployment.
  • Why teams automate all of this instead of running commands by hand.

By the end you can read a pipeline diagram and explain, in plain words, what each stage does and where your code goes after you push it.

The lesson

You just wrote some code and ran it on your laptop. It works. Now what? In a real team, that code has to be combined with everyone else's code, tested, turned into something runnable, and put on a server — over and over, many times a day. Doing that by hand is slow and error-prone. CI/CD is the practice of automating that path from "I pushed code" to "it's running."

1. Continuous Integration (CI)

Integration means combining your changes with the shared codebase (usually the main branch in Git). Continuous Integration means everyone merges small changes frequently — and every merge automatically triggers a build and a test run.

The point is to catch problems early. If ten developers each work alone for two weeks and then try to combine everything (a "big bang merge"), the conflicts and bugs are painful. If instead everyone integrates several times a day, each change is small and breakage is caught within minutes.

A CI system watches your Git repository. When you push, it:

  1. Checks out your code.
  2. Builds it (compiles, or assembles a runnable package).
  3. Runs automated tests.
  4. Reports pass/fail back to you, usually as a green check or red X on your commit.

That fast pass/fail signal is the heart of CI.

2. Continuous Delivery vs Continuous Deployment

Both are abbreviated "CD", which is confusing. Here is the distinction:

  • Continuous Delivery — every change that passes CI is automatically prepared and ready to release, but a human clicks the button to actually push it to production. There is a manual approval gate.
  • Continuous Deployment — there is no button. Every change that passes all tests goes to production automatically.
   Continuous Delivery:
   commit -> build -> test -> [READY]  --(human approves)--> production

   Continuous Deployment:
   commit -> build -> test -> --------(automatic)---------> production

Continuous Delivery is the common, safer choice for most teams: automate everything up to the release, but keep a human in the loop for the final go. Continuous Deployment requires very strong automated testing and monitoring, because nobody is checking before users get the change.

3. Pipeline stages and artifacts

A pipeline is an ordered series of automated steps. A typical one looks like this:

 +---------+   +-------+   +---------+   +----------+   +----------+
 |  BUILD  |-->| TEST  |-->| PACKAGE |-->|  PUSH    |-->|  DEPLOY  |
 | compile |   | unit  |   | make    |   | upload   |   | run on   |
 | code    |   | tests |   | image   |   | artifact |   | server   |
 +---------+   +-------+   +---------+   +----------+   +----------+
      |            |            |              |              |
   if this fails, the pipeline stops here and reports red

Each box is a stage. Stages run in order; if one fails, later ones are skipped. This "fail fast" behavior means you never deploy code that didn't pass its tests.

An artifact is the concrete output a stage produces and hands to the next stage — for example a compiled binary, a .zip, or (most common today) a container image. A container image is a self-contained, runnable package of your app plus everything it needs to run.

In our lab, the package stage builds a container image and the push stage uploads it to the lab's private container registry at 10.100.100.6. A registry is just a storage server for images. Later stages (or another tool entirely) pull the image from there and run it.

4. Push vs Pull deployment

There are two ways the deploy stage actually gets software onto the target server.

  • Push deployment: the pipeline reaches out to the server and pushes the change — e.g. it SSHes in, or runs kubectl apply against a cluster. The CI server needs credentials to the production environment, and it initiates the change.

  • Pull deployment: a tool running inside the target environment watches a Git repository and pulls changes in when it sees them. The CI pipeline only updates Git; it never touches production directly. This is the basis of GitOps, which you'll meet in the Argo CD chapter.

  PUSH model:                          PULL model:
  +----------+                         +----------+        +-----------+
  | CI server|---kubectl apply-------> | cluster  |        | CI server |---> Git repo
  | (has prod|                         |          |        +-----------+        ^
  |  creds)  |                         +----------+                             | watches
  +----------+                                            +----------+          | & pulls
                                                          | agent in |----------+
                                                          | cluster  |
                                                          +----------+

Push is simpler to set up. Pull is safer at scale: production credentials never leave the cluster, and Git becomes the single source of truth for "what should be running."

5. Why automate at all?

Automating the build→test→deploy path gives you:

  • Speed — minutes, not a manual afternoon.
  • Consistency — the pipeline runs the exact same steps every time; no "I forgot to run the tests."
  • A safety net — broken code is blocked before it reaches users.
  • An audit trail — every deploy is tied to a commit, so you know exactly what is running and who changed it.
  • Confidence to ship often — small, frequent releases are far less risky than big rare ones.

In the lab, you'll wire all of this up for real: a Gitea Actions runner on the build VM (10.100.100.11) builds your image and pushes it to the registry (10.100.100.6), and Argo CD pulls it onto the live Kubernetes cluster (master 10.100.100.7).

Dig deeper

Search terms

  • continuous integration vs continuous delivery vs deployment
  • what is a CI/CD pipeline explained
  • what is a build artifact
  • push vs pull deployment gitops
  • why automate software deployment

Check yourself

  1. In one sentence each, define Continuous Integration, Continuous Delivery, and Continuous Deployment.
  2. What is the one difference between Continuous Delivery and Continuous Deployment?
  3. Name the typical stages of a pipeline in order. What happens to later stages if one fails?
  4. What is an "artifact"? Give an example used in our lab.
  5. In a pull-based deployment, which side initiates the change — the CI server or something inside the target environment? Why is that safer?

No comments to display

Back to top