Wichtige Konzepte für neue Azure Pipelines-Benutzer

Azure DevOps Services

Erfahren Sie mehr über die wichtigsten Konzepte und Komponenten einer Pipeline. Das Verständnis der grundlegenden Begriffe und Teile einer Pipeline kann Ihnen dabei helfen, effizienteren und zuverlässigeren Code zu liefern.

Übersicht über wichtige Konzepte

key concepts graphic

  • Ein Trigger weist eine Pipeline dazu an, ausgeführt zu werden.
  • Eine Pipeline besteht aus einer oder mehreren Phasen. Eine Pipeline kann in einer oder in mehreren Umgebungen bereitgestellt werden.
  • Eine Phase ist eine Möglichkeit, Aufträge in einer Pipeline zu organisieren, und jede Phase kann eine oder mehrere Aufträge haben.
  • 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 enthält.
  • Ein Schritt kann eine Aufgabe oder ein Skript sein und ist der kleinste Baustein einer Pipeline.
  • Eine Aufgabe ist ein vorab verpacktes Skript, das eine Aktion ausführt, z. B. ein REST-API aufrufen oder ein Buildartefakt veröffentlichen.
  • Ein Artefakte ist eine Sammlung von Dateien oder Paketen, die von einer Ausführung veröffentlicht werden.

Azure Pipelines Bedingungen

Agent

Wenn der Build oder die Bereitstellung ausgeführt wird, startet das System einen oder mehrere Aufträge. Ein Agent ist Computerinfrastruktur mit installierter Agentsoftware, die einen Auftrag gleichzeitig 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 eine Reihe von Überprüfungen, die erforderlich sind, bevor eine Bereitstellung ausgeführt wird. Die manuelle Genehmigung ist eine häufig durchgeführte Überprüfung, um Bereitstellungen in Produktionsumgebungen zu steuern. Wenn Überprüfungen in einer Umgebung konfiguriert sind, werden Pipelines beendet, bevor Sie eine Phase starten, in der die Umgebung bereitgestellt wird, bis alle Prüfungen erfolgreich abgeschlossen sind.

Artefakt

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

Continuous Delivery

Die kontinuierliche Übermittlung (CD) ist ein Prozess, durch den Code erstellt, getestet und in einer oder mehreren Test- und Produktionsphasen 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 Warnungssysteme werden ständig ausgeführt, um die Sichtbarkeit 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, Fehler oder Probleme früh im Entwicklungszyklus zu fangen, wodurch sie einfacher 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 Kontinuierlichen Übermittlungsversionspipelinen verwendet, um automatische Bereitstellungen zu fördern.

Bereitstellung

Bei klassischen Pipelines handelt es sich bei einer Bereitstellung um die Ausführung der Vorgänge für eine Stufe, die die Ausführung automatisierter Tests, das Bereitstellen von Buildartefakten und alle anderen Aktionen für diese Phase enthalten kann.

Bei YAML-Pipelines bezieht sich eine Bereitstellung in der Regel auf einen Bereitstellungsauftrag. Ein Bereitstellungsauftrag ist eine Sammlung von Schritten, die sequenziell für eine Umgebung ausgeführt werden. Sie können Strategien wie einmal ausführen, rollieren und canary für Bereitstellungsaufträge verwenden.

Bereitstellungsgruppe

Eine Bereitstellungsgruppe ist eine Reihe von Bereitstellungszielcomputern, die Agents installiert haben. Eine Bereitstellungsgruppe ist nur eine andere Gruppierung von Agents, z. B. ein Agentpool. Sie können die Bereitstellungsziele in einer Pipeline für einen Auftrag mithilfe einer Bereitstellungsgruppe festlegen. Erfahren Sie mehr über Bereitstellungs-Agents für Bereitstellungsgruppen.

Environment

Eine Umgebung ist eine Sammlung von Ressourcen, in denen Sie Ihre Anwendung bereitstellen. Sie kann mindestens einen virtuellen Computer, Container, Web-Apps oder einen beliebigen Dienst enthalten, der zum Hosten der entwickelten Anwendung verwendet wird. Eine Pipeline kann die App in einer oder mehreren Umgebungen bereitstellen, nachdem der Build abgeschlossen ist und Tests ausgeführt werden.

Auftrag

