🥇Di GitLab de Rêbernameya Destpêkê ya Bêkêmasî ya CI/CD

An jî meriv çawa di yek êvarê kodkirina hêsan de nîşaneyên xweşik ji bo projeya xwe bistînin

Belkî, her pêşdebirê ku bi kêmî ve projeyek heywanan heye di hin xalan de di derheqê nîşaneyên xweşik ên bi statûyan, vegirtina kodê, guhertoyên pakêtê yên di nugetê de dilgiraniyek heye ... Û vê xuriyê min kir ku ez vê gotarê binivîsim. Di amadekirina nivîsandina wê de, min ev bedewî di yek ji projeyên xwe de girt:

Ev gotar dê we di sazkirina bingehîn a entegrasyon û radestkirina domdar de ji bo projeyek pirtûkxaneya pola .Net Core ya li GitLab, weşandina belgeyên li ser Rûpelên GitLab, û şandina pakêtên çêkirî berbi feed taybet a di Azure DevOps de bi rê ve bibe.

VS Code bi dirêjkirinê re wekî hawîrdora pêşkeftinê hate bikar anîn GitLab Workflow (ji bo rastkirina pelê mîhengan rasterast ji hawîrdora pêşkeftinê).

Danasîna Kurt

CD - ew gava ku we tenê pêl kir, û her tişt berê ketiye ser xerîdar?

CI / CD çi ye û çima hûn jê re hewce ne - hûn dikarin bi hêsanî google bikin. Li ser veavakirina boriyên li GitLab belgeyên bêkêmasî bibînin jî hêsan. Li vir ez ê bi kurtî û, heke gengaz be, bê xeletî, pêvajoya pergalê ji çavê çûk vebêjim:

pêşdebir peymanek ji depoyê re dişîne, bi navgîniya malperê daxwazek yekbûnê diafirîne, an jî bi awayekî din, bi eşkere an jî nepenî dest bi boriyê dike,
hemî peywir ji mîhengê têne hilbijartin, şert û mercên wan dihêlin ku ew di çarçoveyek diyarkirî de werin destpêkirin,
kar li gorî qonaxên xwe têne organîze kirin,
qonax bi dorê têne darve kirin - ango. dûberîn hemû karên vê qonaxê bi dawî bûne,
heke qonax bi ser nekeve (ango, bi kêmanî yek ji karên qonaxê têk biçe), boriyê disekine (hema hema her tim),
eger hemû qonax bi serkeftî bi dawî bibin, boriyê serkeftî tê hesibandin.

Bi vî awayî, em hene:

lûle - komek peywirên ku di qonaxan de têne organîze kirin, ku hûn dikarin tê de çêbikin, ceribandin, kodê pak bikin, avahiyek qediyayî li karûbarek cloudê bicîh bikin, hwd.
qonax (şanocî) - yekîneya rêxistina boriyê, 1+ peywirê vedihewîne,
wezîfe (kar) yekîneya xebatê ya di lûleyê de ye. Ew ji skrîptek (mecbûrî), şertên destpêkirinê, mîhengên ji bo weşandina/veşartina huneran, û hêj bêtir pêk tê.

Li gorî vê yekê, dema sazkirina CI / CD-yê peywira afirandina komek peywiran e ku hemî kiryarên pêwîst ji bo avakirin, ceribandin û weşandina kod û berheman pêk tîne.

Berî destpêkirinê: çima?

Çima Gitlab?

Ji ber ku gava ku hewce bû ku ji bo projeyên heywanan depoyên taybet biafirînin, ew li ser GitHub hatin dayîn, û ez bi çavbirçî bûm. Depo belaş bûne, lê heya niha ev ne sedemek têr e ku ez biçim GitHub.

Çima ne Azure DevOps Pipelines?

Ji ber ku li wir mîheng seretayî ye - zanîna rêzika fermanê jî ne hewce ye. Yekbûnek bi pêşkêşkerên git-ê yên derveyî re - di çend klîk de, îtxalkirina bişkojên SSH-ê ji bo şandina peywiran ji depoyê re - di heman demê de, boriyê bi hêsanî tê mîheng kirin jî ne ji şablonek.

Helwesta destpêkê: tiştê ku we heye û hûn çi dixwazin

Me heye:

