🥇GitLab'da CI/CD bo'yicha boshlanuvchilar uchun (deyarli) to'liq qo'llanma

Yoki qulay kodlashning bir oqshomida loyihangiz uchun chiroyli nishonlarni qanday olish mumkin

Ehtimol, kamida bitta uy hayvonlari loyihasiga ega bo'lgan har bir ishlab chiquvchida statuslar, kodlar qamrovi, nugetdagi paket versiyalari bilan chiroyli nishonlar haqida qichishish bor ... Va bu qichishish meni ushbu maqolani yozishga majbur qildi. Uni yozishga tayyorgarlik ko'rayotganda, men loyihalarimdan birida ushbu go'zallikka ega bo'ldim:

Ushbu maqola sizga GitLab’dagi .Net Core sinf kutubxonasi loyihasi uchun uzluksiz integratsiya va yetkazib berishning asosiy sozlamalari, GitLab Pages’ga hujjatlarni nashr etish va Azure DevOps’dagi shaxsiy tasmaga qurilgan paketlarni o‘tkazish bo‘yicha yo‘l ochadi.

VS kodi kengaytma bilan ishlab chiqish muhiti sifatida ishlatilgan GitLab ish jarayoni (sozlamalar faylini to'g'ridan-to'g'ri ishlab chiqish muhitidan tekshirish uchun).

Qisqacha Kirish

CD - siz shunchaki itarib yuborganingizdami va hamma narsa mijozga tushib qolganmi?

CI / CD nima va u nima uchun kerak - uni osongina Google orqali topishingiz mumkin. GitLab-da quvurlarni sozlash bo'yicha to'liq hujjatlarni toping ham oson. Bu erda men qisqacha va iloji bo'lsa, kamchiliklarsiz tizim jarayonini qush ko'zi bilan tasvirlab beraman:

ishlab chiquvchi omborga majburiyat yuboradi, sayt orqali birlashtirish so'rovini yaratadi, yoki boshqa yo'l bilan aniq yoki bilvosita quvur liniyasini ishga tushiradi,
konfiguratsiyadan sharti ularni ma'lum bir kontekstda ishga tushirishga imkon beradigan barcha vazifalar tanlanadi;
vazifalar bosqichlariga ko'ra tashkil etilgan;
bosqichlar navbatma-navbat bajariladi - ya'ni. parallel Ushbu bosqichning barcha vazifalari bajarildi,
agar bosqich muvaffaqiyatsiz bo'lsa (ya'ni, bosqichning kamida bitta vazifasi bajarilmasa) - quvur to'xtaydi (deyarli har doim),
agar barcha bosqichlar muvaffaqiyatli yakunlangan bo'lsa, quvur liniyasi muvaffaqiyatli hisoblanadi.

Shunday qilib, bizda:

quvur liniyasi - bosqichlarga bo'lingan vazifalar to'plami bo'lib, ularda siz yaratishingiz, sinovdan o'tkazishingiz, kodni paketlashingiz, tayyor tuzilmani bulutli xizmatga joylashtirishingiz va hokazo.
bosqich (bosqichi) - quvur liniyasini tashkil qilish birligi, 1+ vazifani o'z ichiga oladi,
vazifa (ish) quvur liniyasidagi ish birligi. Skript (majburiy), ishga tushirish shartlari, artefaktlarni nashr qilish/keshlash sozlamalari va boshqalardan iborat.

Shunga ko'ra, CI / CD-ni o'rnatishda vazifa kod va artefaktlarni yaratish, sinovdan o'tkazish va nashr etish uchun barcha kerakli harakatlarni amalga oshiradigan vazifalar to'plamini yaratishdan iborat.

Boshlashdan oldin: nima uchun?

Nima uchun Gitlab?

Chunki uy hayvonlari loyihalari uchun shaxsiy omborlarni yaratish zarurati tug'ilganda, ular GitHubda to'langan va men ochko'z edim. Repozitariylar bepul bo'ldi, ammo hozircha bu GitHub-ga o'tishim uchun etarli sabab emas.

Nega Azure DevOps Pipelines emas?

Chunki sozlash oddiy - sizga buyruq qatori bilimi ham kerak emas. Tashqi git provayderlari bilan integratsiya - bir necha marta bosish, omborga majburiyatlarni yuborish uchun SSH kalitlarini import qilish - shuningdek, quvur liniyasi shablonsiz ham osongina sozlanadi.

