Deployment Pipeline

Das Subsystem “Deployment Pipeline” ermöglicht einen kontinuierlichen Entwicklungs- und Produktions- prozess im Sinne von Continuous Delivery, DevOps und Agile ALM. Dafür werden die auf die jeweiligen konkreten Anforderungen angepassten Methoden, Prozesse und Tools bereitgestellt und der Rahmen für eine SSF-kompatible Architektur erstellt.

 

Der Schwerpunkt liegt dabei nicht auf dem Arbeitsumfeld des einzelnen Entwicklers, sondern auf einer Kette reibungslos ineinander greifender Werkzeuge als Mittelpunkt eines gemeinsamen und umfassenden Entwicklungsprozesses.

 

Jeder der vier Abschnitte (siehe Humble/Farlay Continuous Delivery)

  • Build (build und unit tests),
  • automated acceptance tests,
  • performance and load tests und
  • manual acceptance tests

liefert neue Informationen über den Zustand der aktuellen Version der zu entwickelten Software und dokumentiert dieses mit dem Passieren (oder auch nicht) eines “Quality Gates”.

 

grafiken-deployment-pipeline

 

1. Werkzeuge

Zur Umsetzung der Deployment Pipeline werden Tools aus den folgenden Kategorien eingesetzt:

 

1. User- und Rechteverwaltung

Zugangs-Credentials zu den verschiedenen Anwendungen werden in der Regel außerhalb der SSF zentral verwaltet. Die SSF bindet dazu bereits vorhandene LDAP-basierte Hintergrundsysteme, wie z.B. Microsoft Active Directory, OpenLDAP oder andere, an.

2. Code-Verwaltung

Die eigentliche Source-Code-Verwaltung auf der Basis eines verteilten Versions-Control-System (Git) wird um ein Rechtesystem und Möglichkeiten zur Abbildung von Workflows zur Bewertung von Code-Änderungen (Reviews, Freigaben etc.) erweitert.

3. Issue-Management

Die Steuerung der Abfolge einzelner zusammengehöriger Arbeitsschritte (Aufgaben) sowie die Planung (Soll) und Erfassung (Ist) von Ressourcen erfolgt in einem Issue-Management-System.

4. Continuous-Integration-Server

Zentraler Mittelpunkt des Subsystems Deployment-Pipeline ist der CI-Server, der die einzelnen Schritte vom “Auslesen” des Source-Code aus der Code-Verwaltung, über das Erstellen und Testen der zu entwickelnden Artefakte bis zur Auslieferung steuert und die Ergebnisse für weitere Auswertungen zur Verfügung stellt.

5. Artefakt-Repository

Jedes Artefakt wird genau einmal während des Durchlaufens der Deployment Pipeline erstellt und in allen folgenden Schritten wieder- und weiterverwendet.

Dieses Repository ist der zentrale Aufbewahrungsort für die in der Deployment Pipeline erzeugten Artefakte und deren Meta-Daten.

6. Infrastruktur

Sowohl für die bereits beschriebenen Werkzeuge und insbesondere für die Qualitätssicherung müssen ausreichende Rechenkapazitäten in unterschiedlicher aber definierter Form schnell und flexibel zur Verfügung gestellt und auch wieder “entsorgt” werden können.

Die SSF setzt dafür je nach konkreten Anforderungen moderne Virtualisierungs- und Container-Techniken sowie entsprechende Verwaltungswerkzeuge ein.

 

 

2. Architektur

Eine kontinuierliche Auslieferung kann durch den Aufbau einer Anwendung unterstützt oder aber erschwert werden. Ganz allgemein kann davon ausgegangen werden, dass modulare Architekturen zur ersten Kategorie gehören, während monolithische Ansätze eher zu einem “starren” Verhalten führen.

 

Der grundlegende, konkrete Architekturrahmen eines Anwenders der SSF wird deshalb um einen – auf die jeweiligen Anforderungen zugeschnittenen – modularen Systemaufbau ausgerichtet.