Definieren von klassischen Pipelines

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Azure Pipelines bieten eine hochgradig konfigurierbare und verwaltbare Pipeline für Versionen in mehreren Stages wie Entwicklung, Staging, QA und Produktion. Zudem bietet es die Möglichkeit, Gates und Genehmigungen in jeder einzelnen Stage zu implementieren.

In diesem Tutorial erhalten Sie Informationen zu Folgendem:

  • Continuous Deployment-Trigger
  • Hinzufügen von Stages
  • Hinzufügen von Genehmigungen vor der Bereitstellung
  • Erstellen von Releases und Überwachen von Bereitstellungen

Voraussetzungen

Sie benötigen Folgendes:

  • Eine Releasepipeline, die mindestens eine Stage enthält. Wenn Sie noch keine haben, können Sie eine erstellen, indem Sie einen der folgenden Schnellstarts oder ein Tutorials durchlaufen:

  • Zwei separate Ziele, an denen Sie die App bereitstellen. Dies können virtuelle Computer, Webserver, lokale physische Bereitstellungsgruppen oder andere Arten von Bereitstellungszielen sein. In diesem Beispiel verwenden wir Azure App Service-Websiteinstanzen. Wenn Sie sich dafür entscheiden, dasselbe zu tun, müssen Sie eindeutige Namen wählen, wobei es sich empfiehlt, „QA“ in den Namen des einen und „Produktion“ in den des anderen einzubauen, damit Sie sie leicht identifizieren können. Verwenden Sie das Azure-Portal, um eine neue Web-App zu erstellen.

Continuous Deployment-Trigger

Durch das Aktivieren des Triggers für Continuous Deployment wird die Pipeline angewiesen, jedes Mal, wenn ein neuer Build verfügbar ist, automatisch ein neues Release zu erstellen.

  1. Öffnen Sie in Azure Pipelines die Registerkarte Releases. Wählen Sie Ihre Releasepipeline und dann Bearbeiten aus.

    Bearbeiten der Releasepipeline

  2. Wählen Sie im Abschnitt Artefakte das Symbol Continuous Deployment-Trigger aus, um den Triggerbereich zu öffnen. Stellen Sie sicher, dass dies aktiviert ist, damit ein neues Release erstellt wird, nachdem jeder neue erfolgreiche Build abgeschlossen wurde.

    Continuous Deployment-Trigger

  3. Klicken Sie im Abschnitt Stages auf das Symbol Bedingungen vor der Bereitstellung, um den Bedingungsbereich zu öffnen. Stellen Sie sicher, dass der Trigger für die Bereitstellung in dieser Stage auf Nach einem Release festgelegt ist. Dies bedeutet, dass eine Bereitstellung automatisch initiiert wird, wenn ein neues Release aus dieser Releasepipeline erstellt wird.

    Bedingungen vor der Bereitstellung

    Sie können auch Releasetrigger, Stagetrigger oder Bereitstellungen planen festlegen.

Hinzufügen von Phasen

In diesem Abschnitt werden wir unserer Releasepipeline zwei neue Stages hinzufügen: QA und Produktion (In diesem Beispiel zwei Azure App Service-Websites). Dies ist ein typisches Szenario, in dem Sie zunächst auf einem Test- oder Stagingserver und dann auf einem Live- oder Produktionsserver bereitstellen würden. Jede Stage stellt ein Bereitstellungsziel dar.

  1. Wählen Sie die Registerkarte Pipeline in Ihrer Releasepipeline aus, und wählen Sie die vorhandene Stage aus. Ändern Sie den Namen Ihrer Stage in Produktion.

    Auswählen einer vorhandenen Stage auf der Registerkarte „Pipelines“ und Ändern des Namens in „Produktion“ im Bereich „Stage“

  2. Wählen Sie die Dropdownliste + Hinzufügen aus, und wählen Sie Stage klonen aus (die Klonoption ist nur verfügbar, wenn eine vorhandene Stage ausgewählt ist).

    Auswählen von „Stage klonen“

    In der Regel möchten Sie dieselben Bereitstellungsmethoden mit einer Test- und einer Produktionsstage verwenden, damit Sie sicher sein können, dass Ihre bereitgestellten Apps das gleiche Verhalten aufweisen. Das Klonen einer vorhandenen Stage ist eine gute Möglichkeit, um sicherzustellen, dass Sie die gleichen Einstellungen für beide haben. Anschließend müssen Sie nur die Bereitstellungsziele ändern.

  3. Ihre geklonte Stage hat den Namen Kopie von Produktion. Wählen Sie sie aus, und ändern Sie den Namen in QA.

    Ändern des Stagenamens in QA

  4. Um die Stages in der Pipeline neu zu organisieren, wählen Sie in Ihrer Stage QA das Symbol Bedingungen vor der Bereitstellung aus, und legen Sie den Trigger auf Nach einem Release fest. Das Pipelinediagramm zeigt dann die beiden Stages parallel.

    Neuorganisieren von Stages

  5. Wählen Sie in der Stage Produktion das Symbol Bedingungen vor der Bereitstellung aus, und legen Sie den Trigger auf Nach der Stage fest. Dann wählen Sie in der Dropdownliste Stages die Option QA aus. Das Pipelinediagramm zeigt nun an, dass die beiden Stages in der richtigen Reihenfolge ausgeführt werden

    Auswählen von QA-Triggern und -Stages

    Hinweis

    Sie können Ihre Bereitstellung so einrichten, dass sie gestartet wird, wenn eine Bereitstellung in der vorherigen Stage teilweise erfolgreich ist. Dies bedeutet, dass die Bereitstellung auch dann fortgesetzt wird, wenn bei einer bestimmten nicht kritischen Aufgabe ein Fehler aufgetreten ist. Dies wird in der Regel in einer Fork- und Joinbereitstellungen verwendet, die parallel in verschiedenen Stages bereitgestellt werden.

  6. Wählen Sie die Dropdownliste Aufgaben aus, und wählen Sie dann die Stage QA aus.

    Dropdownmenü „Aufgaben“ und Auswählen der QA-Stage

  7. Ändern Sie je nach den von Ihnen verwendeten Aufgaben die Einstellungen, sodass diese Stage für Ihr QA-Ziel bereitgestellt wird. In unserem Beispiel verwenden wir die Aufgabe Bereitstellen von Azure App Service wie unten gezeigt.

    Aufgabe „Azure App Service bereitstellen“

Hinzufügen von Genehmigungen vor der Bereitstellung

Die Releasepipeline, die wir zuvor geändert haben, wird für QA und Produktion bereitgestellt. Wenn die Bereitstellung für QA fehlschlägt, wird die Bereitstellung in der Produktion nicht ausgelöst. Es wird empfohlen, vor der Bereitstellung in der Produktion immer zu überprüfen, ob Ihre App in der QA- oder Teststage ordnungsgemäß funktioniert. Durch das Hinzufügen von Genehmigungen wird sichergestellt, dass alle Kriterien erfüllt sind, bevor sie für die nächste Stage bereitgestellt werden. Führen Sie die folgenden Schritte aus, um Ihrer Pipeline Genehmigungen hinzuzufügen:

  1. Wählen Sie die Registerkarte Pipeline, das Symbol Bedingungen vor der Bereitstellung und dann Genehmigende Personen vor der Bereitstellung aus.

    Bereich für genehmigende Personen vor der Bereitstellung

  2. Geben Sie im Textfeld Genehmigende Personen die Benutzer*innen ein, die für die Genehmigung der Bereitstellung verantwortlich sind. Es wird auch empfohlen, das Kontrollkästchen Der Benutzer, der ein Release oder eine Bereitstellung anfordert, darf keine Genehmigung erteilen zu deaktivieren.

    Hinzufügen von genehmigenden Personen vor der Bereitstellung

    Sie können beliebig viele genehmigende Personen hinzufügen, sowohl einzelne Benutzer*innen als auch Organisationsgruppen. Es ist auch möglich, Genehmigungen nach der Bereitstellung einzurichten, indem Sie das Symbol „Benutzer“ rechts in der Stage im Pipelinediagramm auswählen. Weitere Informationen finden Sie unter Releasegate- und Genehmigungsübersicht.

  3. Wählen Sie Speichern aus.

    Speichern der Releasepipeline

