CI/CD Concepts

A pipeline is an automated, ordered sequence of stages that takes code from commit to delivery. Typical stages build the application, run tests, perform security or quality checks, and deploy to environments. Each stage must pass before the next begins, so problems are caught early. Pipelines are defined as code in files like a workflow or Jenkinsfile, making the process repeatable and version-controlled. They are the backbone of continuous integration and continuous delivery, reducing manual effort and human error.

An artifact is a packaged output produced by a build stage, such as a compiled binary, a Docker image, a JAR, or a zipped bundle. Artifacts are stored in a registry or artifact repository so later stages and deployments can retrieve the exact, immutable build rather than rebuilding. Building once and promoting the same artifact through environments ensures that what you test is precisely what you deploy, a key practice for reliable, reproducible releases across a pipeline.

An environment is a distinct, isolated deployment target where software runs, commonly development, staging, and production. Each typically uses its own configuration, data, and access controls. Code is promoted through environments to gain confidence: developers iterate in dev, integration is validated in staging, and end users are served by production. Keeping environments consistent, ideally provisioned via infrastructure as code, reduces the classic problem of something working in one environment but failing in another.

A rollback reverts a system to a previous, known-good version when a new release causes problems such as errors or degraded performance. Because the prior artifact and configuration are preserved, you can quickly restore service rather than scrambling to fix forward under pressure. Effective rollback strategies require versioned artifacts, backward-compatible database changes, and automation so the revert is fast and reliable. The ability to roll back confidently is essential to safe, frequent deployments.

A blue-green deployment maintains two identical production environments, conventionally labeled blue (current) and green (new). You deploy the new version to the idle environment, test it, then switch all traffic to it by updating a router or load balancer. This makes releases near-instant and gives an immediate rollback path: if the new version misbehaves, you simply switch traffic back. The trade-off is the cost of running two full environments, but it greatly reduces deployment risk and downtime.