Delivery Pipelines as Code – Ein Überblick

Das Jenkins-JobDSL-Plugin [9] ist vermutlich eine der bekanntesten und ältesten Möglichkeiten, CI/CD-Server mithilfe einer deklarativen Sprache zu konfigurieren. Hierbei handelt es sich um eine Groovy-DSL, die XML im Jenkins-Konfigurationsformat generiert. Typischerweise existiert ein Seed-Job, der JobDSL-Code ausführt, um den Rest der Konfiguration zu generieren.

Die etwas mühsame und unübersichtliche Konfiguration einer Pipeline in Jenkins, mit einer Kombination von Downstream-Relationen zwischen Jobs, Parameterized Builds, Fork/Join-plugin und View kann die JobDSL also nur vereinfachen, nicht aber grundlegend verbessern.

repo = 'https://github.com/flosell/simple-maven-project-with-tests.git'
 
def deployQAJobName = deployJob("qa")
def deployCIJobName = deployJob("ci", deployQAJobName)
 
job("build") {
    scm {
        git(repo, "master")
    }
    triggers {
      scm('H/15 * * * *')
    }
    steps {
        shell("mvn test")
    }
    publishers { 
        downstream(deployCIJobName, 'SUCCESS')
    }
}
 
deliveryPipelineView('pipeline view') {
    pipelineInstances(5)
    showAggregatedPipeline()
    columns(2)
    sorting(Sorting.TITLE)
    updateInterval(60)
    enableManualTriggers()
    showAvatars()
    showChangeLog()
    pipelines {
        component('The System', 'build')
    }
}
 
def deployJob(environment, downstreamJob = null) { 
    def jobName = "deploy ${environment}"
    job(jobName) {
        scm {
            git(repo, "master")
        }
        steps { 
            shell("./deploy.sh ${environment}")
        }
        if (downstreamJob) { 
            publishers { 
                downstream(downstreamJob, 'SUCCESS')
            }
        }
    }
    return jobName
}

Sie ist aber in jedem Fall ein einfach umzusetzender erster Schritt hin zu versionierter Pipeline-Konfiguration für alle Entwickler, die bisher Jenkins-Konfigurationen manuell und unversioniert warten.

Mit dem Pipeline-Plugin und Jenkins 2 versucht die Jenkins-Community Continuous Delivery-Pipelines und Pipelines as Code endlich zum First Class Citizen zu machen:

Das Pipeline-Plugin [10] vereinheitlicht hierfür was bisher verstreut über Freestyle Jobs, Fork/Join-Plugin, Pipeline-Visualisierungen und ähnliches implementiert wurde. Als Nutzer definiert man Pipelines in Groovy Scripts, die die Orchestrierung der Pipeline-Jobs übernehmen:

stage name: 'build and test'
 
node {
  git url: 'https://github.com/flosell/simple-maven-project-with-tests.git'
  def mvnHome = tool 'M3'
  sh "${mvnHome}/bin/mvn -B -Dmaven.test.failure.ignore verify"
  step([$class: 'ArtifactArchiver', artifacts: '**/target/*.jar', fingerprint: true])
  step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml'])
}
 
stage name: 'ci and qa'
parallel(ci: {
  node {
    deploy('ci')
  }
},qa: {
  node {
    deploy('qa')
  }
})
 
stage name: 'prod'
 
input 'Ready for Production?'
 
node {
  deploy('prod')
}
 
def deploy(String env) {
  echo "deploying to ${env}"
  sh "deploy.sh ${env}"
}

Anders als bisher dient der Code hier nicht mehr dazu, Konfiguration zu generieren. Stattdessen ist es der Code selbst, der von Jenkins beim Build ausgeführt wird und den Pipeline-Ablauf orchestriert. Der Jenkins-Server selbst wird zur Laufzeit- und Visualisierungsumgebung reduziert, wohingegen die Pipeline selbst in den Code wandert.

Dadurch wird nicht nur die Konfiguration übersichtlicher und versionierbar. Man kann nun auf die Features einer mächtigen Programmiersprache zurückgreifen, um Pipelines zu entwickeln.

Insgesamt ist das Pipeline-Plugin also eine starke Verbesserung, wenn auch die Jenkins-UI zur Visualisierung von Pipelines weiterhin Nachholbedarf hat (z. B. werden parallele Schritte momentan nicht explizit dargestellt).

BlueOcean [11], eine neu entwickelte UI für Jenkins, sollte viele dieser Probleme angehen. Für den Moment sind allerdings viele Features noch nicht implementiert oder ausgereift, sodass sie die alte Jenkins UI zur Zeit noch nicht ersetzen kann.

