CI/CD-ის სახელმძღვანელო GitLab-ში (თითქმის) აბსოლუტური დამწყებთათვის

ან როგორ მიიღოთ ლამაზი სამკერდე ნიშნები თქვენი პროექტისთვის მარტივი კოდირების ერთ საღამოს

ალბათ, ყველა დეველოპერს, რომელსაც აქვს მინიმუმ ერთი შინაური ცხოველების პროექტი რაღაც მომენტში, აქვს ქავილი ლამაზი სამკერდე ნიშნების შესახებ სტატუსებით, კოდის დაფარვით, პაკეტის ვერსიებით nuget-ში... და ამ ქავილმა მიბიძგა დამეწერა ეს სტატია. მის დასაწერად მომზადებისას, ჩემს ერთ-ერთ პროექტში მივიღე ეს სილამაზე:

ეს სტატია გაგაცნობთ GitLab-ში .Net Core კლასის ბიბლიოთეკის პროექტის უწყვეტი ინტეგრაციისა და მიწოდების ძირითად დაყენებას, GitLab-ის გვერდებზე დოკუმენტაციის გამოქვეყნებას და Azure DevOps-ში ჩაშენებული პაკეტების კერძო არხზე გადატანას.

VS Code გამოიყენებოდა როგორც განვითარების გარემო გაფართოებით GitLab სამუშაო პროცესი (პარამეტრების ფაილის პირდაპირ დეველოპერული გარემოდან დასადასტურებლად).

მოკლე შესავალი

CD - ეს მაშინ არის, როდესაც თქვენ უბრალოდ აიძულეთ და ყველაფერი უკვე დაეცა კლიენტს?

რა არის CI/CD და რატომ გჭირდებათ ეს - შეგიძლიათ მარტივად მოძებნოთ გუგლი. იპოვეთ სრული დოკუმენტაცია GitLab-ში მილსადენების კონფიგურაციის შესახებ ასევე ადვილი. აქ მოკლედ და, თუ შესაძლებელია, ხარვეზების გარეშე აღვწერ სისტემის პროცესს ჩიტის თვალთახედვით:

• დეველოპერი აგზავნის commit-ს საცავში, ქმნის შერწყმის მოთხოვნას საიტის მეშვეობით, ან სხვა გზით, აშკარად ან ირიბად იწყებს მილსადენს,
• ყველა დავალება არჩეულია კონფიგურაციიდან, რომლის პირობებიც საშუალებას აძლევს მათ გაშვებას მოცემულ კონტექსტში,
• დავალებები ორგანიზებულია მათი ეტაპების მიხედვით,
• ეტაპები შესრულებულია რიგრიგობით - ე.ი. პარალელურად ამ ეტაპის ყველა დავალება დასრულებულია,
• თუ ეტაპი ვერ მოხერხდა (ანუ, სცენის ერთ-ერთი ამოცანა მაინც ვერ მოხერხდა), მილსადენი ჩერდება (თითქმის ყოველთვის),
• თუ ყველა ეტაპი წარმატებით დასრულდა, მილსადენი წარმატებულად ითვლება.

ამრიგად, ჩვენ გვაქვს:

• მილსადენი - ეტაპებად დალაგებული ამოცანების ნაკრები, რომლებშიც შეგიძლიათ შექმნათ, შეამოწმოთ, შეფუთოთ კოდი, განათავსოთ მზა კონსტრუქცია ღრუბლოვან სერვისზე და ა.შ.
• ეტაპი (ეტაპი) — მილსადენის ორგანიზაციული ერთეული, შეიცავს 1+ ამოცანას,
• დავალება (სამუშაო) არის სამუშაო ერთეული მილსადენში. იგი შედგება სკრიპტისგან (სავალდებულო), გაშვების პირობებისგან, არტეფაქტების გამოქვეყნების/ქეშირების პარამეტრებისგან და მრავალი სხვაგან.

შესაბამისად, CI / CD დაყენებისას დავალება მთავრდება ამოცანების ნაკრების შექმნაზე, რომელიც ახორციელებს ყველა საჭირო მოქმედებას კოდისა და არტეფაქტების შესაქმნელად, ტესტირებისა და გამოქვეყნებისთვის.

დაწყებამდე: რატომ?

