🥇 (demək olar ki) mütləq yeni başlayanlar üçün GitLab-da CI/CD bələdçisi

Və ya asan kodlaşdırmanın bir axşamında layihəniz üçün gözəl nişanları necə əldə etmək olar

Yəqin ki, nə vaxtsa ən azı bir ev heyvanı layihəsi olan hər bir tərtibatçının statusları, kod əhatə dairəsi, nugetdəki paket versiyaları olan gözəl nişanlar haqqında qaşınması var ... Və bu qaşınma məni bu məqaləni yazmağa vadar etdi. Onu yazmağa hazırlaşarkən layihələrimdən birində bu gözəlliyi əldə etdim:

Bu məqalə sizə GitLab-da .Net Core sinif kitabxanası layihəsi üçün davamlı inteqrasiya və çatdırılmanın əsas qurulması, sənədlərin GitLab Səhifələrində dərc edilməsi və Azure DevOps-da xüsusi lentə qurulmuş paketlərin ötürülməsi ilə tanış olacaq.

VS Kodu genişləndirmə ilə inkişaf mühiti kimi istifadə edilmişdir GitLab iş axını (parametrlər faylını birbaşa inkişaf mühitindən doğrulamaq üçün).

Qısa təqdimat

CD - sadəcə itələdiyiniz zaman hər şey müştərinin üzərinə düşdü?

CI / CD nədir və nə üçün lazımdır - onu asanlıqla google-da tapa bilərsiniz. GitLab-da boru kəmərlərinin konfiqurasiyasına dair tam sənədləri tapın həm də asan. Burada qısaca və mümkünsə qüsursuz sistemin prosesini quş baxışı ilə təsvir edəcəyəm:

tərtibatçı depoya öhdəlik göndərir, sayt vasitəsilə birləşmə sorğusu yaradır, və ya başqa bir şəkildə, açıq və ya dolayı olaraq boru kəmərini işə salır,
bütün tapşırıqlar konfiqurasiyadan seçilir, şərtləri onları verilmiş kontekstdə işə salmağa imkan verir,
tapşırıqlar mərhələlərinə uyğun olaraq təşkil edilir,
mərhələlər növbə ilə yerinə yetirilir - yəni. paralel bu mərhələnin bütün tapşırıqları tamamlandı,
mərhələ uğursuz olarsa (yəni mərhələnin tapşırıqlarından ən azı biri uğursuz olarsa), boru kəməri dayanır (demək olar ki, həmişə),
bütün mərhələlər uğurla başa çatdırılarsa, boru kəməri uğurlu sayılır.

Beləliklə, bizdə:

boru kəməri - siz qura, sınaqdan keçirə, kodu paketləyə, bitmiş quruluşu bulud xidmətinə yerləşdirə biləcəyiniz mərhələlərə təşkil edilmiş tapşırıqlar toplusu və s.,
mərhələ (mərhələ) — boru kəmərinin təşkili bölməsi, 1+ tapşırıqdan ibarətdir,
tapşırıq (iş) boru kəmərində iş vahididir. O, skriptdən (məcburi), işə salma şərtlərindən, artefaktların nəşri/keşləşdirilməsi üçün parametrlərdən və daha çox şeydən ibarətdir.

Müvafiq olaraq, CI / CD qurarkən vəzifə kod və artefaktların qurulması, sınaqdan keçirilməsi və dərc edilməsi üçün bütün zəruri tədbirləri həyata keçirən bir sıra tapşırıqlar yaratmaqdan ibarətdir.

Başlamazdan əvvəl: niyə?

Niyə Gitlab?

Çünki ev heyvanları layihələri üçün şəxsi anbarlar yaratmaq zərurəti yarananda onlara GitHub-da pul ödənilirdi və mən acgöz idim. Repozitoriyalar pulsuz oldu, lakin indiyə qədər bu, mənim GitHub-a keçməyim üçün kifayət qədər səbəb deyil.

Niyə Azure DevOps Pipelines deyil?

Çünki orada parametr elementardır - komanda xəttini bilmək belə tələb olunmur. Xarici git provayderləri ilə inteqrasiya - bir neçə kliklə, depoya öhdəliklər göndərmək üçün SSH açarlarının idxalı - həm də boru kəməri şablondan olmasa da asanlıqla konfiqurasiya olunur.

