CI/CD

Merge code frequently; every commit automatically triggers a build + test run so integration bugs are caught within minutes.

Keep the codebase always in a deployable state; release to production is a deliberate, one-click manual action.

Every commit that passes all automated tests is deployed to production automatically — no human approval required.

Ordered sequence of automated stages: Source → Build → Test → Artifact → Deploy, triggered by a code event.

Versioned build output (Docker image, binary, bundle) stored in a registry and consumed by downstream deployment stages.

Machine (GitHub-hosted VM or self-hosted server) that executes pipeline jobs in an isolated environment.

Event that starts a pipeline: push, pull_request, schedule, workflow_dispatch (manual), or completion of an upstream job.

Logical unit of pipeline work. Jobs in the same stage run in parallel; sequential stages require the previous stage to pass first.

Store node_modules, build outputs, or test results between runs so unchanged dependencies are not reinstalled from scratch.

Run the same job across multiple variable combinations (OS × runtime version) in parallel — great for cross-platform compatibility tests.

Named deployment target (dev, staging, production) with its own scoped secrets, protection rules, and required reviewers.

A manual review step that pauses the pipeline until a designated team member approves before the job proceeds to production.

Workflow event triggers. Runs the pipeline on every code push or when a PR is opened, synchronised, or reopened.

Specify the runner OS for a job. Options: ubuntu-latest, windows-latest, macos-latest, or a self-hosted label.

Reusable action that checks out repository code onto the runner. Almost every CI job starts with this step.

Declare a job dependency — this job will only start after the listed jobs pass successfully, creating a sequential pipeline.

Access an encrypted repository or environment secret at runtime. Secret values are automatically masked in all log output.

Pass environment variables (env:) or action input parameters (with:) to a job, step, or reusable action.

Allow manual one-click workflow triggering from the GitHub UI with optional typed input parameters.

Build a Docker image from the Dockerfile in the current directory and tag it with a unique commit SHA for traceability.

Push the built and tested image to a container registry (DockerHub, ECR, GCR) for use by deployment stages downstream.

Pull the previous image from the registry and reuse its unchanged layers to dramatically speed up the docker build step.

Builder stage: installs all dev tools + compiles. Final stage: copies only the built output into a minimal base — tiny production image.

Scan the built image for known CVEs before pushing to the registry. Fail the pipeline on CRITICAL severity findings.

Run the test suite and generate a code coverage report. Fail the pipeline if coverage drops below the configured threshold.

Enforce a minimum coverage % (e.g. 80%) as a pipeline quality gate — PRs that reduce coverage below the threshold are blocked.

Split the test suite across multiple runners (matrix shards) to run all tests in parallel and reduce total pipeline time.

Minimal post-deploy sanity check (e.g. curl /healthz) run immediately after deployment to verify the service started correctly.

Run two identical environments; switch all traffic instantly between them — zero downtime and instant rollback with a single config change.

Route 5–10% of traffic to the new version, monitor error rates, then gradually expand rollout — or rollback if metrics degrade.

Replace old instances one-by-one with the new version so two versions run briefly in parallel — requires backward-compatible APIs.

Apply Kubernetes manifest files to deploy or update workloads. The core CD command in Kubernetes-based pipelines.

Deploy or upgrade a Helm chart release. --install creates it if absent, making the command idempotent for first-run pipelines.

Roll back a Kubernetes Deployment to the previous ReplicaSet revision — fastest recovery when a bad deploy is detected.

HTTP/TCP liveness and readiness probes that must pass before a pod receives traffic — automated gate against broken deploys.