depo li GitLab.

Em dixwazin:

kombûn û ceribandina otomatîkî ji bo her daxwazek yekbûnê,
avakirina pakêtan ji bo her daxwazek hevgirtinê û xistina masterê, bi şertê ku di peyama commit de rêzek diyar hebe,
di Azure DevOps de pakêtên çêkirî dişîne ser feed taybet,
kombûna belgekirin û weşandina di Rûpelên GitLab de,
nîşanan!11

Pêdiviyên diyarkirî bi organîkî li ser modela boriyê ya jêrîn dikevin:

Qonaxa 1 - civîn
- Em kodê berhev dikin, pelên derketinê wekî huner diweşînin
Qonaxa 2 - ceribandin
- Em ji qonaxa çêkirinê huneran digirin, ceribandinan dimeşînin, daneyên vegirtina kodê berhev dikin
Qonaxa 3 - Bişînin
- Kar 1 - pakêta nuget ava bikin û ji Azure DevOps re bişînin
- Kar 2 - em malperê ji xmldoc di koda çavkaniyê de berhev dikin û di Rûpelên GitLab de diweşînin

Ka em dest pê bikin!

Komkirina veavakirinê

Hesaban amade dikin

Di nav de hesabek çêbikin Microsoft Azure
Biçe DevOps Azure
Em projeyek nû ava dikin
1. Nav - her
2. Dîtin - her
Dema ku hûn li ser bişkojka Create bikirtînin, dê proje were afirandin û hûn ê berbi rûpela wê ve werin veguhestin. Li ser vê rûpelê, hûn dikarin bi çûna mîhengên projeyê ve taybetmendiyên nepêwist neçalak bikin (girêdana jêrîn di navnîşa li milê çepê -> Pêşveçûn -> bloka Karûbarên Azure DevOps)
Herin Atrifacts, bikirtînin Create feed
1. Navê çavkaniyê binivîse
2. Dîtiniyê hilbijêrin
3. Hilbijêre Pakêtên ji çavkaniyên gelemperî yên hevpar vekin, da ku çavkanî veneguhere klonek nuştê
Bikirtînin Têkilî ji bo xwarinê, Visual Studio hilbijêrin, Çavkaniyê ji bloka Sazkirina Makîneyê kopî bikin
Herin mîhengên hesabê, Token Access Kesane hilbijêrin
Nîşanek gihîştina nû biafirînin
1. Nav - keyfî
2. Rêxistin - niha
3. Ji bo herî zêde 1 sal derbasdar e
4. Qada - Pakkirin / Xwendin & Binivîsin
Nîşana çêkirî kopî bikin - piştî ku pencereya modal tê girtin, nirx dê ne berdest be
Herin mîhengên depoyê yên li GitLab, mîhengên CI / CD hilbijêrin
Bloka Guherbaran berfireh bike, yekî nû lê zêde bike
1. Nav - her bê valahî (dê di qalika fermanê de peyda bibe)
2. Nirx - nîşana gihîştina ji paragrafa 9
3. Guherbarê Mask hilbijêrin

Ev veavakirina pêşîn temam dike.

Amadekirina çarçoveya veavakirinê

Bi xwerû, veavakirina CI/CD di GitLab de pelê bikar tîne .gitlab-ci.yml ji koka depoyê. Hûn dikarin di mîhengên depoyê de rêyek kêfî ji vê pelê re saz bikin, lê di vê rewşê de ne hewce ye.

Wekî ku hûn ji pêvekê dibînin, pelê di formatê de veavakirinek heye YAML. Hûrguliyên belgekirinê kîjan bişkok dikarin di asta jorîn a veavakirinê de, û di her astên hêlîn de werin hilanîn.

Pêşîn, bila em di pelê mîhengê de, ku tê de peywir bêne kirin, zencîrek bi wêneya docker re zêde bikin. Ji bo vê em dibînin Rûpela wêneyên .Net Core li ser Docker Hub. ew GitHub rêbernameyek berfireh heye ku li ser kîjan wêneyê ji bo karên cûda hilbijêrin. Wêneyek bi .Net Core 3.1 ji bo avakirina me maqûl e, ji ber vê yekê hûn xwe xweş bikin ku rêza yekem li veavakirinê zêde bikin

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