Başlanğıc mövqeyi: nəyə sahibsən və nə istəyirsən

Bizdə:

GitLab-da depo.

Biz istəyirik:

hər birləşmə sorğusu üçün avtomatik montaj və sınaq,
hər bir birləşmə sorğusu üçün paketlər qurmaq və öhdəçilik mesajında müəyyən bir xətt olması şərti ilə mastera itələmək,
qurulmuş paketləri Azure DevOps-da şəxsi lentə göndərmək,
GitLab Səhifələrində sənədlərin yığılması və nəşri,
döş nişanları!11

Təsvir edilən tələblər üzvi olaraq aşağıdakı boru kəməri modelinə düşür:

Mərhələ 1 - Montaj
- Kodu toplayırıq, çıxış fayllarını artefakt kimi dərc edirik
Mərhələ 2 - sınaq
- Quraşdırma mərhələsindən artefaktlar alırıq, testlər keçiririk, kod əhatə dairəsi məlumatlarını toplayırıq
Mərhələ 3 - Təqdim edin
- Tapşırıq 1 - nuget paketini qurun və onu Azure DevOps-a göndərin
- Tapşırıq 2 - saytı mənbə kodunda xmldoc-dan toplayırıq və GitLab Səhifələrində dərc edirik

Gəlin başlayaq!

Konfiqurasiyanın toplanması

Hesabların hazırlanması

-də hesab yaradın Microsoft Azure
Biz keçərik Azure DevOps
Yeni layihə yaradırıq
1. Ad - hər hansı
2. Görünüş - hər hansı
Yarat düyməsini kliklədikdə layihə yaradılacaq və siz onun səhifəsinə yönləndiriləcəksiniz. Bu səhifədə siz layihə parametrlərinə keçərək lazımsız funksiyaları söndürə bilərsiniz (soldakı siyahıda aşağı keçid -> İcmal -> Azure DevOps Xidmətləri bloku)
Atrifaktlara keçin, Lent yarat klikləyin
1. Mənbənin adını daxil edin
2. Görünüşü seçin
3. İşarəni silin Ümumi ictimai mənbələrdən paketləri daxil edin, mənbənin dump nuget klonuna çevrilməməsi üçün
Yemək üçün Qoşul düyməsini klikləyin, Visual Studio seçin, Maşın Quraşdırma blokundan Mənbəni kopyalayın
Hesab parametrlərinə gedin, Personal Access Token seçin
Yeni giriş nişanı yaradın
1. Ad - ixtiyari
2. Təşkilat - Cari
3. Maksimum 1 il müddətində etibarlıdır
4. Əhatə dairəsi - Qablaşdırma/Oxu və Yaz
Yaradılmış nişanı kopyalayın - modal pəncərə bağlandıqdan sonra dəyər əlçatan olmayacaq
GitLab-da depo parametrlərinə keçin, CI / CD parametrlərini seçin
Dəyişənlər blokunu genişləndirin, yenisini əlavə edin
1. Ad - boşluqsuz hər hansı (komanda qabığında mövcud olacaq)
2. Dəyər - 9-cu bənddən giriş nişanı
3. Maska dəyişənini seçin

Bu, əvvəlcədən konfiqurasiyanı tamamlayır.

Konfiqurasiya çərçivəsinin hazırlanması

Varsayılan olaraq, GitLab-da CI/CD konfiqurasiyası fayldan istifadə edir .gitlab-ci.yml deponun kökündən. Depozit parametrlərində bu fayla ixtiyari bir yol təyin edə bilərsiniz, lakin bu halda bu lazım deyil.

Genişlənmədən göründüyü kimi, faylda formatda konfiqurasiya var YAML. Sənədləşdirmə təfərrüatları hansı açarların konfiqurasiyanın yuxarı səviyyəsində və iç-içə səviyyələrin hər birində ola biləcəyini göstərir.

Əvvəlcə tapşırıqların yerinə yetiriləcəyi konfiqurasiya faylında docker şəklinə keçid əlavə edək. Bunun üçün tapırıq Docker Hub-da .Net Core şəkillər səhifəsi. Ilə Github müxtəlif tapşırıqlar üçün hansı təsvirin seçiləcəyi ilə bağlı ətraflı təlimat var. .Net Core 3.1 ilə bir şəkil qurmaq bizim üçün uyğundur, ona görə də konfiqurasiyaya birinci sətri əlavə etməkdən çəkinməyin

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

İndi, boru kəməri Microsoft şəkil deposundan işə salındıqda, konfiqurasiyadan bütün tapşırıqların yerinə yetiriləcəyi müəyyən edilmiş şəkil endiriləcək.

Növbəti addım əlavə etməkdir mərhələnin. Varsayılan olaraq, GitLab 5 mərhələni müəyyənləşdirir:

.pre - bütün mərhələlərə qədər həyata keçirilir,
.post - bütün mərhələlərdən sonra həyata keçirilir,
build - ilk sonra .pre səhnə,
test - ikinci mərhələ,
deploy - üçüncü mərhələ.

Bununla belə, onları açıq şəkildə bəyan etməyə heç nə mane olmur. Addımların sadalanma sırası onların yerinə yetirilmə sırasına təsir edir. Tamlıq üçün konfiqurasiyaya əlavə edək:

stages:
  - build
  - test
  - deploy

Sazlama üçün tapşırıqların icra olunduğu mühit haqqında məlumat əldə etməyin mənası var. Gəlin hər tapşırıqdan əvvəl yerinə yetiriləcək qlobal əmrlər toplusunu əlavə edək before_script:

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

Ən azı bir tapşırıq əlavə etmək qalır ki, öhdəliklər göndərildikdə boru kəməri işə düşsün. Hələlik, nümayiş etdirmək üçün boş bir tapşırıq əlavə edək:

dummy job:
  script:
    - echo ok

Doğrulamağa başlayırıq, hər şeyin qaydasında olduğu mesajı alırıq, öhdəlik götürürük, itələyirik, saytda nəticələrə baxırıq ... Və skript xətası alırıq - bash: .PSVersion: command not found. wtf?

Hər şey məntiqlidir - standart olaraq, qaçışçılar (tapşırıq skriptlərinin icrasına cavabdehdir və GitLab tərəfindən təmin olunur) istifadə edir bash əmrləri yerinə yetirmək üçün. Tapşırığın təsvirində icra edən boru kəmərinin hansı teqlərə malik olması lazım olduğunu açıq şəkildə göstərərək bunu düzəldə bilərsiniz:

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

Əla! Hazırda boru kəməri işləyir.

Göstərilən addımları təkrarlayan diqqətli oxucu tapşırığın mərhələdə tamamlandığını görəcək test, baxmayaraq ki, mərhələni dəqiqləşdirməmişik. Təxmin etdiyiniz kimi test standart addımdır.

Yuxarıda təsvir edilən bütün tapşırıqları əlavə etməklə konfiqurasiya skeletini yaratmağa davam edək:

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

Xüsusilə funksional olmayan, lakin buna baxmayaraq düzgün bir boru kəməri aldıq.

Tətiklərin qurulması

Tapşırıqların heç biri üçün heç bir tetikleyici filtr göstərilmədiyi üçün boru kəməri olacaq tam hər dəfə öhdəliyin depoya itələndiyi zaman yerinə yetirilməlidir. Bu ümumiyyətlə arzuolunan davranış olmadığı üçün biz tapşırıqlar üçün tetikleyici filtrlər quracağıq.

Filtrlər iki formatda konfiqurasiya edilə bilər: yalnız/istisna и qaydaları. Qısaca, only/except tetikleyiciler üzrə filtrləri konfiqurasiya etməyə imkan verir (merge_request, məsələn - hər dəfə çəkmə sorğusu yaradıldıqda və birləşmə sorğusunda mənbə olan filiala hər dəfə commitlər göndərildikdə yerinə yetiriləcək tapşırığı təyin edir) və filial adları (o cümlədən müntəzəm ifadələrdən istifadə etməklə); rules bir sıra şərtləri fərdiləşdirməyə və isteğe bağlı olaraq, əvvəlki tapşırıqların müvəffəqiyyətindən asılı olaraq tapşırığın icra vəziyyətini dəyişdirməyə imkan verir (when GitLab CI/CD-də).

Bir sıra tələbləri yada salaq - yalnız birləşmə sorğusu üçün montaj və sınaq, qablaşdırma və Azure DevOps-a göndərmə - birləşmə sorğusu və mastera təkan, sənədlərin yaradılması - mastera təkan üçün.

