🥇 د (تقریبا) مطلق ابتکار لپاره په GitLab کې CI/CD ته لارښود

یا څنګه د اسانه کوډ کولو په یوه ماښام کې ستاسو د پروژې لپاره ښکلي بیجونه ترلاسه کړئ

شاید ، هر پراختیا کونکی چې په یو وخت کې لږترلږه د پالتو یوه پروژه لري د حالتونو ، کوډ پوښښ ، په نوټ کې د کڅوړې نسخو سره د ښکلي بیجونو په اړه خارښ لري ... او دا خارش ما د دې مقالې لیکلو لامل شوی. د دې لیکلو لپاره چمتو کولو کې ، ما دا ښکلا زما په یوه پروژه کې ترلاسه کړه:

دا مقاله به تاسو ته په GitLab کې د .Net Core ټولګي کتابتون پروژې لپاره د دوامداره ادغام او تحویل لومړني ترتیب له لارې پرمخ بوځي ، د GitLab پا pagesو ته د اسنادو خپرول ، او په Azure DevOps کې شخصي فیډ ته جوړ شوي کڅوړې فشار راوړي.

د VS کوډ د تمدید سره د پراختیا چاپیریال په توګه کارول کیده د GitLab کاري جریان (د پراختیایی چاپیریال څخه مستقیم د ترتیباتو فایل تایید کولو لپاره).

لنډ پیژندنه

CD - ایا دا هغه وخت دی کله چې تاسو یوازې فشار راوړی، او هرڅه دمخه په پیرودونکي باندې راوتلي؟

CI / CD څه شی دی او ولې تاسو ورته اړتیا لرئ - تاسو کولی شئ په اسانۍ سره ګوګل کړئ. په GitLab کې د پایپ لاینونو تنظیم کولو بشپړ اسناد ومومئ هم اسانه. دلته به په لنډه توګه او که امکان ولري، پرته له نیمګړتیاو څخه د سیسټم پروسه د الوتونکو د سترګو له نظره بیان کړم:

پراختیا کونکی ذخیره ته ژمنتیا لیږي ، د سایټ له لارې د ادغام غوښتنه رامینځته کوي ، یا په بل ډول، په ښکاره یا په ښکاره توګه پایپ لاین پیل کوي,
ټولې دندې د ترتیب څخه غوره شوي، کوم شرایط چې دوی ته اجازه ورکوي چې په ورکړل شوي شرایطو کې پیل شي،
دندې د خپلو مرحلو له مخې تنظیم شوي
مرحلې په بدل کې اجرا کیږي - i.e. موازي د دې مرحلې ټولې دندې بشپړې شوې،
که چیرې مرحله ناکامه شي (د بیلګې په توګه، لږترلږه د مرحلې یوه دنده ناکامه شي)، پایپ لاین ودریږي (تقریبا تل),
که ټولې مرحلې په بریالیتوب سره بشپړې شي، پایپ لاین بریالی ګڼل کیږي.

په دې توګه، موږ لرو:

پایپ لاین - د دندو یوه ټولګه چې په مرحلو کې تنظیم شوي په کوم کې چې تاسو کولی شئ جوړ کړئ ، ازموینه وکړئ ، بسته کوډ وکړئ ، د کلاوډ خدمت ته بشپړ شوی جوړښت ځای په ځای کړئ ، او داسې نور.
مرحله (پړاو) - د پایپ لاین تنظیم واحد، 1+ دنده لري،
دنده(د کار) په پایپ لاین کې د کار یو واحد دی. دا یو سکریپټ (لازمی)، د پیل شرایط، د خپرولو / کیشینګ آثارو لپاره ترتیبات، او نور ډیر څه لري.

په دې اساس، دنده کله چې د CI / CD تنظیم کول د دندو یوه ټولګه رامینځته کولو ته راځي چې د کوډونو او هنري اثارو جوړولو ، ازموینې او خپرولو لپاره ټولې اړینې کړنې پلي کوي.

د پیل کولو دمخه: ولې؟

ولې Gitlab؟

ځکه چې کله دا اړینه شوه چې د پالتو پروژو لپاره شخصي ذخیره جوړه شي، دوی په GitHub کې تادیه شوي، او زه لالچ وم. ذخیره وړیا شوې ، مګر تر دې دمه دا زما لپاره کافي دلیل ندی چې ګیټ هب ته لاړ شم.

ولې د Azure DevOps پایپ لاین نه دی؟

ځکه چې هلته ترتیب ابتدايي دی - د کمانډ لاین پوهه حتی اړتیا نلري. د بهرني ګیټ چمتو کونکو سره ادغام - په یو څو کلیکونو کې ، ذخیره ته د ژمنو لیږلو لپاره د SSH کیلي واردول - هم ، پایپ لاین په اسانۍ سره تنظیم شوی حتی د ټیمپلیټ څخه نه.

د پیل موقعیت: هغه څه چې تاسو یې لرئ او څه غواړئ

مونږیۍ لرو:

په GitLab کې ذخیره.

موږ غواړو:

د هر ادغام غوښتنې لپاره اتوماتیک مجلس او ازموینه ،
د هر ادغام غوښتنې لپاره کڅوړې رامینځته کول او ماسټر ته فشار ورکول ، پدې شرط چې د ژمنې پیغام کې یو مشخص کرښه شتون ولري ،
په Azure DevOps کې شخصي فیډ ته جوړ شوي کڅوړې لیږل،
په GitLab پاڼو کې د اسنادو او خپرونو راټولول،
بیجونه!11

تشریح شوي اړتیاوې په عضوي ډول د لاندې پایپ لاین ماډل کې راځي:

مرحله 1 - مجلس
- موږ کوډ راټولوو، د محصول فایلونه د هنري آثارو په توګه خپروو
مرحله 2 - ازموینه
- موږ د جوړونې مرحلې څخه اثار ترلاسه کوو ، ازموینې پرمخ وړو ، د کوډ پوښښ ډیټا راټولوو
دریمه مرحله - سپارل
- ټاسک 1 - د نوګټ کڅوړه جوړه کړئ او Azure DevOps ته یې واستوئ
- دنده 2 - موږ سایټ له xmldoc څخه د سرچینې کوډ کې راټولوو او په GitLab پاڼو کې یې خپروو

راځه چي پیل یی کړو!

د تشکیلاتو راټولول

د حسابونو چمتو کول

کې یو حساب جوړ کړئ د مایکروسافټ آزادی
ورتګ د Azure DevOps
موږ یوه نوې پروژه جوړه کوو
1. نوم - کوم
2. لید - کوم
کله چې تاسو د جوړونې تڼۍ باندې کلیک وکړئ، پروژه به رامینځته شي او تاسو به د هغې پاڼې ته لیږدول کیږئ. په دې پاڼه کې، تاسو کولی شئ د پروژې ترتیباتو ته لاړ شئ غیر ضروري ځانګړتیاوې غیر فعال کړئ (په لیست کې ښکته لینک -> عمومي کتنه -> د Azure DevOps خدماتو بلاک)
Atrifacts ته لاړ شئ، فیډ جوړ کړئ کلیک وکړئ
1. د سرچینې نوم دننه کړئ
2. لید غوره کړئ
3. ناڅاپه د عامه عامه سرچینو څخه کڅوړې شامل کړئد دې لپاره چې سرچینه په ډمپ نیوګټ کلون بدل نشي
د فیډ سره نښلول کلیک وکړئ، بصری سټوډیو غوره کړئ، د ماشین سیټ اپ بلاک څخه سرچینه کاپي کړئ
د حساب ترتیباتو ته لاړ شئ، د شخصي لاسرسي نښه غوره کړئ
د لاسرسي نوې نښه جوړه کړئ
1. نوم - ارواښاد
2. سازمان - اوسنی
3. د اعظمي 1 کال لپاره اعتبار
4. ساحه - بسته بندي/لوستل او لیکل
جوړ شوی نښه کاپي کړئ - کله چې موډل کړکۍ وتړل شي، ارزښت به شتون ونلري
په GitLab کې د ذخیره کولو ترتیباتو ته لاړ شئ، د CI / CD ترتیبات غوره کړئ
د متغیر بلاک پراخ کړئ، یو نوی اضافه کړئ
1. نوم - پرته له کوم ځای څخه (د کمانډ شیل کې به شتون ولري)
2. ارزښت - د 9 پراګراف څخه د لاسرسي نښه
3. د ماسک متغیر غوره کړئ