Erstellen eines Release

Nachdem das Setup der Releasepipeline abgeschlossen ist, können Sie mit der Bereitstellung beginnen. Hierzu erstellen wir manuell ein neues Release. In der Regel wird ein Release automatisch erstellt, wenn ein neues Buildartefakt verfügbar ist. In diesem Szenario erstellen wir sie jedoch manuell.

  1. Öffnen Sie die Dropdownliste Release, und wählen Sie Release erstellen aus.

    Erstellen eines neuen Releases

  2. Geben Sie eine Beschreibung für das Release ein, vergewissern Sie sich, dass die korrekten Artefakte ausgewählt sind, und wählen Sie anschließend Erstellen.

    Bereich zum Erstellen eines neuen Releases

  3. Es wird ein Banner angezeigt, das angibt, dass ein neues Release erstellt wurde. Wählen Sie den Releaselink aus, um weitere Details anzuzeigen.

    Release wurde erfolgreich erstellt

  4. Auf der Seite mit der Releasezusammenfassung werden die Status der Bereitstellung für jede Stage angezeigt.

    Bereitstellungsstatus

    In anderen Ansichten (etwa in der Liste mit den Releases) wird auch ein Symbol angezeigt, das darauf hinweist, dass die Genehmigung aussteht. Wenn Sie auf das Symbol zeigen, wird ein Popupelement mit dem Stagenamen und weiteren Details angezeigt. So kann ein Administrator ganz einfach erkennen, bei welchen Releases eine Genehmigung aussteht, und sich über den Gesamtstatus aller Releases informieren.

    Releaselistenansicht

  5. Wählen Sie das Symbol pending_approval aus, um den Bereich für das Genehmigungsfenster zu öffnen. Geben Sie einen kurzen Kommentar ein, und wählen Sie Genehmigen aus.

    Genehmigung der Bereitstellung

Hinweis

Sie können die Bereitstellung zu einem späteren Zeitpunkt planen, z. B. außerhalb der Spitzenzeiten. Sie können die Genehmigung auch einem anderen Benutzer bzw. einer anderen Benutzerin zuweisen. Releaseadministratoren können auf alle Genehmigungsentscheidungen zugreifen und diese außer Kraft setzen.

Überwachen und Nachverfolgen von Bereitstellungen

Mithilfe von Bereitstellungsprotokollen können Sie das Release Ihrer Anwendung überwachen und debuggen. Führen Sie die folgenden Schritte aus, um die Protokolle unserer Bereitstellung zu überprüfen:

  1. Zeigen Sie in der Releasezusammenfassung auf eine Stage, und wählen Sie Protokolle aus.

    Bereitstellungsprotokolle

    Während der Bereitstellung können Sie weiterhin auf die Protokollseite zugreifen, um die Liveprotokolle jeder Aufgabe anzuzeigen.

  2. Wählen Sie eine beliebige Aufgabe aus, um die Protokolle für diese bestimmte Aufgabe anzuzeigen. Dies erleichtert das Nachverfolgen und Debuggen von Bereitstellungsproblemen. Sie können auch einzelne Aufgabenprotokolle oder eine ZIP-Datei aller Protokolldateien herunterladen.

    Herunterladen von Protokollen

  3. Wenn Sie zusätzliche Informationen zum Debuggen Ihrer Bereitstellung benötigen, können Sie das Release im Debugmodus ausführen.

Nächster Schritt