Pipeline as Code (Declarative Pipelines)
Pipeline as code means your build, test, and deploy process lives in version-controlled files, not in a UI someone configured once and forgot.
Early CI tools were configured by clicking through web forms, and that configuration lived only on the server. Pipeline as code moves the pipeline definition into files that sit beside your application code. This lesson explains the declarative approach, the file formats, and why putting the pipeline under version control is a strict upgrade.
Declarative vs imperative
A declarative pipeline describes *what* the desired steps and stages are, and the CI system figures out how to run them. An imperative pipeline is a script that spells out *how* to do each step. Most modern systems favor declarative YAML because it is easier to read, validate, and reason about. A GitHub Actions workflow or a .gitlab-ci.yml file is a declarative pipeline definition.
What it looks like
A pipeline-as-code file lists jobs, the steps in each job, the runner to use, and the triggers that start it. For example, a workflow might say on: push to run on every push, define a build job and a test job, and declare that test needs build to finish first. Because it is plain text, the entire process is reviewable in a pull request.
Why version control changes everything
- History: every change to the pipeline is tracked, attributable, and revertible.
- Review: pipeline changes go through the same code review as application code.
- Branching: a feature branch can change its own pipeline without affecting others.
- Reproducibility: checking out an old commit gives you the pipeline that built it.
A foundation for the rest of CI/CD
Pipeline as code is the bridge to broader "everything as code" practices. Once the pipeline is a file, you can template it, share it across repositories, lint it, and test it. It is also a prerequisite for treating infrastructure and configuration as code, since those are usually wired into the same pipeline.
Key takeaways
- Pipeline as code stores your CI/CD process in version-controlled files.
- Declarative definitions describe what to run, not how, and are easier to reason about.
- Version control brings history, review, and reproducibility to the pipeline itself.