🥇GitLab жүйесіндегі CI/CD бойынша (дерлік) толық бастаушыға арналған нұсқаулық

Немесе жеңіл кодтаудың бір кешінде жобаңызға әдемі белгілерді қалай алуға болады

Мүмкін, кез-келген уақытта кем дегенде бір үй жануарлары жобасы бар әрбір әзірлеуші мәртебелері, кодты қамтуы, nuget ішіндегі пакеттік нұсқалары бар әдемі бейдждерге қышуы бар ... Және бұл қышу мені осы мақаланы жазуға итермеледі. Оны жазуға дайындалу барысында мен бұл сұлулықты жобаларымның бірінде алдым:

Бұл мақала GitLab жүйесіндегі .Net Core класс кітапханасы жобасы үшін үздіксіз біріктірудің және жеткізудің негізгі орнатуын, құжаттаманы GitLab беттеріне жариялауды және жиналған бумаларды Azure DevOps жүйесіндегі жеке арнаға жіберуді қарастырады.

Кеңейтімі бар VS коды әзірлеу ортасы ретінде пайдаланылды GitLab жұмыс процесі (параметрлер файлын әзірлеу ортасынан тікелей тексеру үшін).

Қысқаша кіріспе

CD - сіз жай ғана итеріп жіберген кезде, бірақ клиент бәрін жоғалтып алды ма?

CI/CD дегеніміз не және ол не үшін қажет? GitLab жүйесінде құбырларды орнату бойынша толық құжаттаманы табыңыз да оңай. Мұнда мен қысқаша және мүмкіндігінше кемшіліктерсіз жүйенің процесін құс көзімен сипаттаймын:

әзірлеуші репозиторийге міндеттеме жібереді, веб-сайт арқылы біріктіру сұрауын жасайды, немесе басқа жолмен тікелей немесе жанама түрде құбырды іске қосады,
конфигурациядан шарттары берілген контексте іске қосуға мүмкіндік беретін барлық тапсырмалар таңдалады,
тапсырмалар кезеңдері бойынша ұйымдастырылады,
кезеңдері кезекпен орындалады - яғни. параллель осы кезеңнің барлық тапсырмалары орындалды,
егер кезең сәтсіз болса (яғни кезеңнің кем дегенде біреуі орындалмаса) - құбыр тоқтайды (әрдайым дерлік),
егер барлық кезеңдер сәтті аяқталса, құбыр сәтті деп саналады.

Осылайша бізде:

конвейер – сіз құрастыруға, сынауға, бума кодын алуға, дайын жинақты бұлттық қызметке орналастыруға және т.б. болатын кезеңдерге ұйымдастырылған тапсырмалар жиынтығы.
кезең (кезеңі) — құбырды ұйымдастыру бірлігі, 1+ тапсырманы қамтиды,
тапсырма (жұмыс) құбырдағы жұмыс бірлігі болып табылады. Сценарийден (міндетті), іске қосу шарттарынан, артефактілерді жариялау/кэштеу параметрлерінен және т.б. тұрады.

Тиісінше, CI/CD орнату кезіндегі тапсырма код пен артефактілерді құрастыру, сынау және жариялау үшін барлық қажетті әрекеттерді жүзеге асыратын тапсырмалар жинағын құруға келеді.

Бастамас бұрын: неге?

Неліктен GitLab?

Өйткені үй жануарларына арналған жобалар үшін жеке репозиторийлерді құру қажеттілігі туындаған кезде, олар GitHub-та төленді, мен ашкөз болдым. Репозиторийлер тегін болды, бірақ әзірге бұл менің GitHub-қа көшуім үшін жеткілікті себеп емес.

Неліктен Azure DevOps құбырлары емес?

Орнату қарапайым болғандықтан, сізге пәрмен жолы туралы білім қажет емес. Сыртқы git провайдерлерімен интеграция - бірнеше рет басу, репозиторийге міндеттеме жіберу үшін SSH кілттерін импорттау - сонымен қатар құбыр желісі үлгісіз де оңай конфигурацияланады.

Бастапқы ұстаным: сізде не бар және сіз не қалайсыз

Бізде:

GitLab репозиторийі.

Біз қалаймыз:

әрбір біріктіру сұрауы үшін автоматты құрастыру және сынау,
әрбір біріктіру сұрауы үшін пакеттерді құру және міндеттеме хабарында белгілі бір жол болған жағдайда шеберге итеру,
жиналған пакеттерді Azure DevOps жүйесіндегі жеке арнаға жіберу,
GitLab беттерінде құжаттарды жинау және жариялау,
төсбелгілер!11

Сипатталған талаптар келесі құбыр үлгісіне табиғи түрде сәйкес келеді:

1 кезең – құрастыру
- Біз кодты жинаймыз, шығыс файлдарын артефакт ретінде жариялаймыз
2 кезең – тестілеу
- Біз құрастыру кезеңінен артефакттарды аламыз, сынақтарды орындаймыз, кодты қамту деректерін жинаймыз
3 кезең – жіберу
- 1-тапсырма - nuget бумасын жинап, Azure DevOps жүйесіне жіберіңіз
- 2-тапсырма - сайтты xmldoc-тен бастапқы кодта жинаймыз және оны GitLab беттерінде жариялаймыз

Бастайық!

Конфигурацияны құрастыру

Есептерді дайындау

ішінде тіркелгі жасаңыз Microsoft Azure
Бару Azure DevOps
Жаңа жоба жасаңыз
1. Аты - кез келген
2. Көріну - кез келген
Жасау түймешігін басқан кезде жоба құрылады және сіз оның бетіне өтесіз. Бұл бетте жоба параметрлеріне өту арқылы қажет емес мүмкіндіктерді өшіруге болады (сол жақтағы тізімдегі төменгі сілтеме -> Шолу -> Azure DevOps Services блогы)
Атрифакттарға өтіп, Арна жасау түймесін басыңыз
1. Дереккөз атын енгізіңіз
2. Көрінуді таңдаңыз
3. Құсбелгіні алып тастаңыз Жалпыға ортақ көздерден алынған бумаларды қосыңызкөзі nuget клонының қоқыс үйіндісіне айналмауы үшін
Арнаға қосылу түймешігін басыңыз, Visual Studio тармағын таңдаңыз, Machine Setup блогынан көзді көшіріңіз
Тіркелгі параметрлеріне өтіп, Жеке қол жеткізу белгісін таңдаңыз
Жаңа рұқсат белгісін жасаңыз
1. Атауы - ерікті
2. Ұйымдастыру – ағымдағы
3. Жарамдылық мерзімі: ең көбі 1 жыл
4. Қолдану аясы - орау/оқу және жазу
Құрылған таңбалауышты көшіру - модальды терезені жапқаннан кейін мән қолжетімді болмайды
GitLab репозиторий параметрлеріне өтіп, CI/CD параметрлерін таңдаңыз
Айнымалылар блогын кеңейтіп, жаңасын қосыңыз
1. Атау - бос орынсыз кез келген (пәрмен қабығында қолжетімді болады)
2. Мән 9-қадамдағы қатынас белгісі болып табылады
3. Маска айнымалысын таңдаңыз

Бұл алдын ала орнатуды аяқтайды.

Конфигурация құрылымын дайындау

Әдепкі бойынша, GitLab жүйесінде CI/CD конфигурациялау үшін пайдаланылатын файл .gitlab-ci.yml репозиторийдің түбірінен. Репозитарий параметрлерінде осы файлға реттелетін жолды конфигурациялауға болады, бірақ бұл жағдайда бұл қажет емес.

Кеңейтімнен көрініп тұрғандай, файл пішімдегі конфигурацияны қамтиды YAML. Құжаттама конфигурацияның жоғарғы деңгейінде және кірістірілген деңгейлердің әрқайсысында қандай кілттерді қамтуға болатынын егжей-тегжейлі сипаттайды.

Алдымен конфигурация файлына тапсырмалар орындалатын докер кескініне сілтеме қосамыз. Мұны істеу үшін біз табамыз Docker Hub жүйесіндегі .Net Core кескіндер беті. The GitHub Әртүрлі тапсырмалар үшін қандай кескінді таңдау керектігі туралы егжей-тегжейлі нұсқаулық бар. .Net Core 3.1 нұсқасы бар кескін бізге құрастыруға жарамды, сондықтан оны конфигурацияға бірінші жол ретінде қосуға болады.

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

Енді конфигурацияны іске қосқан кезде көрсетілген кескін Microsoft кескін репозиторийінен жүктеледі, онда конфигурацияның барлық тапсырмалары орындалады.

Келесі қадам - қосу кезеңіның. Әдепкі бойынша GitLab 5 кезеңді анықтайды:

.pre - барлық кезеңдер бойынша жүзеге асырылады,
.post - барлық кезеңдерден кейін орындалады;
build - бірінші кейін .pre кезең,
test - екінші кезең,
deploy - үшінші кезең.

Дегенмен, оларды анық жариялауға ештеңе кедергі келтірмейді. Қадамдардың тізімделу реті олардың орындалу ретіне әсер етеді. Толық болу үшін конфигурацияға қосайық:

stages:
  - build
  - test
  - deploy

Түзету үшін тапсырмалар орындалатын орта туралы ақпаратты алу мағынасы бар. Әрбір тапсырманы қолданар алдында орындалатын пәрмендердің жаһандық жинағын қосамыз before_script:

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

Тапсырмалар жіберілген кезде құбыр іске қосылуы үшін кем дегенде бір тапсырманы қосу қалады. Әзірге демонстрация үшін бос тапсырманы қосамыз:

dummy job:
  script:
    - echo ok

Біз валидацияны бастаймыз, бәрі жақсы екендігі туралы хабарлама аламыз, орындаймыз, итереміз, сайттағы нәтижелерді қараймыз... Және біз сценарий қатесін аламыз - bash: .PSVersion: command not found. WTF?

Барлығы логикалық - әдепкі бойынша жүгірушілер (тапсырма сценарийлерін орындауға жауапты және GitLab қамтамасыз етеді) пайдаланады bash командаларды орындау үшін. Тапсырма сипаттамасында орындалатын конвейердің іске қосушысында қандай тегтер болуы керектігін нақты көрсету арқылы мұны түзете аласыз:

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

Тамаша! Қазір құбыр жүріп жатыр.

Мұқият оқырман осы қадамдарды қайталай отырып, тапсырманың кезеңде орындалғанын байқайды test, дегенмен біз кезеңді нақтыламадық. Сіз болжағандай, test әдепкі қадам болып табылады.

Жоғарыда сипатталған барлық тапсырмаларды қосу арқылы конфигурация қаңқасын жасауды жалғастырайық:

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

Бізде өте функционалды емес, бірақ дұрыс құбыр алдық.

Триггерлерді орнату

Тапсырмалардың ешқайсысы үшін триггер сүзгілері көрсетілмегендіктен, құбыр болады толық репозиторийге міндеттеме жіберілген сайын орындалады. Бұл жалпы қалаған әрекет емес болғандықтан, біз тапсырмалар үшін триггер сүзгілерін конфигурациялаймыз.

Сүзгілерді екі форматта конфигурациялауға болады: тек/басқа и Ережелер. Қысқасын айтқанда, only/except триггерлер бойынша сүзгілерді конфигурациялауға мүмкіндік береді (merge_request, мысалы - біріктіру сұрауы жасалған сайын және біріктіру сұрауындағы дереккөз болып табылатын филиалға міндеттеме жіберілген сайын орындалатын тапсырманы теңшейді) және тармақ атаулары (соның ішінде тұрақты өрнектерді пайдалану); rules шарттар жинағын теңшеуге және міндетті түрде алдыңғы тапсырмалардың сәттілігіне байланысты тапсырманы орындау шартын өзгертуге мүмкіндік береді (when GitLab CI/CD ішінде).

Талаптар жиынтығын еске түсірейік - тек біріктіру сұраулары үшін құрастыру және тестілеу, Azure DevOps-қа буып-түю және жіберу - біріктіру сұраулары мен шеберге итерулер үшін, құжаттаманы құру - шеберге итеру үшін.

Алдымен, біріктіру сұрауын ғана іске қосатын триггер ережесін қосу арқылы код құрастыру тапсырмасын орнатайық:

build job:
  # snip
  only:
    - merge_request

Енді біріктіру сұрауын іске қосу және мастерге міндеттеме қосу үшін орау тапсырмасын конфигурациялайық:

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

Көріп отырғаныңыздай, бәрі қарапайым және қарапайым.

Біріктіру сұрауы нақты мақсатты немесе бастапқы тармақпен жасалған жағдайда ғана тапсырманы іске қосу үшін теңшей аласыз:

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

Жағдайларда оны қолдануға болады мұнда тізімделген айнымалылар; ережелер rules ережелеріне сәйкес келмейді only/except.

Артефакттарды сақтау конфигурациялануда

Тапсырма орындалып жатқанда build job біз келесі тапсырмаларда қайта пайдалануға болатын артефактілерді құрастырамыз. Бұл әрекетті орындау үшін тапсырма конфигурациясына жолдарды, файлдарды сақтау және келесі тапсырмаларда қайта пайдалану қажет кілтке қосу керек. artifacts:

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

Жолдар қойылмалы таңбаларды қолдайды, бұл оларды орнатуды жеңілдетеді.

Егер тапсырма артефактілерді жасаса, онда әрбір келесі тапсырма оларға қол жеткізе алады - олар бастапқы тапсырмадан жиналған репозиторий түбірге қатысты бірдей жолдар бойында орналасады. Артефактілерді веб-сайтта жүктеп алуға болады.

Енді бізде дайын (және тексерілген) конфигурация құрылымы бар, біз тапсырмалар үшін сценарийлерді нақты жазуға көшеміз.

Біз сценарий жазамыз

Мүмкін, бір кездері алыс, алыс галактикада пәрмен жолынан жобаларды (соның ішінде .net жобаларын) құру ауыртпалық болды. Енді сіз жобаны 3 командада жинап, сынап, жариялай аласыз:

dotnet build
dotnet test
dotnet pack

Әрине, кейбір нюанстар бар, соның арқасында біз командаларды біршама қиындата аламыз.

Біз жөндеуді емес, шығаруды қалаймыз, сондықтан біз әрбір пәрменге қосамыз -c Release
Тестілеу кезінде біз кодты қамту туралы деректерді жинағымыз келеді, сондықтан қамту анализаторын сынақ кітапханаларына қосу керек:
1. Пакет барлық сынақ кітапханаларына қосылуы керек coverlet.msbuild: dotnet add package coverlet.msbuild жоба қалтасынан
2. Сынақты іске қосу пәрменіне қосыңыз /p:CollectCoverage=true
3. Қамту нәтижелерін алу үшін тестілеу тапсырмасының конфигурациясына кілт қосайық (төменде қараңыз)
Кодты nuget бумаларына орау кезінде біз пакеттер үшін шығыс каталогын орнатамыз: -o .

Кодты қамту деректерін жинау

Сынақтарды орындағаннан кейін Coverlet консольге іске қосу статистикасын көрсетеді:

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 статистиканы алу үшін тұрақты өрнекті көрсетуге мүмкіндік береді, содан кейін оны бейдж түрінде алуға болады. Тұрақты өрнек кілтпен тапсырма параметрлерінде көрсетіледі coverage; өрнекте мәні бейджге берілетін түсіру тобы болуы керек:

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

Мұнда біз жолдар бойынша жалпы қамтылған сызықтан статистика аламыз.

Біз пакеттер мен құжаттарды жариялаймыз

Бізде құбырдың соңғы кезеңіне тағайындалған екі әрекет те бар - құрастыру және сынақтар өткендіктен, біз өз әзірлемелерімізді әлеммен бөлісе аламыз.

Алдымен, бума көзіне жариялауды қарастырайық:

Жобада nuget конфигурация файлы болмаса (nuget.config), жаңасын жасаңыз: dotnet new nugetconfig
Не үшін: Кескіннің жаһандық (пайдаланушы және машина) конфигурацияларына жазу рұқсаты болмауы мүмкін. Қателерді ұстамау үшін біз жай ғана жаңа жергілікті конфигурация жасап, онымен жұмыс істейміз.
Жергілікті конфигурацияға жаңа бума көзін қосамыз: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name — жергілікті дереккөз атауы, маңызды емес
2. url — «Тіркелгілерді дайындау» кезеңіндегі дереккөздің URL мекенжайы, 6-қадам
3. organization - Azure DevOps жүйесіндегі ұйымның атауы
4. gitlab variable — GitLab жүйесіне қосылған рұқсат белгісі бар айнымалының атауы («Тіркелгілерді дайындау», 11-бет). Әрине, форматта $variableName
5. -StorePasswordInClearText — қол жеткізуге тыйым салынған қатені айналып өтуге арналған бұзу (Мен бұл тырмаға бірінші басқан емеспін)
6. Қателер болған жағдайда қосу пайдалы болуы мүмкін -verbosity detailed
Біз пакетті көзге жібереміз: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Біз барлық пакеттерді ағымдағы каталогтан жібереміз, сондықтан *.nupkg.
2. name - жоғарыдағы қадамнан.
3. key - кез келген сызық. Azure DevOps жүйесінде Арнаға қосылу терезесінде мысал жолы әрқашан болады az.
4. -skipduplicate — егер бұрыннан бар пакетті осы кілтсіз жіберуге әрекеттенсеңіз, дереккөз қатені қайтарады 409 Conflict; пернесі арқылы жіберу өткізіп жібереді.

Енді құжаттаманы құруды баптайық:

Бастау үшін, репозиторийде, негізгі тармақта, біз docfx жобасын инициализациялаймыз. Ол үшін түбірден пәрменді орындау керек docfx init және құжаттаманы құрастырудың негізгі параметрлерін интерактивті түрде орнатыңыз. Ең аз жобаны орнатудың толық сипаттамасы осында.
1. Орнату кезінде шығыс каталогын көрсету маңызды ..public - GitLab әдепкі бойынша репозиторийдің түбіріндегі жалпы қалтаның мазмұнын Беттердің көзі ретінде қабылдайды. Өйткені жоба репозиторийде кірістірілген қалтада орналасады - жолға келесі деңгейге шығуды қосыңыз.
Өзгерістерді GitLab жүйесіне енгізейік.
Құбыр конфигурациясына тапсырма қосыңыз pages (GitLab беттерінде сайтты жариялау тапсырмалары үшін сақталған сөз):
1. Сценарий:
  1. nuget install docfx.console -version 2.51.0 - docfx орнату; Нұсқа пакетті орнату жолдарының дұрыстығына көз жеткізу үшін берілген.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - құжаттарды жинау
2. Артефактілер түйіні:

pages:
  # snip
  artifacts:
    paths:
      - public

docfx туралы лирикалық шегініс

Бұрын жобаны орнату кезінде шешім файлы ретінде құжаттаманың код көзін көрсеттім. Негізгі кемшілігі құжаттама сынақ жобалары үшін де жасалады. Бұл қажет болмаса, бұл мәнді түйінге орнатуға болады metadata.src:

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

metadata.src.src: "../" — орынға қатысты бір деңгейге көтеріліңіз docfx.json, өйткені Каталогтар ағашын іздеу үлгілерде жұмыс істемейді.
metadata.src.files: ["**/*.csproj"] — жаһандық үлгі, біз барлық C# жобаларын барлық каталогтардан жинаймыз.
metadata.src.exclude: ["*.tests*/**"] - жаһандық үлгі, бар қалталардан барлығын алып тастаңыз .tests Тақырыпта

Жиынтық

Бұл қарапайым конфигурацияны жарты сағатта және бірнеше шыныаяқ кофеде жасауға болады, бұл әрбір біріктіру сұрауымен тексеруге және оны шеберге кодтың жасалып жатқанын және сынақтардан өтіп жатқанын, жаңасын құрастыруын жіберуге мүмкіндік береді. пакет, құжаттаманы жаңарту және README жобасында әдемі бейдждермен көзді қуанту.

Соңғы .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

Белгілер туралы айтатын болсақ

Барлығы солар үшін басталды!

Құбыр күйлері мен кодты қамтуы бар белгішелер GitLab жүйесінде Gtntral құбыр желілері блогындағы CI/CD параметрлерінде қолжетімді:

Мен платформадағы құжаттамаға сілтемесі бар бейдж жасадым Shields.io — мұнда бәрі өте қарапайым, сіз өзіңіздің бейджіңізді жасап, оны сұрау арқылы ала аласыз.

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

Azure DevOps Artifacts сонымен қатар соңғы нұсқаны көрсететін бумалар үшін танымбелгілерді жасауға мүмкіндік береді. Бұл әрекетті орындау үшін, Azure DevOps веб-сайтындағы көзде таңдалған бума үшін белгіні жасау түймесін басып, белгілеу белгісін көшіру керек:

Сұлулық қосу

Біз жалпы конфигурация фрагменттерін бөлектейміз

Конфигурацияны жазу және құжаттаманы іздеу кезінде мен қызықты YAML мүмкіндігін таптым - фрагменттерді қайта пайдалану.

Тапсырма параметрлерінен көріп отырғаныңыздай, олардың барлығы тегті қажет етеді windows жүгірушіден және біріктіру сұрауы шеберге жіберілгенде/құрылғанда іске қосылады (құжаттамадан басқа). Мұны біз қайта қолданатын фрагментке қосайық:

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

Енді біз бұрын жарияланған фрагментті тапсырма сипаттамасына кірістіре аламыз:

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

Фрагмент атаулары тапсырма ретінде түсіндірілмеу үшін нүктеден басталуы керек.

Пакет нұсқасы

Буманы құру кезінде компилятор пәрмен жолы қосқыштарын және олар болмаған жағдайда жоба файлдарын тексереді; Нұсқа түйінін тапқаннан кейін ол өзінің мәнін құрастырылып жатқан бума нұсқасы ретінде қабылдайды. Жаңа нұсқасы бар буманы құру үшін оны жоба файлында жаңарту немесе пәрмен жолы аргументі ретінде беру керек екені белгілі болды.

Тағы бір тілек қосайық - нұсқадағы ең төменгі екі сан пакеттің құрастырылған жылы мен күні болсын және шығарылымға дейінгі нұсқаларды қосыңыз. Әрине, сіз бұл деректерді жоба файлына қосып, оны әрбір жіберу алдында тексере аласыз - бірақ сіз оны контекстен пакет нұсқасын жинап, оны пәрмен жолы аргументі арқылы өткізе отырып, конвейерде де жасай аласыз.

Келісейік, егер міндеттеме хабарында сияқты жол болса release (v./ver./version) <version number> (rev./revision <revision>)?, содан кейін біз осы жолдан пакет нұсқасын аламыз, оны ағымдағы күнмен толықтырамыз және оны пәрменге аргумент ретінде береміз dotnet pack. Сызық болмаған жағдайда, біз жай ғана пакетті жинамаймыз.

Келесі сценарий бұл мәселені шешеді:

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

Тапсырмаға сценарий қосу pack and deploy job және пакеттердің құрастырылуын қатаң қадағалаңыз, егер тапсырма хабарламасында берілген жол болса.

Барлығы

Жарты сағаттан бір сағатқа дейін конфигурацияны жазуға, жергілікті powershell жүйесінде жөндеуге және, мүмкін, бірнеше сәтсіз іске қосуларға жұмсағаннан кейін біз әдеттегі тапсырмаларды автоматтандыруға арналған қарапайым конфигурацияны алдық.

Әрине, GitLab CI/CD бұл нұсқаулықты оқығаннан кейін көрінгеннен әлдеқайда кең және көп қырлы - бұл мүлде дұрыс емес. Тіпті бар Auto DevOps иәмүмкіндік беру

қолданбаларды автоматты түрде анықтау, құрастыру, тексеру, орналастыру және бақылау

Енді жоспарлар келесі мақалада қарастырылатын, Pulumi арқылы және мақсатты ортаны автоматты түрде анықтау арқылы Azure жүйесінде қолданбаларды орналастыру үшін құбырды конфигурациялау болып табылады.

Ақпарат көзі: www.habr.com