Azure Pipelines: Strukturierung und Templates

Eine durchdachte Ablage von Pipelines in der Versionsverwaltung ist wichtig für eine effiziente Entwicklung und das Deployment von Anwendungen. Mit YAML-Dateien in Azure DevOps und GitHub kannst du nicht nur Pipelines für einzelne Anwendungen erstellen, sondern auch Templates nutzen, die verschiedene Logiken abbilden, die wiederverwendet werden können. Dadurch wird der Build- und Deployment-Prozess einer Anwendung optimiert und gleichzeitig die Zugänglichkeit für andere Pipelines sichergestellt. Auch hängen Änderungen an der Pipeline direkt mit Änderungen am Code zusammen, was die Nachvollziehbarkeit und das Review der Änderungen verbessert.

Ablage von YAML-Pipelines

Wie bereits im Artikel zu Source Code: Empfohlene Ordner- und Dateistruktur beschrieben, ist eine klare Strukturierung der Ordner und Dateien in der Versionsverwaltung entscheidend. Dies gilt auch für die Ablage von YAML-Pipelines.

YAML-Pipelines befindet sich auf oberster Ordnerebene in einem Ordner namens eng. Dieser kann je nachdem dafür genutzt werden, um Pipelines abzulegen oder auch Skripte die von Pipelines oder Entwickler:innen genutzt werden. Wer hier nochmal Unterordner für pipelines und scripts benötigt, kann dies nach eigenem Geschmack anpassen.

Wer GitHub Actions nutzt, kann die YAML-Pipelines auch in .github/workflows ablegen. Dieser Ordner wird von GitHub automatisch erkannt und die Pipelines ausgeführt.

Eine weitere Aufteilung der Pipelines nach templates und Ordner je Applikation ist hilfreich für die Übersichtlichkeit.

eng/
  templates/
    build/
        dotnet.steps.yml
    deploy/
        azure/
            app-service.steps.yml
  app1/
    pipeline.yml
    build.yml
    deploy.yml
    deploy-env.yml

Aufteilen von Pipelines für Anwendungen

Die Aufteilung einer Pipeline für eine einzelne Anwendung in verschiedene Dateien ermöglicht eine bessere Übersichtlichkeit und auch eine Wiederverwendbarkeit, z.B. für das Deployment der Anwendung in eine bestimmte Umgebung.

Die pipeline.yml enthält die gesamte Pipeline, die beim Pushen auf den main-Branch ausgeführt wird. Diese kann auf die einzelnen Schritte in den Dateien build.yml, deploy.yml und deploy-env.yml verweisen.

deploy-env.yml beinhaltet dabei alles was nötig ist, um die Anwendung in einer bestimmten Umgebung zu deployen. So kann die Pipeline für das Deployment in die Testumgebung genutzt werden, aber auch für die Produktion, ohne dass die Schritte doppelt definiert werden müssen.

deploy.yml verwendet die deploy-env.yml, um die verschiedenen Environments vorzugeben, wie z.B. Dev, Staging und Production.

build.yml ist für das Kompilieren, Testen und Veröffentlichen der Anwendung verantwortlich. Das hier erzeugte Pipeline-Artefakt wird anschließend vom Deployment-Prozess verwendet.

Wer seine Pipeline für das Build und Deployment getrennt zur Pull Request Validation haben möchte, bei der nur das Kompilieren und Testen durchgeführt wird, kann dies in einer separaten Datei pipeline.pr.yml ablegen. Somit kann man eine separate Pipeline nur für PR Validations erstellen und hat hier eine saubere Trennung zu den Pipeline Runs, die auch ein Deployment ausführen.

Ablage und Namensgebung der Templates

Je nachdem, ob du ein Monorepo oder mehrere Repositories verwendest, empfiehlt es sich, Templates in einem zentralen Ordner wie /eng/templates/ abzulegen oder in einem separaten Repository zu verwalten, auf die verschiedene Teams Zugriff habnen. Dies sorgt dafür, dass unterschiedliche Teams ein einheitliches Vorgehen haben und Redundanzen vermieden werden.

Die Namensgebung der Template-Dateien sollte klar und verständlich sein und sich an den jeweiligen Aufgaben orientieren. Meist sollte sich der Kontext aus den Unterordnern ergeben. So beinhaltet das Template /build/dotnet.steps.yml die steps eines Pipeline-Jobs, welche nötig sind, um eine .NET-Anwendung zu kompilieren, aber auch statische Code-Analyzers und automatisierte Tests auszuführen und final das Kompilat als Pipeline-Artifakt zu veröffentlichen.

Das Suffix .steps.yml, .jobs.yml oder .stages.yml hilft dabei zu identifizieren, an welcher Stelle das Template in der eigenen Pipeline eingesetzt werden kann.

Governing Prozesse etablieren

Ein weiterer Vorteil von YAML-Pipelines ist die Möglichkeit, Governance-Prozesse zu integrieren. Dadurch kann sichergestellt werden, dass jede Pipeline beispielsweise eine Lizenz- und Schwachstellenprüfung durchführt.

Dies lässt sich direkt über die Templates umsetzen, indem die Prüfungen in die Templates eingebaut werden. So wird gewährleistet, dass jede Pipeline diese Prüfungen automatisch durchführt.

Über zusätzliche Checks ist es auch möglich zu prüfen, ob die Pipeline von einem bestimmten Template abgeleitet wurde. Dies ist jedoch schon ein sehr fortgeschrittener Ansatz.

Ein Beispiel kannst du dem Open Space Planner entnehmen. Hier gibt es projektspezifische Pipelines als auch Templates auf oberster Ebene.

Wie handhabst du die Strukturierung deiner Pipelines? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.