Eine Phase enthält einen oder mehrere Aufträge. 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 besten nützlich, wenn Sie eine Reihe von Schritten in verschiedenen Umgebungen ausführen möchten. Sie können beispielsweise zwei Konfigurationen erstellen – x86 und x64. In diesem Fall verfügen Sie über eine Phase und zwei Aufträge. Ein Auftrag wäre für x86 und der andere Auftrag wäre für x64.

Pipeline

Eine Pipeline definiert den Continuous Integration- und Continuous Deployment-Prozess für Ihre App. Es besteht aus einer oder mehreren Phasen. Es kann als Workflow gedacht werden, der definiert, wie Ihre Test-, Build- und Bereitstellungsschritte ausgeführt werden.

Release

Bei klassischen Pipelines ist eine Version eine versionierte Gruppe von Artefakten, die in einer Pipeline angegeben sind. Die Version enthält eine Momentaufnahme aller Informationen, die erforderlich sind, um alle Aufgaben und Aktionen in der Releasepipeline auszuführen, z. B. Phasen, Aufgaben, Richtlinien wie Trigger und Genehmigende und Bereitstellungsoptionen. Sie können eine Version manuell erstellen, mit einem Bereitstellungsauslöser oder mit der REST-API.

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

Ausführen

Eine Ausführung stellt 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 senden dann die Ausführung an einen oder mehrere Agents. Jeder Agent führt Aufträge aus. Erfahren Sie mehr über die Ausführungssequenz der Pipeline.

Skript

Ein Skript führt Code als Schritt in Ihrer Pipeline mithilfe von 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. Es kann verwendet werden, um die Trennung von Bedenken zu kennzeichnen (z. B. Build, QA und Produktion). Jede Phase enthält einen oder mehrere Aufträge. Wenn Sie mehrere Phasen in einer Pipeline definieren, führen sie standardmäßig nacheinander aus. Sie können die Bedingungen für die Ausführung einer Phase angeben. Wenn Sie darüber nachdenken, ob Sie eine Phase benötigen, fragen Sie sich selbst:

  • Verwalten separate Gruppen verschiedene Teile dieser Pipeline? Sie könnten beispielsweise einen Test-Manager haben, der die Aufträge verwaltet, die sich auf Tests und einen anderen Manager beziehen, der Aufträge im Zusammenhang mit der Produktionsbereitstellung verwaltet. In diesem Fall ist es sinnvoll, separate Phasen für Tests und Produktion zu haben.
  • Gibt es eine Reihe von Genehmigungen , die mit einem bestimmten Auftrag oder einer Reihe von Aufträgen verbunden sind? Wenn ja, können Sie Phasen verwenden, um Ihre Aufträge in logische Gruppen zu unterbrechen, die Genehmigungen erfordern.
  • Gibt es Arbeitsplätze, die eine lange Zeit ausführen müssen? Wenn Sie Teil Ihrer Pipeline haben, die über eine erweiterte Laufzeit verfügt, ist es sinnvoll, sie in ihre eigene Phase zu trennen.

Schritt

Ein Schritt ist der kleinste Baustein einer Pipeline. Beispielsweise kann eine Pipeline aus Build- und Testschritten bestehen. Ein Schritt kann entweder ein Skript oder eine Aufgabe sein. Eine Aufgabe ist einfach ein vorab erstelltes Skript, das Ihnen als Komfort angeboten wird. Informationen zum Anzeigen der verfügbaren Aufgaben finden Sie in der Referenz zum Erstellen und Freigeben von Aufgaben . Informationen zum Erstellen benutzerdefinierter Vorgänge finden Sie unter Erstellen einer benutzerdefinierten Aufgabe.

Aufgabe

Eine Aufgabe ist der Baustein zum Definieren der Automatisierung in einer Pipeline. Eine Aufgabe ist verpacktes Skript oder verfahren, das 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 nach einem Push an 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 Buildauslöser und Release-Trigger.

Bibliothek

Die Bibliothek enthält sichere Dateien und variable Gruppen. Sichere Dateien können Dateien speichern und über Pipelines freigeben. Möglicherweise müssen Sie eine Datei auf DevOps Ebene speichern und dann während des Build- oder Bereitstellungsvorgangs verwenden. In diesem Fall können Sie die Datei in der Bibliothek speichern und verwenden, wenn Sie es benötigen. Variable Gruppen speichern Werte und Geheime, die Sie möglicherweise in eine YAML-Pipeline übergeben oder über mehrere Pipelines verfügbar machen möchten.

Über die Autoren

  • Dave Jarvis hat zur Übersichtsgrafik der wichtigsten Konzepte beigetragen.