CI/CD Pipeline Language Exercises

A typical CI/CD pipeline consists of stages named: source (code checkout), build (compile or bundle), test (unit, integration, e2e), security scan (SAST/DAST), package (container image or artifact creation), deploy-to-staging, smoke test, and deploy-to-production. Pipeline configuration files (e.g., GitHub Actions workflows, GitLab CI YAML, Jenkins Declarative Pipelines) use keywords like stages, jobs, steps, and artifacts. Engineers describe pipelines with phrases like "our pipeline runs from commit to production in under 12 minutes."

Blue-green deployment uses two identical production environments: "blue" (current live) and "green" (new version). Traffic is switched from blue to green atomically. The phrase "cut over" describes this switch, and "rollback" means switching back to blue. Canary deployment gradually shifts traffic to the new version — "we're canarying at 5% of traffic before full rollout." Related vocabulary includes "traffic splitting," "feature flags," "progressive delivery," and "rollout percentage." Both strategies minimise downtime and risk during production releases.

A pipeline failure means one or more stages did not complete successfully, blocking the change from progressing. Engineers use phrases like "the build stage is red," "the test suite is flaky," "the deploy job timed out," and "the pipeline is blocked on the security gate." In post-incident communication, teams say "the pipeline failed due to a broken dependency in the integration tests" or "a misconfigured environment variable caused the staging deploy to fail." Clear, specific failure communication reduces time-to-resolution.

A deployment gate (also called a quality gate or approval gate) is a checkpoint that must pass before a pipeline can proceed to the next stage. Language includes "the gate requires 80% test coverage," "manual approval required before production deploy," "the SonarQube gate failed on code smell threshold," and "gate override requires manager sign-off." In GitLab CI, gates are defined as "when: manual" steps; in GitHub Actions as "environment: production" with required reviewers. Gates enforce policy compliance at the pipeline level.

Pipeline configuration vocabulary varies by tool but shares common concepts. GitHub Actions uses workflow, trigger (on:), job, step, uses, run, and env. GitLab CI uses stages, job, script, artifacts, dependencies, and rules. Jenkins Declarative Pipeline uses pipeline, agent, stages, stage, steps, and post. Shared vocabulary includes "matrix build" (running the same job across multiple configurations), "caching" (reusing dependencies between runs), "artifact" (file passed between stages), and "runner" (the compute agent executing the job).

Environment promotion describes the process of moving a software artifact from a lower environment (e.g., dev) to a higher one (staging, pre-production, production). Engineers say "the build is promoted to staging," "the artifact is promoted from QA to UAT," or "we're ready to promote to prod pending sign-off." The key principle is that the same artifact (same container image or binary) is promoted — not rebuilt — ensuring consistency. Promotion language also includes "promotion criteria," "gate checks," and "promotion freeze" (a period where no promotions are allowed, e.g., before a holiday).

Continuous Integration (CI) means developers merge code frequently and each merge triggers automated builds and tests. Continuous Delivery (CD) extends CI to ensure the codebase is always in a deployable state, with deployment to production requiring a manual approval. Continuous Deployment removes the manual approval — every passing pipeline automatically deploys to production. In team conversations, distinguishing these is important: "We practice continuous delivery — we can deploy at any time but choose when to release" vs "We have continuous deployment — every merge to main goes live within minutes."

A flaky test is one that passes and fails non-deterministically without code changes. Engineers say "this test is flaky — it fails 1 in 10 runs due to a race condition" or "we've quarantined the flaky tests so they don't block the pipeline." Managing flakiness uses vocabulary like "test quarantine," "retry logic," "deterministic test," "test isolation," and "environment-dependent failure." Flaky tests erode trust in the pipeline — a common team discussion item is "we can't merge until flakiness is below 1%."

Rollback vocabulary includes "initiate a rollback," "revert to the previous stable release," "the rollback plan is to redeploy build v2.3.1," "we rolled back the migration because the error rate spiked," and "the feature flag was toggled off to mitigate impact." Engineers distinguish between a "rollback" (reverting the deployed artifact) and a "roll-forward" (deploying a hotfix quickly). Post-incident reviews use phrases like "we triggered a rollback at T+8 minutes after the alert fired" to document the timeline.

"Pipeline as code" means the pipeline configuration is stored in version control alongside application code (e.g., .github/workflows/, .gitlab-ci.yml, Jenkinsfile). This enables peer review of pipeline changes ("I'm submitting a PR to update the deployment job"), auditability, and reproducibility. Vocabulary includes "declarative pipeline," "pipeline template," "reusable workflow," and "pipeline inheritance." The practice contrasts with "clickOps" (configuring pipelines via UI), which is harder to audit and replicate.