Naha, dema ku boriyê ji depoya wêneya Microsoft-ê were destpêkirin, wêneya diyarkirî dê were dakêşandin, ku tê de hemî peywirên ji veavakirinê dê bêne bicîh kirin.

Pêngava paşîn zêdekirina e şanocî's. Bi xwerû, GitLab 5 qonaxan diyar dike:

.pre - heta hemû qonaxan pêk tê,
.post - piştî hemî qonaxan pêk tê,
build - yekem piştî .pre şanocî,
test - qonaxa duyemîn,
deploy - qonaxa sêyemîn.

Lêbelê, tiştek nahêle ku hûn wan bi eşkereyî ragihînin. Rêza ku gav têne navnîş kirin bandorê li rêza ku ew têne kirin dike. Ji bo bêkêmasî, em li veavakirinê zêde bikin:

stages:
  - build
  - test
  - deploy

Ji bo debuggingê, têgihîştinek e ku meriv di derheqê hawîrdora ku peywir lê têne bicîh kirin de agahdarî bistînin. Ka em komek fermanên gerdûnî yên ku dê beriya her peywirê bi wan re werin darve kirin lê zêde bikin before_script:

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

Dimîne ku bi kêmî ve yek peywirê lê zêde bike da ku gava ku soz têne şandin, boriyê dê dest pê bike. Heya nuha, em karekî vala lê zêde bikin ku nîşan bidin:

dummy job:
  script:
    - echo ok

Em dest bi pejirandinê dikin, me peyamek werdigire ku her tişt baş e, em soz didin, em dişoxilînin, em li encamên li ser malperê dinêrin ... Û em xeletiyek skrîptê digirin - bash: .PSVersion: command not found. wtf?

Her tişt mentiqî ye - ji hêla xwerû, bazdan (berpirsiyar ji cîbicîkirina skrîptên peywirê ye û ji hêla GitLab ve hatî peyda kirin) bikar tînin bash ji bo pêkanîna fermanan. Hûn dikarin vê yekê rast bikin bi eşkerekirina di danasîna peywirê de çi etîketên ku gerîdeya boriyê ya îcrakar divê hebin:

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

Ecêb! Xeta boriyê niha dimeşe.

Xwendevanek baldar, gava ku gavên destnîşankirî dubare bike, dê bibîne ku peywir di qonaxê de qediya ye test, tevî ku me qonax diyar nekir. Wekî ku hûn texmîn dikin test gavê xwerû ye.

Werin em bi lê zêdekirina hemî peywirên ku li jor hatine destnîşan kirin, afirandina îskeleta veavakirinê bidomînin:

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 boriyek ne bi taybetî fonksiyonel, lê dîsa jî rast girt.

Sazkirina tetikan

Ji ber vê yekê ku ji bo yek ji karan fîlterên tîrêjê nayên destnîşan kirin, boriyê dê bibe temamî her carê ku peywirek ber bi depoyê ve tê kişandin. Ji ber ku ev ne bi gelemperî tevgerê xwestinê ye, em ê ji bo peywiran fîlterên tîrêjê saz bikin.

Parzûn dikarin di du formatan de werin mîheng kirin: tenê/ji bilî и Rêbazan. Kûrt, only/except destûrê dide te ku hûn fîlteran ji hêla tetikan ve mîheng bikin (merge_request, bo nimûne - her carê ku daxwazek kişandinê tê afirandin û her carê ku commits ji şaxê ku jêdera daxwaza hevgirtinê ye re têne şandin) û navên şaxê (tevî karanîna birêkûpêk birêkûpêk); rules destûrê dide te ku hûn komek şertan xweş bikin û, vebijarkî, li gorî serkeftina karên berê, şerta pêkanîna peywirê biguhezînin (when di GitLab CI/CD de).

Ka em komek pêdiviyan bi bîr bînin - kombûn û ceribandin tenê ji bo daxwaza hevgirtinê, pakkirin û şandina ji Azure DevOps re - ji bo daxwaziya hevgirtinê û zextên ji masterê re, hilberîna belgekirinê - ji bo pêlên ji masterê re.

Pêşîn, em bi lêzêdekirina qaîdeyek ku tenê li ser daxwaza hevgirtinê dişewite, peywira avakirina kodê saz bikin:

build job:
  # snip
  only:
    - merge_request

Naha em karê pakkirinê saz bikin da ku li ser daxwaza hevgirtinê bişewitîne û peywiran li masterê zêde bike:

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

Wekî ku hûn dikarin bibînin, her tişt hêsan û hêsan e.

Her weha hûn dikarin peywirê bicîh bikin ku tenê bişewitîne ger daxwazek hevgirtinê bi armancek an şaxek çavkaniyek taybetî re were afirandin:

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

Di bin şert û mercan de, hûn dikarin bikar bînin guherbarên ku li vir hatine rêz kirin; qaîdeyên rules bi qaîdeyan re li hev nakin only/except.

Veavakirina Saving Artifact

Di dema karekî de build job em ê hunerên ku dikarin di karên paşîn de ji nû ve werin bikar anîn hebin. Ji bo vê yekê, hûn hewce ne ku rêyên mîhengê peywirê, pelên ku hûn pê re hewce ne ku di karên jêrîn de hilînin û ji nû ve bikar bînin, li mifteyê zêde bikin. artifacts:

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

Rêwî qertên çolê piştgirî dikin, ku bê guman danîna wan hêsantir dike.

Ger peywirek huneran diafirîne, wê hingê her peywirek paşîn dê bikaribe bigihîje wan - ew ê li ser heman riyan li gorî koka depoyê ya ku ji peywira orîjînal hatine berhev kirin bicîh bibin. Artifacts jî ji bo dakêşandinê li ser malperê hene.

Naha ku me çarçoveyek veavakirinê amade ye (û ceribandin), em dikarin bi rastî nivîsandina nivîsan ji bo peywiran bidomînin.

Em senaryoyan dinivîsin

Belkî, carekê li galaksiyek dûr, dûr, avakirina projeyên (tevî yên li ser .net) ji rêza fermanê êşek bû. Naha hûn dikarin projeyê di 3 tîman de ava bikin, ceribandin û biweşînin:

dotnet build
dotnet test
dotnet pack

Bi xwezayî, hin nuwaze hene ku ji ber wan em ê fermanan hinekî tevlihev bikin.

Em avahiyek berdanê dixwazin, ne avakirina debugê, ji ber vê yekê em li her fermanê zêde dikin -c Release
Dema ceribandinê, em dixwazin daneyên vegirtina kodê berhev bikin, ji ber vê yekê em hewce ne ku di pirtûkxaneyên ceribandinê de analîzerek vegirtinê vekin:
1. Pakêtê li hemî pirtûkxaneyên ceribandinê zêde bikin coverlet.msbuild: dotnet add package coverlet.msbuild ji peldanka projeyê
2. Fermana ceribandina testê zêde bikin /p:CollectCoverage=true
3. Ji bo bidestxistina encamên vegirtinê mifteyek li veavakirina peywira ceribandinê zêde bikin (li jêr binêre)
Dema ku kodê di pakêtên nuget de pak dikin, pelrêça derketinê ji bo pakêtan saz bikin: -o .

Komkirina daneyên vegirtina kodê

Piştî xebitandina ceribandinan, Coverlet statîstîkên xebitandinê li ser konsolê çap dike:

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 dihêle hûn bêjeyek birêkûpêk diyar bikin da ku statîstîk bistînin, ku paşê dikare di forma nîşanekê de were wergirtin. Bişkojka birêkûpêk di mîhengên peywirê de bi mifteyê tê destnîşan kirin coverage; ravekirin divê komeke girtinê hebe, nirxa wê ji nîşaneyê re were derbas kirin:

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

Li vir em statîstîkek ji rêzek bi tevheviya xetê digirin.

Pakêt û belgeyan biweşînin

Her du çalakî ji bo qonaxa paşîn a boriyê têne plansaz kirin - ji ber ku civîn û ceribandin derbas bûne, em dikarin pêşveçûnên xwe bi cîhanê re parve bikin.

Pêşîn, weşana çavkaniya pakêtê bifikirin:

Ger proje pelê veavakirina nuget tune be (nuget.config), yekî nû biafirîne: dotnet new nugetconfig

