--- title: "CI/CD & Automation" description: "Continuous integration, delivery, and deployment terms: pipelines, runners, artifacts, and release strategies." author: "Mohammad Abu Mattar" canonical: https://mkabumattar.com/glossary/post/ci-cd-and-automation --- # CI/CD & Automation A quick-reference glossary of the terms you meet when automating builds, tests, and deployments: pipeline anatomy, test gates, and release strategies like canary and blue-green. ## Terms ### Pipeline (Pipeline Concepts) An automated sequence of stages that takes code from commit to a running deployment, such as build, test, and release. ### Stage (Pipeline Concepts) A named phase of a pipeline that groups related jobs, like "test" or "deploy". Stages usually run in order. ### Job (Pipeline Concepts) A unit of work within a stage that runs on a single runner. Jobs in the same stage often run in parallel. ### Step (Pipeline Concepts) A single command or action inside a job, executed in sequence. ### Trigger (Pipeline Concepts) The event that starts a pipeline, such as a push, a pull request, a tag, a schedule, or a manual click. ### Runner (Pipeline Concepts) The machine or process that executes a job. Runners can be hosted by the CI provider or self-hosted on your own infrastructure. **Example:** A GitHub Actions ubuntu-latest runner, or a self-hosted runner on an EC2 instance. ### Agent (Pipeline Concepts) Another name for a runner, common in Jenkins. It is the worker that picks up and runs pipeline work. ### Workflow (Pipeline Concepts) The full definition of an automated process, usually a YAML file describing triggers, jobs, and steps. ### Artifact (Build & Test) A file or set of files produced by a pipeline, such as a compiled binary, a container image, or a test report, that later stages or humans consume. ### Build cache (Build & Test) Stored intermediate results (dependencies, compiled layers) reused across runs to make builds faster. **Example:** Caching node_modules or Docker layers between runs. ### Test gate (Build & Test) A required check that must pass before the pipeline continues, such as unit tests or linting. A failing gate stops the pipeline. ### Unit test (Build & Test) A fast test that checks one small piece of code in isolation. Unit tests run early because they give quick feedback. ### Integration test (Build & Test) A test that checks how multiple components work together, often against a real database or service. Slower than unit tests, so they run later. ### Matrix build (Build & Test) Running the same job across several combinations of parameters (language versions, operating systems) in parallel. ``` strategy: matrix: node: [18, 20, 22] ``` ### Flaky test (Build & Test) A test that sometimes passes and sometimes fails without any code change, usually due to timing or shared state. Flaky tests erode trust in the pipeline. ### Continuous Integration (CI) (Delivery & Deployment) The practice of merging code frequently and running automated builds and tests on every change to catch problems early. ### Continuous Delivery (Delivery & Deployment) Extending CI so every passing change is automatically prepared for release, with the final push to production requiring a manual approval. ### Continuous Deployment (Delivery & Deployment) Going one step beyond continuous delivery: every change that passes the pipeline is released to production automatically, with no manual gate. ### Blue-green deployment (Delivery & Deployment) Running two identical environments (blue and green) and switching traffic from the old to the new all at once, so rollback is just switching back. ### Canary deployment (Delivery & Deployment) Releasing a new version to a small slice of traffic first, watching for errors, then gradually increasing the rollout if it looks healthy. ### Rollback (Delivery & Deployment) Reverting to a previous known-good version after a bad release. Fast rollback is a core safety net of automated deployment. ### Rolling update (Delivery & Deployment) Replacing instances of the old version with the new one a few at a time, so the service stays up throughout the change. ### Deployment environment (Delivery & Deployment) A named target where code runs, such as dev, staging, or production. Pipelines promote a build through environments in order. ### Semantic versioning (Versioning & Releases) A version scheme of MAJOR.MINOR.PATCH where major means breaking changes, minor means new backward-compatible features, and patch means bug fixes. **Example:** 2.4.1 to 2.5.0 adds features; 2.4.1 to 3.0.0 breaks compatibility. ### Tag (Versioning & Releases) A named pointer to a specific commit, commonly used to mark a release like v1.2.0. Tags often trigger release pipelines. ### Release candidate (Versioning & Releases) A pre-release build believed to be ready for production, published for final testing before the official release. **Example:** v2.0.0-rc.1 ### Changelog (Versioning & Releases) A human-readable record of what changed in each release, grouped by added, changed, fixed, and removed. ### Artifact registry (Versioning & Releases) A store for versioned build outputs such as container images or packages, from which deployments pull. **Example:** Amazon ECR, npm registry, or GitHub Packages. ### GitHub Actions (Common Tools & Concepts) A CI/CD system built into GitHub that runs YAML-defined workflows on events like push and pull request. ### GitLab CI (Common Tools & Concepts) GitLab's built-in CI/CD, configured with a .gitlab-ci.yml file and executed by GitLab runners. ### Jenkins (Common Tools & Concepts) A long-established, self-hosted automation server that runs pipelines defined in a Jenkinsfile, extended through a large plugin ecosystem. ### Secret (Common Tools & Concepts) A sensitive value (API key, token, password) stored encrypted by the CI system and injected into jobs without appearing in the code or logs. ### Environment variable (Common Tools & Concepts) A named value passed into a job to configure behavior, such as an API URL or a build flag. ### Idempotent pipeline (Common Tools & Concepts) A pipeline you can run repeatedly with the same inputs and get the same result, which makes retries and reruns safe. ### Fail fast (Common Tools & Concepts) Configuring a pipeline to stop as soon as a critical step fails, so you get feedback quickly and do not waste runner time.