🥇(дээрлик) абсолюттук башталгычтар үчүн GitLab'та CI/CD гид

Же оңой коддоонун бир кечинде долбооруңуз үчүн кооз төш белгилерди кантип алууга болот

Мүмкүн, кандайдыр бир учурда жок дегенде бир үй жаныбары долбоору бар ар бир иштеп чыгуучу статустары бар кооз төш белгилер, коддун камтуусу, nugetтин пакет версиялары жөнүндө кычышса керек ... Жана бул кычыштыруу мени бул макаланы жазууга алып келди. Аны жазууга даярданып жатып, мен бул сулуулукту долбоорлорумдун биринде алдым:

Бул макала сизди GitLab ичиндеги .Net Core класс китепканасы долбоору үчүн үзгүлтүксүз интеграциялоонун жана жеткирүүнүн негизги жөндөөлөрү, GitLab баракчаларына документтерди жарыялоо жана Azure DevOps ичиндеги жеке каналга курулган пакеттерди түртүү аркылуу көрсөтөт.

VS Code кеңейтүү менен иштеп чыгуу чөйрөсү катары колдонулган GitLab Workflow (түздөн-түз иштеп чыгуу чөйрөсүнөн орнотуулар файлын текшерүү үчүн).

кыскача киришүү

CD - сиз жөн гана түртүп, баары кардарга түшүп калганбы?

CI / CD деген эмне жана ал эмне үчүн керек - сиз аны оңой эле Google таба аласыз. GitLab'да түтүктөрдү конфигурациялоо боюнча толук документтерди табыңыз да жеңил. Бул жерде мен кыскача жана мүмкүн болсо, кемчиликсиз системанын процессин куштун көз карашынан сүрөттөп берем:

иштеп чыгуучу репозиторийге милдеттенме жөнөтөт, сайт аркылуу бириктирүү өтүнүчүн түзөт, же кандайдыр бир башка жол менен, ачык же кыйыр түрдө куурду баштайт,
бардык тапшырмалар конфигурациядан тандалып алынат, анын шарттары аларды берилген контекстте ишке киргизүүгө мүмкүндүк берет,
милдеттери этаптарына жараша уюштурулган,
этаптары кезеги менен аткарылат - б.а. параллель бул этаптын бардык милдеттери аяктады,
этап ишке ашпай калса (б.а., этаптын тапшырмаларынын жок дегенде бири аткарылбай калса), түтүк токтойт (дээрлик ар дайым),
бардык этаптары ийгиликтүү аяктаган болсо, куур ийгиликтүү деп эсептелет.

Ошентип, бизде:

конвейер - этаптарга бөлүнгөн тапшырмалардын жыйындысы, анда сиз кура аласыз, сынай аласыз, кодду топтой аласыз, даяр түзүүнү булут кызматына жайгаштыра аласыз ж.б.,
этап (сахна) — түтүктөрдү уюштуруу бирдиги, 1+ тапшырманы камтыйт,
тапшырма (иш) трубадагы иштин бирдиги болуп саналат. Ал скрипттен (милдеттүү), ишке киргизүү шарттарынан, артефакттарды жарыялоо/кэштөө үчүн орнотуулардан жана башка көптөгөн нерселерден турат.

Демек, CI / CDди орнотууда тапшырма кодду жана артефакттарды куруу, тестирлөө жана жарыялоо үчүн бардык зарыл иш-аракеттерди ишке ашырган тапшырмалардын комплексин түзүүгө туура келет.

Баштоодон мурун: эмне үчүн?

Эмне үчүн Gitlab?

Анткени үй жаныбарлары үчүн долбоорлор үчүн жеке репозиторийлерди түзүү зарыл болуп калганда, алар GitHubда төлөнүп, мен ач көз болдум. Репозиторийлер акысыз болуп калды, бирок азырынча бул мен үчүн GitHub'ка өтүү үчүн жетиштүү себеп эмес.

Эмне үчүн Azure DevOps Pipelines эмес?

Анткени ал жерде жөндөө элементардык - буйрук сабын билүү талап кылынбайт. Тышкы git провайдерлери менен интеграция - бир нече чыкылдатуу менен, репозиторийге милдеттенмелерди жөнөтүү үчүн SSH ачкычтарын импорттоо - ошондой эле конфигурация шаблондон эмес, оңой конфигурацияланат.

Баштапкы позиция: сизде эмне бар жана сиз эмнени каалайсыз

Бизде бар:

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

Биз каалайбыз:

ар бир бириктирүү өтүнүчү үчүн автоматтык чогултуу жана сыноо,
ар бир бириктирүү өтүнүчү үчүн пакеттерди түзүү жана кожоюнга түртүү, эгерде милдеттенме билдирүүсүндө белгилүү бир сызык бар болсо,
Azure DevOps ичиндеги жеке каналга курулган пакеттерди жөнөтүү,
GitLab баракчаларында документтерди чогултуу жана жарыялоо,
белгилер!11