• რატომ Gitlab?

იმის გამო, რომ როდესაც საჭირო გახდა შინაური ცხოველების პროექტებისთვის კერძო საცავების შექმნა, მათ გადახდიდნენ GitHub-ზე და მე ვიყავი ხარბ. საცავები უფასო გახდა, მაგრამ ჯერჯერობით ეს არ არის საკმარისი მიზეზი, რომ გადავიტანო GitHub-ში.

• რატომ არა Azure DevOps Pipelines?

რადგან იქ პარამეტრი ელემენტარულია - ბრძანების სტრიქონის ცოდნა არც კი არის საჭირო. ინტეგრაცია გარე git პროვაიდერებთან - რამდენიმე დაწკაპუნებით, SSH კლავიშების იმპორტი საცავში ვალდებულებების გასაგზავნად - ასევე, მილსადენის კონფიგურაცია მარტივად ხდება თუნდაც შაბლონიდან არა.

საწყისი პოზიცია: რა გაქვს და რა გინდა

Ჩვენ გვაქვს:

• საცავი GitLab-ში.

Ჩვენ გვინდა:

• ავტომატური შეკრება და ტესტირება თითოეული შერწყმის მოთხოვნისთვის,
• შექმენით პაკეტები ყოველი შერწყმის მოთხოვნისთვის და უბიძგებთ მასტერს, იმ პირობით, რომ არსებობს გარკვეული ხაზი commit შეტყობინებაში,
• ჩაშენებული პაკეტების გაგზავნა კერძო არხზე Azure DevOps-ში,
• დოკუმენტაციის შეკრება და გამოქვეყნება GitLab გვერდებზე,
• სამკერდე ნიშნები!11

აღწერილი მოთხოვნები ორგანულად ექცევა მილსადენის შემდეგ მოდელს:

• ეტაპი 1 - შეკრება
  • ჩვენ ვაგროვებთ კოდს, ვაქვეყნებთ გამომავალ ფაილებს არტეფაქტებად
• ეტაპი 2 - ტესტირება
  • ჩვენ ვიღებთ არტეფაქტებს მშენებლობის ეტაპიდან, ვატარებთ ტესტებს, ვაგროვებთ კოდის დაფარვის მონაცემებს
• ეტაპი 3 - წარდგენა
  • ამოცანა 1 - შექმენით nuget პაკეტი და გაგზავნეთ Azure DevOps-ში
  • დავალება 2 - ჩვენ ვაგროვებთ საიტს xmldoc-დან საწყის კოდში და ვაქვეყნებთ მას GitLab გვერდებზე

Დავიწყოთ!

კონფიგურაციის შეგროვება

ანგარიშების მომზადება

1. შექმენით ანგარიში Microsoft Azure

2. Წადი Azure DevOps

3. ჩვენ ვქმნით ახალ პროექტს

   1. სახელი - ნებისმიერი
   2. ხილვადობა - ნებისმიერი
      

4. როდესაც დააწკაპუნებთ ღილაკზე Create, პროექტი შეიქმნება და თქვენ გადამისამართდებით მის გვერდზე. ამ გვერდზე შეგიძლიათ გამორთოთ არასაჭირო ფუნქციები პროექტის პარამეტრებზე გადასვლით (ქვედა ბმული სიაში მარცხნივ -> მიმოხილვა -> Azure DevOps Services ბლოკი)
   

5. გადადით Atrifacts-ზე, დააწკაპუნეთ არხის შექმნაზე

   1. შეიყვანეთ წყაროს სახელი
   2. აირჩიეთ ხილვადობა
   3. მოხსენით მონიშვნა ჩართეთ პაკეტები საერთო საჯარო წყაროებიდან, რათა წყარო არ გადაიქცეს ნაგავსაყრელ ნუგეტ კლონად
      

6. დააწკაპუნეთ დაკავშირება შესანახად, აირჩიეთ Visual Studio, დააკოპირეთ Source Machine Setup ბლოკიდან
   

7. გადადით ანგარიშის პარამეტრებში, აირჩიეთ პერსონალური წვდომის ნიშანი
   

8. შექმენით ახალი წვდომის ნიშანი

   1. სახელი - თვითნებური
   2. ორგანიზაცია - მიმდინარე
   3. ძალაშია მაქსიმუმ 1 წელი
   4. სფერო - შეფუთვა/წაკითხვა და წერა
      

9. დააკოპირეთ შექმნილი ჟეტონი - მოდალური ფანჯრის დახურვის შემდეგ, მნიშვნელობა მიუწვდომელი იქნება

10. გადადით GitLab-ის საცავის პარამეტრებზე, აირჩიეთ CI / CD პარამეტრები
    

11. გააფართოვეთ ცვლადების ბლოკი, დაამატეთ ახალი

    1. სახელი - ნებისმიერი სივრცეების გარეშე (ხელმისაწვდომი იქნება ბრძანების გარსში)
    2. ღირებულება - წვდომის ნიშანი მე-9 პუნქტიდან
    3. აირჩიეთ ნიღაბი ცვლადი
       

ეს ასრულებს წინასწარ კონფიგურაციას.

კონფიგურაციის ჩარჩოს მომზადება

ნაგულისხმევად, CI/CD კონფიგურაცია GitLab-ში იყენებს ფაილს .gitlab-ci.yml საცავის ძირიდან. თქვენ შეგიძლიათ დააყენოთ ამ ფაილის თვითნებური გზა საცავის პარამეტრებში, მაგრამ ამ შემთხვევაში ეს არ არის აუცილებელი.

როგორც გაფართოებიდან ხედავთ, ფაილი შეიცავს კონფიგურაციას ფორმატში YAML. დოკუმენტაცია აწვდის ინფორმაციას, თუ რომელი გასაღებები შეიძლება შეიცავდეს კონფიგურაციის ზედა დონეზე და თითოეულ ჩადგმულ დონეზე.

პირველ რიგში, კონფიგურაციის ფაილში დავამატოთ ბმული დოკერის სურათზე, რომელშიც შესრულდება დავალებები. ამისათვის ჩვენ ვპოულობთ .Net Core სურათების გვერდი Docker Hub-ზე. In 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?

ყველაფერი ლოგიკურია - სტანდარტულად, runners (პასუხისმგებელია დავალების სკრიპტების შესრულებაზე და მოწოდებულია 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

მივიღეთ არა განსაკუთრებით ფუნქციონალური, მაგრამ მაინც სწორი მილსადენი.

ტრიგერების დაყენება

იმის გამო, რომ არცერთი ამოცანისთვის არ არის მითითებული ტრიგერის ფილტრები, მილსადენი იქნება სრულად უნდა შესრულდეს ყოველ ჯერზე, როდესაც commit გადადის საცავში. ვინაიდან ეს არ არის ზოგადად სასურველი ქცევა, ჩვენ დავაყენებთ ამოცანების ტრიგერების ფილტრებს.

ფილტრების კონფიგურაცია შესაძლებელია ორ ფორმატში: მხოლოდ/გარდა и წესები. მოკლედ, only/except საშუალებას გაძლევთ დააკონფიგურიროთ ფილტრები ტრიგერების მიხედვით (merge_request, მაგალითად - ადგენს დავალებას, რომელიც უნდა შესრულდეს ყოველ ჯერზე, როდესაც pull მოთხოვნა იქმნება და ყოველ ჯერზე, როდესაც commits იგზავნება ფილიალში, რომელიც არის წყარო შერწყმის მოთხოვნაში) და ფილიალების სახელები (რეგულარული გამონათქვამების გამოყენების ჩათვლით); 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

ბუნებრივია, არის რამდენიმე ნიუანსი, რის გამოც ჩვენ გარკვეულწილად გავართულებთ ბრძანებებს.

1. ჩვენ გვინდა გამოშვების build და არა გამართვის კონსტრუქცია, ამიტომ ვამატებთ თითოეულ ბრძანებას -c Release
2. ტესტირებისას ჩვენ გვინდა შევაგროვოთ კოდის დაფარვის მონაცემები, ამიტომ უნდა ჩავრთოთ დაფარვის ანალიზატორი ტესტის ბიბლიოთეკებში:
   1. დაამატეთ პაკეტი ყველა სატესტო ბიბლიოთეკაში coverlet.msbuild: dotnet add package coverlet.msbuild პროექტის საქაღალდიდან
   2. დაამატეთ ტესტის გაშვების ბრძანებას /p:CollectCoverage=true
   3. დაამატეთ გასაღები სატესტო დავალების კონფიგურაციაში დაფარვის შედეგების მისაღებად (იხ. ქვემოთ)
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+%)/