Wer nach einem Tool sucht, das viele Jahre Erfahrung mit Continuous Delivery abbildet, für den ist GoCD [2] eine gute Option. Ursprünglich von einem Team um Jez Humble (dem Co-Autor von Continuous Delivery) bei ThoughtWorks (der Firma hinter CruiseControl, dem ersten CI-Server überhaupt) entwickelt, ist es inzwischen als Open Source-Tool für jedermann verfügbar. Ähnlich wie bei Jenkins ist das Konzept von Pipelines as Code hier nicht von vornherein eingebaut. Stattdessen kann diese Funktionalität mithilfe der Python-Bibliothek Gomatic [12] nachgerüstet werden.

Hierbei handelt es sich – im Gegensatz zu den Lösungen für Jenkins – nicht um ein Plugin, sondern um eine Bibliothek, die es möglich macht, die GoCD-API aus Python-Code anzusprechen und so Pipelines zu konfigurieren. Man hat also die gesamte Stärke von Python zur Verfügung, um Pipelines zu beschreiben, zu testen, Abstraktionen zu bauen und wiederzuverwenden. Ähnlich wie bei Jenkins ist dies aber ein reiner Konfigurationsmechanismus. Es gibt keine Möglichkeit, GoCDs Verhalten selbst zu beeinflussen. Hierfür sind weiterhin wie bei Jenkins separate Pluginschnittstellen nötig. Beschrieben werden Pipelines im von GoCD bekannten Datenmodell aus Pipelines, Pipeline Material, Stages, Tasks und Jobs:

#!/usr/bin/env python
from gomatic import *
 
def ensure_deployment(env):
    pipeline.ensure_stage("deploy"+env) \
        .ensure_job("deploy"+env) \
        .add_task(ExecTask(['/bin/bash', '-c', './deploy.sh '+env]))
 
configurator = GoCdConfigurator(HostRestClient("localhost:8153"))
 
pipeline_group = configurator.ensure_pipeline_group("demo-pipeline-group")
 
pipeline = pipeline_group \
    .ensure_replacement_of_pipeline("demo-pipeline") \
    .set_git_url("https://github.com/flosell/simple-maven-project-with-tests.git")
 
pipeline.ensure_stage("test")\
    .ensure_job("test") \
    .add_task(ExecTask(['/bin/bash', '-c', 'mvn test']))
 
ensure_deployment('ci')
ensure_deployment('qa')
 
configurator.save_updated_config()

Für Umsteiger besonders interessant ist Gomatics reverse-engineering Feature. Mit einem einfachen Befehl

python -m gomatic.go_cd_configurator -s <GoCD server hostname> -p <pipeline name> > pipeline.py

kann hiermit der Gomatic-Code für eine von Hand gepflegte Pipeline generiert werden.

Für Fortgeschrittene: LambdaCD

Einen etwas radikaleren Weg als die anderen Tools geht LambdaCD [3]: Es schafft die Trennung zwischen Build-Server und dessen Konfiguration komplett ab. Stattdessen wird hier der Build-Server selbst mit allen seinen Funktionen zur Bibliothek, aus der sich Entwickler bedienen können, um einen Build-Server ganz nach ihren Wünschen zusammenzustellen.

Der "as code"-Ansatz wird hier konsequent verfolgt: Es existiert keine Oberfläche, mit der die Konfiguration am Code vorbei manuell verändert werden könnte. Stattdessen wird das gesamte Verhalten der Pipelines in Clojure-Code definiert: die Pipeline ist eine Clojure-Datenstruktur, Build Steps und Kontrollfluss werden über Clojure-Funktionen implementiert.

(ns lambdacd-example.core
  (:require
    [ring.server.standalone :as ring-server]
    [clojure.tools.logging :as log]
    [lambdacd.ui.ui-server :as ui]
    [lambdacd.runners :as runners]
    [lambdacd.util :as util]
    [lambdacd.core :as lambdacd]
    [lambdacd.steps.manualtrigger :as manualtrigger]
    [lambdacd.steps.control-flow :refer [either with-workspace]]
    [lambdacd-git.core :as lambdacd-git]
    [lambdacd.steps.shell :as shell])
  (:gen-class))
 
; --- build steps: ---
 
(def repo-uri "https://github.com/flosell/simple-maven-project-with-tests.git")
(def repo-branch "master")
 