сүрөттөлгөн талаптар органикалык төмөнкү түтүк моделине түшөт:

1-этап - чогултуу
- Биз кодду чогултабыз, чыгуу файлдарын артефакт катары жарыялайбыз
2-этап - тестирлөө
- Биз артефакттарды куруу стадиясынан алабыз, тесттерди өткөрөбүз, коддун камтуу маалыматтарын чогултабыз
3-этап - тапшыруу
- 1-тапшырма - nuget пакетин түзүп, аны Azure DevOps'ка жөнөтүңүз
- 2-милдет - биз сайтты xmldoc'тен баштапкы коддон чогултуп, GitLab баракчаларында жарыялайбыз

Баштадык!

Конфигурацияны чогултуу

Эсептерди даярдоо

Каттоо эсебин түзүңүз Microsoft Берилл
Мурунку Azure DevOps
Биз жаңы долбоор түзөбүз
1. Аты - каалаган
2. Көрүнүү - каалаган
Түзүү баскычын басканда, долбоор түзүлөт жана сиз анын баракчасына багытталасыз. Бул баракта, сиз долбоордун жөндөөлөрүнө өтүп, керексиз функцияларды өчүрө аласыз (сол жактагы тизмедеги төмөнкү шилтеме -> Обзор -> Azure DevOps Кызматтары блогу)
Atrifacts бөлүмүнө өтүп, каналды түзүү чыкылдатыңыз
1. Булактын атын киргизиңиз
2. Көрүнүүнү тандаңыз
3. Белекти алып салуу Жалпы коомдук булактардан топтомдорду кошуңуз, булак таштанды нугет клонуна айланбашы үчүн
Тамактандыруу үчүн Connect дегенди басыңыз, Visual Studio тандаңыз, Machine Setup блогунан Source көчүрүңүз
Каттоо эсебинин жөндөөлөрүнө өтүп, Жеке мүмкүндүк алуу белгисин тандаңыз
Жаңы мүмкүндүк алуу белгисин түзүңүз
1. Аты - эркин
2. Уюштуруу - учурдагы
3. Эң көп дегенде 1 жылга жарактуу
4. Колдонуу чөйрөсү - таңгактоо/окуу жана жазуу
Түзүлгөн белгини көчүрүү - модалдык терезе жабылгандан кийин, маани жеткиликсиз болуп калат
GitLab репозиторийинин жөндөөлөрүнө өтүп, CI / CD орнотууларын тандаңыз
Variables блогун кеңейтиңиз, жаңысын кошуңуз
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

Фрагменттердин аттары тапшырма катары чечмеленбеши үчүн чекит менен башталышы керек.

Пакет версиясы

Пакетти түзүүдө компилятор буйрук сабынын коммутаторлорун, ал эми алар жок болгон учурда долбоордун файлдарын текшерет; ал Version түйүнүн тапканда, ал курулуп жаткан пакеттин версиясы катары анын маанисин алат. Көрсө, жаңы версиясы бар пакетти куруу үчүн аны долбоордун файлында жаңыртышыңыз керек же буйрук сабынын аргументи катары өткөрүшүңүз керек.

Келгиле, дагы бир Каалоо тизмесин кошолу - версиядагы эки кичинекей сан топтомдун жылы жана түзүлгөн күнү болсун жана релизге чейинки версияларды кошолу. Албетте, сиз бул маалыматтарды долбоордун файлына кошуп, ар бир тапшыруунун алдында текшере аласыз - бирок сиз аны контексттен топтомдун версиясын чогултуп, аны буйрук сабынын аргументи аркылуу өткөрө аласыз.

Келгиле, макулдук берели, эгерде 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 жана пакеттерди чогултуу жөнүндө билдирүүдө берилген сап болгон учурда катуу сактаңыз.

жалпы

Жарым саат же бир сааттай конфигурацияны жазууга, жергиликтүү powershellде мүчүлүштүктөрдү оңдоого жана, балким, бир нече ийгиликсиз ишке киргизүүгө кеткенден кийин, биз күнүмдүк тапшырмаларды автоматташтыруу үчүн жөнөкөй конфигурацияга ээ болдук.

Албетте, GitLab CI / CD бул колдонмону окугандан кийин көрүнгөндөн алда канча кеңири жана көп кырдуу - бул такыр туура эмес. Ал тургай, ошол жерде Auto DevOps болуп саналатуруксат берүү

тиркемелериңизди автоматтык түрдө аныктоо, куруу, сынап көрүү, жайылтуу жана көзөмөлдөө

Эми пландар Pulumi аркылуу Azure тиркемелерин жайылтуу жана максаттуу чөйрөнү автоматтык түрдө аныктоо үчүн конфигурациялоо болуп саналат, алар кийинки макалада каралат.

Source: www.habr.com

(дээрлик) абсолюттук башталгыч үчүн GitLab ичинде CI/CD боюнча колдонмо