🥇Ghid de CI/CD în GitLab pentru (aproape) începători absoluti

Sau cum să obțineți insigne frumoase pentru proiectul dvs. într-o seară de codare ușoară

Probabil, fiecare dezvoltator care are cel puțin un proiect pentru animale de companie la un moment dat are o mâncărime despre insigne frumoase cu statusuri, acoperire de cod, versiuni de pachet în nuget... Și această mâncărime m-a determinat să scriu acest articol. În pregătirea pentru a-l scrie, am obținut această frumusețe într-unul dintre proiectele mele:

Acest articol vă va ghida prin configurarea de bază a integrării și livrării continue pentru un proiect de bibliotecă de clasă .Net Core în GitLab, publicând documentație în GitLab Pages și împingând pachetele construite într-un flux privat în Azure DevOps.

VS Code a fost folosit ca mediu de dezvoltare cu extensia Flux de lucru GitLab (pentru validarea fișierului de setări direct din mediul de dezvoltare).

Scurtă introducere

CD - este atunci când tocmai ați împins și totul a căzut deja asupra clientului?

Ce este CI / CD și de ce aveți nevoie de el - îl puteți căuta cu ușurință pe google. Găsiți documentația completă despre configurarea conductelor în GitLab de asemenea usor. Aici voi descrie pe scurt și, dacă este posibil, fără defecte, procesul sistemului din vedere de pasăre:

dezvoltatorul trimite un commit către depozit, creează o solicitare de îmbinare prin site, sau, într-un alt mod, începe explicit sau implicit conducta,
toate sarcinile sunt selectate din configurație, ale cărei condiții le permit să fie lansate în contextul dat,
sarcinile sunt organizate în funcție de etapele lor,
etapele sunt executate pe rând - i.e. paralel toate sarcinile acestei etape sunt finalizate,
dacă etapa eșuează (adică cel puțin una dintre sarcinile etapei eșuează), conducta se oprește (aproape intotdeauna),
dacă toate etapele sunt finalizate cu succes, conducta este considerată reușită.

Astfel, avem:

pipeline - un set de sarcini organizate în etape în care puteți construi, testa, pachetați cod, implementați o versiune finalizată într-un serviciu cloud etc.,
etapa (etapă) — unitate de organizare a conductei, conține 1+ sarcină,
sarcina (muncă) este o unitate de lucru în conductă. Constă dintr-un script (obligatoriu), condiții de lansare, setări pentru publicarea/memorizarea în cache a artefactelor și multe altele.

În consecință, sarcina la configurarea CI/CD se reduce la crearea unui set de sarcini care implementează toate acțiunile necesare pentru construirea, testarea și publicarea codului și artefactelor.

Înainte de a începe: de ce?

De ce Gitlab?

Pentru că atunci când a devenit necesar să creez depozite private pentru proiecte de companie, acestea au fost plătite pe GitHub, iar eu eram lacom. Arhivele au devenit gratuite, dar până acum acesta nu este un motiv suficient pentru a mă muta la GitHub.

De ce nu Azure DevOps Pipelines?

Pentru că acolo setarea este elementară - nici măcar nu este necesară cunoașterea liniei de comandă. Integrare cu furnizori externi de git - în câteva clicuri, import de chei SSH pentru a trimite comite-uri către depozit - de asemenea, pipeline-ul este ușor de configurat chiar și nu dintr-un șablon.

Poziția de start: ce ai și ce vrei

Avem:

depozit în GitLab.

Noi vrem:

asamblare și testare automată pentru fiecare cerere de îmbinare,
construirea de pachete pentru fiecare cerere de îmbinare și împingerea către master, cu condiția să existe o anumită linie în mesajul de comitere,
trimiterea pachetelor construite la un feed privat în Azure DevOps,
asamblarea documentației și publicare în Pagini GitLab,
insigne!11

Cerințele descrise se încadrează organic pe următorul model de conductă:

Etapa 1 - Asamblare
- Colectăm codul, publicăm fișierele de ieșire ca artefacte
Etapa 2 - testare
- Obținem artefacte din etapa de construire, rulăm teste, colectăm date de acoperire a codului
Etapa 3 - Trimiteți
- Sarcina 1 - construiți pachetul nuget și trimiteți-l la Azure DevOps
- Sarcina 2 - colectăm site-ul de la xmldoc în codul sursă și îl publicăm în Pagini GitLab

Să începem!

Colectarea configurației

Pregatirea conturilor

Creează un cont în Microsoft Azure
Mergi la Azure DevOps
Cream un nou proiect
1. Nume - orice
2. Vizibilitate - orice
Când faceți clic pe butonul Creare, proiectul va fi creat și veți fi redirecționat către pagina acestuia. Pe această pagină, puteți dezactiva funcțiile inutile accesând setările proiectului (linkul de jos din lista din stânga -> Prezentare generală -> Bloc Azure DevOps Services)
Accesați Atrifacts, faceți clic pe Creare feed
1. Introduceți numele sursei
2. Alege vizibilitatea
3. Debifați Includeți pachete din surse publice comune, astfel încât sursa să nu se transforme într-o clonă dump nuget
Faceți clic pe Connect to feed, selectați Visual Studio, copiați Sursa din blocul Machine Setup
Accesați setările contului, selectați Token de acces personal
Creați un nou simbol de acces
1. Nume - arbitrar
2. Organizare - Actual
3. Valabil maxim 1 an
4. Domeniu de aplicare - Ambalare/Citire și scriere
Copiați jetonul creat - după ce fereastra modală este închisă, valoarea va fi indisponibilă
Accesați setările depozitului din GitLab, selectați setările CI / CD
Extindeți blocul Variabile, adăugați unul nou
1. Nume - oricare fără spații (va fi disponibil în shell-ul de comandă)
2. Valoare - jeton de acces de la paragraful 9
3. Selectați variabila Mască

Aceasta completează pre-configurarea.

Pregătirea cadrului de configurare

În mod implicit, configurația CI/CD din GitLab utilizează fișierul .gitlab-ci.yml de la rădăcina depozitului. Puteți seta o cale arbitrară către acest fișier în setările depozitului, dar în acest caz nu este necesar.

După cum puteți vedea din extensie, fișierul conține o configurație în format YAML. Documentația detaliază ce chei pot fi conținute la nivelul superior al configurației și la fiecare dintre nivelurile imbricate.

Mai întâi, să adăugăm un link către imaginea docker în fișierul de configurare, în care vor fi efectuate sarcinile. Pentru aceasta găsim Pagina de imagini .Net Core pe Docker Hub. În GitHub există un ghid detaliat despre ce imagine să alegeți pentru diferite sarcini. O imagine cu .Net Core 3.1 este potrivită pentru a construi, așa că nu ezitați să adăugați prima linie la configurație

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

Acum, când conducta este lansată din depozitul de imagini Microsoft, imaginea specificată va fi descărcată, în care vor fi executate toate sarcinile din configurare.

Următorul pas este să adăugați etapălui. În mod implicit, GitLab definește 5 etape:

.pre - executat până la toate etapele,
.post - efectuat după toate etapele,
build - primul după .pre etapă,
test - a doua fază,
deploy - a treia etapă.

Nimic nu te împiedică însă să le declari în mod explicit. Ordinea în care sunt listați pașii afectează ordinea în care sunt executați. Pentru completare, să adăugăm la configurație:

stages:
  - build
  - test
  - deploy

Pentru depanare, este logic să obțineți informații despre mediul în care sunt executate sarcinile. Să adăugăm un set global de comenzi care vor fi executate înainte de fiecare sarcină cu before_script:

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

Rămâne să adăugați cel puțin o sarcină, astfel încât atunci când commit-urile sunt trimise, conducta va începe. Deocamdată, să adăugăm o sarcină goală pentru a demonstra:

dummy job:
  script:
    - echo ok

Începem validarea, primim un mesaj că totul este în regulă, ne angajăm, împingem, ne uităm la rezultatele de pe site... Și primim o eroare de script - bash: .PSVersion: command not found. wtf?

Totul este logic - în mod implicit, alergătorii (responsabili de executarea scripturilor de sarcini și furnizate de GitLab) folosesc bash pentru a executa comenzi. Puteți remedia acest lucru specificând în mod explicit în descrierea sarcinii ce etichete ar trebui să aibă runnerul conductei care execută:

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

Grozav! Conducta funcționează acum.

Un cititor atent, după ce a repetat pașii indicați, va observa că sarcina a fost finalizată în etapă test, deși nu am precizat etapa. După cum ați putea ghici test este pasul implicit.

Să continuăm crearea scheletului de configurare adăugând toate sarcinile descrise mai sus:

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

Avem o conductă nu deosebit de funcțională, dar totuși corectă.

Configurarea declanșatorilor

Datorită faptului că nu sunt specificate filtre de declanșare pentru niciuna dintre sarcini, conducta va fi complet să fie executat de fiecare dată când un commit este împins în depozit. Deoarece acesta nu este comportamentul dorit în general, vom configura filtre de declanșare pentru sarcini.

Filtrele pot fi configurate în două formate: numai/cu excepția и norme. Scurt, only/except vă permite să configurați filtre după declanșatoare (merge_request, de exemplu - setează sarcina să fie executată de fiecare dată când este creată o cerere de extragere și de fiecare dată când sunt trimise commit-uri către ramura care este sursa în cererea de îmbinare) și numele ramurilor (inclusiv utilizarea expresiilor regulate); rules vă permite să personalizați un set de condiții și, opțional, să modificați condiția de execuție a sarcinii în funcție de succesul sarcinilor anterioare (when în GitLab CI/CD).

Să reamintim un set de cerințe - asamblare și testare numai pentru cererea de îmbinare, ambalarea și trimiterea către Azure DevOps - pentru cererea de îmbinare și trimiteri către master, generarea documentației - pentru push către master.

Mai întâi, să setăm sarcina de compilare a codului adăugând o regulă care se declanșează numai la cererea de îmbinare:

build job:
  # snip
  only:
    - merge_request

Acum să setăm sarcina de împachetare să se declanșeze la cererea de îmbinare și să adăugăm commit-uri la master:

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

După cum puteți vedea, totul este simplu și simplu.

De asemenea, puteți seta sarcina să se declanșeze numai dacă o solicitare de îmbinare este creată cu o anumită țintă sau ramură sursă:

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

În condiții, puteți utiliza variabilele enumerate aici; reguli rules incompatibil cu regulile only/except.

Configurarea salvării artefactelor

În timpul unei sarcini build job vom construi artefacte care pot fi reutilizate în sarcinile ulterioare. Pentru a face acest lucru, trebuie să adăugați căile la configurația sarcinii, fișierele de-a lungul cărora va trebui să salvați și să le refolosiți în următoarele sarcini, la cheie artifacts:

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

Căile acceptă metacaracterele, ceea ce le face cu siguranță mai ușor de setat.

Dacă o sarcină creează artefacte, atunci fiecare sarcină ulterioară va putea să le acceseze - acestea vor fi localizate pe aceleași căi în raport cu rădăcina depozitului care au fost colectate din sarcina originală. Artefactele sunt, de asemenea, disponibile pentru descărcare de pe site.

Acum că avem un cadru de configurare gata (și testat), putem trece la scrierea efectivă a scripturilor pentru sarcini.

Scriem scenarii

Poate că, pe vremuri, într-o galaxie departe, departe, construirea proiectelor (inclusiv cele de pe .net) din linia de comandă a fost o durere. Acum puteți construi, testa și publica proiectul în 3 echipe:

dotnet build
dotnet test
dotnet pack

Desigur, există câteva nuanțe din cauza cărora vom complica oarecum comenzile.

Vrem o versiune de versiune, nu o versiune de depanare, așa că adăugăm la fiecare comandă -c Release
Când testăm, dorim să colectăm date de acoperire a codului, așa că trebuie să includem un analizor de acoperire în bibliotecile de testare:
1. Adăugați pachetul la toate bibliotecile de testare coverlet.msbuild: dotnet add package coverlet.msbuild din folderul de proiect
2. Adăugați la comanda test run /p:CollectCoverage=true
3. Adăugați o cheie la configurația sarcinii de testare pentru a obține rezultate de acoperire (vezi mai jos)
Când împachetați codul în pachete nuget, setați directorul de ieșire pentru pachete: -o .

