Wichtige Konzepte für neue Azure Pipelines-Benutzer

Azure DevOps Services

Erfahren Sie mehr über die wichtigsten Konzepte und Komponenten der Azure Pipelines. Wenn Sie die grundlegenden Begriffe und Teile einer Pipeline kennen, können Sie Code effizienter erstellen, testen und bereitstellen.

Wichtige Konzepte – Übersicht

• Ein Trigger weist eine Pipeline dazu an, ausgeführt zu werden.
• Eine Pipeline besteht aus einer oder mehreren Stages. Eine Pipeline kann in einer oder in mehreren Umgebungen bereitgestellt werden.
• Eine Stage ist eine Möglichkeit zum Organisieren von Aufträgen in einer Pipeline. Jede Stage kann einen oder mehrere Aufträge umfassen.
• Jeder Auftrag wird auf einem Agent ausgeführt. Ein Auftrag kann auch ohne Agent erfolgen.
• Jeder Agent führt einen Auftrag aus, der einen oder mehrere Schritte umfasst.
• Ein Schritt kann eine Aufgabe oder ein Skript sein und stellt den kleinsten Baustein einer Pipeline dar.
• Bei einer Task handelt es sich um ein vorgefertigtes Skript, das eine Aktion durchführt, z. B. das Aufrufen einer REST-API oder das Veröffentlichen eines Buildartefakts.
• Ein Artefakt ist eine Sammlung von Dateien oder Paketen, die bei einer Ausführung veröffentlicht werden.

Azure Pipelines-Begriffe

Agent

Wenn der Build oder die Bereitstellung ausgeführt wird, startet das System einen oder mehrere Aufträge. Ein Agent ist die Computinginfrastruktur mit installierter Agent-Software, die Aufträge einzeln ausführt. Ihr Auftrag könnte beispielsweise auf einem von Microsoft gehosteten Ubuntu-Agent ausgeführt werden.

Ausführlichere Informationen zu den verschiedenen Arten von Agents und deren Verwendung finden Sie unter Azure Pipelines-Agents.

Genehmigungen

Genehmigungen definieren verschiedene Überprüfungen, die vor der Ausführung einer Bereitstellung erforderlich sind. Die manuelle Genehmigung ist eine häufig durchgeführte Überprüfung, um Bereitstellungen in Produktionsumgebungen zu steuern. Sind Überprüfungen für eine Umgebung konfiguriert, wird die Pipelineausführung angehalten, bis alle Überprüfungen erfolgreich abgeschlossen sind.

Artefakt

Ein Artefakt ist eine Sammlung von Dateien oder Paketen, die beim Ausführen veröffentlicht werden. Artefakte werden für nachfolgende Aufgaben wie Verteilung oder Bereitstellung zur Verfügung gestellt. Weitere Informationen finden Sie unter Artefakte in Azure Pipelines.

Continuous Delivery

Continuous Delivery (CD) ist ein Prozess, mit dem Code in einer oder mehreren Test- und Produktionsphasen erstellt, getestet und bereitgestellt wird. Das Bereitstellen und Testen in mehreren Phasen trägt zur Qualitätsverbesserung bei. Continuous Integration-Systeme erzeugen bereitstellbare Artefakte, einschließlich Infrastruktur und Apps. Automatisierte Releasepipelines nutzen diese Artefakte, um neue Versionen und Fehlerkorrekturen für bestehende Systeme freizugeben. Überwachungs- und Warnsysteme werden ständig ausgeführt, um den Einblick in den gesamten CD-Prozess zu fördern. Durch diesen Prozess wird sichergestellt, dass Fehler häufig und frühzeitig abgefangen werden.

Continuous Integration

Continuous Integration (CI) ist die von Entwicklungsteams verwendete Methode, um das Testen und Erstellen von Code zu vereinfachen. CI hilft dabei, Fehler oder Probleme frühzeitig im Entwicklungszyklus zu erkennen, sodass sie leichter und schneller behoben werden können. Automatisierte Tests und Builds werden als Teil des CI-Prozesses ausgeführt. Der Prozess kann nach einem festgelegten Zeitplan ausgeführt werden, immer wenn Code gepusht wird, oder beides. Elemente, die als Artefakte bezeichnet werden, werden von CI-Systemen erstellt. Sie werden von den Continuous Delivery-Releasepipelines verwendet, um automatische Bereitstellungen zu steuern.

Bereitstellung

Bei einer klassischen Pipeline ist eine Bereitstellung die Aktion der Aufgabenausführung für eine Phase. Die Bereitstellung das Ausführen automatisierter Tests, das Bereitstellen von Buildartefakten und alle anderen Aktionen umfassen kann, die für diese Phase angegeben sind.

Bei YAML-Pipelines bezieht sich eine Bereitstellung auf einen Bereitstellungsauftrag. Ein Bereitstellungsauftrag ist eine Sammlung von Schritten, die nacheinander für eine Umgebung ausgeführt werden. Sie können Strategien wie einmaliges Ausführen, Rollen und Canary für Bereitstellungsaufträge verwenden.

Bereitstellungsgruppe

Bei einer Bereitstellungsgruppe handelt es sich um einen Satz von Bereitstellungsziel-Computern, auf denen Agents installiert sind. Eine Bereitstellungsgruppe ist lediglich eine weitere Gruppierung von Agents, ähnlich wie ein Agentpool. Mithilfe einer Bereitstellungsgruppe können Sie die Bereitstellungsziele in einer Pipeline für einen Auftrag festlegen. Erfahren Sie mehr über die Bereitstellung von Agents für Bereitstellungsgruppen.

Umgebung

Eine Umgebung ist eine Sammlung von Ressourcen, in der Sie Ihre Anwendung bereitstellen. Eine Umgebung kann einen oder mehrere virtuelle Computer, Container, Web-Apps oder einen beliebigen Dienst enthalten. Pipelines können für einer oder mehreren Umgebungen bereitstellen, nachdem ein Build abgeschlossen und Tests ausgeführt wurden.

Auftrag

Eine Stage enthält mindestens einen Auftrag. Jeder Auftrag wird auf einem Agent ausgeführt. Ein Auftrag stellt eine Ausführungsgrenze für einen Satz von Schritten dar. Alle Schritte werden zusammen auf demselben Agent ausgeführt. Aufträge sind am nützlichsten, wenn Sie eine Reihe von Schritten in verschiedenen Umgebungen ausführen möchten. Beispielsweise können Sie zwei Konfigurationen erstellen: x86 und x64. In diesem Fall verfügen Sie über eine Stage und zwei Aufträge. Ein Auftrag wäre für x86 und der andere für x64 vorgesehen.

Aufträge ohne Agent werden in Azure DevOps und Azure DevOps Server ohne Verwendung eines Agents ausgeführt. Eine begrenzte Anzahl von Aufgaben unterstützt Aufträge ohne Agent.

Pipeline

Eine Pipeline definiert den Continuous Integration- und Continuous Deployment-Prozess für Ihre App. Sie besteht aus einer oder mehreren Stages. Man kann sie sich als einen Workflow vorstellen, der definiert, wie Test-, Build- und Bereitstellungsschritte ausgeführt werden.

Für klassische Pipelines kann eine Pipeline auch als Definition bezeichnet werden.

Freigabe

Bei klassischen Pipelines ist eine Freigabe ein versionsspezifischer Satz mit Artefakten, die in einer Pipeline angegeben sind. Sie enthält eine Momentaufnahme aller Informationen, die zum Ausführen aller Aufgaben und Aktionen in der Freigabepipeline erforderlich sind, z. B. Stages, Aufgaben, Richtlinien wie Trigger und genehmigende Personen sowie Bereitstellungsoptionen. Sie können ein Release manuell, mit einem Bereitstellungstrigger oder mit der REST-API erstellen.

Für YAML-Pipelines befinden sich die Build- und Freigabephasen in einer mehrstufigen Pipeline.

Ausführen

Das Ausführen stellt jeweils eine Ausführung einer Pipeline dar. Er erfasst die Protokolle, die mit der Ausführung der Schritte verknüpft sind, sowie die Ergebnisse von Testausführungen. Während einer Ausführung verarbeitet Azure Pipelines zuerst die Pipeline und sendet die Ausführung dann an einen oder mehrere Agents. Jeder Agent führt Aufträge aus. Erfahren Sie mehr über die Pipelineausführungssequenz.

Für klassische Pipelines stellt ein Build eine Ausführung einer Pipeline dar.

Skript

Ein Skript führt Code als Schritt in Ihrer Pipeline mithilfe der Befehlszeile, PowerShell oder Bash aus. Sie können plattformübergreifende Skripts für macOS, Linux und Windows schreiben. Im Gegensatz zu einer Aufgabe ist ein Skript benutzerdefinierter Code, der für Ihre Pipeline spezifisch ist.

Phase

Eine Phase ist eine logische Grenze in der Pipeline. Sie kann verwendet werden, um die Trennung von Anliegen (z. B. Build, QA und Produktion) zu markieren. Eine Stage enthält mindestens einen Auftrag. Wenn Sie mehrere Phasen in einer Pipeline definieren, werden diese standardmäßig nacheinander ausgeführt. Sie können die Bedingungen für die Ausführung einer Phase angeben. Wenn Sie sich fragen, ob Sie eine Stage benötigen, bedenken Sie Folgendes:

• Verwalten separate Gruppen verschiedene Teile dieser Pipeline? Beispielsweise können Sie über einen Test-Manager zum Verwalten der Aufträge verfügen, die sich auf Tests beziehen. Zudem können Sie einen anderen Manager haben, der Aufträge im Zusammenhang mit der Produktionsbereitstellung verwaltet. In diesem Fall ist es sinnvoll, separate Test- und Produktionsphasen zu haben.
• Gibt es eine Reihe von Genehmigungen, die mit einem bestimmten Auftrag oder einer Reihe von Aufträgen verknüpft sind? Wenn ja, können Sie Phasen verwenden, um Ihre Aufträge in logische Gruppen aufzuteilen, die Genehmigungen erfordern.
• Gibt es Aufträge, die lange ausgeführt werden müssen? Wenn für einen Auftrag in Ihrer Pipeline eine lange Laufzeit erforderlich ist, macht es Sinn, diesen Auftrag in eigene Phasen aufzuteilen.

Schritt

Ein Schritt ist der kleinste Baustein einer Pipeline. Eine Pipeline kann beispielsweise aus Build- und Testschritte bestehen. Ein Schritt kann entweder ein Skript oder eine Aufgabe sein. Eine Aufgabe ist ganz einfach ein vorgefertigtes Skript, das Ihnen die Arbeit erleichtern soll. Informationen zum Anzeigen der verfügbaren Aufgaben finden Sie in der Referenz zu Build- und Releasetasks. Informationen zum Erstellen benutzerdefinierter Aufgaben finden Sie unter Erstellen einer benutzerdefinierten Aufgabe.

Aufgabe

Eine Aufgabe ist der Baustein zum Definieren der Automatisierung in einer Pipeline. Eine Aufgabe ist ein gepacktes Skript oder eine Prozedur, die mit einer Reihe von Eingaben abstrahiert wurde.

Trigger

Ein Trigger ist ein Element, das eingerichtet wird, um der Pipeline mitzuteilen, wann sie ausgeführt werden soll. Sie können eine Pipeline so konfigurieren, dass sie bei einem Push in ein Repository, zu geplanten Zeiten oder nach Abschluss eines anderen Builds ausgeführt wird. Alle diese Aktionen werden als Trigger bezeichnet. Weitere Informationen finden Sie unter Buildtrigger und Releasetrigger.

Bibliothek

Die Bibliothek enthält sichere Dateien und Variablengruppen. Sichere Dateien stellen eine Möglichkeit zum Speichern und Pipeline-übergreifenden Freigeben von Dateien dar. Sie wollen möglicherweise dieselbe Datei für verschiedene Pipelines referenzieren. In diesem Fall können Sie die Datei in der Bibliothek speichern und sie bei Bedarf verwenden. In Variablengruppen werden Werte und Geheimnisse gespeichert, die Sie möglicherweise an eine YAML-Pipeline übergeben oder Pipeline-übergreifend zur Verfügung stellen möchten.

Über die Autoren

• Dave Jarvis hat an der Übersichtsgrafik zu den wichtigsten Konzepten beigetragen.