Verwendung von Azure Pipelines

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Azure Pipelines unterstützt die kontinuierliche Integration (CI) und die kontinuierliche Übermittlung (CD), um Ihren Code kontinuierlich zu testen, zu erstellen und bereitzustellen. Sie erreichen dies, indem Sie eine Pipeline definieren.

Die neueste Möglichkeit zum Erstellen von Pipelines ist mit dem YAML-Pipeline-Editor. Sie können auch klassische Pipelines mit dem Klassischen Editor verwenden.

Azure Pipelines unterstützt die kontinuierliche Integration (CI) und die kontinuierliche Übermittlung (CD), um Ihren Code kontinuierlich zu testen, zu erstellen und bereitzustellen. Sie führen dies aus, indem Sie eine Pipeline mithilfe der Benutzeroberfläche definieren, auch als Classic bezeichnet.

Hinweis

In Microsoft Team Foundation Server (TFS) 2018 und früheren Versionen werden Build- und Release-Pipelines als Definitionen bezeichnet, Ausführungen werden als Builds bezeichnet, Dienstverbindungen werden als Dienstendpunkte bezeichnet, Stages werden als Umgebungen bezeichnet und Aufträge werden als Phasen bezeichnet.

Automatisieren von Tests, Builds und Übermittlung

Die kontinuierliche Integration (CI) automatisiert Tests und Builds für Ihr Projekt. CI hilft, Fehler oder Probleme früh im Entwicklungszyklus zu erfassen, wenn sie einfacher und schneller zu beheben sind. Elemente, die als Artefakte bezeichnet werden, werden von CI-Systemen erstellt. Sie werden von den Kontinuierlichen Übermittlungsversionspipelinen verwendet, um automatische Bereitstellungen zu fördern.

Die fortlaufende Übermittlung stellt automatisch Code in mehreren Phasen bereit, um die Qualität zu steigern. Continuous Integration-Systeme erzeugen bereitstellbare Artefakte, einschließlich Infrastruktur und Apps. Automatisierte Releasepipelines nutzen diese Artefakte, um neue Versionen und Fehlerkorrekturen für das Ziel Ihrer Wahl freizugeben.

Continuous Integration (CI) Continuous Delivery (CD)
- Erhöhen der Codeabdeckung
- Schneller erstellen, indem Test- und Buildausführungen geteilt werden
- Stellen Sie automatisch sicher, dass Sie keinen fehlerhaften Code senden
- Ausführen von Tests kontinuierlich
- Automatische Bereitstellung von Code in der Produktion
- Stellen Sie sicher, dass Bereitstellungsziele über aktuellen Code verfügen
- Verwenden von getestetem Code aus DEM CI-Prozess

Definieren von Pipelines mithilfe der YAML-Syntax

Sie definieren Ihre Pipeline in einer YAML-Datei, die mit dem Rest Ihrer App aufgerufen azure-pipelines.yml wird.

Pipelines YAML intro image

  • Die Version der Pipeline wird mit Ihrem Code verwaltet. Dabei wird dieselbe Verzweigungsstruktur verwendet. Eine Überprüfung Ihrer Änderungen erzielen Sie durch Code Reviews in Pull Requests und Brancherstellungsrichtlinien.
  • Jede von Ihnen verwendete Zweigstelle kann die Pipeline ändern, indem Sie die azure-pipelines.yml Datei ändern. Erfahren Sie mehr über die Verzweigung von YAML-Pipelines.
  • Eine Änderung am Buildprozess kann zu einer Unterbrechung oder zu einem unerwarteten Ergebnis führen. Da sich die Änderung mit dem Rest Ihrer Codebasis der Versionskontrolle unterliegt, können Sie das Problem leichter identifizieren.

Führen Sie die folgenden grundlegenden Schritte aus:

  1. Konfigurieren Sie Azure Pipelines zur Verwendung Ihres Git-Repositorys.
  2. Bearbeiten Sie Ihre Datei, um Ihren azure-pipelines.yml Build zu definieren.
  3. Übertragen Sie den Code per Push in Ihr Repository für die Versionskontrolle. Mit dieser Aktion wird der Standardauslöser ausgelöst, um den Buildvorgang und die Bereitstellung durchzuführen und anschließend die Ergebnisse zu überwachen.

Ihr Code wird nun aktualisiert, erstellt, getestet und gepackt. Er kann auf einem beliebigen Ziel bereitgestellt werden.

YAML-Pipelines sind in TFS 2018 und früheren Versionen nicht verfügbar.

Definieren von Pipelines mithilfe der klassischen Schnittstelle

Erstellen und Konfigurieren von Pipelines im Azure DevOps-Webportal mit dem Editor für die Klassische Benutzeroberfläche. Sie definieren eine Buildpipeline, um Ihren Code zu erstellen und zu testen sowie um anschließend Artefakte zu veröffentlichen. Außerdem definieren Sie eine Releasepipeline, um diese Artefakte zu nutzen und für Bereitstellungsziele bereitzustellen.

Pipelines designer intro image

Führen Sie die folgenden grundlegenden Schritte aus:

  1. Konfigurieren Sie Azure Pipelines zur Verwendung Ihres Git-Repositorys.
  2. Verwenden Sie den klassischen Editor Azure Pipelines, um Ihre Build- und Releasepipelinen zu erstellen und zu konfigurieren.
  3. Übertragen Sie den Code per Push in Ihr Repository für die Versionskontrolle. Diese Aktion löst Ihre Pipeline aus und führt Tasks wie das Erstellen oder Testen von Code aus.

Der Build erstellt ein Artefakte, das von den restlichen Pipelines verwendet wird, um Aufgaben auszuführen, z. B. die Bereitstellung in der Bereitstellung in der Bereitstellung oder Produktion.

Ihr Code wird nun aktualisiert, erstellt, getestet und gepackt. Er kann auf einem beliebigen Ziel bereitgestellt werden.

Verfügbarkeit von Funktionen

Bestimmte Pipelinefeatures sind nur beim Verwenden von YAML oder beim Definieren von Build- oder Releasepipelinen mit der klassischen Schnittstelle verfügbar. In der folgenden Tabelle wird angegeben, welche Features unterstützt werden und für welche Aufgaben und Methoden.

Funktion YAML Klassischer Build Klassisches Release Notizen
Agents Ja Ja Ja Gibt eine erforderliche Ressource an, auf der die Pipeline ausgeführt wird.
Genehmigungen Ja Nein Ja Definiert eine Reihe von Überprüfungen, die vor abschluss einer Bereitstellungsphase erforderlich sind.
Artefakte Ja Ja Ja Unterstützt das Veröffentlichen oder Nutzen verschiedener Pakettypen.
Zwischenspeichern Ja Ja Nein Reduziert die Buildzeit, indem die Wiederverwendung von Ausgaben oder heruntergeladenen Abhängigkeiten aus einer Ausführung in späteren Ausführungen zugelassen wird. In der Vorschauversion nur mit Azure Pipelines verfügbar.
Conditions (MSBuild-Bedingungen) Ja Ja Ja Gibt Bedingungen an, die vor dem Ausführen eines Auftrags erfüllt werden sollen.
Containeraufträge Ja Nein Nein Gibt Aufträge an, die in einem Container ausgeführt werden sollen.
Forderungen Ja Ja Ja Stellt sicher, dass die Pipelineanforderungen erfüllt werden, bevor eine Pipelinestufe ausgeführt wird. Erfordert selbstgehostete Agents.
Abhängigkeiten Ja Ja Ja Gibt eine Anforderung an, die erfüllt werden muss, um den nächsten Auftrag oder die nächste Phase auszuführen.
Bereitstellungsgruppen Ja Nein Ja Definiert einen logischen Satz von Bereitstellungszielcomputern.
Bereitstellungsgruppenaufträge Nein Nein Ja Gibt einen Auftrag für das Release in einer Bereitstellungsgruppe an.
Bereitstellungsaufträge Ja Nein Nein Definiert die Bereitstellungsschritte.
Umgebung Ja Nein Nein Stellt eine Sammlung von Ressourcen dar, die für die Bereitstellung als Ziel dienen. Nur mit Azure Pipelines verfügbar.
Gates Nein Nein Ja Unterstützt die automatische Sammlung und Auswertung externer Integritätssignale, bevor sie eine Veröffentlichungsphase abschließen. Nur für classic Release verfügbar.
Aufträge Ja Ja Ja Definiert die Ausführungssequenz einer Reihe von Schritten.
Dienstverbindungen Ja Ja Ja Aktiviert eine Verbindung mit einem Remotedienst, der zum Ausführen von Aufgaben in einem Auftrag erforderlich ist.
Dienstcontainer Ja Nein Nein Ermöglicht es Ihnen, den Lebenszyklus eines containerisierten Diensts zu verwalten.
Phasen Ja Nein Ja Organisiert Aufträge innerhalb einer Pipeline.
Aufgabengruppen Nein Ja Ja Kapselt eine Abfolge von Aufgaben in eine einzelne, wiederverwendbare Aufgabe. Wenn Sie YAML verwenden, finden Sie weitere Informationen unter „Vorlagen“.
Aufgaben Ja Ja Ja Definiert die Bausteine, aus denen sich eine Pipeline zusammensetzt.
Vorlagen Ja Nein Nein Definiert wiederverwendbare/n Inhalt, Logik und Parameter.
Trigger Ja Ja Ja Definiert das Ereignis, das die Ausführung einer Pipeline auslöst.
Variablen Ja Ja Ja Stellt einen Wert dar, der durch Daten ersetzt wird, die an die Pipeline übergeben werden sollen.
Variablengruppen Ja Ja Ja Dient dem Speichern von Werten, die Sie kontrollieren und über mehrere Pipelines hinweg verfügbar machen möchten.

