Zusammenfassung
In diesem Modul haben Sie ein Bereitstellungsmuster als automatisierte Möglichkeit zum reibungslosen Rollout neuer Anwendungsfeatures für Ihre Benutzer definiert. Ein gutes Bereitstellungsmuster kann Ihnen helfen, Ausfallzeiten zu minimieren. Außerdem können Sie neue Features schrittweise für Ihre Benutzer bereitstellen.
Sie können aus verschiedenen Bereitstellungsmustern wählen. Das von Ihnen ausgewählte Bereitstellungsmuster hängt von ihren Gründen für die Bereitstellung und Ihre Ressourcen ab. Verwenden Sie Canary-Tester? Werden Sie einen dunklen Start verwenden und Tester auswählen, die nicht wissen, dass sie Tester sind? 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. Oder wenn Sie wissen möchten, ob eine Version besser als eine andere Version funktioniert, können Sie A/B-Tests auswählen.
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 Bereitstellungsplätze austauschen. Durch den Austausch können sie Änderungen an der Produktion sofort fördern. Obwohl das Team nicht bereit ist, ihre Website für die Öffentlichkeit freizugeben, haben sie bewiesen, dass sie neue Features für ihre Benutzer erhalten können, ohne dass Ausfallzeiten auftreten.
Als Bonus haben Sie in diesem Modul auch gelernt, wie Sie eine unbeabsichtigte Änderung weiterleiten, indem Sie einen Git-Commit zurücksetzen und dann die zurückgesetzte Änderung durch die Pipeline verschieben.
Wie schneidet das Team ab?
Zuvor in der DevOps-Reise des Teams hat Mara eine Wertstromzuordnungsübung ausgeführt, die dem Team bei der Analyse ihres aktuellen Release-Zyklus-Prozesses half.
Erinnern Sie sich daran, dass das Aktivitätsverhältnis oder die Effizienz die Prozesszeit dividiert durch die Gesamtvorlaufzeit ist:
$${Aktvitätsverhältnis = }{\dfrac{Prozesszeit}{Gesamtvorlaufzeit}}$$
Das Tailspin-Webteam hat zunächst diese Metrik verwendet, um festzustellen, dass sie 23 Prozent effizient waren.
Das Team reduzierte zunächst einige Ineffizienzen, wenn sie eine kontinuierliche Integration (CI) implementierten. Durch die Anwendung der kontinuierlichen Lieferung (CD) haben sie nun noch mehr Ineffizienzen reduziert.
In früheren Lernpfaden reduzierte das Team:
Die Zeit, die zum Einrichten der Quellcodeverwaltung für neue Features benötigt wird. Die erforderliche Zeit dauerte von drei Tagen bis null Tage.
Das Team hat diese Verbesserung erreicht, indem er von der zentralen Quellcodeverwaltung zu Git, einer Form der verteilten Quellcodeverwaltung, wechselt. Durch die Verwendung der verteilten Quellcodeverwaltung müssen sie nicht warten, bis Dateien entsperrt werden.
Die Zeit, die es braucht, um Code an Amita, den Tester zu liefern. Die erforderliche Zeit ging zwischen zwei Tagen und null Tagen.
Das Team hat diese Verbesserung erreicht, indem sie ihren Buildprozess auf Azure Pipelines umstellten. Azure Pipelines benachrichtigt Amita automatisch, wenn ein Build verfügbar ist. Entwickler müssen die Kalkulationstabelle von Amita nicht mehr aktualisieren, um sie zu benachrichtigen.
Die Zeit, die Amita benötigt, um neue Features zu testen. Die erforderliche Zeit dauerte von drei Tagen bis zu einem Tag.
Das Team hat diese Verbesserung durch Komponententests seines Codes erreicht. Sie führen Komponententests jedes Mal aus, wenn eine Änderung durch die Buildpipeline wechselt, sodass weniger Fehler und Regressionen Amita erreichen. Die reduzierte Arbeitsauslastung 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 Zeit, die benötigt wird, um den Build in die Testphase zu bringen. Die erforderliche Zeit dauerte von drei Tagen bis zu einem Tag.
Das Team hat dies erreicht, indem es einen geplanten Trigger verwendete, um jeden Tag um 3:00 Uhr zum Test zu deployen.
Die Zeit, die benötigt wird, um den getesteten Build in Staging zu bringen. Die erforderliche Zeit ging zwischen zwei Tagen und null Tagen.
Das Team hat diese Verbesserung durch Hinzufügen von Selenium-UI-Tests, einer Form von Funktionstests, zur Testphase erreicht. Diese automatisierten Tests sind viel schneller als die manuellen Versionen.
Die Zeit, die benötigt wird, um den genehmigten Build von Staging in die Live-Umgebung zu übertragen. Die erforderliche Zeit ging von einem Tag auf weniger als einen Tag.
Das Team erzielte diese Verbesserung, indem es der Pipeline manuelle Genehmigungsprüfungen hinzufügte. Wenn das Management zustimmt, kann Tim die Änderungen von der Staging- zur Liveumgebung freigeben.
Diese Änderungen verringern die Gesamtlaufzeit von 22 Tagen auf 10 Tage. Wenn wir diese Zahlen in die Formel ersetzen:
$${Aktivitätsverhältnis\ =\ }{\dfrac{5\ Tage}{10\ Tage}}{ = 0,50}$$
Multiplizieren Sie das Ergebnis mit 100 Prozent, und wir erhalten eine Reduktion von 50 Prozent .
Obwohl es immer Verbesserungsmöglichkeiten gibt, ist diese Änderung ein Gewinn für das Team. Kunden erhalten nicht nur einen Mehrwert schneller, das Tailspin-Team verbringt jetzt weniger Zeit mit Warten und mehr Zeit damit, das zu tun, was ihnen am meisten Spaß macht: Features liefern, die ihre Kunden lieben werden.
Erfahren Sie mehr
Verwenden Sie diese zusätzlichen Ressourcen, um mehr über App Service, Bereitstellungsplätze und das Zurücksetzen von Änderungen zu erfahren: