🥇Mwongozo wa CI/CD katika GitLab kwa Mtoto (Karibu) Mpya kabisa

Au jinsi ya kupata beji nzuri za mradi wako katika jioni moja ya usimbaji tulivu

Pengine, kila msanidi ambaye ana angalau mradi mmoja wa pet wakati fulani ana itch kwa beji nzuri na statuses, chanjo ya kanuni, matoleo ya mfuko katika nuget ... Na itch hii imeniongoza kuandika makala hii. Katika mchakato wa kujiandaa kuiandika, nilipata uzuri huu katika moja ya miradi yangu:

Makala haya yatashughulikia usanidi wa msingi wa ujumuishaji na uwasilishaji wa mradi wa maktaba ya darasa la .Net Core katika GitLab, uchapishaji wa hati kwa Kurasa za GitLab na kutuma vifurushi vilivyokusanywa kwa mpasho wa kibinafsi katika Azure DevOps.

Msimbo wa VS ulio na kiendelezi ulitumika kama mazingira ya ukuzaji Mtiririko wa kazi wa GitLab (kuthibitisha faili ya mipangilio moja kwa moja kutoka kwa mazingira ya ukuzaji).

Utangulizi mfupi

CD ni wakati ulisukuma tu, lakini mteja tayari amepoteza kila kitu?

CI/CD ni nini na kwa nini inahitajika? Unaweza kuitafuta kwa urahisi. Pata hati kamili juu ya kusanidi mabomba katika GitLab pia rahisi. Hapa nitaelezea kwa ufupi na, ikiwezekana, bila dosari, kuelezea mchakato wa mfumo kutoka kwa mtazamo wa ndege:

msanidi hutuma ahadi kwenye hazina, huunda ombi la kuunganisha kupitia tovuti, au kwa njia nyingine kuzindua bomba kwa njia ya wazi au isiyo wazi,
kutoka kwa usanidi, kazi zote huchaguliwa ambazo hali zao huruhusu kuzinduliwa katika muktadha fulani,
kazi zinapangwa kulingana na hatua zao,
hatua zinatekelezwa kwa zamu - i.e. sambamba kazi zote za hatua hii zimekamilika,
ikiwa hatua itashindwa (i.e. angalau moja ya kazi ya hatua itashindwa) - bomba litasimama (karibu kila wakati),
ikiwa hatua zote zimekamilika kwa ufanisi, bomba inachukuliwa kuwa imefanikiwa.

Kwa hivyo tunayo:

bomba ni seti ya kazi zilizopangwa katika hatua ambazo unaweza kukusanyika, kujaribu, nambari ya kifurushi, kupeleka mkusanyiko uliomalizika kwa huduma ya wingu, nk.
jukwaa (hatua) - kitengo cha shirika la bomba, ina kazi 1+,
kazi (kazi) ni kitengo cha kazi katika bomba. Inajumuisha hati (inahitajika), masharti ya uzinduzi, mipangilio ya uchapishaji / kuhifadhi vizalia vya programu na mengi zaidi.

Ipasavyo, kazi wakati wa kusanidi CI/CD inakuja kuunda seti ya kazi zinazotekeleza vitendo vyote muhimu vya kukusanyika, kupima na kuchapisha msimbo na mabaki.

Kabla ya kuanza: kwa nini?

Kwa nini GitLab?

Kwa sababu wakati hitaji lilipoibuka la kuunda hazina za kibinafsi za miradi ya kipenzi, zililipwa kwenye GitHub, na nilikuwa na pupa. Hifadhi zimekuwa huru, lakini kwa sasa hii sio sababu nzuri ya mimi kuhamia GitHub.

Kwa nini sio Mabomba ya Azure DevOps?

Kwa sababu usanidi ni rahisi - hauitaji hata ujuzi wa mstari wa amri. Kuunganishwa na watoa huduma wa git wa nje - katika kubofya mara kadhaa, uingizaji wa funguo za SSH kwa ajili ya kutuma ahadi kwenye hazina - pia, bomba husanidiwa kwa urahisi hata bila kiolezo.

Nafasi ya kuanza: kile unacho na unachotaka

Tuna:

hazina katika GitLab.

Tunataka:

