Relevanz der Continuous Integration und Release-Automatisierung

Um relevante und qualitativ hochwertige Produkte liefern zu können, muss in der modernen Softwareentwicklung auf geschäftliche Anforderungen schnell reagiert und auch das Feedback von Produktverantwortlichen umgesetzt werden. Je früher das Entwicklungsteam eine Verbesserung integriert und überprüft, desto höher ist die Qualität des Softwareprodukts. Dies ist vor allem bei direkten Verifizierungsprozessen wichtig, die eine sofortige Reaktion auf Änderungen an der Codebasis gewährleisten und die Anzahl der manuellen Schritte während der Release-Vorbereitung reduzieren.

Neben den grundlegenden bewährten DevOps-Vorgehensweisen, die in dieser Blogserie zur Methodik der mobilen Zwölf-Faktor-App beschrieben werden, tragen die kontinuierliche Integration (CI) und kontinuierliche Bereitstellung (CD) dazu bei, den Aufwand für das Operations-Team im Entwicklungs- und Verteilungsprozess für mobile Apps deutlich zu reduzieren. Eine Automatisierung stellt sicher, dass die verteilte Software vor den manuellen Tests die Standards der Codequalität erfüllt:

• Die Continuous Integration dient dazu, das Build-Artefakt der mobilen App anhand der neuesten Codebasis-Änderungen zu assemblieren, in eine verwaltete Repository-Verzweigung zu verschieben und sicherzustellen, dass der resultierende Verzweigungsstatus „stabil“ ist (d. h. dass er die Qualitätsziele des Produkts erfüllt).
• Die Continuous Delivery wird eingebunden, um das ausgewählte Build-Artefakt automatisch als installierbare App in einer Zielumgebung (z. B. über TestFlight) zu implementieren.
• Mit Continuous Deployment werden die kontinuierlichen Bereitstellungsvorgänge hin zur vollautomatischen Veröffentlichung der ausgewählten App-Version für den Produktionseinsatz erweitert. Dies gilt nicht für öffentliche Apps, da ein Release Candidate zur formalen Überprüfung manuell eingereicht werden muss. Allerdings ist dies für Unternehmens-Apps relevant, für die keine Möglichkeit gibt, das Release automatisch mit einer App-Management-Lösung des Unternehmens zu veröffentlichen.

Bei der kontinuierlichen Integration werden spezielle Tools eingesetzt, um mithilfe eines Triggers die Codebasis aus einer Code-Verzweigung des Entwicklungs-Repository abzurufen. Wenn der Code-Snapshot abgerufen wurde, führt die Automatisierung eine Abfolge von definierten Aktionen durch, um ein Build-Artefakt zu erzeugen. Sie führt optional auch eine Verifizierung anhand von Quality Gates (Qualitätsprüfpunkte) durch.

Die Codebasis-Änderung wird bestätigt und als korrekt integriert betrachtet, wenn die Pipeline-Sequenz erfolgreich durchlaufen wurde.

Die korrekte CI-Pipeline-Sequenz für eine mobile Zwölf-Faktor-App sollte im Vorfeld geplant werden. Folgendes muss definiert werden:

• Build-Host-Umgebung: Ein sogenannter „Agent“ oder „Runner“ – entweder ein dedizierter oder ein virtueller/containerisierter Rechner in einer Cloud, der alle erforderlichen Abhängigkeiten enthalten muss (Zielbetriebssystem, SDKs für Frameworks, externe App-Bibliotheken, Prüftools). In einigen Fällen können die Kosten reduziert werden, wenn Linux oder ein dedizierter, selbst gehosteter Build-Agent verwendet wird.
• Pipeline-Trigger: Entweder eine „git push“-Eingabe in eine bestimmte Repository-Verzweigung oder das Erstellen einer Pull-Anfrage. Bei größeren Projekten sollten nicht zu viele Trigger hinzugefügt werden, damit die Pipeline-Ausgaben aussagekräftig bleiben, z. B. nur die Überprüfung von geschützten Verzweigungen.
• Pull-Operation: Die Codebasis aus einer bestimmten Repository-Verzweigung bei einem Trigger. Bei großen Repositorys sollte ein inkrementelles (flaches) Klonen verwendet werden, damit nicht der gesamte Repository-Arbeitsbaum heruntergeladen wird.
• Build-Konfiguration: Unterstützung durch die Codebasis, um ein bestimmtes App-Bundle und eine angepasste Überprüfung je nach Zweck zu generieren, beispielsweise eine Ad-hoc-Verteilung für manuelle Tests oder Leistungsprofil-Ermittlung, und Live-Ready-Verteilung für automatisierte Tests auf echten Geräten, Beta-Tests durch Nutzer oder Produktionseinsatz.
• Pre-Build-Schritte: Beispielsweise Codegenerierung, automatisierte Formatierung oder Asset-Bündelung.
• Post-Build-Qualitätsprüfpunkt: Zur Verifizierung der Codebasis.

