Wie eine komplett automatisierte Deployment-Pipeline die agile Softwareentwicklung durch kontinuierliche Rollouts unterstützt.
Das IT-Beratungsgeschäft befindet sich derzeit in einem Umbruch. Traditionelle Entwicklungsmodelle und Abläufe werden unter den Spannungsfeldern schnellere Produkteinführung (Time-To-Market) und Kosteneinsparung täglich in Frage gestellt. Auch die profi.com AG stellt sich regelmäßig diesen Herausforderungen. Um unseren Kunden fundiertes Know-how zur Verfügung zu stellen, beobachten und verfolgen wir stetig Marktentwicklungen und führen Pilotprojekte zu vielversprechenden Vorgehen und Technologien durch. Einer dieser Piloten umfasst den Aufbau und die kritische Analyse eines Source2Production-Prozesses.
Source2Production – Was meinen wir damit?
Im klassischen Release-Ablauf wurde neuer Code einer Software zu bestimmten Zeitpunkten eingefroren und über langwierige Prozesse in diversen Testumgebungen freigegeben, um dann in die Produktionsumgebung als neue Version ausgerollt zu werden. Mit dem Aufleben agiler Softwareentwicklung werden viele dieser Schritte automatisiert und erfolgen zeitnah. Qualitätsaussagen zu einer potenziellen neuen Software-Version sollen möglichst schnell nach Änderungen der Codebasis erfolgen. Manuelle Eingriffe sind in diesen Abläufen eher hinderlich. Im besten Fall – es traten keine Fehler auf – soll die neue Version direkt für ein Produktions-Release vorbereitet und, wenn möglich, freigegeben werden.
Wir haben mit einer intern entwickelten Applikation zur verteilten Arbeit in SCRUM-Meetings (Planning und Retrospective) einen derartigen Prozess beispielhaft erstellt. Der „profi.com Scrummaster“ ist als Drei-Schicht-Applikation auf Basis von angular, nodejs sowie mariadb entwickelt und befindet sich derzeit in der internen Beta-Phase.
Sobald es zu einer Code-Änderung kommt, werden die entsprechenden Build-, Test- und Release-Prozesse angestoßen. Im Falle eines fehlerhaften Tests wird ein Release in Produktion abgelehnt. Nur erfolgreich getestete Software geht in Produktion.
Der Prozess
Unser Demo-Setup beinhaltet Systeme zur Source Code-Verwaltung sowie zur Orchestrierung der einzelnen Prozess-Schritte. Eine neue Code-Version startet per Web-Hook die Jenkins-Pipeline, welche im Groben aus den folgenden Schritten besteht:
- Provisionierung eines Agenten in OpenShift
- Starten des Build-Prozesses und erzeugen einer neuen Version
- Deployment einer Testumgebung
- Durchführung von Integrations- und Performance-Tests
- Freigabe der neuen Version
Um technische Ressourcen (CPU, Speicher etc.) auch für weitere Prozesse nutzen zu können, werden innerhalb unseres Kubernetes-Clusters – verwaltet als OpenShift-Plattform – Build-Ressourcen nach Bedarf provisioniert und gestartet. Der erste Schritt besteht daher in der Bereitstellung eines dedizierten CI-Agenten für den Job.
Jenkins bietet hierfür durch die offene Plugin-Struktur diverse Möglichkeiten. Unsere Entscheidung fiel auf das Basis Kubernetes-Plugin und der Beschreibung des Agenten innerhalb des Jenkins-Files.
Nachdem ein Build-Agent erfolgreich zur Verfügung gestellt wurde, muss eine neue Version der Applikation erzeugt werden. Dies erfolgt durch Build-Konfigurationen in OpenShift. Jenkins startet lediglich eine Instanz des Builds und wartet auf eine erfolgreiche Terminierung des Prozesses. Die dadurch entstandene Version wird in einem OpenShift ImageStream, einer internen Registry, gespeichert.
Auf Basis der neuen Version – es erfolgen zu diesem Zeitpunkt noch keine dynamischen Tests – wird eine neue Testumgebung aufgebaut. Hier können Oberflächen-Tests und eine Performance-Analyse in einer unabhängigen und „frischen“ Umgebung durchgeführt werden. Das Vorgehen stellt sicher, dass neue Versionen zeitnah einer Qualitätsprüfung unterzogen werden. Des Weiteren sichern wir mit der Bereitstellung neuer Testumgebungen ab, dass die Automatisierung stets auf der korrekten, neuen Software-Version durchgeführt wird.
Sollten alle Tests fehlerfrei durchgeführt worden sein, wird der Build als neue Produktiv-Version freigegeben und eventuelle Deployments der Anwendung werden automatisch durch OpenShift-Prozesse aktualisiert.
Das Ergebnis
Der hier beschriebene Pilot machte uns mit der Komplexität agiler Entwicklung und agilen Rollouts vertraut. Vor allem das Zusammenspiel diverser Softwarelösungen, von Source Code Management-Systemen (SCM) bis hin zu Feedback-Möglichkeiten, stellte eine kleine Herausforderung dar.
Zusammenfassend hat uns der Pilot ein tieferes Verständnis für die technischen Möglichkeiten zur Umsetzung von Continuous Deployment-Prozessen verschafft. Vor allem der Einsatz skalierbarer Container-Plattformen stellt für die Bereitstellung neuer Testumgebungen einen erheblichen Mehrwert dar. Ein Ausbau des Piloten sowie eine kontinuierliche Verbesserung und Erweiterung erfolgt unter Anderem im Laufe unseres Trainee-Programms.
Wir werden auch in Zukunft weiter am „Zahn der Zeit“ bleiben und durch interne Projekte und Proof-of-Concepts neue Herangehensweisen und Tools evaluieren, um weiterhin Beratungsleistung in der gewohnten Qualität liefern zu können.