mkusanyiko otomatiki na upimaji kwa kila ombi la kuunganisha,
ujenzi wa vifurushi kwa kila ombi la kuunganisha na kusukuma kwa bwana, mradi kuna mstari fulani katika ujumbe wa ahadi,
kutuma vifurushi vilivyokusanywa kwa malisho ya kibinafsi katika Azure DevOps,
mkusanyiko wa nyaraka na uchapishaji katika Kurasa za GitLab,
beji!11

Mahitaji yaliyofafanuliwa yanafaa kwa kawaida katika modeli ifuatayo ya bomba:

Hatua ya 1 - mkusanyiko
- Tunakusanya msimbo, kuchapisha faili za pato kama mabaki
Hatua ya 2 - kupima
- Tunapokea vizalia vya programu kutoka kwa hatua ya uundaji, kufanya majaribio, kukusanya data ya chanjo ya msimbo
Hatua ya 3 - kutuma
- Kazi ya 1 - kukusanya kifurushi cha nuget na utume kwa Azure DevOps
- Kazi ya 2 - tunakusanya tovuti kutoka kwa xmldoc katika msimbo wa chanzo na kuichapisha katika Kurasa za GitLab

Hebu kuanza!

Kukusanya usanidi

Kuandaa hesabu

Unda akaunti ndani Microsoft Azure
Enda kwa Azure DevOps
Unda mradi mpya
1. Jina - yoyote
2. Kuonekana - yoyote
Unapobofya kitufe cha Unda, mradi utaundwa na utachukuliwa kwenye ukurasa wake. Kwenye ukurasa huu unaweza kuzima huduma zisizo za lazima kwa kwenda kwa mipangilio ya miradi (kiungo cha chini kwenye orodha iliyo upande wa kushoto -> Muhtasari -> Kizuizi cha Huduma za Azure DevOps)
Nenda kwenye Atrifacts, bofya Unda mipasho
1. Ingiza jina la chanzo
2. Chagua mwonekano
3. Ondoa uteuzi kwenye kisanduku Jumuisha vifurushi kutoka kwa vyanzo vya kawaida vya ummaili chanzo kisigeuke kuwa dampo la takataka la clone ya nuget
Bofya Unganisha ili kulisha, chagua Visual Studio, nakili Chanzo kutoka kwa kizuizi cha Kuweka Mashine
Nenda kwa mipangilio ya akaunti, chagua Tokeni ya Ufikiaji wa Kibinafsi
Unda tokeni mpya ya ufikiaji
1. Jina - kiholela
2. Shirika - sasa
3. Muda wa uhalali: upeo wa mwaka 1
4. Upeo - Ufungaji/Soma & Andika
Nakili ishara iliyoundwa - baada ya kufunga dirisha la modal thamani haitapatikana
Nenda kwa mipangilio ya hazina katika GitLab, chagua mipangilio ya CI/CD
Panua kizuizi cha Vigezo na uongeze mpya
1. Jina - yoyote bila nafasi (itapatikana kwenye ganda la amri)
2. Thamani ni tokeni ya ufikiaji kutoka kwa hatua ya 9
3. Chagua mabadiliko ya Mask

Hii inakamilisha usanidi wa awali.

Kuandaa mfumo wa usanidi

Kwa chaguo-msingi, faili inayotumiwa kusanidi CI/CD katika GitLab ni .gitlab-ci.yml kutoka kwa mzizi wa hazina. Unaweza kusanidi njia maalum kwa faili hii katika mipangilio ya uhifadhi, lakini katika kesi hii sio lazima.

Kama inavyoonekana kutoka kwa kiendelezi, faili ina usanidi katika umbizo YAML. Nyaraka zinaelezea kwa undani ni funguo gani zinaweza kuwa katika kiwango cha juu cha usanidi, na katika kila ngazi zilizowekwa.

Kwanza, hebu tuongeze kwenye faili ya usanidi kiungo cha picha ya docker ambayo kazi zitatekelezwa. Ili kufanya hivyo tunapata Ukurasa wa picha za Net Core kwenye Docker Hub. Katika GitHub Kuna mwongozo wa kina juu ya picha gani ya kuchagua kwa kazi tofauti. Picha iliyo na .Net Core 3.1 inafaa kwa ajili yetu kuunda, kwa hivyo jisikie huru kuiongeza kama mstari wa kwanza kwenye usanidi.

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

Sasa, unapoanza bomba, picha maalum itapakuliwa kutoka kwenye hifadhi ya picha ya Microsoft, ambayo kazi zote kutoka kwa usanidi zitatekelezwa.

Hatua inayofuata ni kuongeza hatuaya. Kwa msingi, GitLab inafafanua hatua 5:

.pre - kutekelezwa kwa hatua zote,
.post - kutekelezwa baada ya hatua zote,
build - kwanza baada .pre jukwaa,
test - awamu ya pili,
deploy - hatua ya tatu.

Hakuna kinachokuzuia kuzitangaza kwa uwazi, hata hivyo. Mpangilio ambao hatua zimeorodheshwa huathiri mpangilio ambao zimekamilika. Kwa ukamilifu, wacha tuongeze kwenye usanidi:

stages:
  - build
  - test
  - deploy

Kwa utatuzi, ni mantiki kupata habari kuhusu mazingira ambayo kazi zinatekelezwa. Hebu tuongeze seti ya kimataifa ya amri ambazo zitatekelezwa kabla ya kila kazi kutumia before_script:

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

Inabakia kuongeza angalau kazi moja ili wakati ahadi zinatumwa, bomba itaanza. Kwa sasa, wacha tuongeze kazi tupu kwa onyesho:

dummy job:
  script:
    - echo ok

Tunaanza uthibitishaji, kupata ujumbe kwamba kila kitu ni sawa, jitoe, sukuma, angalia matokeo kwenye tovuti... Na tunapata hitilafu ya hati - bash: .PSVersion: command not found. WTF?

Kila kitu ni cha kimantiki - kwa chaguo-msingi, wakimbiaji (wanaohusika na utekelezaji wa hati za kazi na zinazotolewa na GitLab) matumizi. bash kutekeleza amri. Unaweza kurekebisha hii kwa kuonyesha wazi katika maelezo ya kazi ni vitambulisho gani mkimbiaji wa bomba anapaswa kuwa nazo:

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

Kubwa! Bomba linaendelea sasa.

Msomaji makini, akirudia hatua hizi, ataona kwamba kazi imekamilika kwenye hatua test, ingawa hatukutaja hatua. Kama unavyoweza kudhani, test ni hatua ya msingi.

Wacha tuendelee kuunda kiunzi cha usanidi kwa kuongeza kazi zote zilizoelezewa hapo juu:

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

Tulipata bomba lisilofanya kazi haswa, lakini ni sahihi.

Kuweka vichochezi

Kwa sababu ya ukweli kwamba hakuna vichungi vya trigger vilivyoainishwa kwa kazi yoyote, bomba litafanya kikamilifu kutekelezwa kila wakati ahadi zinatumwa kwenye hazina. Kwa kuwa hii sio tabia inayotakikana kwa ujumla, tutasanidi vichungi vya vichochezi vya kazi.

Vichujio vinaweza kusanidiwa katika miundo miwili: pekee/isipokuwa и sheria. Kwa kifupi, only/except hukuruhusu kusanidi vichungi kwa vichochezi (merge_request, kwa mfano - husanidi kazi ya kutekelezwa kila wakati ombi la kuunganisha linapoundwa na kila wakati ahadi zinatumwa kwa tawi ambalo ni chanzo katika ombi la kuunganisha) na majina ya matawi (pamoja na kutumia misemo ya kawaida); rules hukuruhusu kubinafsisha seti ya masharti na, kwa hiari, kubadilisha hali ya utekelezaji wa kazi kulingana na mafanikio ya kazi zilizopita (when katika GitLab CI/CD).

Hebu tukumbuke seti ya mahitaji - kusanyiko na kupima tu kwa maombi ya kuunganisha, ufungaji na kutuma kwa Azure DevOps - kwa maombi ya kuunganisha na kusukuma kwa bwana, kizazi cha nyaraka - kwa kusukuma kwa bwana.

Kwanza, wacha tuanzishe kazi ya kusanyiko la nambari kwa kuongeza sheria ya kichochezi ambayo husababisha ombi la kuunganisha tu:

build job:
  # snip
  only:
    - merge_request

Sasa hebu tusanidi kazi ya ufungaji ili kuanzisha ombi la kuunganisha na kuongeza ahadi kwa bwana:

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

Kama unaweza kuona, kila kitu ni rahisi na moja kwa moja.

Unaweza pia kusanidi kazi ili kuanzisha tu ikiwa ombi la kuunganisha limeundwa na lengo maalum au tawi la chanzo:

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

Katika hali inaweza kutumika vigezo vilivyoorodheshwa hapa; kanuni rules haiendani na kanuni only/except.

Inasanidi Uhifadhi wa Vizalia vya programu

Wakati kazi inaendelea build job tutakuwa na vizalia vya ujenzi vilivyoundwa ambavyo vinaweza kutumika tena katika kazi zinazofuata. Ili kufanya hivyo, unahitaji kuongeza njia za usanidi wa kazi, faili ambazo zitahitaji kuhifadhiwa na kutumika tena katika kazi zinazofuata, kwa ufunguo. artifacts:

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

Njia zinaunga mkono kadi-mwitu, ambayo kwa hakika hurahisisha kuweka.

Ikiwa kazi itaunda mabaki, basi kila kazi inayofuata itaweza kuzifikia - zitakuwa ziko kwenye njia zile zile zinazohusiana na mzizi wa hazina ambao zilikusanywa kutoka kwa kazi ya asili. Vipengee pia vinapatikana kwa kupakuliwa kwenye tovuti.

Kwa kuwa sasa tuna mfumo wa usanidi tayari (na kuthibitishwa), tunaweza kuendelea na kuandika hati za kazi.

Tunaandika maandishi

Pengine, mara moja, katika galaxy mbali, miradi ya ujenzi (ikiwa ni pamoja na .net ndio) kutoka kwa mstari wa amri ilikuwa maumivu. Sasa unaweza kukusanya, kujaribu na kuchapisha mradi katika timu 3:

dotnet build
dotnet test
dotnet pack

Kwa kawaida, kuna baadhi ya nuances kutokana na ambayo sisi magumu amri kiasi fulani.

Tunataka kutolewa, sio utatuzi, jenga, kwa hivyo tunaongeza kwa kila amri -c Release
Tunapojaribu, tunataka kukusanya data kuhusu uwekaji wa misimbo, kwa hivyo tunahitaji kuunganisha kichanganuzi cha chanjo kwenye maktaba za majaribio:
1. Kifurushi kinapaswa kuongezwa kwa maktaba zote za majaribio coverlet.msbuild: dotnet add package coverlet.msbuild kutoka kwa folda ya mradi
2. Ongeza kwa amri ya uzinduzi wa jaribio /p:CollectCoverage=true
3. Hebu tuongeze ufunguo wa usanidi wa kazi ya majaribio ili kupata matokeo ya chanjo (tazama hapa chini)
Wakati wa kufunga nambari kwenye vifurushi vya nuget, tutaweka saraka ya pato kwa vifurushi: -o .

Kukusanya data ya chanjo ya msimbo

Baada ya kufanya majaribio, Coverlet huonyesha takwimu za uzinduzi kwenye kiweko:

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 hukuruhusu kubainisha usemi wa kawaida ili kupata takwimu, ambazo zinaweza kupatikana kwa njia ya beji. Usemi wa kawaida umebainishwa katika mipangilio ya kazi na ufunguo coverage; usemi lazima uwe na kikundi cha kukamata, ambacho thamani yake itahamishiwa kwa beji:

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

Hapa tunapata takwimu kutoka kwa mstari wenye chanjo ya jumla kwa mistari.

Tunachapisha vifurushi na nyaraka

Tuna hatua zote mbili zilizowekwa kwa hatua ya mwisho ya bomba - kwa kuwa mkusanyiko na majaribio yamepita, tunaweza kushiriki maendeleo yetu na ulimwengu.

Kwanza, hebu tuangalie uchapishaji kwa chanzo cha kifurushi:

Ikiwa mradi hauna faili ya usanidi wa nuget (nuget.config), unda mpya: dotnet new nugetconfig

