Pipeline as code is the practice of expressing a project’s continuous integration and delivery pipeline as a text file kept under version control, rather than configuring the pipeline by clicking through a web interface. The pipeline definition lives in the same repository as the application, so the steps that build, test, and deploy the software travel with the code they act on.
The Jenkins documentation gives the canonical statement of the idea. It explains that “the definition of a Jenkins Pipeline is written into a text file (called a Jenkinsfile) which in turn can be committed to a project’s source control repository.” This approach, which the docs call Pipeline-as-code, lets pipelines build automatically across branches and pull requests, receive the same code review as application code, and provide an audit trail of every change.
The same model appears across modern CI/CD tools under different file names. GitLab CI/CD reads a .gitlab-ci.yml file at the root of the repository that, in GitLab’s words, “specifies the stages, jobs, and scripts to be executed during your CI/CD pipeline.” GitHub Actions stores YAML workflow files under .github/workflows, and CircleCI uses a config.yml. In each case the pipeline is data in the repository rather than state hidden inside a server’s configuration screens.
Putting the pipeline in source control yields concrete benefits. Changes to the build process are reviewed, tested, and reverted with the same tools as any other code change; a single file becomes the shared source of truth that the whole team can read and modify; and a new clone of the repository carries everything needed to reproduce the pipeline. It removes the fragile situation where critical automation exists only as undocumented clicks in someone’s CI server.
Pipeline as code is closely related to infrastructure as code and is a core practice of DevOps. Both treat operational definitions as versioned, reviewable artifacts rather than manual procedures, and together they push toward systems whose entire lifecycle, from provisioning through build to deployment, is described declaratively in files that live alongside the application.