Boshlang'ich pozitsiyasi: sizda nima bor va nima xohlaysiz

Bizda ... bor:

GitLab-dagi ombor.

Biz xohlaymiz:

har bir birlashma so'rovi uchun avtomatik yig'ish va sinov,
har bir birlashtirish so'rovi uchun paketlar yaratish va majburiyat xabarida ma'lum bir qator mavjud bo'lsa, masterga surish;
yig'ilgan paketlarni Azure DevOps-da shaxsiy tasmaga yuborish,
GitLab sahifalarida hujjatlarni yig'ish va nashr etish,
nishonlar!11

Ta'riflangan talablar tabiiy ravishda quyidagi quvur liniyasi modeliga mos keladi:

1-bosqich - yig'ish
- Biz kodni yig'amiz, chiqish fayllarini artefakt sifatida nashr qilamiz
2-bosqich - sinov
- Qurilish bosqichidan artefaktlarni olamiz, testlarni o'tkazamiz, kodni qamrab olish ma'lumotlarini to'playmiz
3-bosqich - topshirish
- Vazifa 1 - nuget paketini yig'ing va Azure DevOps-ga yuboring
- Vazifa 2 - biz saytni xmldoc-dan manba kodida yig'amiz va uni GitLab sahifalarida nashr qilamiz

Qani boshladik!

Konfiguratsiyani yig'ish

Hisoblarni tayyorlash

Hisob qaydnomasini yarating Microsoft Azure
ga boring Azure DevOps
Yangi loyiha yarating
1. Ism - har qanday
2. Ko'rinish - har qanday
Yaratish tugmasini bosganingizda, loyiha yaratiladi va siz uning sahifasiga yo'naltirilasiz. Ushbu sahifada siz loyiha sozlamalariga o'tish orqali keraksiz xususiyatlarni o'chirib qo'yishingiz mumkin (chapdagi ro'yxatdagi pastki havola -> Umumiy ko'rinish -> Azure DevOps xizmatlari bloki)
Atrifacts-ga o'ting, Tasma yaratish-ni bosing
1. Manba nomini kiriting
2. Ko'rinishni tanlang
3. Belgini olib tashlang Umumiy ommaviy manbalardan paketlarni qo'shing, manba dump nuget kloniga aylanmasligi uchun
Tasmaga ulanish-ni bosing, Visual Studio-ni tanlang, Mashina sozlamalari blokidan Manbadan nusxa oling
Hisob sozlamalariga o'ting, Shaxsiy kirish tokenini tanlang
Yangi kirish tokenini yarating
1. Ism - o'zboshimchalik bilan
2. Tashkilot - joriy
3. Amal qilish muddati: maksimal 1 yil
4. Qo'llash sohasi - qadoqlash/o'qish va yozish
Yaratilgan tokenni nusxalash - modal oyna yopilgandan so'ng, qiymat mavjud bo'lmaydi
GitLab-dagi ombor sozlamalariga o'ting, CI / CD sozlamalarini tanlang
O'zgaruvchilar blokini kengaytiring, yangisini qo'shing
1. Ism - bo'sh joysiz har qanday (buyruqlar qobig'ida mavjud bo'ladi)
2. Qiymat 9-bosqichdagi kirish tokenidir
3. Mask o'zgaruvchisini tanlang

Bu oldindan konfiguratsiyani yakunlaydi.

Konfiguratsiya ramkasini tayyorlash

Odatiy bo'lib, GitLab-da CI/CD-ni sozlash uchun ishlatiladigan fayl .gitlab-ci.yml omborning ildizidan. Siz ombor sozlamalarida ushbu faylga o'zboshimchalik bilan yo'lni o'rnatishingiz mumkin, ammo bu holda bu kerak emas.

Kengaytmadan ko'rinib turibdiki, fayl formatdagi konfiguratsiyani o'z ichiga oladi YAML. Hujjatlarda konfiguratsiyaning yuqori darajasida va har bir ichki o'rnatilgan darajalarda qaysi kalitlar bo'lishi mumkinligi haqida batafsil ma'lumot berilgan.

Birinchidan, konfiguratsiya faylidagi docker tasviriga havolani qo'shamiz, unda vazifalar bajariladi. Buning uchun biz topamiz Docker Hub’dagi .Net Core tasvirlar sahifasi. The GitHub turli vazifalar uchun qaysi tasvirni tanlash haqida batafsil ko'rsatma mavjud. .Net Core 3.1 oʻrnatilgan rasm biz yaratishimiz uchun mos, shuning uchun konfiguratsiyaga birinchi qatorni qoʻshing.

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

Endi, quvur liniyasi Microsoft tasvirlar omboridan ishga tushirilganda, ko'rsatilgan rasm yuklab olinadi, unda konfiguratsiyadagi barcha vazifalar bajariladi.

Keyingi qadam qo'shishdir bosqichining. Odatiy bo'lib, GitLab 5 bosqichni belgilaydi:

.pre - barcha bosqichlargacha bajarilgan;
.post - barcha bosqichlardan so'ng amalga oshiriladi;
build - birinchi keyin .pre bosqich,
test - ikkinchi bosqich,
deploy - uchinchi bosqich.

Biroq, ularni aniq e'lon qilishingizga hech narsa to'sqinlik qilmaydi. Bosqichlarni sanab o'tish tartibi ularni bajarish tartibiga ta'sir qiladi. To'liqlik uchun konfiguratsiyaga qo'shamiz:

stages:
  - build
  - test
  - deploy

Nosozliklarni tuzatish uchun vazifalar bajariladigan muhit haqida ma'lumot olish mantiqan to'g'ri keladi. Keling, har bir topshiriq oldidan bajariladigan global buyruqlar to'plamini qo'shamiz before_script:

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

Hech bo'lmaganda bitta vazifani qo'shish kerak, shunda majburiyatlar yuborilganda quvur liniyasi ishga tushadi. Hozircha, ko'rsatish uchun bo'sh vazifa qo'shamiz:

dummy job:
  script:
    - echo ok

Biz tekshirishni boshlaymiz, biz hamma narsa yaxshi ekanligi haqida xabar olamiz, biz majburiyat qilamiz, turamiz, saytdagi natijalarga qaraymiz ... Va biz skript xatosini olamiz - bash: .PSVersion: command not found. wtf?

Hammasi mantiqiy - sukut bo'yicha yuguruvchilar (vazifa skriptlarini bajarish uchun mas'ul va GitLab tomonidan taqdim etilgan) foydalanadilar. bash buyruqlarni bajarish uchun. Buni vazifa tavsifida bajaruvchi quvur liniyasining qaysi teglari bo'lishi kerakligini aniq ko'rsatish orqali tuzatishingiz mumkin:

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

Ajoyib! Hozir quvur liniyasi ishga tushirilmoqda.

Diqqatli o'quvchi, ko'rsatilgan qadamlarni takrorlab, vazifa bosqichda bajarilganligini sezadi test, garchi biz bosqichni aniqlamagan bo'lsak ham. Siz taxmin qilganingizdek test standart qadamdir.

Yuqorida tavsiflangan barcha vazifalarni qo'shish orqali konfiguratsiya skeletini yaratishni davom ettiramiz:

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

Biz juda funktsional bo'lmagan, ammo shunga qaramay to'g'ri quvur liniyasiga ega bo'ldik.

Triggerlarni sozlash

Har qanday vazifa uchun hech qanday tetik filtrlari ko'rsatilmaganligi sababli, quvur liniyasi bo'ladi to'liq har safar majburiyat omborga yuborilganda bajariladi. Bu umuman kerakli xatti-harakatlar emasligi sababli, biz vazifalar uchun tetik filtrlarini o'rnatamiz.

Filtrlarni ikkita formatda sozlash mumkin: faqat / bundan mustasno и qoidalari. Qisqasi, only/except triggerlar bo'yicha filtrlarni sozlash imkonini beradi (merge_request, masalan - har safar birlashtirish so'rovi yaratilganda va har safar birlashma so'rovida manba bo'lgan filialga topshiriqlar yuborilganda bajarilishi kerak bo'lgan vazifani sozlaydi) va filial nomlari (shu jumladan, oddiy iboralar yordamida); rules sizga shartlar to'plamini sozlash va ixtiyoriy ravishda oldingi vazifalarning muvaffaqiyatiga qarab vazifani bajarish shartini o'zgartirish imkonini beradi (when GitLab CI/CD da).

Bir qator talablarni eslaylik - faqat birlashtirish so'rovi uchun yig'ish va sinovdan o'tkazish, Azure DevOps-ga qadoqlash va jo'natish - birlashtirish so'rovi va masterga surish, hujjatlarni yaratish - masterga surish uchun.

Birinchidan, faqat birlashma so'rovida ishga tushadigan qoidani qo'shish orqali kod yaratish vazifasini o'rnatamiz:

build job:
  # snip
  only:
    - merge_request

Keling, birlashtirish so'rovini ishga tushirish va masterga majburiyatlarni qo'shish uchun qadoqlash vazifasini o'rnatamiz:

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

Ko'rib turganingizdek, hamma narsa oddiy va tushunarli.

Bundan tashqari, vazifani faqat ma'lum bir maqsad yoki manba filiali bilan birlashtirish so'rovi yaratilgan bo'lsa, ishga tushirishga o'rnatishingiz mumkin:

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

Shartlar ostida siz foydalanishingiz mumkin o'zgaruvchilar bu erda keltirilgan; qoidalar rules qoidalarga mos kelmaydi only/except.

Artifaktni saqlashni sozlash

Vazifa bajarilayotganda build job Biz keyingi vazifalarda qayta foydalanish mumkin bo'lgan yaratilgan artefaktlarni yaratamiz. Buni amalga oshirish uchun siz kalitga vazifa konfiguratsiyasiga yo'llarni qo'shishingiz kerak, ular bo'ylab saqlanishi va keyingi vazifalarda qayta ishlatilishi kerak bo'lgan fayllar. artifacts:

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

Yo'llar joker belgilarni qo'llab-quvvatlaydi, bu ularni o'rnatishni osonlashtiradi.

Agar vazifa artefaktlarni yaratsa, har bir keyingi vazifa ularga kirish imkoniyatiga ega bo'ladi - ular asl topshiriqdan to'plangan ombor ildiziga nisbatan bir xil yo'llar bo'ylab joylashgan bo'ladi. Artifaktlarni ham saytda yuklab olish mumkin.

Endi bizda konfiguratsiya tizimi tayyor (va tasdiqlangan) bor, biz vazifalar uchun skriptlarni yozishga o'tishimiz mumkin.

Biz skriptlarni yozamiz

Ehtimol, bir vaqtlar, uzoq, uzoq galaktikada buyruq satridan loyihalarni (jumladan, .net) qurish og'riqli edi. Endi siz loyihani 3 ta jamoada qurishingiz, sinab ko'rishingiz va nashr qilishingiz mumkin:

dotnet build
dotnet test
dotnet pack

Tabiiyki, ba'zi nuanslar mavjud, ular tufayli biz buyruqlarni biroz murakkablashtiramiz.

Biz disk raskadrovka tuzilmasi emas, balki reliz tuzilishini istaymiz, shuning uchun biz har bir buyruqqa qo'shamiz -c Release
Sinov paytida biz kod qamrovi haqida ma'lumot to'plashni xohlaymiz, shuning uchun biz qamrov analizatorini test kutubxonalariga ulashimiz kerak:
1. Paketni barcha test kutubxonalariga qo'shing coverlet.msbuild: dotnet add package coverlet.msbuild loyiha papkasidan
2. Sinovni ishga tushirish buyrug'iga qo'shing /p:CollectCoverage=true
3. Qamrov natijalarini olish uchun test topshirig'i konfiguratsiyasiga kalit qo'shing (pastga qarang)
Kodni nuget paketlariga o'rashda paketlar uchun chiqish katalogini o'rnating: -o .

Kod qamrovi ma'lumotlarini yig'ish

Sinovlarni o'tkazgandan so'ng, Coverlet nashrlari konsolga statistikani ishga tushiradi:

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 statistik ma'lumotlarni olish uchun muntazam ifodani belgilash imkonini beradi, keyin uni nishon shaklida olish mumkin. Oddiy ifoda kalit bilan vazifa sozlamalarida ko'rsatilgan coverage; ifoda qiymati nishonga o'tkaziladigan suratga olish guruhini o'z ichiga olishi kerak:

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

Bu erda biz umumiy chiziq qamroviga ega bo'lgan chiziqdan statistik ma'lumotlarni olamiz.

Paketlar va hujjatlarni nashr qilish

Bizda quvurning so'nggi bosqichiga tayinlangan ikkala harakat ham bor - yig'ilish va sinovlar o'tgandan beri biz o'z ishlanmalarimizni dunyo bilan baham ko'rishimiz mumkin.

Birinchidan, paket manbasiga nashr qilishni o'ylab ko'ring:

Agar loyihada nuget konfiguratsiya fayli bo'lmasa (nuget.config), yangisini yarating: dotnet new nugetconfig

Nima uchun: Rasmda global (foydalanuvchi va mashina) konfiguratsiyalarga yozish huquqi bo'lmasligi mumkin. Xatolarga yo'l qo'ymaslik uchun biz shunchaki yangi mahalliy konfiguratsiyani yaratamiz va u bilan ishlaymiz.
Mahalliy konfiguratsiyaga yangi paket manbasini qo'shamiz: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - mahalliy manba nomi, muhim emas
2. url — “Hisob qaydnomalarini tayyorlash” bosqichidagi manbaning URL manzili, 6-bosqich
3. organization - Azure DevOps-dagi tashkilot nomi
4. gitlab variable — GitLab-ga qo'shilgan kirish tokeni bilan o'zgaruvchining nomi ("Hisob qaydnomalarini tayyorlash", 11-bet). Tabiiyki, formatda $variableName
5. -StorePasswordInClearText - kirish taqiqlangan xatoni chetlab o'tish uchun buzg'unchilik (Men bu rakega birinchi qadam bosganim yo‘q)
6. Xatolar bo'lsa, qo'shish foydali bo'lishi mumkin -verbosity detailed
Paketni manbaga yuborish: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Biz barcha paketlarni joriy katalogdan yuboramiz, shuning uchun *.nupkg.
2. name - yuqoridagi bosqichdan.
3. key - har qanday chiziq. Azure DevOps-da, Tasmaga ulanish oynasida, misol har doim chiziqdir az.
4. -skipduplicate - allaqachon mavjud paketni ushbu kalitsiz yuborishga urinayotganda, manba xatolik qaytaradi 409 Conflict; kalit bilan yuborish o'tkazib yuboriladi.

Endi hujjatlarni yaratishni o'rnatamiz:

Birinchidan, omborda, asosiy filialda biz docfx loyihasini ishga tushiramiz. Buning uchun buyruqni ildizdan ishga tushiring docfx init va hujjatlarni yig'ish uchun asosiy parametrlarni interaktiv tarzda o'rnating. Minimal loyihani o'rnatishning batafsil tavsifi shu yerda.
1. O'rnatishda chiqish katalogini ko'rsatish muhimdir ..public - GitLab sukut bo'yicha Sahifalar uchun manba sifatida ombor ildizidagi umumiy jildning mazmunini oladi. Chunki loyiha omborga joylashtirilgan papkada joylashgan bo'ladi - yo'lda yuqori darajaga chiqish qo'shing.
O'zgarishlarni GitLab-ga kiritamiz.
Quvur konfiguratsiyasiga vazifa qo'shing pages (GitLab sahifalarida saytni nashr qilish vazifalari uchun ajratilgan so'z):
1. Skript:
  1. nuget install docfx.console -version 2.51.0 - docfx o'rnatish; versiya paketni o'rnatish yo'llari to'g'ri ekanligini ta'minlash uchun ko'rsatilgan.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - hujjatlarni yig'ish
2. Artefakt tugunlari:

pages:
  # snip
  artifacts:
    paths:
      - public

Docfx haqida lirik chekinish

Ilgari, loyihani o'rnatishda men hujjatlar uchun kod manbasini yechim fayli sifatida ko'rsatdim. Asosiy kamchilik shundaki, hujjatlar sinov loyihalari uchun ham yaratilgan. Agar bu kerak bo'lmasa, siz ushbu qiymatni tugunga o'rnatishingiz mumkin metadata.src:

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

metadata.src.src: "../" - biz joylashuvga nisbatan bir daraja yuqoriga chiqamiz docfx.json, chunki naqshlarda katalog daraxtini qidirish ishlamaydi.
metadata.src.files: ["**/*.csproj"] - global naqsh, biz barcha kataloglardan barcha C # loyihalarini yig'amiz.
metadata.src.exclude: ["*.tests*/**"] - global naqsh, papkalardan hamma narsani chiqarib tashlang .tests Sarlavhada

Jami

Bunday oddiy konfiguratsiyani atigi yarim soat va bir necha chashka qahva ichida yaratish mumkin, bu sizga kod tuzilganligini va sinovlardan o'tganligini tekshirish, yangi paketni yaratish, hujjatlarni yangilash va ko'zni chiroyli ko'rinish bilan xursand qilish imkonini beradi. loyihaning README-dagi nishonlarni har bir birlashtirish so'rovi va ustaga yuborish bilan.

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