Kwa nini: Picha inaweza kukosa ufikiaji wa maandishi kwa usanidi wa kimataifa (mtumiaji na mashine). Ili tusipate makosa, tutaunda tu usanidi mpya wa ndani na kufanya kazi nayo.
Wacha tuongeze chanzo kipya cha kifurushi kwenye usanidi wa ndani: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - jina la chanzo cha ndani, sio muhimu
2. url - URL ya chanzo kutoka hatua ya "Kuandaa akaunti", hatua ya 6
3. organization - jina la shirika katika Azure DevOps
4. gitlab variable — jina la kigezo chenye tokeni ya ufikiaji iliyoongezwa kwa GitLab (“Kutayarisha akaunti”, uk. 11). Kwa kawaida, katika muundo $variableName
5. -StorePasswordInClearText - udukuzi wa kupita kosa lililokataliwa la ufikiaji (Mimi sio wa kwanza kukanyaga safu hii)
6. Katika kesi ya makosa inaweza kuwa muhimu kuongeza -verbosity detailed
Tunatuma kifurushi kwa chanzo: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Tunatuma vifurushi vyote kutoka kwa saraka ya sasa, kwa hivyo *.nupkg.
2. name - kutoka hatua ya juu.
3. key - mstari wowote. Katika Azure DevOps, kwenye dirisha la Unganisha kulisha, mstari wa mfano ni daima az.
4. -skipduplicate - ukijaribu kutuma kifurushi kilichopo tayari bila ufunguo huu, chanzo kitarudisha hitilafu 409 Conflict; na ufunguo, kutuma kutarukwa.

Sasa hebu tuanzishe uundaji wa nyaraka:

Kuanza na, katika hazina, katika tawi kuu, tunaanzisha mradi wa docfx. Ili kufanya hivyo, unahitaji kuendesha amri kutoka kwa mizizi docfx init na kwa maingiliano weka vigezo muhimu vya kukusanya nyaraka. Maelezo ya kina ya usanidi mdogo wa mradi hapa.
1. Wakati wa kuanzisha, ni muhimu kutaja saraka ya pato ..public - GitLab kwa chaguo-msingi huchukua yaliyomo kwenye folda ya umma kwenye mzizi wa hazina kama chanzo cha Kurasa. Kwa sababu mradi utapatikana kwenye folda iliyowekwa kwenye ghala - ongeza njia ya kutoka kwa kiwango kinachofuata cha njia.
Wacha tusukuma mabadiliko kwa GitLab.
Ongeza kazi kwenye usanidi wa bomba pages (neno lililohifadhiwa kwa kazi za uchapishaji wa tovuti katika Kurasa za GitLab):
1. Hati:
  1. nuget install docfx.console -version 2.51.0 - kufunga docfx; Toleo hutolewa ili kuhakikisha kuwa njia za usakinishaji wa kifurushi ni sahihi.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - kukusanya nyaraka
2. Nodi ya vizalia vya programu:

pages:
  # snip
  artifacts:
    paths:
      - public

Kicheko cha sauti kuhusu docfx

Hapo awali, wakati wa kuanzisha mradi, nilitaja chanzo cha msimbo wa nyaraka kama faili ya suluhisho. Hasara kuu ni kwamba nyaraka pia zinaundwa kwa ajili ya miradi ya mtihani. Ikiwa hii sio lazima, unaweza kuweka thamani hii kwa node metadata.src:

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

metadata.src.src: "../" - panda ngazi moja juu ukilinganisha na eneo docfx.json, kwa sababu Kutafuta mti wa saraka haifanyi kazi katika mifumo.
metadata.src.files: ["**/*.csproj"] - muundo wa kimataifa, tunakusanya miradi yote ya C# kutoka saraka zote.
metadata.src.exclude: ["*.tests*/**"] - muundo wa kimataifa, usiondoe kila kitu kutoka kwa folda na .tests Katika kichwa

jumla ndogo

Usanidi huu rahisi unaweza kuunda kwa nusu saa na vikombe kadhaa vya kahawa, ambayo itakuruhusu kuangalia na kila ombi la kuunganisha na kuituma kwa bwana kwamba nambari inaundwa na majaribio yanapita, kukusanya mpya. kifurushi, kusasisha hati na kufurahisha jicho na beji nzuri katika mradi wa README.

Mwisho .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

Akizungumza ya beji

Ilikuwa ni kwa ajili yao kwamba kila kitu kilianzishwa!

