🥇CI/CD juhend GitLabis (peaaegu) täiesti uuele kasutajale

Või kuidas saada oma projekti jaoks ilusad ribaiketid ühe õhtu tasuta kodeerimisega

Võib-olla tunneb iga arendaja, kellel on vähemalt üks isiklik projekt, mingi hetk soovi luua ilusaid ribaiketid olekute, koodikatvuse ja nuget'i paketiversioonide kohta… Ja see soov viis mind selle artikli kirjutamiseni. Artikli ettevalmistamise käigus sain enda projektis sellise ilu:

Artiklis käsitletakse pideva integreerimise ja kohaletoimetamise põhiseadistust .Net Core klasside raamatukogu projekti jaoks GitLabis, dokumentatsiooni avaldamist GitLab Pages'is ja koostatud pakettide saatmist privaati fidi Azure DevOps'is.

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

Lühike sissejuhatus

CD on see, kui sa just push'isid ja kliendil on juba kõik maas?

CI/CD on see, mida see tähendab ja miks seda vajate — saab lihtsalt googeldada. Täieliku dokumentatsiooni leidmine GitLabi torude seadistamiseks ei ole samuti keeruline samuti mitte keeruline. Siin tutvustan lühidalt ja võimalikult täpselt süsteemi toimimist linnulennult:

arendaja saadab koodi reposse, loob merge requesti veebisaidi kaudu, või käivitab toru mingil muul viisil selgelt või kaudselt,
konfiguratsioonist valitakse kõik ülesanded, mille tingimused võimaldavad neid antud kontekstis käivitada,
ülesanded organiseeritakse vastavalt oma etappidele,
etapid täidetakse järjestikku – st. paralleelselt kõik selle etapi ülesanded täidetakse,
kui etapp fails, (st. ebaõnnestub vähemalt üks etapi ülesanne) – toru peatub (peaaegu alati),
kui kõik etapid lõpetatakse edukalt, loetakse toru silmitsi läbituks.

Nii saame:

toru – ülesannete kogum, organiseeritud etappides, milles saab koguda, testida, pakendada koodi, juurutada valmis kogumist pilveteenuses jne.
etapp (etapi) – toru organiseerimise üksus, sisaldab 1+ ülesannet,
ülesanne (job) – tööüksus torus. Koosneb skriptist (kohustuslik), käivitamise tingimustest, artefaktide avaldamise/vahemälu seadistustest ja paljust muust.

Seega, CI/CD seadistamise ülesanne on luua ülesannete kogum, mis hõlmab kõiki vajalikke toimingute tegemiseks koodi ja artefaktide koostamiseks, testimiseks ja avaldamiseks.

Enne alustamist: miks?

Miks GitLab?

Kuna kui tekkis vajadus luua privaatseid repositooriume isiklikeks projektideks, siis GitHub'is nad olid tasulised, aga mina olin kokkuhoidlik. Repositooriumid muutusid tasuta, kuid see ei ole minu jaoks piisav põhjus GitHub'i kolimiseks.

Miks mitte Azure DevOps Pipelines?

Kuna seal on seadistamine elementaarne — ei ole isegi vajalik käsuree tundmine. Integreerimine väliste git-provideerijatega — mõne klõpsuga, SSH-võtmete importimine commit'ide saatmiseks repositooriumisse — samuti, pipeline'i saab hõlpsasti seadistada ka ilma mallideta.

Algne positsioon: mis on olemas ja mida soovitakse

On olemas:

repositoorium GitLab'is.

Soovitakse:

automaatset koostamist ja testimist iga merge request'i jaoks,
pakettide koostamist iga merge request'i ja masterisse push'imise korral, kui commit'i sõnumis on teatud rida,
koostatud pakettide saatmist privaatfide Azure DevOps'is,
dokumentatsiooni koostamist ja avaldamist GitLab Pages'is,
märgid!11

Käesolevad nõuded sobivad järgmise töövoo mudeliga:

1. etapp — kogumine
- Kogume koodi, väljundfailid avaldame artefaktidena
2. etapp — testimine
- Saame artefaktid kogumise etapist, käitame teste ja kogume koodi katvust
3. etapp — saatmine
- Ülesanne 1 — kogume nuget-paketi ja saadame Azure DevOps
- Ülesanne 2 — kogume veebisaidi xmldoc-ist lähtekoodis ja avaldame GitLab Pages

Alustame!

Kogume konfiguratsiooni

Valmistame kontod ette

Loome konto Microsoft Azure
Liigume Azure DevOps
Loome uue projekti
1. Nimi — ükskõik milline
2. Nähtavus — ükskõik milline
Nupu Create vajutamisel luuakse projekt ja suundume selle lehele. Selles lehes on võimalik välja lülitada mittevajalikud funktsioonid, minnes projekti seadetesse (alllingil nimekirja vasakus servas -> Overview -> Azure DevOps Services bloki)
Liigume Atrifacts, vajutame Create feed
1. Sisestame allika nime
2. Valime nähtavuse
3. Tühistame linnukese Include packages from common public sources, et allikas ei muutuks nuget-klone täis prügiks
Vajutame Connect to feed, valime Visual Studio, Machine Setup blokis kopeerime Source
Läheme konto seadete juurde, valime Personal Access Token
Loome uue juurdepääsutokeni
1. Nimi — meelepärane
2. Organisatsioon — aktuaalne
3. Kehtivusaeg — maksimaalselt 1 aasta
4. Kasutusala (scope) — Packaging/Read & Write
Kopeerime loodud tokeni — pärast modaalakna sulgemist väärtus ei ole enam kättesaadav
Minge GitLabi hoidla seadete juurde, valige CI/CD seadistused
Laiendame Variables plokki, lisame uue
1. Nimi — mis tahes, ilma tühikuta (olemas käskude shellis)
2. Väärtus — juurdepääsu token punktist 9
3. Valige Mask variable

Sellega eelkokkuvõte on lõpetatud.

Valmistame ette konfiguratsiooni raamistikku

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

Nagu näha laiendist, sisaldab fail konfiguratsiooni formaadis YAML. Dokumentatsioonis on üksikasjalikult kirjeldatud, milliseid võtmeid võivad sisaldada ülemise taseme konfiguratsioonid ja iga sisenemise taseme all.

Esmalt lisame konfiguratsioonifaili lingi docker-pildile, kus ülesannete täitmine toimub. Selle jaoks leiame .Net Core piltide lehe Docker Hubis. Dokumendihalduses GitHub on olemas üksikasjalik juhend, kuidas valida erinevate ülesannete jaoks pilti. Meie jaoks on .Net Core 3.1, seetõttu lisame julgelt konfiguratsiooni esimese rea.

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

Nüüd, kui käivitame Microsofti pildihoiust, laaditakse alla määratud pilt, milles täidetakse kõik konfiguratsiooni ülesanded.

Järgmine samm — lisada etapietappe. 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.

Pole midagi, mis takistaks neid selgelt deklareerida. Etappide järjekord mõjutab nende täitmise järjekorda. Täienduseks lisame konfiguratsiooni:

stages:
  - build
  - test
  - deploy

Silumise huvides on mõistlik hankida teavet keskkonna kohta, milles ülesanded 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

Peame lisama vähemalt ühe ülesande, et commitide saatmisel pipeline käivituks. Praegu lisame näidisena tühja ülesande:

dummy job:
  script:
    - echo ok

Käivitame valideerimise, saame sõnumi, et kõik on hästi, commitime, pushime ja vaatame tulemusi saidil... Ja saame skripti vea — bash: .PSVersion: käsku ei leitud. WTF?

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 kirjel, millised sildid peaks olema täitva pipeline runner'i jaoks:

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

Suurepärane! Nüüd täidetakse pipeline.

Täpne lugeja, kes kordab ülaltoodud samme, märkab, et ülesanne täideti etapis test, kuigi me ei määranud etappi. Kuidas arvata võib, test on see vaikimisi etapp.

Jätkame konfiguratsiooni skeletoni loomist, lisades kõik ülalmainitud ü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