აქ ჩვენ ვიღებთ სტატისტიკას ხაზის მთლიანი დაფარვით.

გამოაქვეყნეთ პაკეტები და დოკუმენტაცია

ორივე მოქმედება დაგეგმილია მილსადენის ბოლო ეტაპზე - მას შემდეგ, რაც აწყობა და ტესტები გაიარა, ჩვენ შეგვიძლია გავუზიაროთ ჩვენი განვითარებები მსოფლიოს.

პირველ რიგში, განიხილეთ პაკეტის წყაროზე გამოქვეყნება:

1. თუ პროექტს არ აქვს nuget კონფიგურაციის ფაილი (nuget.config), შექმენით ახალი: dotnet new nugetconfig

   Რისთვის: სურათს შეიძლება არ ჰქონდეს ჩაწერის წვდომა გლობალურ (მომხმარებლისა და მანქანის) კონფიგურაციებზე. იმისათვის, რომ არ დავიჭიროთ შეცდომები, ჩვენ უბრალოდ ვქმნით ახალ ლოკალურ კონფიგურაციას და ვიმუშავებთ მასთან.

2. მოდით დავამატოთ პაკეტის ახალი წყარო ლოკალურ კონფიგურაციაში: 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
3. პაკეტის გაგზავნა წყაროზე: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
   1. ჩვენ ვაგზავნით ყველა პაკეტს მიმდინარე დირექტორიადან, ასე რომ *.nupkg.
   2. name - ზემოთ საფეხურიდან.
   3. key - ნებისმიერი ხაზი. Azure DevOps-ში, Connect to feed ფანჯარაში, მაგალითი ყოველთვის არის ხაზი az.
   4. -skipduplicate - ამ გასაღების გარეშე უკვე არსებული პაკეტის გაგზავნის მცდელობისას, წყარო დააბრუნებს შეცდომას 409 Conflict; გასაღებით, გაგზავნა გამოტოვებული იქნება.

ახლა მოდით დავაყენოთ დოკუმენტაციის შექმნა:

1. პირველ რიგში, საცავში, სამაგისტრო ფილიალში, ჩვენ ვაწარმოებთ docfx პროექტს. ამისათვის გაუშვით ბრძანება root-დან docfx init და ინტერაქტიულად დააყენეთ სამშენებლო დოკუმენტაციის ძირითადი პარამეტრები. პროექტის მინიმალური დაყენების დეტალური აღწერა აქ.
   1. კონფიგურაციისას მნიშვნელოვანია გამომავალი კატალოგის მითითება ..public - GitLab ნაგულისხმევად იღებს საჯარო საქაღალდის შიგთავსს საცავის ძირში, როგორც გვერდების წყარო. იმიტომ რომ პროექტი განთავსდება საცავში ჩადგმულ საქაღალდეში - დაამატეთ გამოსავალი ბილიკზე მაღლა დონეზე.
2. მოდით გადავიტანოთ ცვლილებები GitLab-ში.
3. დაამატეთ დავალება მილსადენის კონფიგურაციაში 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 ---
}

1. metadata.src.src: "../" - ადგილთან შედარებით ერთი საფეხურით მაღლა ავდივართ docfx.json, იმიტომ შაბლონებში, დირექტორიაში ხის ძიება არ მუშაობს.
2. metadata.src.files: ["**/*.csproj"] - გლობალური ნიმუში, ჩვენ ვაგროვებთ ყველა C # პროექტს ყველა დირექტორიიდან.
3. 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-ში CI/CD პარამეტრებში Gtntral მილსადენების ბლოკში:

მე შევქმენი ბეჯი პლატფორმაზე დოკუმენტაციის ბმულით shields.io - იქ ყველაფერი საკმაოდ მარტივია, შეგიძლიათ შექმნათ თქვენი საკუთარი ბეჯი და მიიღოთ იგი მოთხოვნის გამოყენებით.

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

