Zusammenfassung

  • 2 Minuten

Gute Arbeit! Ihre Pipeline nimmt Gestalt an. Sie und das Tailspin-Team sind von einem einfachen Proof of Concept zu einer realistischen Releasepipeline übergegangen. Sie können diese Pipeline verwenden, um ein Artefakt zu erstellen und es zu testen, bevor Sie es an Ihre Benutzer weitergeben.

In diesem Modul haben Sie Möglichkeiten zur Steuerung kennengelernt, wie Änderungen von einer Phase einer Pipeline zur nächsten gelangen können. Lassen Sie uns die Pipeline überprüfen, die Sie in diesem Modul erstellt haben. Diese Abbildung zeigt die Gesamtform Ihrer Pipeline:

Diagram where the whiteboard shows the final pipeline, which includes the Build, Dev, Test, and Staging stages.

Die Phasen Dev, Test und Staging stellen das Buildartefakt jeweils in ihrer eigenen Azure App Service-Umgebung bereit.

  • Wenn eine Änderung auf GitHub gepusht wird, bewirkt ein Trigger, dass die Build-Phase ausgeführt wird. Die Build-Phase erzeugt ein Buildartefakt als Ausgabe.
  • Die Dev-Phase wird nur ausgeführt, wenn die Änderung im release-Branch erfolgt. Sie verwenden eine Bedingung, um diese Anforderung anzugeben.
  • Die Test-Phase wird jeden Morgen um 3 Uhr ausgeführt. Diese Phase wird nur ausgeführt, wenn der release-Branch Änderungen seit der letzten Ausführung enthält. Sie verwenden einen geplanten Trigger, um anzugeben, wann die Test-Phase ausgeführt wird.
  • Die Staging-Phase wird erst ausgeführt, nachdem Sie die Änderungen in der Test-Phase genehmigt haben. Sie fügen der Stagingumgebung eine Releasegenehmigung hinzu, um die Pipeline anzuhalten, bis Sie die Änderung genehmigen oder ablehnen.

Diese Pipeline erfüllt die Anforderungen des Tailspin-Teams. Die Form Ihrer Pipeline und die Art, wie Änderungen sie durchlaufen, hängen von den Anforderungen Ihres Teams und von den Apps und Diensten ab, die Sie entwickeln.

Obwohl das Team sein Release-Intervall verbessert hat, gibt es noch Spielraum für weitere Verbesserungen. Beispielsweise muss Amita aus der Qualitätssicherung Builds manuell testen und genehmigen, bevor das Team der Geschäftsleitung neue Features präsentieren kann. Im nächsten Modul werden Sie mit dem Tailspin-Team zusammenarbeiten, um weitere Tests zu automatisieren, damit Änderungen die Pipeline noch schneller durchlaufen können.

Weitere Informationen

In diesem Modul haben Sie mit Bedingungen, Triggern und Genehmigungen gearbeitet. Weitere Informationen finden Sie in den folgenden Ressourcen.