Bo çi: Dibe ku wêne ji veavakirinên gerdûnî (bikarhêner û makîneyê) re negihîje nivîsandinê. Ji bo ku em xeletiyan negirin, em bi tenê vesaziyek herêmî ya nû diafirînin û pê re dixebitin.
Ka em çavkaniyek pakêtek nû li veavakirina herêmî zêde bikin: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - Navê çavkaniya herêmî, ne krîtîk
2. url - URLa çavkaniyê ji qonaxa "Amadekirina hesaban", rûpel 6
3. organization - Navê rêxistinê di Azure DevOps de
4. gitlab variable - navê guhêrbara bi nîşana gihîştinê li GitLab hatiye zêdekirin ("Amadekirina hesaban", rûp. 11). Bi xwezayî, di forma $variableName
5. -StorePasswordInClearText - hackek ji bo derbaskirina xeletiya redkirina gihîştinê (Ez ne yê yekem im ku li ser vê rakêşanê gav bavêjim)
6. Di rewşên xeletiyan de, dibe ku lê zêde bike kêrhatî be -verbosity detailed
Şandina pakêtê ji çavkaniyê re: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Em hemî pakêtan ji pelrêça heyî dişînin, lewra *.nupkg.
2. name - ji qonaxa jorîn.
3. key - her rêzek. Di Azure DevOps de, di pencereya Connect to feed-ê de, mînak her gav rêz e az.
4. -skipduplicate - Dema ku hûn hewl bidin ku pakêtek berê ya heyî bêyî vê mifteyê bişînin, çavkanî dê xeletiyek vegerîne 409 Conflict; bi mifteyê, şandina wê were paşguh kirin.

Naha werin em çêkirina belgeyan saz bikin:

Pêşîn, di depoyê de, di şaxê master de, em projeya docfx dest pê dikin. Ji bo kirina vê yekê, emrê ji kokê bimeşînin docfx init û bi înteraktîf pîvanên sereke ji bo belgekirina avahiyê saz bikin. Danasîna hûrgulî ya sazkirina projeyê ya herî kêm vir.
1. Dema mîheng kirin, girîng e ku pelrêça derketinê diyar bike ..public - GitLab ji hêla xwerû ve naveroka peldanka gelemperî ya di koka depoyê de wekî çavkaniyek Rûpelan digire. Bo proje dê di peldankek ku di depoyê de hêlînkirî de were bicîh kirin - di rê de di astê de hilberek zêde bike.
Ka em guheztinên GitLab bişopînin.
Peywirek li veavakirina boriyê zêde bikin pages (ji bo karên weşana malperê di Rûpelên GitLab de peyva parastî ye):
1. Nivîs:
  1. nuget install docfx.console -version 2.51.0 - docfx saz bike; Versiyon ji bo ku rêyên sazkirina pakêtê rast in were destnîşan kirin.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - berhevkirina belgeyan
2. Artifactên node:

pages:
  # snip
  artifacts:
    paths:
      - public

Derbasbûna lîrîk li ser docfx

Berê, dema ku projeyek saz kir, min çavkaniya kodê ji bo belgekirinê wekî pelek çareseriyê destnîşan kir. Kêmasiya sereke ev e ku belge ji bo projeyên ceribandinê jî têne afirandin. Ger ev ne hewce be, hûn dikarin vê nirxê li ser girêkê bicîh bikin metadata.src:

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

metadata.src.src: "../" - em li gorî cîhê yek ast bilind dibin docfx.json, ji ber di şablonan de, lêgerîna dara pelrêçayê nexebite.
metadata.src.files: ["**/*.csproj"] - Nimûneyek gerdûnî, em hemî projeyên C # ji hemî pelrêçan berhev dikin.
metadata.src.exclude: ["*.tests*/**"] - Nimûneya gerdûnî, her tiştî ji peldankên pê derxe .tests Di sernavê de

Subtotal

Veavakirinek wusa hêsan dikare di nav nîv saetê de û çend fincan qehwe de were çêkirin, ku dê bihêle hûn kontrol bikin ka kod hatî çêkirin û ceribandin derbas dibin, pakêtek nû ava bikin, belgeyê nûve bikin û çavê xweşik xweş bikin. nîşaneyên di README ya projeyê de bi her daxwazek yekbûnê û şandina ji masterê re.

Dawî .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

Axaftina nîşanan

Ji ber wan, her tişt dest pê kir!

