ProHoster > Օրագիր > Վարչակազմը > CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

Կամ ինչպես ստանալ գեղեցիկ կրծքանշաններ ձեր նախագծի համար հեշտ կոդավորման մեկ երեկոյան

Հավանաբար, յուրաքանչյուր ծրագրավորող, ով ինչ-որ պահի ունի գոնե մեկ ընտանի կենդանիների նախագիծ, քոր է զգում գեղեցիկ կրծքանշանների մասին՝ ստատուսներով, ծածկագրով ծածկույթով, փաթեթային տարբերակներով nuget-ում... Եվ այս քորը ստիպեց ինձ գրել այս հոդվածը: Նախապատրաստվելով այն գրելուն, ես ստացա այս գեղեցկությունը իմ նախագծերից մեկում.

CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

Այս հոդվածը ձեզ կուղեկցի GitLab-ում .Net Core դասի գրադարանային նախագծի շարունակական ինտեգրման և առաքման հիմնական կարգավորումները, փաստաթղթերը GitLab էջերում հրապարակելը և Azure DevOps-ում ներկառուցված փաթեթները մասնավոր հոսքի վրա դնելը:

VS Code-ը օգտագործվել է որպես ընդլայնման մշակման միջավայր GitLab Workflow (Կարգավորումների ֆայլը անմիջապես մշակման միջավայրից վավերացնելու համար):

Կարճ ներկայացում

CD - արդյո՞ք դա այն ժամանակ է, երբ դուք պարզապես հրել եք, և ամեն ինչ արդեն ընկել է հաճախորդի վրա:

Ինչ է CI / CD-ն և ինչու է այն ձեզ անհրաժեշտ, հեշտությամբ կարող եք google-ում փնտրել այն: Գտեք GitLab-ում խողովակաշարերի կազմաձևման վերաբերյալ ամբողջական փաստաթղթեր նաև հեշտ. Այստեղ ես հակիրճ և, հնարավորության դեպքում, առանց թերությունների կնկարագրեմ համակարգի գործընթացը թռչնի հայացքից.

  • ծրագրավորողը commit է ուղարկում պահեստ, ստեղծում է միաձուլման հարցում կայքի միջոցով, կամ այլ կերպ, բացահայտ կամ անուղղակի կերպով սկսում է խողովակաշարը,
  • բոլոր առաջադրանքները ընտրվում են կոնֆիգուրացիայից, որոնց պայմանները թույլ են տալիս գործարկել տվյալ համատեքստում,
  • առաջադրանքները կազմակերպվում են ըստ իրենց փուլերի,
  • փուլերը կատարվում են հերթով, այսինքն. զուգահեռ այս փուլի բոլոր առաջադրանքները ավարտված են,
  • եթե փուլը ձախողվի (այսինքն՝ բեմի առաջադրանքներից գոնե մեկը ձախողվի), խողովակաշարը դադարում է (գրեթե միշտ),
  • եթե բոլոր փուլերը հաջողությամբ ավարտվեն, խողովակաշարը համարվում է հաջողված:

Այսպիսով, մենք ունենք.

  • խողովակաշար - փուլերով կազմակերպված առաջադրանքների մի շարք, որոնցում դուք կարող եք ստեղծել, փորձարկել, փաթեթավորել ծածկագիրը, ավարտված շինարարությունը տեղադրել ամպային ծառայության մեջ և այլն,
  • փուլ (փուլ) — խողովակաշարի կազմակերպման միավոր, պարունակում է 1+ առաջադրանք,
  • առաջադրանք (աշխատանք) խողովակաշարում աշխատանքի միավոր է: Այն բաղկացած է սկրիպտից (պարտադիր), գործարկման պայմաններից, արտեֆակտների հրապարակման/քեշավորման կարգավորումներից և շատ ավելին:

Համապատասխանաբար, CI / CD-ն կարգավորելիս առաջադրանքը հանգում է առաջադրանքների մի շարք ստեղծելուն, որոնք իրականացնում են բոլոր անհրաժեշտ գործողությունները կոդի և արտեֆակտների կառուցման, փորձարկման և հրապարակման համար:

Նախքան սկսելը. ինչու:

  • Ինչու՞ Gitlab:

Քանի որ երբ անհրաժեշտություն առաջացավ ստեղծել մասնավոր պահոցներ կենդանիների նախագծերի համար, դրանք վճարվում էին GitHub-ում, և ես ագահ էի: Պահեստները դարձել են անվճար, բայց առայժմ դա բավարար պատճառ չէ, որպեսզի ես տեղափոխվեմ GitHub:

  • Ինչու՞ ոչ Azure DevOps խողովակաշարերը:

Քանի որ այնտեղ պարամետրը տարրական է, հրամանի տողի իմացությունը նույնիսկ պարտադիր չէ: Ինտեգրում արտաքին git պրովայդերների հետ՝ մի քանի կտտոցով, SSH ստեղների ներմուծում՝ պարտավորություններ պահեստ ուղարկելու համար, նույնպես, խողովակաշարը հեշտությամբ կազմաձևվում է նույնիսկ ոչ կաղապարից:

Մեկնարկային դիրք՝ ինչ ունես և ինչ ես ուզում

Մենք ունենք:

  • պահոց GitLab-ում:

Ուզում ենք:

  • ավտոմատ հավաքում և փորձարկում յուրաքանչյուր միաձուլման հարցման համար,
  • ստեղծելով փաթեթներ յուրաքանչյուր միաձուլման խնդրանքի համար և մղել դեպի Master, պայմանով, որ որոշակի տող կա commit հաղորդագրության մեջ,
  • ներկառուցված փաթեթներ ուղարկելով Azure DevOps-ի մասնավոր հոսքին,
  • փաստաթղթերի հավաքում և հրապարակում GitLab էջերում,
  • կրծքանշաններ!11

Նկարագրված պահանջները օրգանապես ընկնում են խողովակաշարի հետևյալ մոդելի վրա.

  • Փուլ 1 - հավաքում
    • Մենք հավաքում ենք կոդը, հրապարակում ենք ելքային ֆայլերը որպես արտեֆակտ
  • Փուլ 2 - փորձարկում
    • Մենք արտեֆակտներ ենք ստանում կառուցման փուլից, փորձարկումներ ենք կատարում, հավաքում կոդի ծածկույթի տվյալներ
  • Փուլ 3 - Ներկայացնել
    • Առաջադրանք 1 - կառուցեք nuget փաթեթը և ուղարկեք այն Azure DevOps-ին
    • Առաջադրանք 2 - մենք կայքը հավաքում ենք xmldoc-ից սկզբնաղբյուրում և հրապարակում այն ​​GitLab էջերում

Եկեք սկսենք!

Կազմաձևի հավաքում

Հաշիվների պատրաստում

  1. Ստեղծեք հաշիվ Microsoft Azure- ը

  2. Գնալ Azure DevOps

  3. Մենք ստեղծում ենք նոր նախագիծ

    1. Անունը - ցանկացած
    2. Տեսանելիություն - ցանկացած
      CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

  4. Երբ սեղմում եք Ստեղծել կոճակը, նախագիծը կստեղծվի, և դուք կվերահղվեք նրա էջ: Այս էջում դուք կարող եք անջատել ավելորդ գործառույթները՝ անցնելով նախագծի կարգավորումներ (ձախ կողմում գտնվող ցանկի ստորին հղումը -> Overview -> Azure DevOps Services բլոկ)
    CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

  5. Գնացեք Atrifacts, սեղմեք Ստեղծել հոսք

    1. Մուտքագրեք աղբյուրի անունը
    2. Ընտրեք տեսանելիությունը
    3. Անջատեք նշումը Ներառեք փաթեթներ ընդհանուր հանրային աղբյուրներից, որպեսզի աղբյուրը չվերածվի dump nuget clone-ի
      CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

  6. Սեղմեք Connect to feed, ընտրեք Visual Studio, պատճենեք Source-ը Machine Setup բլոկից
    CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

  7. Գնացեք հաշվի կարգավորումներ, ընտրեք Անձնական մուտքի նշան
    CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

  8. Ստեղծեք նոր մուտքի նշան

    1. Անունը - կամայական
    2. Կազմակերպություն - ընթացիկ
    3. Գործում է առավելագույնը 1 տարի
    4. Շրջանակ - Փաթեթավորում/Կարդալ և գրել
      CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

  9. Պատճենել ստեղծված նշանը - մոդալ պատուհանը փակելուց հետո արժեքը անհասանելի կլինի

  10. Գնացեք GitLab-ի պահեստի կարգավորումները, ընտրեք CI / CD կարգավորումները
    CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

  11. Ընդարձակեք փոփոխականների բլոկը, ավելացրեք նորը

    1. Անունը՝ ցանկացած առանց բացատների (հասանելի կլինի հրամանի վահանակում)
    2. Արժեք - մուտքի նշան 9-րդ պարբերությունից
    3. Ընտրեք Դիմակ փոփոխական
      CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

Սա ավարտում է նախնական կազմաձևումը:

Կազմաձևման շրջանակի պատրաստում

Լռելյայնորեն, CI/CD-ի կոնֆիգուրացիան GitLab-ում օգտագործում է ֆայլը .gitlab-ci.yml շտեմարանի արմատից։ Դուք կարող եք կամայական ուղի սահմանել դեպի այս ֆայլը պահեստի կարգավորումներում, բայց այս դեպքում դա անհրաժեշտ չէ:

Ինչպես տեսնում եք ընդլայնումից, ֆայլը պարունակում է կոնֆիգուրացիա ձևաչափով YAML. Փաստաթղթերը մանրամասնում են, թե որ ստեղները կարող են պարունակվել կազմաձևման վերին մակարդակում և յուրաքանչյուր ներդիր մակարդակում:

Նախ, կոնֆիգուրացիայի ֆայլում ավելացնենք հղում դոկերի պատկերին, որում կկատարվեն առաջադրանքները։ Դրա համար մենք գտնում ենք .Net Core պատկերների էջ Docker Hub-ում: Մեջ 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, օրինակ - սահմանում է առաջադրանքը, որը պետք է կատարվի ամեն անգամ, երբ ստեղծվում է pull-ի հարցում և ամեն անգամ, երբ commit-ներն ուղարկվում են միաձուլման հարցումի աղբյուր հանդիսացող մասնաճյուղին) և մասնաճյուղերի անունները (ներառյալ կանոնավոր արտահայտությունների օգտագործումը); 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. Մենք ցանկանում ենք թողարկման կառուցում, այլ ոչ թե վրիպազերծման, այնպես որ մենք ավելացնում ենք յուրաքանչյուր հրամանին -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 նախագիծը: Դա անելու համար գործարկեք հրամանը արմատից 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 խողովակաշարերի բլոկում.

CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

Ես ստեղծել եմ կրծքանշան՝ հարթակի փաստաթղթերին հղումով shields.io - այնտեղ ամեն ինչ բավականին պարզ է, դուք կարող եք ստեղծել ձեր սեփական կրծքանշանը և ստանալ այն՝ օգտագործելով հարցումը:

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

CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

Azure DevOps Artifacts-ը նաև թույլ է տալիս ստեղծել կրծքանշաններ փաթեթների համար վերջին տարբերակով: Դա անելու համար Azure DevOps կայքի սկզբնաղբյուրում անհրաժեշտ է սեղմել «Ստեղծել կրծքանշան ընտրված փաթեթի համար» և պատճենել նշագրման նշումը.

CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

CI/CD-ի ուղեցույց GitLab-ում (գրեթե) բացարձակ սկսնակների համար

Գեղեցկության ավելացում

Ընդգծելով ընդհանուր կազմաձևման բեկորները

Կոնֆիգուրացիան գրելիս և փաստաթղթերը փնտրելիս ես հանդիպեցի YAML-ի հետաքրքիր առանձնահատկությունին` բեկորների վերօգտագործմանը:

Ինչպես տեսնում եք առաջադրանքի կարգավորումներից, բոլորն էլ պահանջում են պիտակ windows վազողում և գործարկվում են, երբ միաձուլման հարցումն ուղարկվում է վարպետին/ստեղծվում է (բացառությամբ փաստաթղթերի): Եկեք սա ավելացնենք այն հատվածին, որը մենք նորից կօգտագործենք.

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

Եվ այժմ մենք կարող ենք տեղադրել ավելի վաղ հայտարարված հատվածը առաջադրանքի նկարագրության մեջ.

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

Հատվածների անունները պետք է սկսվեն կետով, որպեսզի չմեկնաբանվեն որպես առաջադրանք:

Փաթեթի տարբերակում

Փաթեթ ստեղծելիս կոմպիլյատորը ստուգում է հրամանի տողի անջատիչները, իսկ դրանց բացակայության դեպքում՝ նախագծի ֆայլերը; երբ այն գտնում է Տարբերակի հանգույց, այն ընդունում է դրա արժեքը որպես կառուցվող փաթեթի տարբերակ: Ստացվում է, որ նոր տարբերակով փաթեթ կառուցելու համար պետք է կամ թարմացնել այն նախագծի ֆայլում, կամ փոխանցել որպես հրամանի տող արգումենտ։

Եկեք ավելացնենք ևս մեկ Ցանկության ցանկ. թող տարբերակի փոքր երկու համարները լինեն փաթեթի տարին և ստեղծման ամսաթիվը, և ավելացնենք նախնական թողարկման տարբերակները: Իհարկե, դուք կարող եք ավելացնել այս տվյալները նախագծի ֆայլին և ստուգել յուրաքանչյուր ներկայացումից առաջ, բայց կարող եք նաև դա անել խողովակաշարի մեջ՝ համատեքստից հավաքելով փաթեթի տարբերակը և փոխանցելով այն հրամանի տողի փաստարկով:

Եկեք համաձայնենք, որ եթե 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-ն և ավտոմատ կերպով որոշել թիրախային միջավայրը, որը կքննարկվի հաջորդ հոդվածում:

Source: www.habr.com

Добавить комментарий