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”.
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.