Pipeline as Code: Addressing CI/CD Pain Points with Version Control and DSLs

In November 2016 the concept of "Pipeline as Code" was defined as encoding CI/CD pipelines as code rather than configuring them, allowing the entire build, test, deployment, and infrastructure setup to be versioned and reproduced.

The idea is to encapsulate complex build processes into a simple script that any developer can run locally, eliminating the privileged, singular nature of traditional CI/CD environments.

Practitioners face several pain points: configuration drift, "snowflake" servers that become impossible to replicate or understand, and undocumented changes that make risk assessment difficult.

Typical evolution starts with automating build and deployment, then adding unit testing and code analysis, followed by acceptance testing and finally full release automation, continuously improving CI speed and stability.

Two main solutions are proposed: managing pipelines in version control and describing them with a domain‑specific language (DSL). Storing pipelines as code ensures every change is recorded and stays in sync with project progress.

For Jenkins 2.0, a Groovy‑based DSL can be used; an example Jenkinsfile is shown below:

node('master') {
   stage('Checkout') {…}
   stage('Code Analysis') {…}
   stage('Unit Test') {…}
   stage('Packing') {…}
   stage('Archive') {…}
   stage('DEV') {…}
}
stage('SIT') {
   timeout(time:4, unit:'HOURS') {
       input "Deploy to SIT?"
   }
   node('master') {…}
}
stage('Acceptance Test') {
   node('slave') {…}
}

Other tools include Concourse.ci, which uses a YAML‑based DSL to define resources, jobs, and tasks, and λCD, which leverages Clojure to express pipelines and steps.

An example of a λCD pipeline definition written in Clojure:

(def pipeline-def
 `(
   (either
    manualtrigger/wait-for-manual-trigger
    wait-for-repo)

   (with-workspace
     clone
     (in-parallel
      run-some-tests
      run-smokeing-tests)

     run-package
     deploy)))

λCD itself is a microservice written in Clojure, allowing it to be deployed using its own pipeline (a bootstrap scenario), which may require a separate instance for self‑deployment.

In summary, treating pipelines as code is a emerging practice that demands testing and debugging like any other code, but it enables pipelines to become first‑class citizens, evolve continuously, and unlock further value in a lean delivery process.