Colectarea datelor de acoperire a codului

După rularea testelor, Coverlet prints rulează statistici pe consolă:

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% |
+---------+--------+--------+--------+

GitLab vă permite să specificați o expresie regulată pentru a obține statistici, care pot fi apoi obținute sub forma unei insigne. Expresia regulată este specificată în setările sarcinii cu tasta coverage; expresia trebuie să conțină un grup de captură, a cărui valoare va fi transmisă insignei:

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

Aici obținem statistici de la o linie cu acoperire totală a liniei.

Publicați pachete și documentație

Ambele acțiuni sunt programate pentru ultima etapă a conductei - deoarece asamblarea și testele au trecut, putem împărtăși dezvoltările noastre cu lumea.

Mai întâi, luați în considerare publicarea în sursa pachetului:

Dacă proiectul nu are un fișier de configurare nuget (nuget.config), creați unul nou: dotnet new nugetconfig

Pentru ce: este posibil ca imaginea să nu aibă acces de scriere la configurațiile globale (utilizator și mașină). Pentru a nu detecta erori, pur și simplu creăm o nouă configurație locală și lucrăm cu ea.
Să adăugăm o nouă sursă de pachet la configurația locală: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - numele sursei locale, nu critic
2. url - URL-ul sursei din etapa „Pregătirea conturilor”, p. 6
3. organization - numele organizației în Azure DevOps
4. gitlab variable - numele variabilei cu token-ul de acces adăugat la GitLab („Pregătirea conturilor”, p. 11). Desigur, în format $variableName
5. -StorePasswordInClearText - un hack pentru a ocoli eroarea de acces refuzat (Nu sunt primul care calcă pe grebla asta)
6. În caz de erori, poate fi util să adăugați -verbosity detailed
Trimiterea pachetului la sursa: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Trimitem toate pachetele din directorul curent, deci *.nupkg.
2. name - de la pasul de mai sus.
3. key - orice linie. În Azure DevOps, în fereastra Conectare la feed, exemplul este întotdeauna linia az.
4. -skipduplicate - când încercați să trimiteți un pachet deja existent fără această cheie, sursa va returna o eroare 409 Conflict; cu cheia, trimiterea va fi omisă.

Acum să setăm crearea documentației:

Mai întâi, în depozit, în ramura master, inițializam proiectul docfx. Pentru a face acest lucru, executați comanda de la rădăcină docfx init și setați în mod interactiv parametrii cheie pentru documentația clădirii. Descrierea detaliată a configurației minime a proiectului aici.
1. La configurare, este important să specificați directorul de ieșire ..public - GitLab preia în mod implicit conținutul folderului public din rădăcina depozitului ca sursă pentru Pages. Deoarece proiectul va fi localizat într-un folder imbricat în depozit - adăugați o ieșire la nivelul de sus în cale.
Să împingem modificările aduse GitLab.
Adăugați o sarcină la configurația conductei pages (cuvânt rezervat pentru sarcinile de publicare a site-ului în paginile GitLab):
1. Scenariul:
  1. nuget install docfx.console -version 2.51.0 - instalați docfx; versiunea este specificată pentru a se asigura că căile de instalare a pachetului sunt corecte.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - colectarea documentatiei
2. Artefacte nod:

pages:
  # snip
  artifacts:
    paths:
      - public

Digresiune lirică despre docfx

Anterior, la configurarea unui proiect, am specificat sursa codului pentru documentație ca fișier de soluție. Principalul dezavantaj este că documentația este creată și pentru proiectele de testare. În cazul în care acest lucru nu este necesar, puteți seta această valoare nodului metadata.src:

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

metadata.src.src: "../" - urcăm cu un nivel față de locație docfx.json, deoarece în modele, căutarea în arborele de directoare nu funcționează.
metadata.src.files: ["**/*.csproj"] - un model global, colectăm toate proiectele C # din toate directoarele.
metadata.src.exclude: ["*.tests*/**"] - model global, excludeți totul din foldere cu .tests În titlu

