🥇 GitLab CI/CD juhend (peaaegu) absoluutselt algajale

Või kuidas hankida oma projekti jaoks kauneid märgid ühe õhtuse vaevatute koodide kirjutamisega

Tõenäoliselt iga arendaja, kellel on vähemalt üks kodune projekt, tunneb teatud hetkel isu kaunite märkide järele, mis kajastavad staatuseid, koodi katvust, paketiversioone nugetis... Ja see isu viis mind selle artikli kirjutamiseni. Artikli ettevalmistamise käigus sain ma ühe oma projekti jaoks just sellise ilu:

Artiklis käsitletakse pideva integreerimise ja kohaletoimetamise põhiseadet .Net Core klasside raamatukogu projekti jaoks GitLabis, dokumentatsiooni avaldamist GitLab Pages'is ning koostatud paketide saatmist privaatsetesse toimetusteedesse Azure DevOps'is.

Arenduskeskkonnana kasutati VS Code'i koos laiendusega GitLab Workflow (seadistamisfaili valideerimiseks otse arenduskeskkonnast).

Lühike sissejuhatus

CI/CD on see, kui sa just surusid ja kliendil on juba kõik maas?

Mida CI/CD tähendab ja miks see vajalik on — seda on lihtne Google'ist leida. Täielik dokumentatsioon GitLabi torude seadistamiseks on samuti kergesti kättesaadav Hästi. Siin kirjeldan lühidalt ja võimalikult vigu vältides süsteemi tööd linnulennult:

arendaja saadab commit'i reposse, loob merge request'i veebilehe kaudu, või muud moodi käivitab toru selges või varjatud viisil,
konfiguratsioonist valitakse kõik ülesanded, mille tingimused võimaldavad neid käivitada antud kontekstis,
ülesanded korraldatakse oma etappide järgi,
etapid täidetakse järjekorras — st. paralleelselt täidetakse kõik selle etapi ülesanded,
kui etapp lõppeb ebaõnnesti (st. kui vähemalt üks etapi ülesanne lõppeb ebaõnnestunult) — toru peatatakse (peaaegu alati),
kui kõik etapid on õnnelikult lõppenud, peetakse toru edukaks.

Nii et saame:

toru — ülesannete kogum, mis on korraldatud etappides, milles saab koguda, testida, pakkida koodi, juurutada valmis koostise pilveteenuses jne,
etapp (stage) — toru korraldamise üksus, sisaldab 1+ ülesannet,
ülesanne (job) — tööüksus torus. Koosneb skriptist (kohustuslik), käivitamistingimustest, artefaktide avaldamise/vahemälu seadistustest ja paljust muust.

Seega, ülesanne CI/CD seadistamisel on luua ülesannete kogum, mis rakendab kõiki vajalikke toimingute koode, katsetamiseks ja avaldamiseks artefakte.

Enne alustamist: miks?

Miks GitLab?

Sest kui tekkis vajadus luua isiklikke reposte pet-projectide jaoks, olid need GitHubis tasulised ja mina olin kokkuhoidev. Repo-d on nüüd tasuta, aga see ei ole piisav põhjus GitHubi ülemiseks.

Miks mitte Azure DevOps Pipelines?

Sest seal on seadistamine elementaarne - isegi käsurea teadmisi ei ole vajalik. Integreerimine väliste git-teenusepakkujatega ka paar klikiga, SSH- võtmete importimine commits'i tegemiseks repo-sse on samuti kiire, pipeline'i saab hõlpsasti seadistada isegi mitte mallist.

Algne seis: mis meil on ja mida tahame

Meil on:

repo GitLabis.

Tahame:

automaatset kompileerimist ja testimist iga merge request'i jaoks,
pakettide kompileerimist iga merge request'i ja masterisse push'i jaoks, tingimusel et commit'i sõnumis on teatud rida,
koostatud paketid privaatfide saatmine Azure DevOps'i,
dokumentatsiooni koostamine ja avaldamine GitLab Pages,
badge'id!11

Kavandatud nõuded sobivad järgmistesse pipeline'i mudelisse:

Etapp 1 — ehitamine
- Kompileerime koodi, väljundfailid avaldame artefaktidena
Etapp 2 — testimine
- Saame artefaktid kompileerimise etapist, käime teste, kogume koodi katvuse andmeid
Etapp 3 — saatmine
- Ülesanne 1 — loome nuget-paketi ja saadame Azure DevOps'i
- Ülesanne 2 — loome veebilehe xmldoc'i allikakoodist ja avaldame GitLab Pages

Alustame!

Kogume konfiguratsiooni

Valmistame ülesanded ette

Loome konto Microsoft Azure
Liigume Azure DevOps'is
Loome uue projekti
1. Nimi — mis tahes
2. Nähtavus — mis tahes
Kogumisel nuppu Create projekt luuakse ja suundume selle lehele. Selles lehes saad välja lülitada tarbetud funktsioonid, minnes projekti seadistustesse (allolev link vasakus kõrval —> Overview -> Azure DevOps Services plokk)
Liigume Atrifacts'isse, vajutame Create feed
1. Sisestame allika nime
2. Valime nähtavuse
3. Tühistame märkeruudu Include packages from common public sources, et allikast ei saaks nuget'i kloonimise prügi
Vajutame Connect to feed, valime Visual Studio, Machine Setup plokist kopeerime Source'i
Läheme konto seadistustesse, valime Personal Access Token
Loome uue juurdepääsutokeni
1. Nimi — lubatud
2. Organisatsioon — praegune
3. Kehtivusaeg — maksimaalselt 1 aasta
4. Toimingute ulatus (scope) — Packaging/Read & Write
Kopeerime loodud tokeni — pärast modaalakna sulgemist väärtus ei ole enam saadaval
Siseneme GitLabi hoidla seadistustesse, valime CI/CD seadistused
Avame blokki Variables, lisame uue
1. Nimi — mis tahes, ilma tühikute jaotamata (olemas käsureas)
2. Väärtus — juurdepääsutoken punktis 9
3. Valime Mask variable

Sellega eeltehnistamine on lõpetatud.

Valmistame konfiguratsiooniraami

Vaikimisi kasutatakse GitLabis CI/CD seadistamiseks faili .gitlab-ci.yml hoidla juurest. Saame seadistada selle faili jaoks suvalise tee hoidla seadistustes, kuid antud juhul ei ole see vajalik.

Nagu näha laiendist, sisaldab fail konfiguratsiooni formaadis YAML. Dokumentatsioonis on põhjalikult kirjeldatud, millised võtmed võivad olla ülemises konfiguratsioonitasemes ja igas alumises tasemes.

Esmalt lisame konfiguratsioonifaili viite docker-pildile, milles ülesannete täitmine toimub. Selleks leiame Docker Hubis .Net Core piltide lehe. Failis GitHub on üksikasjalik juhend, milline pilt valida erinevate ülesannete jaoks. Meile sobib .Net Core 3.1 pilt, seega lisame julgelt konfiguratsiooni esimese reana

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

Nüüd, kui käivitame pipeline'i Microsofti pildihoidlast, laaditakse alla määratud pilt, kus kõik ülesanded konfiguratsioonist täidetakse.

Järgmine etapp — lisada stage'id. Vaikimisi määrab GitLab 5 etappi:

.pre — täidetakse enne kõiki etappe,
.post — täidetakse pärast kõiki etappe,
build — esimene pärast .pre etappi,
test — teine etapp,
deploy — kolmas etapp.

Miski ei takista nende selget kuulutamist. Etappide järjekord, milles need on loetletud, mõjutab seda, millises järjekorras need täidetakse. Täiendavaks selgitamiseks lisame konfiguratsiooni:

stages:
  - build
  - test
  - deploy

Veadude otsimiseks on mõistlik hankida teavet keskkonna kohta, kus ülesandeid täidetakse. Lisame globaalsete käskude komplekti, mis täidetakse enne iga ülesannet, kasutades before_script:

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

Jäänud on lisada vähemalt üks ülesanne, et commit'ide saatmisel pipeline käivituks. Hetkel lisame tühja ülesande demonstreerimiseks:

dummy job:
  script:
    - echo ok

Käivitame valideerimise, saame teate, et kõik on korras, teeme commit'i, push'ime, vaatame tulemusi veebisaidil… Ja saame skripti vea — bash: .PSVersion: käsku ei leitud. Mida kuradit?

Kõik on loogiline — vaikimisi kasutavad runner'id (mis vastutavad ülesannete skriptide täitmise eest ja mida pakub GitLab) bash käskude täitmiseks. Seda saab parandada, määrates ülesande kirjelduses selgelt, millised sildid peavad täitma pipeliini runner'il olema:

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

Suurepärane! Nüüd toimib pipelii.

Hoolikas lugeja, kes kordab nimetatud samme, märgib, et ülesanne viidi ellu etapis test, kuigi me etappi ei määranud. Kuidas võiks arvata, test on vaikimisi etapp.

Jätkame konfiguratsiooniskeleti loomist, lisades kõik ülaltoodud ülesanded:

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

Me saime mitte eriti funktsionaalse, kuid siiski korrektse pipeliini.

Käivituste seadistamine

Kuna ühelegi ülesandele ei ole määratud käivitusfiltreid, toimub pipeliini täielik täitmine iga kord, kui kommititakse reposse. Kuna see ei ole soovitud käitumine, seadistame ülesannete jaoks käivitusfiltrid.

Filtreid saab seadistada kahes formaadis: only/except ja rules. Lühidalt öeldes, only/except lubab seadistada filtreid põhinedes käivitustel (merge_request, näiteks — seab ülesande täitmise iga kord, kui luuakse ühinemise taotlus ja iga kord, kui kommititakse harusse, mis on ühinemise taotluse algne haru) ja harude nimede põhjal (ka regulaarsete väljendite kasutamisel);allowing for a set of conditions and, optionally, changing the task execution condition based on the success of preceding tasks ( rules GitLab CI/CD-sjne. Mida rohkem te Ansible'i tunnete, seda rohkem nüansse saate öelda "kavalate" lahenduste kohta. Ja lihtne lahendus — loomulik jaotus pre/roles/post vahel — ei tekita nüansse. Korrata nõudmiste komplekti — koodide ülesehitamine ja testimine ainult ühinemise taotluse ajal, pakkimine ja Azure DevOps'i saatmine — ühinemise taotluste ja push'imiste puhul masterisse, dokumentatsiooni genereerimine — masterisse push'imiste jaoks.).

Esiteks seadistame koodide ülesehitamise ülesande, lisades reegli, mis käivitub ainult ühinemise taotluse ajal:

build job: # snip only: - merge_request

Nüüd seadistame pakkimisülesande käivituma ühinemise taotluste ja commit'ide lisamisel masterisse:

Nüüd seadistame pakkimise ülesande käivituma sulandumise taotluse ja peamisse commiteerimise ajal:

tööde pakkimine ja juurutamine:
  # snip
  ainult:
    - merge_request
    - master

Nagu näha, on kõik lihtne ja selge.

Samuti saab ülesanete seadistamisel määrata, et need käivituvad ainult siis, kui luuakse merge request teatud siht- või lähteharule:

  reeglid:
    - kui: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

Tingimustes saab kasutada siin loetletud muutujaid; reeglid rules ei ühildu reeglitega only/except.

Artefaktide salvestamise seadistamine

Töö ülesande täitmise ajal build job meie ülesande täitmise käigus luuakse ehitusartefaktid, mida saab järgnevates ülesannetes uuesti kasutada. Selleks tuleb ülesande konfiguratsiooni lisada teed, failid, mida tuleb salvestada ja järgmistes ülesannetes uuesti kasutada, võtmesse artefaktid:

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

Teed toetavad wildcard'e, mis muudab nende määramise kindlasti lihtsamaks.

Kui ülesanne loob artefakte, siis igal järgmisel ülesandel on neile juurdepääs — need asub samadel teedel sõltumatult repository juurest, nagu nad said algsest ülesandest. Samuti on artefaktid saadaval allalaadimiseks saidil.

Nüüd, kui meie konfiguratsiooni karkass on valmis (ja kontrollitud), saame liikuda ülesannete skriptide kirjutamise juurde.

Kirjutame skripte

Võib-olla, kunagi ammu, kauges-galaktikas, oli projektide (sealhulgas .net) ehitamine käsurealt valus. Nüüd suudame ehitada, testida ja avaldada projekti kolme käsuga:

dotnet build
dotnet test
dotnet pack

Loomulikult on mõned nüansid, mille tõttu me käske pisut keerukamaks teeme.

Soovime vabastust, mitte silumise kokkupanekut, seega lisame iga käsu juurde -c Release
Testimisel soovime koguda katvuseandmeid, seega on vajalik lisada katvuse analüsaator testimisraamatukogudesse:
1. Kõigisse testimisraamatukogudesse tuleks lisada pakett coverlet.msbuild: dotnet add package coverlet.msbuild projektikataloogist
2. Testide käivitamise käsule lisame /p:CollectCoverage=true
3. Testimise ülesande konfiguratsiooni lisame võtme katvuse tulemuste hankimiseks (vt allpool)
Koodi nuget-pakettidesse pakkimisel määrame pakettide väljundkausta: -o .

Koodi katvuse andmete kogumine

Coverlet kuvab testide käivitamisel konsoolis käivitamisstatistika:

Kattevuse tulemuse arvutamine...
  Generatsioon aruandele 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Moodul      | Rida   | Haru   | Meetod |
+-------------+--------+--------+--------+
| projekt 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| projekt 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| projekt 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Rida   | Haru   | Meetod |
+---------+--------+--------+--------+
| Kokku   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Keskmine| 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

GitLab võimaldab määrata regulaaravaldiste jaoks statistikat, mida saab hiljem kuvada nagu märk. coverage; avaldise sees peab olema capture-grupp, mille väärtus edastatakse märgisena:

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

Siin saame statistikat rida üldise katvuse arvu kohta.

Avaldame pakette ja dokumentatsiooni

Mõlemad tegevused on määratud meie pipeline'i viimases etapis — kuna kompileerimine ja testid on läbitud, on aeg jagada oma edusamme maailmaga.

Alustuseks vaatame, kuidas pakette allikasse avaldada:

Kui projektis ei ole nuget konfiguratsioonifaili (nuget.config), loome uue: dotnet new nugetconfig
Miks: pildil võib olla kirjutamisõigus keelatud globaalsetesse (kasutaja ja masin) konfiguratsioonidesse. Et mitte tõrkuda vigu, loome lihtsalt uue kohaliku konfiguratsiooni ja töötame selle kallal.
Lisame kohaliku konfiguratsiooni uue paketiallika: nuget sources add -name -source -username -password -configfile nuget.config -StorePasswordInClearText
1. nimi — kohaliku allika nimi, mitte põhimõtteliselt
2. url — allika URL, mis saadakse etapis "Valmistame kontod", p. 6
3. organization — organisatsiooni nimi Azure DevOpsis
4. gitlab variable — turvavõtme nimi, mis on lisatud GitLabi keskkonnas ("Valmistame kontod", p. 11). Loomulikult, formaadis $variableName
5. -StorePasswordInClearText — häkkimine juurdepääsu keeldumise vea ületamiseks (ma ei ole esimene, kes nende takistustega kokku puutub)
6. Vigade korral võib olla kasulik lisada -verbosity detailed
Saadame paketi allikasse: nuget push -source -skipduplicate -apikey *.nupkg
1. Saadame kõik paketid praegusest kataloogist, seetõttu *.nupkg.
2. nimi — eelmise tegevuse tulemus.
3. key — igasugune string. Azure DevOpsis, aknas Connect to feed, antakse alati näitena string az.
4. -skipduplicate — kui proovite saata juba olemasolevat paketti ilma selle võtmeta, tagastab allikas vea 409 Konflikt; võtmega saadetud dokumendid jäetakse vahelt.

Nüüd seadistame dokumentatsiooni loomise:

Esmalt, hoidlas, haru master, initsialiseerime projekti docfx. Selleks tuleb juurest käivitada käsk docfx init ja interaktiivses režiimis määrame võtmeparameetrid dokumentatsiooni koostamiseks. Üksikasjalik kirjeldus minimaalsest projekti seadistamisest siin.
1. Seadistamisel on oluline näidata väljundi katalooge ..public — GitLab võtab vaikimisi sisu public kaustast hoidlas kui allika GitHubi lehtede jaoks. Kuna projekt asub hoidlas, lisame teele väljundi ühele tasemele ülespoole.
Saadame muudatused GitLabi.
Pipeline'i konfiguratsiooni lisame ülesande lehed (reserveeritud sõna veebilehtede ülesannete jaoks GitLab Pages):
1. Skript:
  1. nuget install docfx.console -version 2.51.0 — installib docfx; versioon on määratud paketi paigaldusteede õigsuse tagamiseks.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json — kogume dokumentatsiooni
2. Artifaktide sõlm:

lehed:
  # snip
  artifaktid:
    teed:
      - public

Luuletuse eraldumine docfx'ist

Varem määrasin projekti seadistamisel dokumentatsiooni allikaks lahenduse faili. Peamine puudus on see, et dokumentatsiooni luuakse ka testimisprojektide jaoks. Kui see pole vajalik, saab anda sellise väärtuse sõlmele metadata.src:

{
  "metadata": [
    {
      "src": [
        {
          "src": "..\/",
          "failid": [
            "**\/*.csproj"
          ],
          "välja jätta":[
            "*.tests*\/**"
          ]
        }
      ],
      \/\/ --- snip ---
    },
    \/\/ --- snip ---
  ],
  \/\/ --- snip ---
}

metadata.src.src: "..\/" — väljume ülespoole seoses asukohaga docfx.json, sest mustrites ei tööta puu struktuuris ülespoole otsing.
metadata.src.files: ["**\/*.csproj"] — globaalne mustr, kogume kõik C# projektid kõigist direktoridest.
metadata.src.exclude: ["*.tests*\/**"] — globaalne mustr, jätame välja kõik kataloogid, millel on .tests nimetuses

Vahekokkuvõte

Sellise lihtsa konfiguratsiooni saab koostada vaid poole tunni ja paarikese kohviga, mis võimaldab iga ühendamise ja meistrisse saatmise päringu korral kontrollida, et kood compileerub ja testid läbivad, genereerida uus pakett, värskendada dokumentatsiooni ja rõõmustada silmi kaunite märkidega projekti README-s.

Lõplik .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.0/tools/docfx.exe .docfx/docfx.json
  artifacts:
    paths:
      - public
  only:
    - master

Muide, badge'idest

Just nende nimel see kõik algatati!

Pipeline'i ja koodikatte staatuse badge'id on saadaval GitLabis CI/CD seadistustes Gtntral pipelines jaotises:

Dokumentatsioonilinkide badge'i loomine toimus platvormil Shields.io — seal on kõik suhteliselt sirgjooneline, saad luua oma badge'i ja saada seda päringu kaudu.

![Näide Shields.io](https://img.shields.io/badge/custom-badge-blue)

Azure DevOps Artifacts lubab samuti luua badge'e pakettide jaoks, näidates kehtivat versiooni. Selleks tuleb Azure DevOps saidil valitud paketi jaoks klõpsata Create badge ja kopeerida markdown-i tähendus:

Lisame ilu

Tõstame esile ühised konfiguratsioonifragmendid

Konfiguratsiooni kirjutamise ja dokumentatsiooni uurimise käigus avastasin huvitava võimaluse YAML-is — fragmentide taaskasutamine.

Kuna näha on ülesannete seadistustes, vajavad kõik need sildi olemasolu windows runneris ja aktiveeruvad siis, kui saadetakse masterisse/loodakse sulgemispäring (välja arvatud dokumentatsioon). Lisame selle fragmenti, mida kavatseme taaskasutada:

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

Ja nüüd saame ülesande kirjelduse sisse sisestada varem deklareeritud framenti:

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

Fragmentide nimed peavad algama punktiga, et neid ei tõlgendataks ülesanneena.

Pakettide versioonimine

Paketi loomisel kontrollib kompilaator käsurea võtmeid ning nende puudumisel — projekti faile; leides sõlme Version, võtab ta selle väärtuse kui kogu paketi versiooni. Seega, et pakett uue versiooniga kokku panna, tuleb kas värskendada seda projekti failis või edastada see käsurea argumendina.

Lisame veel ühe soovi — las nooremad kaks numbrit versioonis oleks aastat ja kuupäeva paketiga kokkupanemisest ning lisame eelversioonid. Need andmed saab küll projekti faili lisada ja kontrollida enne igat üleslaadimist — aga miks mitte teha seda ka torustikus, tuues paketi versiooni kontekstist ja edastades käsurea argumendina.

Leppime kokku, et kui commit-sõnumis on rida kujul release (v. / ver. / version) <version number> (rev. / revision <revision>)?, siis võtame selle rea põhjal paketi versiooni, täiendame selle praeguse kuupäevaga ja edastame käsurea argumendina käsklusele dotnet pack. Kui rida puudub — ei koostata paketti.

Seda ülesannet lahendab järgmine skript:

# регулярное выражение для поиска строки с версией
$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

Lisame skripti ülesandele pack and deploy job ja jälgime pakettide koostamist rangelt antud rea olemasolul commit-sõnumis.

Kokkuvõttes

Kulutades umbes pool kuni tund aega konfiguratsiooni kirjutamiseks, kohaliku Powershellis veaotsinguks ja võib-olla paariks ebaõnnestunud käivituseks, saime lihtsa konfiguratsiooni rutiinsete ülesannete automatiseerimiseks.

Muidugi on GitLab CI/CD palju laiem ja mitmekesisem, kui võiks pärast selle juhendi lugemist arvata — see ei ole kaugeltki tõsi. Seal on isegi Auto DevOps, mis võimaldab

automaatne tuvastamine, ehitamine, testimine, juurutamine ja teie rakenduste jälgimine

Nüüd on plaanis konfigureerida torustik rakenduste juurutamiseks Azure'is, kasutades Pulumit ja automaatset sihtkeskkonna määratlemist, mis on kajastatud järgmises artiklis.

Allikas: habr.com