Ein konformes Quality Gate für die mobile Zwölf-Faktor-App muss folgende automatisierte Schritte zur Verifizierung umfassen, um sicherzustellen, dass der Build für weitere manuelle Funktionstests bereit ist:

1. Überprüfen des Quellcode-Stils und Durchführen einer statischen Analyse gemäß eines Regelwerks mit geeigneten Lint- und statischen Analyse-Tools.
2. Ausführen von Komponententests, um sicherzustellen, dass die Code-Änderung den Erwartungen entspricht.

Mit diesen zusätzlichen Faktoren lässt sich eine umfassende Checkliste zusammenstellen:

• Erfassung der Kennzahlen zur Codeabdeckung und Abgleich mit einem Mindestabdeckungsziel.
• Erfassung der Kennzahlen zur Codequalität, z. B. die zyklomatische Komplexität oder Duplizierung und Abgleich mit den Basiszielen.
• Ausführung einer chronologischen Analyse zur Codequalität, um Trends zu ermitteln, und Abgleich mit früheren Codebasis-Metrik-Snapshots.
• Durchführung automatischer Integrationstests, Ausführung eines dedizierten API-Client-Moduls für die Remote-Endpunkte.
• Opt-in-End-to-End-UI-Tests, die durch Geräte-Cloud-Dienste mit Berichterstellung koordiniert werden.

Die manuelle Release-Vorbereitung ist möglicherweise mühsam und fehleranfällig, vor allem, wenn die Arbeitsabläufe für verschiedene Ziele angepasst werden. Um die Verteilung von Apps zu gewährleisten, sollten die Delivery- und Deployment-Pipelines die kontinuierliche Integration (CI) nutzen, um App-Bundles vorzubereiten. Sie sollten jedoch je nach Zweck getrennt finalisiert werden.

Einige Beispiele:

• Öffentliche Releases (B2C/B2B), die mit einem Produktionszertifikat für Apple App Store Connect und Google Play Console (für den weiteren Prüfprozess) signiert sind.
• Beta-App-Builds, die mit einem Produktions- oder Ad-hoc-Zertifikat signiert sind, und Prüfung der Apple- und Google-Dokumentation auf verfügbare Optionen.
  
• Ad-hoc-Qualitätsprüfung von App-Builds für eine registrierte Liste von Geräten, für Dienste wie App Center, Firebase App Distribution oder TestFlight.
  
• Interne (B2E) Releases und Builds, die mit einem Unternehmenszertifikat für die Verteilungsplattform eines Unternehmens (MDM- oder UEM-Dienst) signiert sind.

Komplexe CI-/CD-Prozesse für Twelve-Factor-Apps setzen eine korrekte Code-Repository-Organisation, Verzweigungen und Schutzkonventionen voraus. Mit kürzeren Verifizierungszyklen für die Code-Änderungen eines Entwicklers, am besten inline während der Codierung, lassen sich bessere Ergebnisse erzielen. Überlegen Sie, ob die Einrichtung einer Codestil-Analyse in Echtzeit sinnvoll wäre. Die Vorbereitung der Workspace-Build-Skripte für die nahtlose Erstellung, Analyse und Überprüfung von Komponententests und die lokale Ausführung von Integrations- und Ende-zu-Ende-Tests führen zu schnelleren Quality-Gate-Prüfungen, noch bevor CI/CD-Ressourcen eingebunden werden.

Durch die Priorisierung der kontinuierlichen Integration und Bereitstellung führen automatisierte Codebasis-Abläufe zu einer nahtlosen Integration von Änderungen und einer höheren Produktqualität. So lassen sich die Entwicklungszeiten verkürzen und die Organisation und Umsetzung von Produkt-Releases verbessern.