TFS 2015 bis TFS 2018 unterstützt nur die klassische Schnittstelle. In der folgenden Tabelle wird angegeben, welche Pipelinefeatures beim Definieren von Build- oder Releasepipelinen verfügbar sind.

Funktion Klassischer Build Klassisches Release Notizen
Agents Ja Ja Gibt eine erforderliche Ressource an, auf der die Pipeline ausgeführt wird.
Genehmigungen Nein Ja Definiert eine Reihe von Überprüfungen, die vor abschluss einer Bereitstellungsphase erforderlich sind.
Artefakte Ja Ja Unterstützt das Veröffentlichen oder Nutzen verschiedener Pakettypen.
Conditions (MSBuild-Bedingungen) Ja Ja Gibt bedingungen an, die vor dem Ausführen eines Auftrags erfüllt werden sollen.
Forderungen Ja Ja Stellt sicher, dass die Pipelineanforderungen erfüllt werden, bevor eine Pipelinestufe ausgeführt wird. Erfordert selbstgehostete Agents.
Abhängigkeiten Ja Ja Gibt eine Anforderung an, die erfüllt werden muss, um den nächsten Auftrag oder die nächste Phase auszuführen.
Bereitstellungsgruppen Nein Ja Definiert einen logischen Satz von Bereitstellungszielcomputern.
Bereitstellungsgruppenaufträge Nein Ja Gibt einen Auftrag für das Release in einer Bereitstellungsgruppe an.
Aufträge Ja Ja Definiert die Ausführungssequenz einer Reihe von Schritten.
Dienstverbindungen Ja Ja Aktiviert eine Verbindung mit einem Remotedienst, der zum Ausführen von Aufgaben in einem Auftrag erforderlich ist.
Phasen Nein Ja Organisiert Aufträge innerhalb einer Pipeline.
Aufgabengruppen Ja Ja Kapselt eine Abfolge von Aufgaben in eine einzelne, wiederverwendbare Aufgabe. Wenn Sie YAML verwenden, finden Sie weitere Informationen unter „Vorlagen“.
Aufgaben Ja Ja Definiert die Bausteine, aus denen sich eine Pipeline zusammensetzt.
Trigger Ja Ja Definiert das Ereignis, das die Ausführung einer Pipeline auslöst.
Variablen Ja Ja Stellt einen Wert dar, der durch Daten ersetzt wird, die an die Pipeline übergeben werden sollen.
Variablengruppen Ja Ja Dient dem Speichern von Werten, die Sie kontrollieren und über mehrere Pipelines hinweg verfügbar machen möchten.

Nächste Schritte