Əvvəlcə yalnız birləşmə sorğusu ilə işə salınan bir qayda əlavə edərək kod qurma tapşırığını quraq:

build job:
  # snip
  only:
    - merge_request

İndi birləşmə sorğusunu işə salmaq və mastera öhdəliklər əlavə etmək üçün qablaşdırma tapşırığını quraq:

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

Gördüyünüz kimi, hər şey sadə və sadədir.

Siz həmçinin tapşırığı yalnız müəyyən bir hədəf və ya mənbə filialı ilə birləşmə sorğusu yaradıldığı halda işə salmaq üçün təyin edə bilərsiniz:

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

Şərtlərdə istifadə edə bilərsiniz burada sadalanan dəyişənlər; Qaydalar rules qaydalara uyğun gəlmir only/except.

Artefakt Saxlama Konfiqurasiyası

Tapşırıq zamanı build job biz sonrakı vəzifələrdə təkrar istifadə edilə bilən artefaktlar quracağıq. Bunu etmək üçün tapşırıq konfiqurasiyasına yolları, aşağıdakı tapşırıqlarda saxlamaq və yenidən istifadə etməli olduğunuz faylları açara əlavə etməlisiniz. artifacts:

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

Yollar joker simvolları dəstəkləyir, bu da onları təyin etməyi mütləq asanlaşdırır.

Tapşırıq artefaktlar yaradırsa, onda hər bir sonrakı tapşırıq onlara daxil ola biləcək - onlar orijinal tapşırıqdan toplanmış depo kökünə nisbətən eyni yollar boyunca yerləşəcəklər. Artefaktları da saytda yükləmək mümkündür.

İndi konfiqurasiya çərçivəmiz hazırdır (və sınaqdan keçirilmişdir), biz tapşırıqlar üçün əslində skript yazmağa davam edə bilərik.

Skriptlər yazırıq

Ola bilsin ki, bir zamanlar, uzaq, çox uzaq bir qalaktikada, komanda xəttindən layihələrin (o cümlədən .net-də olanlar) qurulması ağrı idi. İndi siz layihəni 3 komandada qura, sınaqdan keçirə və dərc edə bilərsiniz:

dotnet build
dotnet test
dotnet pack

Təbii ki, bəzi nüanslar var ki, buna görə əmrləri bir qədər çətinləşdirəcəyik.

Biz sazlama quruluşu deyil, buraxılış quruluşu istəyirik, ona görə də hər əmrə əlavə edirik -c Release
Test zamanı biz kod əhatə dairəsi məlumatlarını toplamaq istəyirik, ona görə də test kitabxanalarına əhatə analizatorunu daxil etməliyik:
1. Paketi bütün test kitabxanalarına əlavə edin coverlet.msbuild: dotnet add package coverlet.msbuild layihə qovluğundan
2. Test işləmə əmrinə əlavə edin /p:CollectCoverage=true
3. Əhatə nəticələrini əldə etmək üçün test tapşırığı konfiqurasiyasına açar əlavə edin (aşağıya baxın)
Kodu nuget paketlərinə yığarkən, paketlər üçün çıxış kataloqunu təyin edin: -o .

Kod əhatə dairəsi məlumatlarının toplanması

Testləri yerinə yetirdikdən sonra Coverlet çapları konsolda statistikanı işlədir:

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 məlumatları əldə etmək üçün müntəzəm ifadəni təyin etməyə imkan verir ki, bu da sonra nişan şəklində əldə edilə bilər. Normal ifadə açarla tapşırıq parametrlərində müəyyən edilir coverage; ifadədə dəyəri nişana ötürülən tutma qrupu olmalıdır:

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

Burada ümumi xətti əhatə edən bir xəttdən statistika alırıq.

Paketləri və sənədləri dərc edin

Hər iki tədbir kəmərin son mərhələsi üçün nəzərdə tutulub - montaj və sınaqlar keçdiyi üçün biz öz inkişaflarımızı dünya ilə bölüşə bilərik.

Əvvəlcə paket mənbəyinə dərc etməyi düşünün:

Layihədə nuget konfiqurasiya faylı yoxdursa (nuget.config), yenisini yaradın: dotnet new nugetconfig