Beji zilizo na hali ya bomba na ufunikaji wa msimbo zinapatikana katika GitLab katika mipangilio ya CI/CD katika kizuizi cha mabomba ya Gtntral:

Niliunda beji yenye kiungo cha hati kwenye jukwaa ngao.io - kila kitu ni sawa kabisa hapo, unaweza kuunda beji yako mwenyewe na kuipokea kwa kutumia ombi.

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

Azure DevOps Artifacts pia hukuruhusu kuunda beji za vifurushi vinavyoonyesha toleo jipya zaidi. Ili kufanya hivyo, kwenye chanzo kwenye tovuti ya Azure DevOps, unahitaji kubofya kwenye Unda beji ya kifurushi kilichochaguliwa na unakili alama ya alama:

Kuongeza uzuri

Tunaangazia vipande vya usanidi vya kawaida

Wakati nikiandika usanidi na kutafuta kupitia nyaraka, nilikutana na kipengele cha kuvutia cha YAML - kutumia tena vipande.

Kama unaweza kuona kutoka kwa mipangilio ya kazi, zote zinahitaji lebo windows kutoka kwa mkimbiaji, na husababishwa wakati wa kutuma ombi la kuunganisha kwa bwana / kuunda ombi la kuunganisha (isipokuwa kwa nyaraka). Wacha tuongeze hii kwenye kipande ambacho tutatumia tena:

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

Na sasa tunaweza kuingiza kipande kilichotangazwa hapo awali kwenye maelezo ya kazi:

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

Majina ya vipande lazima yaanze na kipindi ili kuepuka kutafsiriwa kama kazi.

Toleo la kifurushi

Wakati wa kuunda mfuko, mkusanyaji huangalia swichi za mstari wa amri, na bila kutokuwepo, faili za mradi; Baada ya kupata nodi ya Toleo, inachukua thamani yake kama toleo la kifurushi kinachojengwa. Inabadilika kuwa ili kuunda kifurushi na toleo jipya, unahitaji kusasisha kwenye faili ya mradi au kuipitisha kama hoja ya safu ya amri.

Wacha tuongeze matakwa mengine - acha nambari mbili za chini zaidi katika toleo ziwe mwaka na tarehe ya kifurushi kujengwa, na ongeza matoleo ya kutolewa mapema. Bila shaka, unaweza kuongeza data hii kwenye faili ya mradi na kuiangalia kabla ya kila uwasilishaji - lakini unaweza pia kufanya hivyo katika bomba, kukusanya toleo la kifurushi kutoka kwa muktadha na kupitisha hoja ya mstari wa amri.

Wacha tukubaliane kwamba ikiwa ujumbe wa ahadi una mstari kama release (v./ver./version) <version number> (rev./revision <revision>)?, basi tutachukua toleo la kifurushi kutoka kwa mstari huu, tuongeze na tarehe ya sasa na tuipitishe kama hoja kwa amri. dotnet pack. Kwa kukosekana kwa mstari, hatutakusanya kifurushi.

Nakala ifuatayo inasuluhisha shida hii:

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

Kuongeza hati kwenye kazi pack and deploy job na uangalie mkusanyiko wa vifurushi madhubuti ikiwa kuna mstari uliopeanwa katika ujumbe wa ahadi.

Katika jumla ya

Baada ya kutumia takribani nusu saa hadi saa moja kuandika usanidi, kurekebisha hitilafu katika ganda la nguvu la ndani na, ikiwezekana, uzinduzi kadhaa ambao haukufanikiwa, tulipokea usanidi rahisi wa uwekaji kazi za kawaida kiotomatiki.

Kwa kweli, GitLab CI/CD ni pana zaidi na ina mambo mengi kuliko inavyoweza kuonekana baada ya kusoma mwongozo huu - hiyo si kweli hata kidogo. Huko hata Auto DevOps ndiyokuruhusu

tambua kiotomatiki, jenga, jaribu, peleka na ufuatilie programu zako kiotomatiki

Sasa mipango ni kusanidi bomba la kupeleka programu katika Azure, kwa kutumia Pulumi na kugundua kiotomatiki mazingira lengwa, ambayo yatashughulikiwa katika makala inayofuata.

Chanzo: mapenzi.com

Mwongozo wa CI/CD katika GitLab kwa mwanzilishi (karibu) kabisa