CI/CD & Automation

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.

Stored intermediate results (dependencies, compiled layers) reused across runs to make builds faster.

A required check that must pass before the pipeline continues, such as unit tests or linting. A failing gate stops the pipeline.

A fast test that checks one small piece of code in isolation. Unit tests run early because they give quick feedback.

A test that checks how multiple components work together, often against a real database or service. Slower than unit tests, so they run later.

Running the same job across several combinations of parameters (language versions, operating systems) in parallel.

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.

A CI/CD system built into GitHub that runs YAML-defined workflows on events like push and pull request.

GitLab's built-in CI/CD, configured with a .gitlab-ci.yml file and executed by GitLab runners.

A long-established, self-hosted automation server that runs pipelines defined in a Jenkinsfile, extended through a large plugin ecosystem.

A sensitive value (API key, token, password) stored encrypted by the CI system and injected into jobs without appearing in the code or logs.

A named value passed into a job to configure behavior, such as an API URL or a build flag.

A pipeline you can run repeatedly with the same inputs and get the same result, which makes retries and reruns safe.

Configuring a pipeline to stop as soon as a critical step fails, so you get feedback quickly and do not waste runner time.

The practice of merging code frequently and running automated builds and tests on every change to catch problems early.

Extending CI so every passing change is automatically prepared for release, with the final push to production requiring a manual approval.

Going one step beyond continuous delivery: every change that passes the pipeline is released to production automatically, with no manual gate.

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.

Releasing a new version to a small slice of traffic first, watching for errors, then gradually increasing the rollout if it looks healthy.

Reverting to a previous known-good version after a bad release. Fast rollback is a core safety net of automated deployment.

Replacing instances of the old version with the new one a few at a time, so the service stays up throughout the change.

A named target where code runs, such as dev, staging, or production. Pipelines promote a build through environments in order.

An automated sequence of stages that takes code from commit to a running deployment, such as build, test, and release.

A named phase of a pipeline that groups related jobs, like "test" or "deploy". Stages usually run in order.

A unit of work within a stage that runs on a single runner. Jobs in the same stage often run in parallel.

A single command or action inside a job, executed in sequence.

The event that starts a pipeline, such as a push, a pull request, a tag, a schedule, or a manual click.

The machine or process that executes a job. Runners can be hosted by the CI provider or self-hosted on your own infrastructure.

Another name for a runner, common in Jenkins. It is the worker that picks up and runs pipeline work.

The full definition of an automated process, usually a YAML file describing triggers, jobs, and steps.

A version scheme of MAJOR.MINOR.PATCH where major means breaking changes, minor means new backward-compatible features, and patch means bug fixes.

A named pointer to a specific commit, commonly used to mark a release like v1.2.0. Tags often trigger release pipelines.

A pre-release build believed to be ready for production, published for final testing before the official release.

A human-readable record of what changed in each release, grouped by added, changed, fixed, and removed.

A store for versioned build outputs such as container images or packages, from which deployments pull.