Nə üçün: təsvirin qlobal (istifadəçi və maşın) konfiqurasiyalarına yazma imkanı olmaya bilər. Səhvləri tutmamaq üçün biz sadəcə olaraq yeni yerli konfiqurasiya yaradırıq və onunla işləyirik.
Yerli konfiqurasiyaya yeni paket mənbəyi əlavə edək: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - yerli mənbə adı, kritik deyil
2. url - “Hesabların hazırlanması” mərhələsindən mənbənin URL-i, səh
3. organization - Azure DevOps-da təşkilat adı
4. gitlab variable - GitLab-a əlavə edilmiş giriş nişanı ilə dəyişənin adı ("Hesabların hazırlanması", səh. 11). Təbii ki, formatda $variableName
5. -StorePasswordInClearText - girişin qadağan edilmiş xətasını keçmək üçün hack (Mən bu dırmıqda ilk addım atan deyiləm)
6. Səhvlər olduqda, əlavə etmək faydalı ola bilər -verbosity detailed
Paketin mənbəyə göndərilməsi: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Biz bütün paketləri cari kataloqdan göndəririk *.nupkg.
2. name - yuxarıdakı addımdan.
3. key - istənilən xətt. Azure DevOps-da, feed to Connect pəncərəsində nümunə həmişə xəttdir az.
4. -skipduplicate - bu açar olmadan artıq mövcud paketi göndərməyə çalışarkən mənbə xəta qaytaracaq 409 Conflict; açarı ilə göndərmə atlanacaq.

İndi sənədlərin yaradılmasını quraq:

Əvvəlcə depoda, master filialında docfx layihəsini işə salırıq. Bunu etmək üçün əmri kökdən işə salın docfx init və bina sənədləri üçün əsas parametrləri interaktiv şəkildə təyin edin. Minimum layihənin qurulmasının ətraflı təsviri burada.
1. Konfiqurasiya edərkən çıxış qovluğunu müəyyən etmək vacibdir ..public - GitLab standart olaraq Səhifələr üçün mənbə kimi repozitoriyanın kökündəki ümumi qovluğun məzmununu götürür. Çünki layihə depoda yerləşdirilmiş qovluqda yerləşəcək - yolda yuxarı səviyyəyə çıxış əlavə edin.
Dəyişiklikləri GitLab-a köçürək.
Boru kəməri konfiqurasiyasına tapşırıq əlavə edin pages (GitLab Səhifələrində saytın nəşri tapşırıqları üçün ayrılmış söz):
1. Ssenari:
  1. nuget install docfx.console -version 2.51.0 - docfx quraşdırın; versiya paketin quraşdırılması yollarının düzgün olmasını təmin etmək üçün müəyyən edilmişdir.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - sənədlərin toplanması
2. Node artefaktları:

pages:
  # snip
  artifacts:
    paths:
      - public

docfx haqqında lirik təxribat

Əvvəllər layihə qurarkən mən sənədləşdirmə üçün kod mənbəyini həll faylı kimi göstərmişdim. Əsas çatışmazlıq, sənədlərin sınaq layihələri üçün də yaradılmasıdır. Bu lazım deyilsə, bu dəyəri node üçün təyin edə bilərsiniz metadata.src:

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

metadata.src.src: "../" - yerə nisbətən bir pillə yuxarı qalxırıq docfx.json, çünki nümunələrdə kataloq ağacını axtarmaq işləmir.
metadata.src.files: ["**/*.csproj"] - qlobal nümunə, biz bütün C# layihələrini bütün kataloqlardan toplayırıq.
metadata.src.exclude: ["*.tests*/**"] - qlobal model, hər şeyi olan qovluqlardan xaric edin .tests Başlıqda

Cəmi

Belə sadə bir konfiqurasiya cəmi yarım saat və bir neçə fincan qəhvə ilə yaradıla bilər ki, bu da kodun qurulduğunu və testlərin keçdiyini yoxlamağa, yeni paket qurmağa, sənədləri yeniləməyə və gözəl görünüşlərlə gözü sevindirməyə imkan verəcəkdir. Hər birləşmə sorğusu ilə layihənin README-də nişanlar və mastera göndərilir.

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

Nişanlardan söz düşmüşkən

Onların sayəsində hər şey başladı!

