CI/CD Quick Reference
This reference collects the terminology, ordering conventions, and platform-specific syntax that come up constantly when working with CI/CD, condensed for fast lookup rather than deep explanation. It assumes you already understand the underlying concepts from other study-notes topics and want a single page to check while writing a pipeline or preparing for a conversation about one.
Cricket analogy: Like a laminated cheat-sheet of fielding positions a captain like Rohit Sharma keeps in his pocket mid-match, useful only if you already understand the game — a quick reminder, not a coaching manual for beginners.
Core Terminology at a Glance
Continuous Integration (CI): automatically building and testing every change merged into a shared branch. Continuous Delivery (CD): every change that passes CI is kept in a deployable state, released via a manual trigger. Continuous Deployment: every change that passes CI is released automatically, with no manual gate. Pipeline: the full automated sequence from source change to deployed artifact. Stage/Job: a discrete phase of a pipeline (build, test, deploy). Runner/Agent: the compute environment that executes pipeline steps. Artifact: a built output (binary, container image, package) produced by one stage and consumed by later stages.
Cricket analogy: Like distinguishing net practice where every ball is checked (CI), being match-ready but waiting for the selectors' final word to take the field (Continuous Delivery), and simply walking out to bat automatically once selected (Continuous Deployment), with the scorecard as the artifact.
Standard Stage Ordering
A conventional pipeline orders stages roughly as: lint/static-analysis → unit test → build/package → integration test → security scan (SAST/dependency scan) → deploy to staging → smoke test → deploy to production. Not every pipeline needs every stage, but this ordering reflects the fail-fast principle — cheapest and fastest checks first, most expensive and highest-risk operations last.
Cricket analogy: Like a bowler's pre-match routine — a quick fitness check (lint), bowling in the nets (unit test), fitness certification (build), a warm-up match (integration test), an anti-doping test (security scan), a tour game (staging), a final net session (smoke test), before playing the Test match (production) — cheap checks first.
Deployment Strategy Cheat Sheet
Rolling deployment: replaces instances of the old version with the new one gradually, a few at a time, with no separate environment required. Blue-green deployment: runs two full environments (blue = current, green = new); traffic switches all at once when green is verified, and rollback is an instant traffic switch back. Canary release: routes a small percentage of traffic to the new version, increasing gradually while monitoring health, minimizing blast radius if something is wrong. Feature flags: decouple code deployment from feature activation entirely, letting a team ship dark code and turn it on for specific users independent of any deploy.
Cricket analogy: Like a captain rotating bowlers one over at a time (rolling), versus benching the entire XI for a fresh reserve squad in a dead rubber (blue-green), versus giving a debutant just a few overs before a full spell (canary), while a coach may select a player but not field him until conditions suit (feature flags).
# Common CI/CD CLI snippets for quick reference
# GitHub Actions: re-run a failed workflow from the CLI
gh run rerun <run-id> --failed
# GitHub Actions: view logs for the most recent run
gh run view --log
# Jenkins: trigger a job via CLI
curl -X POST "$JENKINS_URL/job/my-pipeline/build" \
--user "$JENKINS_USER:$JENKINS_TOKEN"
# GitLab CI: run a pipeline against a specific ref via API
curl --request POST \
--form token="$CI_TRIGGER_TOKEN" \
--form ref=main \
"https://gitlab.example.com/api/v4/projects/123/trigger/pipeline"
# Docker: build and tag an image with the git SHA for traceable deploys
docker build -t registry.example.com/app:$(git rev-parse --short HEAD) .A fast way to recall deployment strategy tradeoffs: rolling is cheapest but slowest to fully roll back; blue-green is fastest to roll back but doubles infrastructure cost during the switch; canary offers the smallest blast radius but is the most operationally complex to automate correctly.
Don't confuse 'the pipeline is passing' with 'the release is safe.' A quick-reference sheet is useful for syntax and ordering, but it is not a substitute for understanding why each stage and gate exists — memorized ordering without understanding leads to cargo-culted pipelines that skip stages that mattered.
Quick Glossary: Secrets and Security
SAST (Static Application Security Testing): scans source code for vulnerability patterns without executing it. Dependency scanning: checks third-party packages against known-vulnerability databases (e.g. CVE feeds). Least privilege: granting a service account or pipeline only the exact permissions it needs, nothing more. Secret masking: a CI platform's automatic redaction of known secret values from log output, which only works if the secret was injected via the platform's secret mechanism.
Cricket analogy: Like a coach reviewing a bowler's action on video for illegal patterns without a live delivery (SAST), checking a new signing's medical history against known injury databases (dependency scanning), giving a substitute fielder only boundary-patrol duty rather than the captaincy (least privilege), and a broadcaster bleeping a player's expletive only if picked up through the official stump mic (secret masking).
- CI = automated build/test on every merge; CD (delivery) = deployable with manual release; continuous deployment = fully automatic release.
- Standard stage order: lint → unit test → build → integration test → security scan → deploy staging → smoke test → deploy production.
- Rolling = gradual instance replacement; blue-green = instant full-environment switch; canary = gradual traffic-percentage rollout.
- Feature flags decouple deployment from feature activation, enabling dark launches independent of the deploy pipeline.
- SAST and dependency scanning are two distinct security checks: one examines your code, the other examines third-party packages.
- Secret masking in logs only works reliably when secrets are injected through the CI platform's native secret mechanism.
Practice what you learned
1. According to the quick reference, what is the key difference between continuous delivery and continuous deployment?
2. In the standard stage ordering given, why does the security scan stage typically come after build/integration test but before deploy?
3. Which deployment strategy is described as fastest to roll back but doubling infrastructure cost during the switch?
4. What do feature flags decouple, according to the quick reference?
5. What is the distinction between SAST and dependency scanning?
Was this page helpful?
You May Also Like
CI/CD Interview Questions
A curated set of conceptual and scenario-based CI/CD interview questions covering pipeline design, deployment strategies, and troubleshooting, with model answers.
Common CI/CD Pitfalls
A survey of recurring mistakes teams make when building CI/CD pipelines — from flaky tests to secret leakage — and the practical fixes for each.
Blue-Green Deployments
Understand the blue-green deployment pattern for near-instant, low-risk releases and rollbacks by running two full environments and switching traffic between them.
Canary Releases
Learn how canary releases gradually expose a small percentage of real traffic to a new version, using metrics to decide whether to expand or abort the rollout.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics