Wichtige Konzepte für neue Azure Pipelines-Benutzer
Azure DevOps Services
Erfahren Sie mehr über die wichtigsten Konzepte und Komponenten einer Pipeline. Wenn Sie die grundlegenden Begriffe und Teile einer Pipeline verstehen, können Sie besseren Code effizienter und zuverlässiger bereitstellen.
Wichtige Konzepte – Übersicht
- 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 einen oder mehrere Aufträge enthalten.
- 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. das Aufrufen einer REST-API oder das Veröffentlichen eines Buildartefakts.
- Ein Artefakt ist eine Sammlung von Dateien oder Paketen, die von 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 Agentsoftware, 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 eine Reihe von Ü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, werden Pipelines angehalten, bevor eine Phase zur Bereitstellung in der Umgebung beginnt, 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 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 Warnsysteme werden ständig ausgeführt, um den gesamten CD-Prozess sichtbar zu machen. 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, 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 Continuous Delivery-Releasepipelines verwendet, um automatische Bereitstellungen zu steuern.
Bereitstellung
Bei klassischen Pipelines ist eine Bereitstellung die Aktion zum Ausführen der Tasks für eine Phase, die das Ausführen automatisierter Tests, das Bereitstellen von Buildartefakten und alle anderen Aktionen umfassen kann, die für diese Phase angegeben werden.
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 Gruppe von Bereitstellungszielcomputern, auf denen Agents installiert sind. Eine Bereitstellungsgruppe ist nur eine weitere Gruppe 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 die Bereitstellung von Agents für Bereitstellungsgruppen.
Environment
Eine Umgebung ist eine Sammlung von Ressourcen, in der Sie Ihre Anwendung bereitstellen. Sie kann einen oder mehrere virtuelle Computer, Container, Web-Apps oder einen beliebigen Dienst enthalten, der zum Hosten der zu entwickelnden Anwendung verwendet wird. Eine Pipeline kann die App in einer oder mehreren Umgebungen bereitstellen, nachdem der Build abgeschlossen 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 gemeinsam auf demselben Agent ausgeführt. Aufträge sind besonders nützlich, 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 Phase und zwei Aufträge. Ein Auftrag wäre für x86 und der andere 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.
Bei klassischen Pipelines kann eine Pipeline auch als Definition bezeichnet werden.
Freigabe
Bei klassischen Pipelines ist ein Release ein Versionssatz von Artefakten, die in einer Pipeline angegeben sind. Das Release enthält eine Momentaufnahme aller Informationen, die zum Ausführen aller Aufgaben und Aktionen in der Releasepipeline erforderlich sind, z. B. Phasen, 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 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 zunächst 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.
Bei klassischen Pipelines stellt ein Build eine Ausführung einer Pipeline dar.
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. 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 Stages 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 darüber nachdenken, ob Sie eine Phase benötigen, fragen Sie sich:
- Verwalten separate Gruppen verschiedene Teile dieser Pipeline? Beispielsweise können Sie einen Test-Manager haben, der die Aufträge verwaltet, die sich auf Tests beziehen, und einen anderen Manager, 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 aufzuteilen, die Genehmigungen erfordern.
- Gibt es Aufträge, die lange ausgeführt werden müssen? Wenn Sie über einen Teil Ihrer Pipeline verfügen, der über eine längere Laufzeit verfügt, ist es sinnvoll, sie in eine eigene Phase zu unterteilen.
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 Benutzerfreundlichkeit angeboten wird. 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 einem Satz 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 sind eine Möglichkeit, Dateien zu speichern und pipelineübergreifend freizugeben. Möglicherweise müssen Sie eine Datei auf DevOps-Ebene speichern und sie dann während des Builds oder der Bereitstellung verwenden. In diesem Fall können Sie die Datei in der Bibliothek speichern und verwenden, wenn Sie sie benötigen. Variablengruppen speichern Werte und Geheimnisse, die Sie möglicherweise an eine YAML-Pipeline übergeben oder über mehrere Pipelines hinweg verfügbar machen möchten.
Über die Autoren
- Dave Jarvis hat an der Übersichtsgrafik zu den wichtigsten Konzepten beigetragen.