Zusammenfassung
In diesem Modul haben Sie ein Bereitstellungsmuster als automatisierte Methode definiert, um ein Rollout neuer Anwendungsfeatures für Ihre Benutzer reibungslos auszuführen. Ein gutes Bereitstellungsmuster kann Ihnen helfen, Downtime zu minimieren. Es kann es Ihnen auch ermöglichen, den Rollout neuer Features schrittweise für Ihre Benutzer auszuführen.
Sie können aus verschiedenen Bereitstellungsmustern auswählen. Welches Bereitstellungsmuster Sie wählen, hängt sowohl von Ihren Gründen für die Bereitstellung als auch von Ihren Ressourcen ab. Verwenden Sie Canary-Tester? Werden Sie einen Dark Launch nutzen und Tester*innen auswählen, die nicht wissen, dass sie etwas testen? Wenn Sie über eine vertrauenswürdige Gruppe von Testern verfügen, die schrittweise von einer kleinen Gruppe zu einer größeren Gruppe anwächst, dann könnten Sie sich für eine Bereitstellung mit progressiver Exposition entscheiden. Wenn Sie wissen möchten, ob eine Version bessere Ergebnisse liefert als eine andere, können Sie sich auch für A/B-Tests entscheiden.
Das Tailspin-Team hat sich entschieden, das blaugrüne Bereitstellungsmuster mithilfe von Bereitstellungsplätzen in Azure App Service zu implementieren. Bereitstellungsslots sind Live-Apps mit eigenen Hostnamen. Das Team kann zwei Bereitstellungsslots vertauschen. Durch den Austausch können sie Änderungen in der Produktion sofort höher stufen. Obwohl das Team noch nicht bereit ist, die Website für die Öffentlichkeit freizugeben, hat es bewiesen, dass den Benutzer*innen neue Features ohne Downtime zur Verfügung gestellt werden können.
Als Bonus haben Sie in diesem Modul auch gelernt, wie Sie für eine unbeabsichtigte Änderung einen Rollforward ausführen können, indem Sie einen Git-Commit rückgängig machen und dann die rückgängig gemachte Änderung über die Pipeline pushen.
Wie schneidet das Team ab?
Im Modul Zugriff auf Ihren vorhandenen Softwareentwicklungsprozess führte Mara eine Übung zur Wertstromanalyse durch. Die Übung half dem Team, ihren aktuellen Releasezyklusprozess zu analysieren.
Denken Sie daran, dass das Aktivitätsverhältnis bzw. die Effizienz als Verarbeitungszeit, geteilt durch die gesamte Vorlaufzeit definiert ist.
$${Aktvitätsverhältnis\ =\ }{\dfrac{Prozesszeit}{Gesamtvorlaufzeit}}$$
Das Tailspin-Webteam verwendete diese Metrik zunächst, um festzustellen, dass die Effizienz bei 23 Prozent lag.
Das Team reduzierte zunächst einige Ineffizienzen, als es Continuous Integration (CI) implementierte. Durch die Anwendung von Continuous Delivery (CD) haben sie nun Ineffizienzen noch weiter reduziert.
In vorherigen Lernpfaden hat das Team Folgendes reduziert:
Die erforderliche Zeit zum Einrichten der Quellcodeverwaltung für neue Features. Die benötigte Zeit ging von drei Tagen auf null Tage zurück.
Das Team erreichte diese Verbesserung, indem es von der zentralisierten Quellcodeverwaltung zu Git wechselte, einer Form der verteilten Quellcodeverwaltung. Durch die Verwendung der verteilten Quellcodeverwaltung müssen sie nicht darauf warten, dass Dateien entsperrt werden.
Die erforderliche Zeit für die Bereitstellung von Code für Amita (Tester). Die benötigte Zeit ging von zwei Tagen auf null Tage zurück.
Das Team erreichte diese Verbesserung, indem es mit seinem Buildprozess zu Azure Pipelines wechselte. Azure Pipelines benachrichtigt Amita automatisch, wenn ein Build verfügbar ist. Die Entwickler müssen die Kalkulationstabelle von Amita nicht länger aktualisieren, um sie zu benachrichtigen.
Die Zeit, die Amita zum Testen neuer Features benötigt. Die benötigte Zeit ging von drei Tagen auf einen Tag zurück.
Diese Verbesserung erreichte das Team durch Komponententests für ihren Code. Sie führen jedes Mal Komponententests durch, wenn eine Änderung die Buildpipeline durchläuft, sodass Amita weniger Fehler und Regressionen erreichen. Die reduzierte Workload bedeutet, dass Amita jeden manuellen Test schneller abschließen kann.
Die Releasepipeline, die Sie und das Team in diesem Lernpfad erstellt haben, hat Folgendes reduziert:
Die erforderliche Zeit, um den Build in die Stage Test zu versetzen. Die benötigte Zeit ging von drei Tagen auf einen Tag zurück.
Das Team nutzte dafür einen Plantrigger, damit die Bereitstellung täglich um 3:00 Uhr auf Test erfolgt.
Die erforderliche Zeit, um den getesteten Build in die Stagingumgebung zu versetzen. Die benötigte Zeit ging von zwei Tagen auf null Tage zurück.
Das Team fügte dafür in der Phase Test Selenium-Benutzeroberflächentests, eine Art von Funktionstest, hinzu. Diese automatisierten Tests sind viel schneller als die manuellen Versionen.
Die erforderliche Zeit, um den genehmigten Build von der Stagingumgebung in die Liveumgebung zu versetzen. Die benötigte Zeit ging von einem Tag auf weniger als einen Tag zurück.
Das Team erreichte diese Verbesserung, indem es die Pipeline um manuelle Genehmigungsüberprüfungen ergänzte. Wenn das Management zustimmt, kann Tim die Änderungen von der Staging- zur Liveumgebung freigeben.
Diese Änderungen reduzieren die Gesamtvorlaufzeit von 22 Tagen auf 10 Tage. Wenn wir diese Zahlen in die Formel ersetzen:
$${Aktvitätsverhältnis\ =\ }{\dfrac{5\ Tage}{10\ Tage}}{ = 0,50}$$
Multiplizieren Sie das Ergebnis mit 100 Prozent, so erhalten wir eine Reduzierung um 50 Prozent.
Obwohl es immer Raum für Verbesserungen gibt, ist diese Änderung ein Gewinn für das Team. Kunden erhalten den Wert nicht nur schneller, das Tailspin-Team verbringt jetzt weniger Zeit mit dem Warten und mehr Zeit mit dem, was Sie am meisten genießen: Features entwickeln, die ihre Kunden lieben werden.
Weitere Informationen
Verwenden Sie diese zusätzlichen Ressourcen, um mehr über App Service, Bereitstellungsslots und das Ausführen von Rollbacks für Änderungen zu erfahren: