🥇Leitfaden zu CI/CD in GitLab für den (fast) absoluten Anfänger

Oder wie Sie an einem Abend mit einfachem Programmieren schöne Abzeichen für Ihr Projekt erhalten

Wahrscheinlich hat jeder Entwickler, der mindestens ein Lieblingsprojekt hat, irgendwann ein Interesse an schönen Abzeichen mit Status, Codeabdeckung, Paketversionen in Nuget ... Und dieses Interesse hat mich dazu gebracht, diesen Artikel zu schreiben. Als Vorbereitung zum Schreiben habe ich in einem meiner Projekte diese Schönheit bekommen:

Dieser Artikel führt Sie durch die grundlegende Einrichtung der kontinuierlichen Integration und Bereitstellung für ein .Net Core-Klassenbibliotheksprojekt in GitLab, das Veröffentlichen von Dokumentation auf GitLab-Seiten und das Übertragen erstellter Pakete an einen privaten Feed in Azure DevOps.

Als Entwicklungsumgebung wurde bei der Erweiterung VS Code verwendet GitLab-Workflow (zur Validierung der Einstellungsdatei direkt aus der Entwicklungsumgebung).

Kurze Einführung

CD - ist es, wenn Sie gerade gedrückt haben und bereits alles auf den Client gefallen ist?

Was ist CI/CD und warum braucht man es – das kann man ganz einfach googeln. Eine vollständige Dokumentation zum Konfigurieren von Pipelines finden Sie in GitLab auch einfach. Hier beschreibe ich kurz und möglichst fehlerfrei den Ablauf des Systems aus der Vogelperspektive:

Der Entwickler sendet einen Commit an das Repository, erstellt eine Zusammenführungsanforderung über die Site. oder auf andere Weise explizit oder implizit die Pipeline startet,
alle Aufgaben werden aus der Konfiguration ausgewählt, deren Bedingungen es ermöglichen, sie im gegebenen Kontext zu starten,
Aufgaben werden nach ihren Phasen geordnet,
Phasen werden der Reihe nach ausgeführt, d. h. parallel zu alle Aufgaben dieser Phase abgeschlossen sind,
Wenn die Stufe fehlschlägt (d. h. mindestens eine der Aufgaben der Stufe fehlschlägt), stoppt die Pipeline (fast immer),
Wenn alle Phasen erfolgreich abgeschlossen wurden, gilt die Pipeline als erfolgreich.

Somit haben wir:

Pipeline – eine Reihe von Aufgaben, die in Phasen organisiert sind, in denen Sie Code erstellen, testen, verpacken, einen fertigen Build für einen Cloud-Dienst bereitstellen usw. können.
Bühne (Stufe) – Pipeline-Organisationseinheit, enthält 1+ Aufgabe,
Aufgabe (Job) ist eine Arbeitseinheit in der Pipeline. Es besteht aus einem Skript (obligatorisch), Startbedingungen, Einstellungen zum Veröffentlichen/Caching von Artefakten und vielem mehr.

Dementsprechend besteht die Aufgabe beim Einrichten von CI/CD darin, eine Reihe von Aufgaben zu erstellen, die alle erforderlichen Aktionen zum Erstellen, Testen und Veröffentlichen von Code und Artefakten implementieren.

Bevor es losgeht: Warum?

Warum Gitlab?

Denn als es notwendig wurde, private Repositories für Lieblingsprojekte zu erstellen, wurden diese auf GitHub bezahlt, und ich war gierig. Die Repositories sind zwar kostenlos geworden, aber das ist für mich bislang kein ausreichender Grund, zu GitHub zu wechseln.

Warum nicht Azure DevOps Pipelines?

Denn dort ist die Einstellung elementar – Kenntnisse der Kommandozeile sind nicht einmal erforderlich. Auch die Integration mit externen Git-Anbietern – mit ein paar Klicks, Import von SSH-Schlüsseln zum Senden von Commits an das Repository – lässt sich leicht konfigurieren, auch wenn keine Vorlage erforderlich ist.

Ausgangslage: was Sie haben und was Sie wollen

Wir haben:

Repository in GitLab.

Wir wollen:

automatische Zusammenstellung und Prüfung für jede Zusammenführungsanforderung,
Erstellen von Paketen für jede Zusammenführungsanforderung und Weiterleiten an den Master, vorausgesetzt, dass die Commit-Nachricht eine bestimmte Zeile enthält,
Senden erstellter Pakete an einen privaten Feed in Azure DevOps,
Zusammenstellung der Dokumentation und Veröffentlichung in GitLab Pages,
Abzeichen!11

Die beschriebenen Anforderungen ergeben sich organisch aus dem folgenden Pipeline-Modell:

Stufe 1 – Montage
- Wir sammeln den Code und veröffentlichen die Ausgabedateien als Artefakte
Stufe 2 – Testen
- Wir erhalten Artefakte aus der Build-Phase, führen Tests durch und sammeln Daten zur Codeabdeckung
Stufe 3 – Senden
- Aufgabe 1: Erstellen Sie das Nuget-Paket und senden Sie es an Azure DevOps
- Aufgabe 2 – Wir sammeln die Site aus xmldoc im Quellcode und veröffentlichen sie in GitLab Pages

Fangen wir an!

Sammeln der Konfiguration

Konten vorbereiten

Erstellen Sie ein Konto in Microsoft Azure
Wir gehen zu Azure-DevOps
Wir erstellen ein neues Projekt
1. Name - beliebig
2. Sichtbarkeit – beliebig
Wenn Sie auf die Schaltfläche „Erstellen“ klicken, wird das Projekt erstellt und Sie werden zu seiner Seite weitergeleitet. Auf dieser Seite können Sie unnötige Funktionen deaktivieren, indem Sie zu den Projekteinstellungen gehen (unterer Link in der Liste links -> Übersicht -> Azure DevOps Services-Block).
Gehen Sie zu Atrifacts und klicken Sie auf Feed erstellen
1. Geben Sie den Namen der Quelle ein
2. Wählen Sie Sichtbarkeit
3. Deaktivieren Sie das Kontrollkästchen Schließen Sie Pakete aus gängigen öffentlichen Quellen ein, damit die Quelle nicht zu einem Dump-Nuget-Klon wird
Klicken Sie auf „Mit Feed verbinden“, wählen Sie Visual Studio aus und kopieren Sie die Quelle aus dem Maschinen-Setup-Block
Gehen Sie zu den Kontoeinstellungen und wählen Sie Persönliches Zugriffstoken
Erstellen Sie ein neues Zugriffstoken
1. Name - willkürlich
2. Organisation – aktuell
3. Gültig für maximal 1 Jahr
4. Geltungsbereich – Verpacken/Lesen und Schreiben
Kopieren Sie den erstellten Token - Nachdem das modale Fenster geschlossen wurde, ist der Wert nicht mehr verfügbar
Gehen Sie zu den Repository-Einstellungen in GitLab und wählen Sie die CI-/CD-Einstellungen aus
Erweitern Sie den Block „Variablen“ und fügen Sie einen neuen hinzu
1. Name – beliebig ohne Leerzeichen (wird in der Befehlsshell verfügbar sein)
2. Wert - Zugriffstoken aus Absatz 9
3. Wählen Sie „Variable maskieren“ aus

Damit ist die Vorkonfiguration abgeschlossen.

Vorbereiten des Konfigurationsframeworks

Standardmäßig verwendet die CI/CD-Konfiguration in GitLab die Datei .gitlab-ci.yml aus dem Stammverzeichnis des Repositorys. Sie können in den Repository-Einstellungen einen beliebigen Pfad zu dieser Datei festlegen, dies ist jedoch in diesem Fall nicht erforderlich.

Wie Sie an der Erweiterung erkennen können, enthält die Datei eine Konfiguration im Format YAML. In der Dokumentation wird detailliert beschrieben, welche Schlüssel auf der obersten Ebene der Konfiguration und auf jeder der verschachtelten Ebenen enthalten sein können.

Fügen wir zunächst einen Link zum Docker-Image in der Konfigurationsdatei hinzu, in dem die Aufgaben ausgeführt werden. Dafür finden wir .Net Core-Bilderseite auf Docker Hub. In GitHub Es gibt eine detaillierte Anleitung, welches Bild Sie für verschiedene Aufgaben auswählen sollten. Ein Image mit .Net Core 3.1 ist für uns zum Erstellen geeignet, Sie können also gerne die erste Zeile zur Konfiguration hinzufügen

image: mcr.microsoft.com/dotnet/core/sdk:3.1

Wenn nun die Pipeline aus dem Microsoft-Image-Repository gestartet wird, wird das angegebene Image heruntergeladen, in dem alle Aufgaben aus der Konfiguration ausgeführt werden.

Der nächste Schritt ist das Hinzufügen Stufe'S. Standardmäßig definiert GitLab 5 Stufen:

.pre - bis zu allen Stufen durchgeführt,
.post - nach allen Etappen durchgeführt,
build - zuerst danach .pre Bühne,
test - zweite Phase,
deploy - die dritte Stufe.

Nichts hindert Sie jedoch daran, sie explizit zu deklarieren. Die Reihenfolge, in der die Schritte aufgelistet sind, wirkt sich auf die Reihenfolge aus, in der sie ausgeführt werden. Der Vollständigkeit halber ergänzen wir die Konfiguration:

stages:
  - build
  - test
  - deploy

Für das Debugging ist es sinnvoll, Informationen über die Umgebung zu erhalten, in der die Aufgaben ausgeführt werden. Fügen wir einen globalen Befehlssatz hinzu, der vor jeder Aufgabe ausgeführt wird before_script:

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

Es muss noch mindestens eine Aufgabe hinzugefügt werden, damit die Pipeline startet, wenn die Commits gesendet werden. Fügen wir zunächst eine leere Aufgabe hinzu, um Folgendes zu demonstrieren:

dummy job:
  script:
    - echo ok

Wir beginnen mit der Validierung, wir erhalten eine Nachricht, dass alles in Ordnung ist, wir verpflichten uns, wir pushen, wir schauen uns die Ergebnisse auf der Website an ... Und wir erhalten einen Skriptfehler - bash: .PSVersion: command not found. Was zum Teufel?

Alles ist logisch – standardmäßig verwenden Runner (die für die Ausführung von Aufgabenskripten verantwortlich sind und von GitLab bereitgestellt werden). bash Befehle auszuführen. Sie können dies beheben, indem Sie in der Aufgabenbeschreibung explizit angeben, welche Tags der ausführende Pipeline-Läufer haben soll:

dummy job on windows:
  script:
    - echo ok
  tags:
    - windows

Großartig! Die Pipeline läuft jetzt.

Ein aufmerksamer Leser wird nach Wiederholung der angegebenen Schritte feststellen, dass die Aufgabe in dieser Phase abgeschlossen wurde test, obwohl wir die Bühne nicht angegeben haben. Wie Sie vielleicht erraten haben test ist der Standardschritt.

Fahren wir mit der Erstellung des Konfigurationsgerüsts fort, indem wir alle oben beschriebenen Aufgaben hinzufügen:

build job:
  script:
    - echo "building..."
  tags:
    - windows
  stage: build

test and cover job:
  script:
    - echo "running tests and coverage analysis..."
  tags:
    - windows
  stage: test

pack and deploy job:
  script:
    - echo "packing and pushing to nuget..."
  tags:
    - windows
  stage: deploy

pages:
  script:
    - echo "creating docs..."
  tags:
    - windows
  stage: deploy

Wir haben eine nicht besonders funktionsfähige, aber dennoch korrekte Pipeline erhalten.

Trigger einrichten

Aufgrund der Tatsache, dass für keine der Aufgaben Triggerfilter angegeben sind, wird die Pipeline dies tun voll jedes Mal ausgeführt werden, wenn ein Commit in das Repository übertragen wird. Da dies im Allgemeinen nicht das gewünschte Verhalten ist, werden wir Triggerfilter für Aufgaben einrichten.

Filter können in zwei Formaten konfiguriert werden: nur/außer и Ohne eine erfahrene Medienplanung zur Festlegung von Regeln und Strategien beschleunigt der programmatische Medieneinkauf einfach die Rate der verschwenderischen Ausgaben. . Knapp, only/except ermöglicht Ihnen die Konfiguration von Filtern nach Auslösern (merge_request, zum Beispiel – legt die Aufgabe fest, die jedes Mal ausgeführt werden soll, wenn eine Pull-Anfrage erstellt wird und jedes Mal, wenn Commits an den Zweig gesendet werden, der die Quelle in der Zusammenführungsanforderung ist) und Zweignamen (einschließlich der Verwendung regulärer Ausdrücke); rules ermöglicht es Ihnen, eine Reihe von Bedingungen anzupassen und optional die Ausführungsbedingung der Aufgabe abhängig vom Erfolg früherer Aufgaben zu ändern (when in GitLab CI/CD).

Erinnern wir uns an eine Reihe von Anforderungen: Zusammenstellen und Testen nur für Zusammenführungsanforderungen, Verpacken und Senden an Azure DevOps – für Zusammenführungsanforderungen und Pushs an den Master, Dokumentationserstellung – für Pushs an den Master.

Zuerst richten wir die Code-Build-Aufgabe ein, indem wir eine Regel hinzufügen, die nur bei Zusammenführungsanforderung ausgelöst wird:

build job:
  # snip
  only:
    - merge_request

Nun richten wir die Paketierungsaufgabe so ein, dass sie bei der Zusammenführungsanforderung ausgelöst wird und Commits zum Master hinzufügt:

pack and deploy job:
  # snip
  only:
    - merge_request
    - master

Wie Sie sehen, ist alles einfach und unkompliziert.

Sie können die Aufgabe auch so einstellen, dass sie nur dann ausgelöst wird, wenn eine Zusammenführungsanforderung mit einem bestimmten Ziel- oder Quellzweig erstellt wird:

  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

Unter bestimmten Bedingungen können Sie verwenden Hier aufgeführte Variablen; Regeln rules nicht mit den Regeln vereinbar only/except.

Konfigurieren der Artefaktspeicherung

Während einer Aufgabe build job Wir werden Build-Artefakte haben, die in nachfolgenden Aufgaben wiederverwendet werden können. Dazu müssen Sie dem Schlüssel die Pfade zur Aufgabenkonfiguration und die Dateien hinzufügen, entlang derer Sie sie speichern und in den folgenden Aufgaben wiederverwenden müssen artifacts:

build job:
  # snip
  artifacts:
    paths:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

Pfade unterstützen Platzhalter, was das Festlegen definitiv erleichtert.

Wenn eine Aufgabe Artefakte erstellt, kann jede nachfolgende Aufgabe darauf zugreifen – sie befinden sich relativ zum Repository-Stammverzeichnis auf denselben Pfaden, die von der ursprünglichen Aufgabe gesammelt wurden. Auf der Website stehen auch Artefakte zum Download zur Verfügung.

Nachdem wir nun das Konfigurationsframework fertig (und getestet) haben, können wir mit dem eigentlichen Schreiben von Skripten für Aufgaben fortfahren.

Wir schreiben Drehbücher

Vielleicht war es einmal, in einer weit, weit entfernten Galaxie, eine Qual, Projekte (einschließlich derer auf .net) über die Befehlszeile zu erstellen. Jetzt können Sie das Projekt in 3 Teams erstellen, testen und veröffentlichen:

dotnet build
dotnet test
dotnet pack

Natürlich gibt es einige Nuancen, aufgrund derer wir die Befehle etwas komplizieren werden.

Wir wollen einen Release-Build, keinen Debug-Build, also fügen wir jedem Befehl etwas hinzu -c Release
Beim Testen möchten wir Daten zur Codeabdeckung sammeln, daher müssen wir einen Abdeckungsanalysator in die Testbibliotheken aufnehmen:
1. Fügen Sie das Paket allen Testbibliotheken hinzu coverlet.msbuild: dotnet add package coverlet.msbuild aus dem Projektordner
2. Zum Testlaufbefehl hinzufügen /p:CollectCoverage=true
3. Fügen Sie der Testaufgabenkonfiguration einen Schlüssel hinzu, um Abdeckungsergebnisse zu erhalten (siehe unten).
Legen Sie beim Packen des Codes in Nuget-Pakete das Ausgabeverzeichnis für die Pakete fest: -o .

Sammeln von Codeabdeckungsdaten

Nach der Ausführung der Tests druckt Coverlet Laufstatistiken auf der Konsole aus:

Calculating coverage result...
  Generating report 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Module      | Line   | Branch | Method |
+-------------+--------+--------+--------+
| project 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| project 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| project 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Line   | Branch | Method |
+---------+--------+--------+--------+
| Total   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Average | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

Mit GitLab können Sie einen regulären Ausdruck angeben, um Statistiken zu erhalten, die dann in Form eines Badges abgerufen werden können. Der reguläre Ausdruck wird in den Aufgabeneinstellungen mit dem Schlüssel angegeben coverage; Der Ausdruck muss eine Capture-Gruppe enthalten, deren Wert an das Badge übergeben wird:

test and cover job:
  # snip
  coverage: /|s*Totals*|s*(d+[,.]d+%)/

Hier erhalten wir Statistiken von einer Linie mit der gesamten Linienabdeckung.

Veröffentlichen Sie Pakete und Dokumentation

Beide Aktionen sind für die letzte Phase der Pipeline geplant – da die Montage und Tests abgeschlossen sind, können wir unsere Entwicklungen mit der Welt teilen.

Erwägen Sie zunächst die Veröffentlichung in der Paketquelle:

Wenn das Projekt keine Nuget-Konfigurationsdatei hat (nuget.config), erstellen Sie ein neues: dotnet new nugetconfig

Wofür: Das Image hat möglicherweise keinen Schreibzugriff auf globale (Benutzer- und Maschinen-)Konfigurationen. Um Fehler zu vermeiden, erstellen wir einfach eine neue lokale Konfiguration und arbeiten damit.
Fügen wir der lokalen Konfiguration eine neue Paketquelle hinzu: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - Name der lokalen Quelle, nicht kritisch
2. url - URL der Quelle aus der Stufe „Konten vorbereiten“, S. 6
3. organization – Organisationsname in Azure DevOps
4. gitlab variable - der Name der Variable mit dem zu GitLab hinzugefügten Zugriffstoken („Konten vorbereiten“, S. 11). Natürlich im Format $variableName
5. -StorePasswordInClearText – ein Hack, um den Fehler „Zugriff verweigert“ zu umgehen (Ich bin nicht der Erste, der auf diesen Rechen tritt)
6. Im Fehlerfall kann eine Ergänzung sinnvoll sein -verbosity detailed
Senden des Pakets an die Quelle: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Wir versenden also alle Pakete aus dem aktuellen Verzeichnis *.nupkg.
2. name - aus dem obigen Schritt.
3. key - jede Zeile. In Azure DevOps ist das Beispiel im Fenster „Mit Feed verbinden“ immer die Zeile az.
4. -skipduplicate - Beim Versuch, ein bereits vorhandenes Paket ohne diesen Schlüssel zu senden, gibt die Quelle einen Fehler zurück 409 Conflict; Mit der Taste wird das Senden übersprungen.

Nun richten wir die Erstellung der Dokumentation ein:

Zuerst initialisieren wir im Repository, im Master-Zweig, das docfx-Projekt. Führen Sie dazu den Befehl im Stammverzeichnis aus docfx init und legen Sie interaktiv die wichtigsten Parameter für die Baudokumentation fest. Detaillierte Beschreibung des minimalen Projektaufbaus hier.
1. Bei der Konfiguration ist es wichtig, das Ausgabeverzeichnis anzugeben ..public – GitLab verwendet standardmäßig den Inhalt des öffentlichen Ordners im Stammverzeichnis des Repositorys als Quelle für Pages. Weil Das Projekt befindet sich in einem im Repository verschachtelten Ordner. Fügen Sie eine Ausgabe auf der höheren Ebene im Pfad hinzu.
Lassen Sie uns die Änderungen auf GitLab übertragen.
Fügen Sie der Pipeline-Konfiguration eine Aufgabe hinzu pages (reserviertes Wort für Site-Publishing-Aufgaben in GitLab Pages):
1. Skript:
  1. nuget install docfx.console -version 2.51.0 - docfx installieren; Die Version wird angegeben, um sicherzustellen, dass die Paketinstallationspfade korrekt sind.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - Sammeln von Unterlagen
2. Knotenartefakte:

pages:
  # snip
  artifacts:
    paths:
      - public

Lyrischer Exkurs über docfx

Zuvor habe ich beim Einrichten eines Projekts die Codequelle für die Dokumentation als Lösungsdatei angegeben. Der Hauptnachteil besteht darin, dass auch für Testprojekte Dokumentationen erstellt werden. Falls dies nicht erforderlich ist, können Sie diesen Wert für den Knoten festlegen metadata.src:

{
  "metadata": [
    {
      "src": [
        {
          "src": "../",
          "files": [
            "**/*.csproj"
          ],
          "exclude":[
            "*.tests*/**"
          ]
        }
      ],
      // --- snip ---
    },
    // --- snip ---
  ],
  // --- snip ---
}

metadata.src.src: "../" - Wir gehen relativ zum Standort eine Ebene höher docfx.json, Weil In Mustern funktioniert das Durchsuchen des Verzeichnisbaums nicht.
metadata.src.files: ["**/*.csproj"] - ein globales Muster, wir sammeln alle C#-Projekte aus allen Verzeichnissen.
metadata.src.exclude: ["*.tests*/**"] - Globales Muster, alles aus Ordnern ausschließen mit .tests im Namen

Zwischensumme

Eine so einfache Konfiguration kann in nur einer halben Stunde und ein paar Tassen Kaffee erstellt werden. So können Sie überprüfen, ob der Code erstellt und die Tests bestanden wurden, ein neues Paket erstellen, die Dokumentation aktualisieren und das Auge mit Schönheit erfreuen Abzeichen in der README-Datei des Projekts bei jeder Zusammenführungsanforderung und beim Senden an den Master.

Endgültige .gitlab-ci.yml

image: mcr.microsoft.com/dotnet/core/sdk:3.1

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

stages:
  - build
  - test
  - deploy

build job:
  stage: build
  script:
    - dotnet build -c Release
  tags:
    - windows
  only:
    - merge_requests
    - master
  artifacts:
    paths:
      - your/path/to/binaries

test and cover job:
  stage: test
  tags:
    - windows
  script:
    - dotnet test -c Release /p:CollectCoverage=true
  coverage: /|s*Totals*|s*(d+[,.]d+%)/
  only:
    - merge_requests
    - master

pack and deploy job:
  stage: deploy
  tags:
    - windows
  script:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  only:
    - master

pages:
  tags:
    - windows
  stage: deploy
  script:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

Apropos Abzeichen

Durch sie wurde schließlich alles begonnen!

Abzeichen mit Pipeline-Status und Codeabdeckung sind in GitLab in den CI/CD-Einstellungen im Gtntral-Pipelines-Block verfügbar:

Ich habe ein Abzeichen mit einem Link zur Dokumentation auf der Plattform erstellt Shields.io - Dort ist alles ganz einfach, Sie können Ihren eigenen Ausweis erstellen und ihn auf Anfrage erhalten.

![Пример с Shields.io](https://img.shields.io/badge/custom-badge-blue)

Mit Azure DevOps Artifacts können Sie auch Abzeichen für Pakete mit der neuesten Version erstellen. Dazu müssen Sie in der Quelle auf der Azure DevOps-Site auf „Badge erstellen“ für das ausgewählte Paket klicken und das Markdown-Markup kopieren:

Schönheit hinzufügen

Hervorheben gemeinsamer Konfigurationsfragmente

Während ich die Konfiguration schrieb und die Dokumentation durchsuchte, stieß ich auf eine interessante Funktion von YAML – die Wiederverwendung von Fragmenten.

Wie Sie den Aufgabeneinstellungen entnehmen können, benötigen sie alle das Tag windows beim Läufer und werden ausgelöst, wenn eine Zusammenführungsanforderung an den Master gesendet/erstellt wird (außer Dokumentation). Fügen wir dies zu dem Fragment hinzu, das wir wiederverwenden werden:

.common_tags: &common_tags
  tags:
    - windows
.common_only: &common_only
  only:
    - merge_requests
    - master

Und jetzt können wir das zuvor in der Aufgabenbeschreibung deklarierte Fragment einfügen:

build job:
  <<: *common_tags
  <<: *common_only

Fragmentnamen müssen mit einem Punkt beginnen, damit sie nicht als Aufgabe interpretiert werden.

Paketversionierung

Beim Erstellen eines Pakets überprüft der Compiler die Befehlszeilenschalter und, falls diese nicht vorhanden sind, die Projektdateien. Wenn ein Versionsknoten gefunden wird, übernimmt er als Wert die Version des zu erstellenden Pakets. Es stellt sich heraus, dass Sie, um ein Paket mit einer neuen Version zu erstellen, es entweder in der Projektdatei aktualisieren oder als Befehlszeilenargument übergeben müssen.

Fügen wir noch eine Wunschliste hinzu – lassen Sie die beiden Nebenzahlen in der Version das Jahr und das Erstellungsdatum des Pakets sein und fügen Sie Vorabversionen hinzu. Natürlich können Sie diese Daten zur Projektdatei hinzufügen und vor jeder Übermittlung überprüfen – Sie können dies aber auch in der Pipeline tun, indem Sie die Paketversion aus dem Kontext sammeln und sie über das Befehlszeilenargument übergeben.

Lassen Sie uns vereinbaren, dass, wenn die Commit-Nachricht eine Zeile wie enthält release (v./ver./version) <version number> (rev./revision <revision>)?, dann entnehmen wir dieser Zeile die Version des Pakets, ergänzen sie mit dem aktuellen Datum und übergeben sie als Argument an den Befehl dotnet pack. In Ermangelung einer Warteschlange holen wir das Paket einfach nicht ab.

Das folgende Skript löst dieses Problem:

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

Hinzufügen eines Skripts zu einer Aufgabe pack and deploy job und beobachten Sie die Zusammenstellung von Paketen strikt bei Vorhandensein einer bestimmten Zeichenfolge in der Commit-Nachricht.

Insgesamt

Nachdem wir etwa eine halbe oder eine Stunde mit dem Schreiben der Konfiguration, dem Debuggen in der lokalen Powershell und möglicherweise einigen erfolglosen Starts verbracht hatten, erhielten wir eine einfache Konfiguration zur Automatisierung von Routineaufgaben.

Natürlich ist GitLab CI/CD viel umfangreicher und vielfältiger, als es nach der Lektüre dieses Leitfadens erscheinen mag – das ist völlig falsch. Da sogar Auto DevOps istzulassen

Erkennen, erstellen, testen, implementieren und überwachen Sie Ihre Anwendungen automatisch

Nun ist geplant, eine Pipeline für die Bereitstellung von Anwendungen in Azure zu konfigurieren, Pulumi zu verwenden und die Zielumgebung automatisch zu bestimmen, was im nächsten Artikel behandelt wird.

Source: habr.com

Eine Anleitung zu CI/CD in GitLab für den (fast) absoluten Anfänger