دا د مخکینۍ ترتیب بشپړوي.

د تنظیم کولو چوکاټ چمتو کول

په ډیفالټ ، په GitLab کې د CI/CD تشکیلات فایل کاروي .gitlab-ci.yml د ذخیرې له ریښې څخه. تاسو کولی شئ د ذخیره کولو تنظیماتو کې دې فایل ته خپل سري لاره تنظیم کړئ ، مګر پدې حالت کې دا اړین ندي.

لکه څنګه چې تاسو د توسیع څخه لیدلی شئ، فایل په بڼه کې یو ترتیب لري YAML. د اسنادو توضیحات په ګوته کوي چې کوم کیلي د ترتیب په پورتنۍ کچه کې شتون لري ، او په هرې نیستې کچې کې.

لومړی، راځئ چې د ترتیب کولو فایل کې د ډاکر عکس ته لینک اضافه کړو، په کوم کې چې دندې به ترسره شي. د دې لپاره موږ پیدا کوو په ډاکر هب کې د نیټ کور عکسونو پاڼه. د GitHub دلته یو مفصل لارښود شتون لري چې کوم عکس د مختلف کارونو لپاره غوره کړئ. د .Net Core 3.1 سره یو انځور زموږ د جوړولو لپاره مناسب دی، نو په ترتیب کې د لومړۍ کرښې اضافه کولو لپاره وړیا احساس وکړئ

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

اوس ، کله چې پایپ لاین د مایکروسافټ عکس ذخیره څخه پیل شي ، ټاکل شوی عکس به ډاونلوډ شي ، په کوم کې چې د تشکیلاتو ټولې دندې به اجرا شي.

بل ګام اضافه کول دي پړاود د ډیفالټ په واسطه، 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. د پوښښ پایلو ترلاسه کولو لپاره د ازموینې کاري ترتیب کې کلیدي اضافه کړئ (لاندې وګورئ)
کله چې کوډ په نوګټ کڅوړو کې بسته کړئ ، د کڅوړو لپاره د محصول لارښود تنظیم کړئ: -o .

د کوډ پوښښ ډاټا راټولول

د ازموینو له چلولو وروسته، د پوښښ چاپونه کنسول ته احصایې چلوي:

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

د بیجونو په اړه خبرې کول

د دوی له امله، وروسته له دې، هرڅه پیل شول!

د پایپ لاین حالتونو او کوډ پوښښ سره بیجونه د Gtntral پایپ لاین بلاک کې د CI/CD ترتیباتو کې په GitLab کې شتون لري:

ما په پلیټ فارم کې د اسنادو لینک سره بیج جوړ کړ shields.io - دلته هرڅه خورا ساده دي ، تاسو کولی شئ خپل بیج جوړ کړئ او د غوښتنې په کارولو سره یې ترلاسه کړئ.

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

د Azure DevOps آثار هم تاسو ته اجازه درکوي د وروستي نسخې سره د کڅوړو لپاره بیجونه رامینځته کړئ. د دې کولو لپاره ، د Azure DevOps سایټ کې سرچینې کې ، تاسو اړتیا لرئ د ټاکل شوي کڅوړې لپاره بیج جوړ کړئ کلیک وکړئ او د مارک ډاون مارک اپ کاپي کړئ:

ښکلا اضافه کول

د عامو تشکیلاتو ټوټې روښانه کول

پداسې حال کې چې د ترتیب لیکلو او د اسنادو له لارې لټون کول، زه د YAML په زړه پورې ځانګړتیا سره مخ شوم - د ټوټې بیا کارول.

لکه څنګه چې تاسو د کاري ترتیباتو څخه لیدلی شئ، دوی ټول ټګ ته اړتیا لري windows په رنر کې، او هغه وخت پیل کیږي کله چې د یوځای کولو غوښتنه ماسټر / جوړ شوي (د اسنادو پرته) ته لیږل کیږي. راځئ چې دا په هغه ټوټه کې اضافه کړو چې موږ به یې بیا کاروو:

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

او اوس موږ کولی شو هغه ټوټه دننه کړو چې دمخه یې د دندې توضیح کې اعلان کړی:

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

د ټوټې نومونه باید د نقطې سره پیل شي، ترڅو د دندې په توګه تشریح نشي.

د بسته بندي نسخه

کله چې بسته جوړه کړئ، کمپیلر د کمانډ لاین سویچونه ګوري، او د دوی په نشتوالي کې، د پروژې فایلونه؛ کله چې دا د نسخې نوډ ومومي، دا د هغې ارزښت اخلي لکه څنګه چې د بسته بندۍ نسخه جوړه شوې. دا معلومه شوه چې د نوې نسخې سره د کڅوړې جوړولو لپاره، تاسو اړتیا لرئ چې دا د پروژې فایل کې تازه کړئ یا یې د کمانډ لاین دلیل په توګه تېر کړئ.

راځئ چې یو بل د خوښې لیست اضافه کړو - اجازه راکړئ چې په نسخه کې کوچني دوه شمیرې کال وي او د بسته بندۍ نیټه جوړه کړئ ، او د مخکینۍ نسخې اضافه کړئ. البته، تاسو کولی شئ دا ډاټا د پروژې فایل کې اضافه کړئ او د هرې سپارنې دمخه یې وګورئ - مګر تاسو کولی شئ دا په پایپ لاین کې هم ترسره کړئ، د شرایطو څخه د کڅوړې نسخه راټول کړئ او د کمانډ لاین دلیل له لارې یې تېر کړئ.

راځئ موافقه وکړو چې که د ژمنې پیغام کې یو کرښه وي لکه 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 او د ژمنې پیغام کې د ورکړل شوي تار په شتون کې د کڅوړو مجلس په کلکه وګورئ.

ټول

د ترتیب لیکلو شاوخوا نیم ساعت یا یو ساعت مصرف کولو وروسته ، په محلي پاور شیل کې ډیبګ کول او احتمالا د یو څو ناکامو لانچونو سره ، موږ د معمول کارونو اتومات کولو لپاره یو ساده ترتیب ترلاسه کړ.

البته، د GitLab CI / CD خورا پراخه او څو اړخیزه ده په پرتله چې د دې لارښود لوستلو وروسته ښکاري - دا بالکل ریښتیا نه ده. هلته حتی Auto DevOps دیاجازه ورکول

په اتوماتيک ډول ستاسو غوښتنلیکونه کشف ، جوړ کړئ ، ازموینه وکړئ ، ځای په ځای کړئ او څارنه وکړئ

اوس پلانونه دي چې Azure ته د غوښتنلیکونو ځای په ځای کولو لپاره پایپ لاین تنظیم کړي ، د پلومي په کارولو سره او په اتوماتيک ډول د هدف چاپیریال ټاکي ، کوم چې به په راتلونکي مقاله کې پوښل شي.

سرچینه: www.habr.com

د (تقریبا) مطلق ابتکار لپاره په GitLab کې CI/CD ته لارښود