Subtotal

O astfel de configurație simplă poate fi creată în doar o jumătate de oră și câteva cești de cafea, ceea ce vă va permite să verificați dacă codul este construit și testele trec, să construiți un nou pachet, să actualizați documentația și să vă bucurați de ochi frumos. insigne în fișierul README al proiectului cu fiecare cerere de îmbinare și trimitere către master.

.gitlab-ci.yml final

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

Apropo de insigne

Din cauza lor, până la urmă, totul a început!

Insignele cu stările conductei și acoperirea codului sunt disponibile în GitLab în setările CI/CD din blocul conductelor Gtntral:

Am creat o insignă cu un link către documentația de pe platformă scuturi.io - totul este destul de simplu acolo, puteți să vă creați propria insignă și să o primiți folosind o cerere.

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

Azure DevOps Artefacts vă permite, de asemenea, să creați insigne pentru pachete cu cea mai recentă versiune. Pentru a face acest lucru, în sursa de pe site-ul Azure DevOps, trebuie să faceți clic pe Creare insignă pentru pachetul selectat și să copiați marcajul de reducere:

Adăugând frumusețe

Evidențierea fragmentelor de configurare comune

În timp ce scriam configurația și căutăm prin documentație, am dat peste o caracteristică interesantă a YAML - reutilizarea fragmentelor.

După cum puteți vedea din setările sarcinii, toate necesită eticheta windows la runner și sunt declanșate atunci când o solicitare de îmbinare este trimisă către master/creat (cu excepția documentației). Să adăugăm acest lucru la fragmentul pe care îl vom reutiliza:

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

Și acum putem introduce fragmentul declarat mai devreme în descrierea sarcinii:

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

Numele fragmentelor trebuie să înceapă cu un punct, pentru a nu fi interpretate ca o sarcină.

Versiune pachet

La crearea unui pachet, compilatorul verifică comutatoarele liniei de comandă, iar în lipsa acestora, fișierele de proiect; când găsește un nod Versiune, își ia valoarea ca versiune a pachetului care este construit. Se pare că, pentru a construi un pachet cu o nouă versiune, trebuie fie să îl actualizați în fișierul de proiect, fie să îl transmiteți ca argument în linia de comandă.

Să mai adăugăm o listă de dorințe - lăsați ca cele două numere minore din versiune să fie anul și data construirii pachetului și adăugați versiuni preliminare. Desigur, puteți adăuga aceste date în fișierul de proiect și puteți verifica înainte de fiecare trimitere - dar o puteți face și în pipeline, colectând versiunea pachetului din context și trecând-o prin argumentul liniei de comandă.

Să fim de acord că dacă mesajul de commit conține o linie ca release (v./ver./version) <version number> (rev./revision <revision>)?, apoi vom lua versiunea pachetului din această linie, o vom completa cu data curentă și o vom trece ca argument la comandă dotnet pack. În absența unei linii, pur și simplu nu vom ridica coletul.

Următorul script rezolvă această 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

Adăugarea unui script la o sarcină pack and deploy job și observați asamblarea pachetelor strict în prezența unui șir dat în mesajul de comitere.

În total

După ce am petrecut aproximativ o jumătate de oră sau o oră pentru a scrie configurația, a depana în powershell-ul local și, eventual, a câteva lansări nereușite, am obținut o configurație simplă pentru automatizarea sarcinilor de rutină.

Desigur, GitLab CI / CD este mult mai extins și mai multiplu decât ar părea după citirea acestui ghid - asta nu este deloc adevarat. Acolo chiar Auto DevOps estepermițând

detectează, construiește, testează, implementează și monitorizează automat aplicațiile dvs

Acum planurile sunt de a configura o conductă pentru implementarea aplicațiilor în Azure, folosind Pulumi și determinând automat mediul țintă, care va fi tratat în următorul articol.

Sursa: www.habr.com

Un ghid pentru CI/CD în GitLab pentru începătorii (aproape) absolut