Azure-Pipelines Erstellen und in Azure DevOps einbinden

Beschreibt das Erstellen der Azure-Pipeline-Skripte und wie diese zum Überprüfen der PullRequests und Deployen von Add-on-Releases in Azure DevOps eingebunden werden?

1. Azure-Pipelines Erstellen

Benötigte Dateien:

Pipeline für die PullRequest Validierung

Das Script azure-pipelines-test.yml definiert eine Azure Build Pipeline. Diese Pipeline soll verwendet werden, um beim Erstellen von PullRequests und commits in PullRequests ausgeführt zu werden. Es wird die gesamte Solution kompiliert und alle enthaltenen Tests werden ausgeführt. Dabei wird auch die CodeCoverage ermittelt. Der Trigger in dieser Pipeline wurde nicht definiert, da diese Pipeline manuell in die PullRequest automation eingebunden werden muss. Dieses Script kann direkt aus dem Repository kopiert werden.
Eine Änderung ist vorzunehmen: Der Wert der Variable artifactReleaseName muss auf den Namen des Projektes/Add-ons angepasst werden.

...
# Ausschnitt aus azure-pipelines-test.yml
variables:
  solution: '**/*.sln'
  buildPlatform: Any CPU
  buildConfigurationStrongName: ReleaseWithStrongName
  artifactFeed-pitFmAddons: pitFM_Addons/pitFM.Addons
  artifactPackagePitAddonSnk: pit-addon.snk
  # Projektname oder ähnliches setzen. Wird nur benötigt, wenn 'Publish Results' (letzter Abschnitt) aktiviert ist.
  artifactReleaseName: pitFM_Example
...

TDB: Beschreibung erstellen, wie die Pipeline in der PullRequest-Automation eingebunden wird.

Pipeline zum Release erstellen

Das Script azure-pipelines-build-release.yml definiert die Build Pipeline zum Erstellen des Add-on-Releases. Der Trigger ist so definiert, dass diese Pipeline gestartet wird, sobald ein neues Tag mit der Syntax "v*.." erstellt wird.

...
# Ausschnitt aus azure-pipelines-build-release.yml
variables:
  solution: '**/*.sln'
  buildPlatform: Any CPU
  artifactPackagePitAddonSnk: pit-addon.snk
  artifactFeed-pitFmAddons: pitFM_Addons/pitFM.Addons

  # Die releaseVersion darf nicht verändert werden. Das übernimmt das Build-Skript.
  # Für Testzwecke kann die Azure-Variable 'Release.MainVersion' definiert werden. Die darin enthaltene Versionsnummer muss 4-stellig sein. Beispielwert: "1.0.2.0"
  # Die releaseVersion wird automatisch überschrieben, wenn der Tag- oder Branch-Name die Syntax 'v1.2.3' erfüllt.
  releaseVersion: $(Release.MainVersion)
  # Das buildTarget muss mit dem <TargetFramework> aus der *.csproj übereinstimmen. (vom Add-on-Projekt)
  buildTarget: net472
  # Der projectName ist der Name des C#-Projektes(Add-on-Projekt). Der Name wird für die Add-on-Zip-Datei und das Auffinden der kompilierten DLLs verwendet.
  projectName: pitFM_Example
...

2. Azure-Pipelines Einbinden

Vorbedingung: Um die erstellten Azure-Pipelines in Azure DevOps einbinden zu können, müssen die beiden Skripte in dem Repository (main) gespeichert werden.

2.1. Folder für Pipelines

Pro Add-on wird ein neuer Folder erstellt.

Im Seitenmenü Pipelines auswählen.
In der Pipelines-Ansicht die Pipelines-Liste auf All stellen.
Den neuen Pipeline-Folder erstellen.
Als Name den Namen des Addons ohne "pitFM_" eingeben.

2.2. Azure-Pipelines erstellen

Die nachfolgend beschriebenen Schritte müssen für beide Pipeline-Skripte separat ausgeführt werden.

Unter dem neu erstellten Ordner auf "Create a new pipeline here." klicken.
"Azure Repos Git" auswählen.
Das Repository des Add-ons auswählen. -> Example
"Existing Azure Pipelines YAML file" auswählen.
Der main-branch muss ausgewählt werden.
Es werden beide erstellten Pipelineskripte angezeigt.
Das Skript azure-pipelines-test.yml ist auszuwählen.
Abspeichern der Pipeline mit dem Save-Button. Das Speichern ist etwas versteckt, daher siehe Screenshot.
Die Azure Pipeline ist nun erzeugt. Es soll jetzt noch ein passender Name vergeben werden.
Es sollen die Namen wie im Screenshot angegeben verwendet werden.
1. aus azure-pipelines-test.yml wird "Example PR validation"
2. aus azure-pipelines-build-release.yml wird "Example Release"

2.3. Pipelines verwenden

Die Example PR validation Pipeline wird als Branch Policy verwendet. Das bedeutet, wenn ein PullRequest erstellt wird, wird diese Pipeline automatisch gestartet. Diese Pipeline muss erfolgreich durchlaufen, damit der PullRequest gemergt werden kann.

Die Example Release Pipeline startet, durch seinen definierten Trigger immer, wenn ein Tag erstellt wird. Dabei sollte der Tag die oben beschriebene Syntax "v*.." aufweisen.

Im linken Menü den untersten Eintrag "Projektsettings" anklicken.
Im Project-Settings-Menü den Eintrag Repositories anklicken.
Das Repository auswählen.
Den Policies-Tab auswählen.
Nach unten scrollen und den main-branch auswählen.
In den Policies für den main-branch "Check for comment resolution" aktivieren und Required setzen. Dieser Schalter definiert, dass der PullRequest nicht gemergt werden kann, wenn Kommentare (z.B. durch Code-Review) geschrieben wurden und diese nicht als gelöst markiert wurden.
Etwas weiter unten in den Branch-Policies soll, über den +-Button, eine Build-Policy unter "Build Validation" hinzugefügt werden.
Information: Diese Build-Policy checkt den PR-Branch und den main-Branch aus und mergt den PR-Branch in den main-Branch. Das passiert lokal in einer Sandbox. Der Main-Branch wird also nicht wirklich verändert. Dieser Merge auf main ist wichtig, dadurch wird der Code-Stand so für die Build-Pipeline vorbereitet wie nach dem echten Merge. So laufen Compiler und Tests auf dem zukünftigen Code-Stand.
Es ist die "PR validation"-Pipeline des Projektes auszuwählen. -> "Example PR validation"
Einstellungen sind wie im Screenshot zu setzen.
Die Trigger-Einstellung (Automatic) definiert, dass die Pipeline nach jeder Änderung am PullRequest (hauptsächlich neue Commits) erneut ausgeführt wird.
Policy requirement (Required) definiert, dass die angegebene Pipeline erfolgreich durchlaufen sein muss, damit der PullRequest beendet werden kann.
Build expiration (Immediately...) definiert, dass Änderungen am main-Branch ebenfalls die Pipeline starten und zwar direkt nach der Änderung. Die kann passieren, wenn mehrere PullRequests existieren und einer in den main-Branch gemergt wird. Dann müssen alle offenen PullRequests erneut geprüft werden. Azure selbst prüft, ob neue merge-Konflikte existieren. Ist dies nicht der Fall, wird die Pipeline gestartet.

Table of Contents