(defn clone [args ctx]
  (lambdacd-git/clone ctx repo-uri repo-branch (:cwd args)))
 
(defn wait-for-commit [args ctx]
  (lambdacd-git/wait-for-git ctx repo-uri))
 
(defn run-tests [args ctx]
  (shell/bash ctx (:cwd args)
              "mvn test"))
 
(defn deploy [env]
  (fn [args ctx]
    (shell/bash ctx (:cwd args)
                (str "echo deploying to " env)
                (str "./deploy.sh" env))))
 
; --- pipeline structure: ---
 
(def pipeline-structure
  `(
     (either
       wait-for-commit
       manualtrigger/wait-for-manual-trigger)
     (with-workspace
       clone
       run-tests
       (deploy :ci)
       (deploy :qa))))
 
; --- wiring to start the server and pipeline ---
 
(defn -main [& args]
  (let [home-dir (util/create-temp-dir)
        config   {:home-dir home-dir
                  :name     "lambdacd example"}
        pipeline (lambdacd/assemble-pipeline pipeline-structure config)
        app      (ui/ui-for pipeline)]
    (log/info "LambdaCD Home Directory is " home-dir)
    (runners/start-one-run-after-another pipeline)
    (ring-server/serve app {:open-browser? false
                            :port          8080})))

Durch diese Architektur können Entwickler die Build-Pipeline wie ein gewöhnliches Stück Software behandeln: Zum Betrieb und Deployment können damit die selben Mechanismen genutzt werden, die das Entwicklungsteam bereits für "normale" Applikationen verwendet.

Zur Entwicklung steht das gesamte Clojure-Ökosystem bereit, um Build-Steps und Kontrollfluss den eigenen Wünschen anzupassen, zu testen und über Teams hinweg wiederzuverwenden. Es ist daher das vermutlich flexibelste der hier angesprochenen Tools. Mit dieser Flexibilität kommt allerdings auch eine gewisse Lernkurve, will man die Möglichkeiten des Tools auch tatsächlich ausschöpfen. Auch in Sachen Feature-Reichtum und Community bleibt dieses noch relativ junge Tool hinter seinen großen und älteren Konkurrenten zurück.

Von den hier vorgestellten Tools ist Concourse [4] vermutlich am schwierigsten aufzusetzen: Im vollen Ausbaustadium hat man es hier mit einem kompletten BOSH Cluster zu tun. Zum Glück bieten die Entwickler inzwischen Vagrant-Boxen und Docker-Container an, die für den Anfang völlig ausreichen.

Concourse entstand ursprünglich als CI/CD-Lösung für das PaaS-Projekt CloudFoundry und ist daher ähnlich wie GoCD optimiert auf komplexere Continuous Delivery-Pipelines in großen Softwareprojekten. Auch hier wird der "as code"-Gedanke konsequent verfolgt: Pipelines werden ausschließlich über YAML-Files definiert und per API in den Build-Server deployed.

Diese YAML-Files definieren Tasks, Resources und Jobs. Dabei definieren Tasks die auszuführenden Aufgaben einer Pipeline, z. B. das Ausführen von Tests oder das Erstellen von deployment-Artefakten. Git-Repositories für Source-Code oder S3-Buckets zum Ablegen von Artefakten werden als Resources modelliert. Jobs bringen beide Konzepte zusammen, sie definieren die Ein- und Ausgaberessourcen für einen Task. Die Pipeline entsteht über diese Abhängigkeitsstrukturen. Zur einfacheren Wartbarkeit können Tasks parametrisiert und in eigene Dateien ausgelagert werden, die zusammen mit der Anwendung versioniert werden.

---
resources:
- name: repo
  type: git
  source:
    uri: github.com/flosell/simple-maven-project-with-tests.git
    branch: concourse
jobs:
- name: test
  plan:
  - get: repo
    trigger: true
  - task: run-tests
    config:
      platform: linux
      image_resource:
        type: docker-image
        source: {repository: maven}
      inputs: 
      - name: repo
      run:
        path: "mvn"
        args: ["test"]
        dir: repo
  - task: deploy-ci
    file: repo/hello-deploy.yaml
    params: 
      TARGET_ENV: "ci"
  - task: deploy-qa
    file: repo/hello-deploy.yaml
    params: 
      TARGET_ENV: "qa"

---
platform: linux
image_resource:
  type: docker-image
  source: {repository: maven}
run:
  path: "bash"
  args: ["-c", "./deploy.sh $TARGET_ENV"]
  dir: "repo"
inputs: 
- name: repo