CI/CD Fundamentals: Understanding the Core Principles of Continuous Delivery

CI/CD Fundamentals

CI (Continuous Integration) focuses on automatically building and testing code after each commit. CD can mean either Continuous Delivery—where a build artifact is always ready for release and deployment is triggered manually—or Continuous Deployment—where passing the quality gate automatically pushes the artifact to production.

Problems Solved by CI/CD

Integration risk is shifted earlier, avoiding "integration hell" at release time.

Feedback loops become faster; defects are caught before they reach test or production environments.

Environments become reproducible; the same build runs locally and in CI.

Release processes become controllable; steps are scripted instead of relying on manual memory.

CI/CD automates the sequence build → test → package → (optional) release so every change follows the same path.

Pipeline Core Concepts

Pipeline : a complete run triggered by a commit, analogous to an entire production line.

Stage : a logical phase (e.g., lint, test, build) that expresses order and gate conditions, similar to a workshop process.

Job : the actual task (a set of scripts) executed on a runner, comparable to a specific workstation operation.

lint / analyze → test → build → package/image → push (→ deploy)

Jobs within the same stage run in parallel; stages run sequentially unless a needs: dependency is declared to form a DAG.

Pipeline Triggers

Push : builds on every commit to a branch.

Merge Request / Pull Request : validates changes before merging to protect the main branch.

Schedule : runs at defined times for full‑suite tests or dependency scans.

Manual : used for production releases or sensitive deployments.

Webhook / API : integrates external systems.

For learning, the combination push + MR is most common; production jobs are usually manual to avoid accidental execution.

Artifacts, Cache, Variables & Secrets

Artifact : files produced by a job (e.g., JAR, test reports) that must be passed to downstream jobs; missing artifacts cause failures.

Cache : dependency caches (e.g., Maven repository) that speed up builds; they are best‑effort and should never hold critical build outputs.

Variables / Secrets : configuration values and credentials (e.g., Harbor password, tokens); they must never be stored in source code and should be kept in CI variable stores or secret managers.

Placement of Build, Test, and Release in the Pipeline

Source (GitLab) → clone / fetch → build & test (GitLab Runner) → produce artifact / image → docker push → Harbor → runtime environment

The "quality gate" decides whether a change proceeds to the next step. Typical hard conditions are:

Compilation or packaging failure aborts the pipeline.

Unit‑test failure prevents image creation or merge.

Optional vulnerability‑scan thresholds can block pushes or merges.

Gates should be few and strict; an all‑green pipeline indicates a healthy process.

Left‑Shift Concept

Detecting defects early reduces cost. Developers should run the same commands locally that CI runs (e.g., mvn test / mvn package) to ensure consistency.

Toolchain Position

GitLab : source hosting and CI engine; pipelines are defined in .gitlab-ci.yml.

GitLab Runner : the worker that executes jobs; Docker executor is recommended.

Harbor : private OCI registry providing UI, permissions, replication and vulnerability scanning.

Jenkins : independent CI server used in this series only for environment validation; business pipelines are written for GitLab CI.

GitLab CI vs Jenkins (Conceptual Comparison)

GitLab CI : code lives in GitLab, pipeline defined by .gitlab-ci.yml, Runner executes jobs, results are pushed to Harbor.

Jenkins : code can reside elsewhere, Jenkins pulls the code, executes a Jenkinsfile or Job, and can also push to Harbor.

Enterprises often use GitLab CI for a unified platform, while legacy Jenkins installations persist due to existing plugins and permissions.

Runner / Agent Importance

No matching runner → jobs stay pending and eventually timeout.

Incorrect runner environment (missing Docker, wrong JDK, unable to pull images) → job failure.

This series emphasizes local Docker with domestic image acceleration to ensure stable, reproducible runner behavior.

Containers and Images in CI/CD

Traditional deliverables are JAR/WAR binaries. Container images add the operating system layer, dependencies, start commands and configuration, decoupling the application from the host machine. Building the image in CI and running the same image in production eliminates environment drift.

Public vs Private Registries

Public registry (e.g., Docker Hub) : used for pulling base images; risks include rate limits, external dependencies, and accidental exposure of credentials.

Private registry (Harbor) : stores your own business images; provides access control, audit, internal network reachability, and built‑in vulnerability scanning.

Harbor is built on the open‑source Distribution Registry (OCI) and adds UI, project permissions, replication and scanning capabilities.

Series Structure

Principles : explains CI, the two CD meanings, pipeline concepts, artifacts, tools, and overall workflow.

Environment : guides deployment of Harbor, GitLab (with Runner) and Jenkins, including Docker domestic mirror configuration.

Hands‑On : demonstrates full pipelines for Node, Python and Spring Boot projects, pushing built images to Harbor.