Azure DevOps Artifacts ასევე საშუალებას გაძლევთ შექმნათ სამკერდე ნიშნები პაკეტებისთვის უახლესი ვერსიით. ამისათვის, Azure DevOps საიტის წყაროში, თქვენ უნდა დააჭიროთ შერჩეული პაკეტისთვის ბეჯის შექმნას და დააკოპიროთ მარკირების მარკირება:

სილამაზის დამატება

ხაზს უსვამს საერთო კონფიგურაციის ფრაგმენტებს

კონფიგურაციის წერისას და დოკუმენტაციის ძიებისას, წავაწყდი YAML-ის საინტერესო თვისებას - ფრაგმენტების ხელახლა გამოყენებას.

როგორც დავალების პარამეტრებიდან ხედავთ, ყველა მათგანს სჭირდება ტეგი windows runner-ზე და ამოქმედდება, როდესაც შერწყმის მოთხოვნა ეგზავნება მასტერს/შექმნილს (გარდა დოკუმენტაციისა). მოდით ეს დავამატოთ ფრაგმენტს, რომელსაც ხელახლა გამოვიყენებთ:

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

ახლა ჩვენ შეგვიძლია ჩავსვათ ადრე გამოცხადებული ფრაგმენტი დავალების აღწერაში:

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

ფრაგმენტების სახელები უნდა იწყებოდეს წერტილით, რათა არ იყოს განმარტებული, როგორც დავალება.

პაკეტის ვერსიირება

პაკეტის შექმნისას შემდგენელი ამოწმებს ბრძანების ხაზის გადამრთველებს, ხოლო მათი არყოფნის შემთხვევაში პროექტის ფაილებს; როდესაც ის პოულობს ვერსიის კვანძს, ის იღებს მის მნიშვნელობას, როგორც შემუშავებული პაკეტის ვერსიას. ირკვევა, რომ ახალი ვერსიით პაკეტის ასაგებად, თქვენ უნდა განაახლოთ იგი პროექტის ფაილში ან გადასცეთ იგი ბრძანების ხაზის არგუმენტად.

მოდით დავამატოთ კიდევ ერთი Wishlist - ვერსიის მცირე ორი რიცხვი იყოს პაკეტის აგების წელი და თარიღი და დავამატოთ წინასწარი გამოშვების ვერსიები. რა თქმა უნდა, თქვენ შეგიძლიათ დაამატოთ ეს მონაცემები პროექტის ფაილში და შეამოწმოთ ყოველი წარდგენის წინ - მაგრამ თქვენ ასევე შეგიძლიათ ამის გაკეთება მილსადენში, შეაგროვოთ პაკეტის ვერსია კონტექსტიდან და გადაიტანოთ იგი ბრძანების ხაზის არგუმენტში.

მოდით შევთანხმდეთ, რომ თუ commit შეტყობინება შეიცავს მსგავს ხაზს 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 და მკაცრად დააკვირდით პაკეტების აწყობას commit შეტყობინებაში მოცემული სტრიქონის თანდასწრებით.

საერთო ჯამში

დაახლოებით ნახევარი საათის ან საათის დახარჯვის შემდეგ კონფიგურაციის დაწერაზე, ადგილობრივ powershell-ში გამართვისა და, შესაძლოა, რამდენიმე წარუმატებელი გაშვების შემდეგ, მივიღეთ მარტივი კონფიგურაცია რუტინული ამოცანების ავტომატიზაციისთვის.

რა თქმა უნდა, GitLab CI / CD ბევრად უფრო ვრცელი და მრავალმხრივია, ვიდრე ეს შეიძლება ჩანდეს ამ სახელმძღვანელოს წაკითხვის შემდეგ - ეს საერთოდ არ არის სიმართლე. იქ კი Auto DevOps არის, საშუალებას იძლევა

თქვენი აპლიკაციების ავტომატურად აღმოჩენა, შექმნა, ტესტირება, დანერგვა და მონიტორინგი

ახლა გეგმებია მილსადენის კონფიგურაცია Azure-ში აპლიკაციების განლაგებისთვის, Pulumi-ის გამოყენებით და სამიზნე გარემოს ავტომატურად განსაზღვრისთვის, რაც მომდევნო სტატიაში იქნება განხილული.

წყარო: www.habr.com