Sai sai mitte kuigi funktsionaalne, kuid siiski korrektne pipeline.

Käivitajate seadistamine

Kuna ühele ülesandele ei ole määratud töökäivituse filtreid, töötab pipeline täielikult iga kord, kui commite tehakse reposse. Kuna see ei ole soovitud käitumine, seadistame ülesannete jaoks käivituse filtrid.

Filtreid saab seadistada kahes formaadis: only/except ja rules. Ühendavalt, only/except võimaldab seadistada filtreid käivitajate järgi (merge_request, näiteks — seadistab ülesande täitmise igal korral, kui luuakse sulgemistaotlus või kui commite tehakse harusse, mis on sulgemistaotluses allikas) ja harude nimede järgi (sealhulgas regulaarsete väljendite kasutamine); rules võimaldab seadistada tingimuste komplekti ja, soovi korral, muuta ülesande täitmise tingimusi sõltuvalt eelnevate ülesannete edukusest (when GitLab CI/CD).

Tuletama nõudmiste komplekti — koostamine ja testimine on ainult merge request'ide jaoks, pakkimine ja saatmine Azure DevOps'i — merge request'idele ja peadokumendile, dokumentatsiooni genereerimine — peadokumendi pushide jaoks.

Kuna alustame, seadistame koodikogumise ülesande, lisades reegli, mis aktiveeritakse ainult merge request'i korral:

build job:
  # snip
  only:
    - merge_request

Nüüd seadistame pakkimise ülesande, mis aktiveerub merge request'i ja commit'ide lisamisel peadokumenti:

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

Kuidas on näha, on kõik lihtne ja otsekohene.

Samuti saab seadistada ülesande, mis aktiveeritakse ainult juhul, kui merge request on loodud teatud siht- või algharu korral:

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

Mõistetes saab kasutada siin loetletud muutujad; reeglid rules ei ühildu reeglitega only/except.

Artefaktide säilitamise seadistamine

Ülesande täitmise ajal build job meie poolt luuakse konstruktsiooni artefakte, mida saab järgnevates ülesannetes uuesti kasutada. Selleks tuleb ülesande konfiguratsioonile lisada teed, failid, mida tuleb säilitada ja kasutada järgnevates ülesannetes, võtmes artifacts:

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

Teed toetavad wildcard'e, mis kindlasti lihtsustab nende määramist.

Kui ülesanne loob artefakte, saavad kõik järgnevad ülesanded neile juurde pääseda — need asuvad sama tee suhtes reposti juurest, mille kaudu nad esialgsest ülesandest koguti. Samuti on artefaktid allalaadimiseks saadaval veebisaidil.

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

Kirjutame skripte

Võib-olla, kunagi kauges kauges galaktikas, oli projektide (sealhulgas .net-i) kogumine käsurealt valus. Praegu on projekti kogumine, testimine ja avaldamine võimalik kolme käsuga:

dotnet build
dotnet test
dotnet pack

Loomulikult on teatud nüansse, mis muudavad käsud natuke keerukamaks.

Soovime väljalaske, mitte silumise ehitust, seetõttu lisame igale käsule -c Release
Testimise käigus soovime koguda koodi katvuse andmeid, seetõttu tuleb testibibliotekesse lisada katvuse analüsaator:
1. Igal testibibliotekil tuleks lisada paket coverlet.msbuild: dotnet add package coverlet.msbuild projekti kaustast
2. Lisa testide käivitamise meeskonda /p:CollectCoverage=true
3. Lisame testimise ülesande konfiguratsiooni võtme katte tulemuste saamiseks (vt allpool)
Pakendades koodi nuget-pakettidesse, määrame pakettide väljundikausta: -o .

Kogume koodi katteandmeid

Coverlet kuvab testide käivitamise statistika konsoolile:

Katte tulemuse arvutamine...
  Koostatakse aruanne '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 järgi statistika saamiseks, mille saadakse hiljem häbimärgistuse kujul. Regulaaravaldis määratakse ülesande seadistustes võtmega coverage; avaldises peab olema tabamisrühm, mille väärtus edastatakse häbimärgistusele:

testi ja katte töö:
  # snip
  katte: \/|s*Totals*|s*(d+[,.]d+%)\/

Siin saame statistikat üldiste ridade katvuse kohta.

Avaldame paketid ja dokumentatsiooni

Mõlemad tegevused on meil määratud pipeline'i viimasesse etappi — kui koostamine ja testid on läbitud, siis saame jagada maailmaga oma töö tulemust.

Alustame paketiallika avaldamise kaalumisega:

Kui projektis ei sisaldu nuget'i konfiguratsioonifaili (nuget.config), loome uue: dotnet new nugetconfig
Miks: pildil võib olla keelatud kirjutamise juurdepääs globaalsetele (kasutaja ja masina) konfiguratsioonidele. Vigade vältimiseks loome lihtsalt uue kohaliku konfiguratsiooni ja töötame selle kallal.
Lisame kohalikku konfiguratsioonisse uue paketiallika: nuget sources add -name -source -username -password -configfile nuget.config -StorePasswordInClearText
1. name — kohaliku allika nimi, mitte eriti oluline
2. url — allika URL etapist "Valmistame kontod", p. 6
3. organization — organisatsiooni nimi Azure DevOps'is
4. gitlab variable — muutuja nimi, mis sisaldab juurdepääsuluba GitLab'is ("Valmistame kontod", p. 11). Loomulikult vormingus $variableName
5. -StorePasswordInClearText — nipp juurdepääsu keeldumise vea ületamiseks (ei ole ma esimene, kes sellel komistab)
6. Vigade korral võib olla kasulik lisada -verbosity detailed
Saadame paketi allikale: nuget push -source -skipduplicate -apikey *.nupkg
1. Saadame kõik paketid praegusest kataloogist, seega *.nupkg.
2. name — eelnevalt mainitud sammust.
3. key — mis tahes string. Azure DevOps'is toovad ühenduse loomise aknas alati näitena välja stringi az.
4. -skipduplicate — kui proovite saata juba olemasolevat paketti ilma selle võtmeta, tagastab allikas vea 409 Conflict; võtmega saatmine jäetakse vahele.

Nüüd seadistame dokumentatsiooni loomise:

Alustamiseks initsialiseerime docfx projekti master haru repos. Selle jaoks tuleb juurest käivitada käsk docfx init ja interaktiivses režiimis küsime olulised parameetrid dokumentatsiooni koostamiseks. Üksikasjalik kirjeldus minimaalsetest seadistustest siit.
1. Seadistamisel on oluline märkida väljundkataloog ..public — GitLab võtab vaikimisi aluseks publi katalooge sisu juure kataloogist lehtede jaoks. Kuna projekt asub repos oleva katalooge sees — lisame väljundile taseme võrra ülespoole.
Saadame muudatused GitLabi.
Lisame pipeline'i konfiguratsiooni ülesande pages (reserveeritud sõna GitLab Pages'i veebilehtede avaldamise ülesannete jaoks):
1. Skripts:
  1. nuget install docfx.console -version 2.51.0 — installib docfx; versioon on määratud paketi installimise teede õigsuse tagamiseks.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json — kogume dokumentatsiooni
2. Artifaktide sõlm:

lehed:
  # snip
  artifaktid:
    teed:
      - avalik

Lühiülevaade docfx'ist

Varem määrasin projekti seadistamisel dokumentatsiooni koodiallikaks lahenduse faili. Peamine puudus on see, et dokumentatsioon luuakse ka testprojektide jaoks. Kui see ei ole vajalik, saab sõlmele määrata järgmise väärtuse metadata.src:

{
  "metadata": [
    {
      "src": [
        {
          "src": "../",
          "failid": [
            "**/*.csproj"
          ],
          "välista":[
            "*.tests*/**"
          ]
        }
      ],
      // --- snip ---
    },
    // --- snip ---
  ],
  // --- snip ---
}

