Das von uns entwickelte Tool optimiert den gesamten Release-Prozess Schritt für Schritt von der Integration bis zur Produktion, steigert die Effizienz und minimiert mögliche Fehlerquellen, indem es eine klare und strukturierte Verbindung zwischen den beteiligten Systemen herstellt, den Release-Prozess für mehrere Microservices in mehreren Kubernetes-Clustern automatisiert und als Schnittstelle zwischen verschiedenen Systemen wie Jira API, GitLab API, Azure Cloud und Kubernetes fungiert. Die Anwendung umfasst alle notwendigen Schritte, um den Release-Workflow effizient zu gestalten. Zunächst wird auf Basis der Jira API der Scope erfasst, indem die betroffenen Microservices identifiziert und der Umfang des Releases festgelegt werden. Das Tool erstellt eine versionierte Release-Dokumentation, die die spezifischen Versionen der Releases beschreibt, sowie automatisierte Release-Tags als Verbindung zu den CI/CD-Pipelines von GitLab. Schließlich überprüft das Tool die Versionen der Microservices, die im Kubernetes-Cluster bereitgestellt werden.
Warum Releases lästig sein können
Während der Entwicklung dieser Software waren wir für die Releases und Deployments mehrerer Microservices in einer komplexen Infrastruktur verantwortlich und stießen dabei auf einige Schwierigkeiten. Erstens blieb die Liste der Tickets, die leicht mehrere Dutzend erreichen konnte, in einem Release selten konstant. Einige Tickets wurden aus dem Release entfernt, andere kamen hinzu. Einige wurden im letzten Moment geschlossen. All dies musste nachverfolgt werden, was manuell eine ziemlich schwierige Aufgabe war. Jedes Ticket enthielt einen oder mehrere Merge Requests, die sorgfältig gesammelt werden mussten. Nachdem alle Änderungen in einem gemeinsamen Branch zusammengeführt worden waren, war es eine gute Idee, zu überprüfen, ob nicht einige vergessen worden waren. Dies konnte durchaus passieren, wenn man bedenkt, dass der Umfang der Tickets nicht konstant war und ein Eigenleben führte. Andere Überprüfungen waren auch nützlich, z.B. in welchem Branch der Merge durchgeführt worden war. Entwickler waren Menschen, und Menschen machten Fehler. So konnte es passieren, dass die Ziel-Branches von Merge Requests versehentlich die falschen waren. Es war eine gute Idee, dies jedes Mal automatisch zu überprüfen. Es war auch eine gute Idee, zu überprüfen, ob der Feature Branch nach einem Merge gelöscht worden war.
Mehrere Releases auf einmal - kein Problem?
Es kam häufig vor, dass sich Major- und Minor-Releases sowie Bugfixes überschnitten und nicht der menschlichen, sondern der Geschäftslogik folgten. Ohne ein entsprechendes System konnte man leicht verwirrt werden. Die Lösung war einfach, musste jedoch programmiert werden. Alle Versionsinformationen waren dynamisch und wurden in einer Datenbank gespeichert. Für jedes Release wurde für jede Phase eine Dokumentenseite erstellt, die alle notwendigen Informationen über das Release, Links zu Tickets, Merge Requests, Tags und Pipelines enthielt. Diese Seiten waren versioniert, und man konnte jederzeit alle Änderungen während des Releases nachvollziehen. Was wurde hinzugefügt, was wurde entfernt. Das Programm ermöglichte es dem Benutzer, die vollständige Liste der Releases zu sehen und zu jedem einzelnen zu wechseln.
Tags für mehrere Dienste werden nicht manuell erstellt
Nachdem die Feature Branches in den Release Branch zusammengeführt worden waren, mussten Tags in jedem der Services erstellt werden. Die Tags wurden automatisch erstellt, und ihre Versionierung wurde berücksichtigt, wenn während des Release-Prozesses bereits ein Ticket zu einem der Services hinzugefügt worden war, d.h. ein Merge-Request gestellt worden war und das Tag aktualisiert werden musste.
Ist alles einwandfrei gelaufen?
Nach Abschluss des Deployments musste der Inhalt des Clusters überprüft werden, um sicherzustellen, dass die Container-Versionen den Release-Zielen entsprachen. Zu diesem Zweck kommunizierte ein spezieller CLI-Befehl mit dem Cluster und listete alle zu überprüfenden Versionen auf. Ein separates Team kümmerte sich darum, dass die Inhalte der Develop-Branches (ein Merkmal des Unternehmens, für das das Programm entwickelt worden war) zu einem bestimmten Zeitpunkt des Releases in die Master-Branches eingespielt wurden.
Status und Kommentare
Beim Start eines Deployments auf den einzelnen Stages musste sichergestellt werden, dass alle Tickets einen bestimmten Status hatten und dem zuständigen Product Owner zugeordnet waren, was ebenfalls automatisch geschah, sobald der Befehl ausgeführt wurde. Nach dem Deployment auf die einzelnen Stages mussten die Tickets kommentiert, ihr Status gegebenenfalls geändert und sie an den zuständigen Product Owner weitergeleitet werden. Dieser Prozess war nicht kompliziert, aber wenn er manuell durchgeführt wurde, verschwendete man Zeit mit sich wiederholenden Routinearbeiten. Solche Prozesse konnten automatisiert werden, was in diesem Fall auch geschehen war. Nach der Bereitstellung in den einzelnen Phasen wurden der Status und die Eigentümerschaft der Tickets automatisch geändert.
Bereinigung des Dev-Stages
Nach einem Release war es oft notwendig, die Dev-Stage zu „bereinigen“, um unnötige Container mit Test- und Feature-Branches zu entfernen. Dieser Prozess musste für jeden Service einzeln durchgeführt werden, was eine zeitaufwändige Aufgabe darstellte. Um dies zu vereinfachen, wurden die Inhalte der Dev-Stage, die sich auf die Services in der Version bezogen, in einer Tabelle zusammengefasst. Auf dieser Grundlage war es sehr einfach, unnötige Branches zu entfernen, die notwendigen Zusammenführungen durchzuführen und die Feature-Branches, die sich im Genehmigungsprozess befanden, in den Development Stack einzufügen, sodass sie die neuesten Änderungen der Version enthielten.
Mehr Projekte rund um Release:
Igor Ilin – 01.12.2020