Belgilar haqida gapirganda

Hammasi ular uchun boshlandi!

Quvur holati va kod qamroviga ega nishonlar GitLab-da Gtntral quvur liniyasi blokidagi CI/CD sozlamalarida mavjud:

Men platformadagi hujjatlarga havola bilan nishon yaratdim shields.io - u erda hamma narsa juda oddiy, siz o'zingizning nishoningizni yaratishingiz va uni so'rov yordamida olishingiz mumkin.

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

Azure DevOps Artifacts eng so'nggi versiyaga ega paketlar uchun nishonlar yaratishga ham imkon beradi. Buni amalga oshirish uchun Azure DevOps saytidagi manbada tanlangan paket uchun nishon yaratish tugmasini bosishingiz va belgilash belgisini nusxalashingiz kerak:

Go'zallik qo'shish

Umumiy konfiguratsiya fragmentlarini ajratib ko'rsatish

Konfiguratsiyani yozish va hujjatlarni qidirish paytida men YAMLning qiziqarli xususiyatiga duch keldim - parchalarni qayta ishlatish.

Vazifa sozlamalaridan ko'rinib turibdiki, ularning barchasi tegni talab qiladi windows yuguruvchida va birlashtirish so'rovi ustaga yuborilganda/yaratilganda ishga tushiriladi (hujjatlardan tashqari). Keling, buni biz qayta ishlatadigan fragmentga qo'shamiz:

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

Va endi biz oldindan e'lon qilingan fragmentni vazifa tavsifiga kiritishimiz mumkin:

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

Fragment nomlari vazifa sifatida talqin qilinmasligi uchun nuqta bilan boshlanishi kerak.

Paket versiyasi

Paketni yaratishda kompilyator buyruq qatori kalitlarini, ular yo'q bo'lganda esa loyiha fayllarini tekshiradi; Versiya tugunini topib, u qurilayotgan paketning versiyasi sifatida o'z qiymatini oladi. Ma'lum bo'lishicha, yangi versiya bilan paket yaratish uchun uni loyiha faylida yangilashingiz yoki buyruq qatori argumenti sifatida topshirishingiz kerak.

Keling, yana bitta istaklar ro'yxatini qo'shamiz - versiyadagi kichik ikkita raqam paketning yili va tuzilgan sanasi bo'lsin va relizdan oldingi versiyalarni qo'shing. Albatta, siz ushbu ma'lumotlarni loyiha fayliga qo'shishingiz va har bir taqdim etishdan oldin tekshirishingiz mumkin - lekin siz uni kontekstdan paket versiyasini yig'ib, buyruq qatori argumenti orqali o'tkazib, quvur liniyasida ham qilishingiz mumkin.

Keling, rozilik bildiraylik, agar majburiyat xabarida kabi qator mavjud bo'lsa release (v./ver./version) <version number> (rev./revision <revision>)?, keyin biz ushbu qatordan paketning versiyasini olamiz, uni joriy sana bilan to'ldiramiz va uni buyruqqa argument sifatida beramiz. dotnet pack. Agar chiziq bo'lmasa, biz shunchaki paketni yig'maymiz.

Quyidagi skript bu muammoni hal qiladi:

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

Vazifaga skript qo'shish pack and deploy job va paketlarning yig'ilishiga qat'iy rioya qilish xabarida berilgan qator mavjud bo'lganda rioya qiling.

jami

Taxminan yarim soat yoki bir soat vaqtni konfiguratsiyani yozish, mahalliy Powershell-da disk raskadrovka qilish va, ehtimol, bir nechta muvaffaqiyatsiz ishga tushirishdan so'ng, biz oddiy vazifalarni avtomatlashtirish uchun oddiy konfiguratsiyaga ega bo'ldik.

Albatta, GitLab CI/CD ushbu qo'llanmani o'qib chiqqandan keyin ko'rinadiganidan ancha kengroq va ko'p qirrali - bu umuman to'g'ri emas. Hatto bor Auto DevOps - buruxsat berish

ilovalaringizni avtomatik aniqlash, qurish, sinovdan o‘tkazish, joylashtirish va nazorat qilish

Endi rejalar Pulumi-dan foydalangan holda Azure-da ilovalarni joylashtirish va maqsadli muhitni avtomatik ravishda aniqlash uchun quvur liniyasini sozlash, bu keyingi maqolada muhokama qilinadi.

Manba: www.habr.com