metadata.src.src: "../" — väljuge ülemisele tasemele võrreldes asukohaga docfx.json, kuna mustrites ei tööta ülemise kausta otsing.
metadata.src.files: ["**/*.csproj"] — globaalne muster, kogume kõik C# projektid kõigist kaustadest.
metadata.src.exclude: ["*.tests*/**"] — globaalne muster, välistame kõik testikaustadega .tests nimes

Vahekokkuvõte

Seda lihtsat konfiguratsiooni saab koostada tõeliselt poolteise tunni ja paarikese tassi kohviga, mis võimaldab iga liitumistaotlusega ja meistrisse saatmise korral kontrollida, et kood kompileerub ja testid läbivad, koguda uus paket, uuendada dokumentatsiooni ja rõõmustada silma kenade märgistega 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.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

Muide märgiste kohta

Nende pärast see kõik algas!

Pipeline'i staatuse ja katvuse märgid on saadaval GitLabis CI/CD seadetest jaotisest Gtntral pipelines:

Dokumentatsiooni lingiga märgi lõin platvormil Shields.io — seal on kõik piisavalt lihtne, saate luua oma märgi ja saada seda päringu kaudu.

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

Azure DevOps Artifacts võimaldab samuti luua pakettide jaoks märke, märkides aktualiseeritud versiooni. Selleks tuleb Azure DevOps veebisaidil valitud paketi juures klikata Create badge ja kopeerida markdown-märgistus:

Lisame ilu

Tõstame esile ühised konfiguratsiooni fragmendid

Konfiguratsiooni kirjutamise ja dokumenteerimise otsingute käigus kohtasin huvitavat võimalust YAML-is — fragmentide taaskasutamine.

Nagu näha ülesannete seadistustest, vajavad kõik need käivitusmärki windows runner'i ja aktiveeruvad, kui saadetakse masterisse/luuakse liitumispäring (välja arvatud dokumentatsioon). Lisame selle fragmendi, mida hakkame taaskasutama:

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

Ja nüüd saame ülesande kirjel lisada varem deklareeritud fragmendi:

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

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

Pakettide versioonimine

Paketi loomisel kontrollib kompilaator käskude rea võtmeid ja nende puudumisel - projektifaile; leides sõlme Version, võtab ta selle väärtuse kokkupanemiseks. Seega, et koostada uus versioon pakett, tuleb kas värskendada seda projekti failis või edastada kui käskude rea argument.

Lisame veel ühe soovi - aluseks oleku kahe alumise numbri versioonis, olgu need aasta ja paketi koostamise kuupäev, ning lisame eelversioonid. Loomulikult saab neid andmeid projekti faili lisada ja enne igat edastamist kontrollida - kuid seda saab teha ka pipelines, saavutades paketi versiooni kontekstist ja edastades käskude rea argumentina.

Kokkuleppel, et kui commit sõnumis on rida kujul release (v./ver./version) <version number> (rev./revision <revision>)?, siis võtame selle rea versiooninumbri, täiendame seda praeguse kuupäevaga ja edastame selle käsule dotnet pack. Rida puudumise korral - lihtsalt ei koostata paketti.

Selle ülesande 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 ülesande juurde pakendi ja ülesande juurutamine ja jälgime pakettide koostamist rangelt siis, kui antud rida on kinnitusteates olemas.

Kokku

Veetes umbes pool tundi kuni tund aega konfiguratsiooni kirjutamisele, kohandamisele kohalikus powershellis ja võib-olla paarile ebaõnnestunud käivitusele, saime lihtsa konfiguratsiooni rutiinsete ülesannete automatiseerimiseks.

Muidugi on GitLab CI/CD oluliselt ulatuslikum ja mitmekesisem, kui see võib pärast selle juhendi lugemist tunduda — see ei ole üldse nii. Seal on isegi Auto DevOps, mis võimaldab

automaatne avastamine, koostamine, testimine, juurutamine ja teie rakenduste jälgimine

Nüüd on plaanis seadistada pipeline rakenduste juurutamiseks Azure'is, kasutades Pulumit ja sihtkeskkonna automaatset tuvastamist, millest räägitakse järgmises artiklis.

Allikas: habr.com