Boru kəməri statusları və kodu əhatə edən nişanlar GitLab-da Gtntral boru kəmərləri blokunda CI/CD parametrlərində mövcuddur:

Platformada sənədlərə keçid olan nişan yaratdım shields.io - orada hər şey olduqca sadədir, siz öz nişanınızı yarada və sorğu ilə ala bilərsiniz.

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

Azure DevOps Artifacts həmçinin sizə ən son versiya ilə paketlər üçün nişanlar yaratmağa imkan verir. Bunu etmək üçün Azure DevOps saytındakı mənbədə seçilmiş paket üçün nişan yarat üzərinə klikləməlisiniz və işarələmə işarəsini kopyalamalısınız:

Gözəllik əlavə etmək

Ümumi Konfiqurasiya Fraqmentlərinin Vurğulanması

Konfiqurasiyanı yazarkən və sənədləri axtararkən YAML-in maraqlı xüsusiyyəti ilə rastlaşdım - fraqmentlərin təkrar istifadəsi.

Tapşırıq parametrlərindən göründüyü kimi, onların hamısı etiket tələb edir windows koşucuda və birləşmə sorğusu mastera göndərildikdə/yaradıldıqda işə salınır (sənədlər istisna olmaqla). Yenidən istifadə edəcəyimiz fraqmentə bunu əlavə edək:

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

İndi tapşırıq təsvirində əvvəllər elan edilmiş fraqmenti daxil edə bilərik:

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

Fraqment adları tapşırıq kimi şərh edilməməsi üçün nöqtə ilə başlamalıdır.

Paket versiyası

Paket yaratarkən kompilyator komanda xəttinin keçidlərini, onlar olmadıqda isə layihə fayllarını yoxlayır; o, Versiya qovşağını tapdıqda onun dəyərini qurulan paketin versiyası kimi qəbul edir. Belə çıxır ki, yeni versiya ilə paket qurmaq üçün onu ya layihə faylında yeniləməlisən, ya da komanda xətti arqumenti kimi ötürməlisən.

Gəlin daha bir İstək siyahısı əlavə edək - versiyada iki kiçik rəqəm paketin ili və qurulma tarixi olsun və buraxılışdan əvvəlki versiyaları əlavə edək. Əlbəttə ki, siz bu məlumatları layihə faylına əlavə edə və hər təqdimatdan əvvəl yoxlaya bilərsiniz - lakin siz bunu boru kəmərində də edə bilərsiniz, kontekstdən paket versiyasını toplayıb komanda xətti arqumentindən keçirə bilərsiniz.

Razılaşaq ki, əgər commit mesajında kimi bir xətt varsa release (v./ver./version) <version number> (rev./revision <revision>)?, sonra paketin versiyasını bu sətirdən götürəcəyik, onu cari tarixlə əlavə edəcəyik və əmrə arqument kimi ötürəcəyik. dotnet pack. Xətt olmadıqda, sadəcə paketi yığmayacağıq.

Aşağıdakı skript bu problemi həll edir:

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

Tapşırığa skript əlavə etmək pack and deploy job və commit mesajında verilmiş sətirin mövcudluğunda paketlərin yığılmasına ciddi şəkildə riayət edin.

Ümumi

Təxminən yarım saat və ya bir saat vaxt sərf etdikdən sonra konfiqurasiyanı yazmağa, yerli güc qabığında sazlamaya və bəlkə də bir neçə uğursuz işə saldıqdan sonra adi tapşırıqları avtomatlaşdırmaq üçün sadə bir konfiqurasiya əldə etdik.

Əlbəttə ki, GitLab CI / CD bu təlimatı oxuduqdan sonra göründüyündən daha geniş və çoxşaxəlidir - bu heç doğru deyil. Orada hətta Auto DevOps, imkan verir

proqramlarınızı avtomatik aşkar edin, qurun, sınaqdan keçirin, yerləşdirin və nəzarət edin

İndi planlar Pulumi-dən istifadə edərək Azure-da proqramların yerləşdirilməsi və hədəf mühitin avtomatik müəyyən edilməsi üçün boru xəttini konfiqurasiya etməkdir ki, bu da növbəti məqalədə müzakirə olunacaq.

Mənbə: www.habr.com

(Demək olar ki,) mütləq başlanğıc üçün GitLab-da CI/CD üçün bələdçi