CI/CD explained: from a code change to a release

A change that works on a developer's laptop still needs to be checked, packaged and delivered to users. Continuous integration (CI) automatically builds and tests changes as they join the shared codebase. Continuous delivery keeps checked software ready for release through a repeatable deployment process; continuous deployment additionally releases qualifying changes automatically.

A pipeline is the sequence of jobs that performs this work. Start by identifying the exact image or package produced by a build and keep that same artifact as it moves between environments. Then decide what must pass before release and how to return to a previous version if the application fails.

Try it in a lab

Draw the path from a commit to a deployment in a disposable environment. Identify the immutable artifact, the approval or policy gate and the evidence checked after rollout. Practice reverting one harmless change.

Check your understanding

Explain how a failed rollout is detected and how the previous version is selected. Show that rebuilding later is not required to identify the released artifact.

Before you start

A green build does not establish a healthy production deployment. Keep credentials scoped to the environment and validate real workload behavior after release.

Read the official guide

Read GitHub’s continuous integration documentation and deployment-environment documentation for an example of build/test workflows, approval gates and scoped secrets. Use OpenGitOps for the principles of declarative, versioned desired state and continuous reconciliation. Follow your chosen delivery tool’s documentation for its commands and prerequisites. Record your environment and results; this exercise does not establish that Kubedex has tested every platform combination.

This is a newly written study reference at an address from the original Kubedex course outline. The original lesson was not recovered. It does not include course enrolment, progress tracking or a certificate.