Nîşanên bi statûyên boriyê û vegirtina kodê li GitLab di mîhengên CI/CD-ê de di bloka lûleyên Gtntral de hene:

Min nîşanek bi girêdanek belgeyên li ser platformê çêkir shields.io - Li wir her tişt pir sade ye, hûn dikarin nîşana xwe biafirînin û bi karanîna daxwazek bistînin.

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

Azure DevOps Artifacts di heman demê de dihêle hûn ji bo pakêtên bi guhertoya herî dawî nîşanan biafirînin. Ji bo kirina vê yekê, di çavkaniya li ser malpera Azure DevOps de, hûn hewce ne ku ji bo pakêta hilbijartî nîşana Create bikirtînin û nîşana nîşankirinê kopî bikin:

Zêdekirina bedewiyê

Nîşandana Parçeyên Vesazkirina Hevbeş

Dema ku veavakirinê dinivîsim û di nav belgeyan de digerim, ez rastî taybetmendiyek balkêş a YAML hatim - ji nû ve karanîna perçeyan.

Wekî ku hûn ji mîhengên peywirê dibînin, ew hemî tagê hewce dikin windows li runner, û gava ku daxwazek yekbûnê ji masterê re tê şandin / afirandin (ji bilî belgekirinê) têne destpêkirin. Ka em vê yekê li perçeya ku em ê ji nû ve bikar bînin zêde bikin:

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

Û naha em dikarin parçeya ku berê di danasîna peywirê de hatî ragihandin têxin:

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

Navên perçeyan divê bi xalekê dest pê bikin, da ku wekî peywirek neyê şîrove kirin.

Guhertoya pakêtê

Dema ku pakêtek diafirîne, berhevkar guheztinên rêza fermanê kontrol dike, û di nebûna wan de, pelên projeyê; gava ku ew nodek Versiyonek dibîne, ew nirxa xwe wekî guhertoya pakêta ku tê çêkirin digire. Derket holê ku ji bo ku hûn pakêtek bi guhertoyek nû ava bikin, hûn hewce ne ku wê di pelê projeyê de nûve bikin an jî wekî argumana rêzika fermanê derbas bikin.

Werin em navnîşek Daxwazek din lê zêde bikin - bila du hejmarên piçûk ên di guhertoyê de bibin sal û dîroka avakirina pakêtê, û guhertoyên pêşdibistanê lê zêde bikin. Bê guman, hûn dikarin vê daneyê li pelê projeyê zêde bikin û berî her radestkirinê kontrol bikin - lê hûn dikarin wê di rê de jî bikin, guhertoya pakêtê ji çarçovê berhev bikin û wê di nav argumana xeta fermanê re derbas bikin.

Ka em bipejirînin ku heke peyama commit xêzek mîna heye release (v./ver./version) <version number> (rev./revision <revision>)?, wê hingê em ê guhertoya pakêtê ji vê rêzê bigirin, wê bi dîroka heyî re temam bikin û wekî argumanek ji fermanê re derbas bikin. dotnet pack. Di nebûna rêzek de, em ê bi tenê pakêtê kom nekin.

Skrîpta jêrîn vê pirsgirêkê çareser dike:

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

Zêdekirina skrîptekê li karekî pack and deploy job û berhevkirina pakêtan bi hişkî di hebûna rêzek diyarkirî de di peyama commit de bişopînin.

Tevahî

Piştî ku bi qasî nîv saet an saetek bi nivîsandina vesazkirinê, debugkirina di powershell-a herêmî de û, dibe ku, çend destpêkirinên neserkeftî derbas kirin, me ji bo otomatîkkirina karên rûtîn mîhengek hêsan girt.

Bê guman, GitLab CI / CD ji ya ku piştî xwendina vê rêbernameyê xuya dike pir berfireh û piralî ye - ew qet ne rast e. Li wir jî Auto DevOps e, destûr dide

bixweber serîlêdanên xwe kifş bikin, ava bikin, ceribandin, bicîh bikin û bişopînin

Naha pîlan ew e ku boriyek ji bo bicîhkirina serîlêdanên li Azure, bi karanîna Pulumi û bixweber destnîşankirina jîngeha armancê, ku dê di gotara pêş de were vegirtin, mîheng bikin.

Source: www.habr.com