A DevOps engineer wants the definition of the CI/CD pipeline itself (build stages, test steps, deployment triggers) to be stored and versioned in the same repository as the application source code, so pipeline changes go through the same code review and history tracking as application changes. Which practice enables this?
- APipeline as code
- BInfrastructure as code
- CContinuous deployment
- DGitOps
Show answer & explanationAnswer & explanation
Correct answer: A. Pipeline as code
Pipeline as code (e.g., a Jenkinsfile or a .gitlab-ci.yml file) defines the CI/CD pipeline's stages and logic in a version-controlled file alongside the application code, enabling review, history, and rollback of pipeline changes. Infrastructure as code provisions infrastructure resources, GitOps uses Git as the source of truth for deploying infrastructure/application state (a broader operational model), and continuous deployment refers to automatically releasing every passing build to production.
Why the other options are wrong
- B. Infrastructure as code defines infrastructure resources, not the pipeline logic itself.
- C. Continuous deployment automatically pushes passing builds to production, unrelated to where pipeline logic is stored.
- D. GitOps uses Git as the source of truth for deployment state, a broader concept than defining pipeline steps.
Pipeline as Code
The practice of defining a CI/CD pipeline's stages, steps, and triggers in a text file stored in version control, enabling review and history tracking of pipeline changes.
- Examples: Jenkinsfile, .gitlab-ci.yml, GitHub Actions workflow YAML
- Stored alongside application source code
- Allows pipeline changes to be reviewed like application code
Memory trick: Pipeline as code: the recipe for baking your app lives in the same cookbook as the ingredients.