Hochkarätige Build-Automatisierung zur Unterstützung datengesteuerter Entscheidungen beim Britischen Roten Kreuz

• Erfahren Sie, wie Zühlke das Britische Rote Kreuz unterstützt hat

• Wertvolles Feedback lässt sich leichter erhalten, wenn der Fokus auf einer schnellen Wertschöpfung für den Endnutzer liegt

• GitLab bietet eine Vielzahl nützlicher Funktionen

In einer idealen Welt erhalten Entwickler schnelles Feedback zu ihrer Arbeit, wodurch sie ihren Code schnell validieren können. In einer noch idealeren Welt erhält das gesamte Team hinter einem einzigen Produkt rasches Feedback zu den Funktionen, die es den Endnutzern zur Verfügung stellt. Während der Zusammenarbeit mit dem Britischen Roten Kreuz konnte ich erfreut feststellen, wie wir dies in die Wirklichkeit umgesetzt haben.

Rechtzeitiges und rasches Feedback

Rechtzeitiges, rasches Feedback erhalten Produktentwicklungsteams leichter, wenn der Fokus auf schneller Wertschöpfung für den Endnutzer liegt, wodurch dies zum Mittelpunkt ihrer Arbeitsweise werden kann.

Bevor ich Ihnen erläutere, was das Entwicklungsteam bei Zühlke unternommen hat, um eine Gesamtzykluszeit von 10 Minuten zu erreichen, sollten Sie sich einmal in die Welt des Britischen Roten Kreuzes versetzen. Sie sind mit einer sich ständig verändernden Umgebung konfrontiert und müssen genaue und fundierte Entscheidungen treffen, die datengesteuert sind, ein entscheidender Faktor zur Umsetzung ihrer Strategie – zum Beispiel für die Entscheidung, wo in Grossbritannien sie am meisten gebraucht werden.

Was wir für das Britische Rote Kreuz entwickeln sollen, haben wir anhand einer Reihe von User-Experience-Workshops erfahren. Doch das Entwicklungsteam musste erst noch herausfinden, wie wir die Lösung schnell bereitstellen, Wert generieren und Feedback rasch zum Team bringen können, um unsere Ergebnisse zu bestätigen.

Wir benötigten eine Lösung, die Folgendes beinhalten sollte:

• ein Repository der Versionskontrolle;
• Verfolgung von Storys und Fortschritten, die in Sprints unterteilt werden;
• Bereitstellung einer Management- und Zugriffssteuerung für Teammitglieder;
• Einrichtung von CI/CD-Pipelines in deklarativer Weise;
• Speicherung von Docker-Container-Bildern in einer privaten Registrierung;
• Verwaltung von Anmeldeinformationen, um Daten geheim und vom Quellcode getrennt zu halten;
• Integration in Azure.

GitLab erfüllte alle diese Bedürfnisse am besten. Es war in mehrfacher Hinsicht praktisch, doch es war für uns auch eine Überraschung, das Verhalten von GitLab bei der Aufspaltung unseres Projekts zu sehen – auf Einzelheiten werde ich später eingehen …

Was haben wir unternommen?

Zuallererst verfügten wir über ein klares Konzept. Unsere Praktiken umfassen Paarprogrammierung, testgetriebene Entwicklung, einen kontinuierlichen Build-, Test- und Bereitstellungsprozess und eine Begrenzung der laufenden Arbeiten und Benutzertests zur Bestätigung unserer Entscheidungen.

Um ein schnelles und zuverlässiges Verfahren zur Bereitstellung von funktionsfähiger Software für eine Produktionsumgebung in Azure einzuführen, haben wir begonnen, eine «.gitlab-ci.yml»-Datei in unserem Projekt zu erstellen. Diese Datei beschreibt unsere Pipeline-Konfigurationsinformationen. GitLab identifiziert sie und führt automatisch die Pipeline aus, die in drei Phasen laufen soll: Build, Test, Bereitstellung.

Einige nützliche Aspekte bestehen darin, dass Markierung und Versionsverwaltung von Docker-Bildern leicht mit verwalteten Geheimnissen in schlüsselwertbasierten Variablen erfolgen können, die in GitLab gespeichert und in der Pipeline-Konfigurationsdatei referenziert werden. Azure musste eine Authentifizierung durchführen, um Bilder aus der privaten Registrierung abzurufen, indem es leicht zu erstellende Bereitstellungs-Tokens verwendet. Die Bildregistrierung von GitLab war von der Pipeline aus leicht zu verwenden – diese Registrierung ist eine hervorragende Alternative zur Verwendung und Konfiguration einer privaten Registrierung wie etwa derjenigen eines Cloud-Anbieters. Sie ermöglichte uns zum Beispiel, ein Bild direkt von einem Pipeline-Auftrag per Push zu übertragen, alles innerhalb desselben Hosts.

Wir haben bei der Entwicklung einer robusten Pipeline festgestellt, dass man, wenn man das Projekt aufspaltet, eine Pipeline erhält, die bis zur Bereitstellungsphase ausgeführt wird, die in GitLab festgelegte Geheimnisse benötigt, um erfolgreich zu sein, und keine andere Partei sollte wirklich auf diese Variablen zugreifen, oder sie könnte eine nicht funktionsfähige Version für die Produktion bereitstellen.

Insgesamt sind wir sehr stolz darauf, an einem Projekt mitgewirkt zu haben, das einen direkten Wert und Auswirkungen für die Menschen hinter dem Roten Kreuz auf vollautomatische Weise generiert – und so einen Beitrag zu ihrer so wichtigen Arbeit leistet.