راهنمای CI/CD در GitLab برای مبتدیان (تقریباً).

یا اینکه چگونه در یک شب کدنویسی آسان، نشان های زیبایی برای پروژه خود دریافت کنید

احتمالاً، هر توسعه‌دهنده‌ای که حداقل یک پروژه حیوان خانگی داشته باشد، در مورد نشان‌های زیبا با وضعیت‌ها، پوشش کد، نسخه‌های بسته در nuget ... و این خارش باعث شد من این مقاله را بنویسم. در آماده سازی برای نوشتن آن، این زیبایی را در یکی از پروژه هایم دریافت کردم:

این مقاله شما را از طریق راه اندازی اولیه یکپارچه سازی و تحویل مداوم برای پروژه کتابخانه کلاس Net Core در GitLab، انتشار اسناد در صفحات GitLab و انتقال بسته های ساخته شده به یک فید خصوصی در Azure DevOps راهنمایی می کند.

VS Code به عنوان محیط توسعه با پسوند استفاده شد گردش کار GitLab (برای اعتبارسنجی فایل تنظیمات به طور مستقیم از محیط توسعه).

معرفی مختصر

سی دی - آیا زمانی است که شما فقط فشار داده اید، و همه چیز قبلاً روی مشتری افتاده است؟

CI / CD چیست و چرا به آن نیاز دارید - به راحتی می توانید آن را در گوگل جستجو کنید. اسناد کامل پیکربندی خطوط لوله را در GitLab بیابید همچنین آسان است. در اینجا من به طور خلاصه و در صورت امکان بدون نقص، روند سیستم را از دید پرنده شرح خواهم داد:

• توسعه دهنده یک commit به مخزن می فرستد، یک درخواست ادغام از طریق سایت ایجاد می کند، یا به روشی دیگر به طور صریح یا ضمنی خط لوله را شروع می کند,
• همه وظایف از پیکربندی انتخاب می شوند، شرایطی که به آنها اجازه می دهد در زمینه داده شده راه اندازی شوند،
• وظایف بر اساس مراحل آنها سازماندهی می شوند،
• مراحل به نوبه خود اجرا می شوند - یعنی. موازی تمام وظایف این مرحله تکمیل شده است،
• اگر مرحله شکست بخورد (یعنی حداقل یکی از وظایف مرحله شکست بخورد)، خط لوله متوقف می شود (تقریبا همیشه),
• اگر تمام مراحل با موفقیت به پایان برسد، خط لوله موفق در نظر گرفته می شود.

بنابراین، ما داریم:

• خط لوله - مجموعه ای از وظایف سازماندهی شده در مراحلی که در آن می توانید بسازید، آزمایش کنید، کد بسته بندی کنید، یک ساخت تمام شده را در یک سرویس ابری مستقر کنید و غیره،
• صحنه (مرحله) - واحد سازماندهی خط لوله، شامل 1+ وظیفه،
• وظیفه (کار) یک واحد کار در خط لوله است. این شامل یک اسکریپت (اجباری)، شرایط راه اندازی، تنظیمات برای انتشار/ذخیره سازی مصنوعات و موارد دیگر است.

بر این اساس، وظیفه هنگام راه اندازی CI / CD به ایجاد مجموعه ای از وظایف است که تمام اقدامات لازم برای ساخت، آزمایش و انتشار کد و مصنوعات را انجام می دهد.

قبل از شروع: چرا؟

• چرا Gitlab؟

زیرا زمانی که نیاز به ایجاد مخازن خصوصی برای پروژه های حیوانات خانگی شد، در GitHub به آنها پرداخت می شد و من حرص می خوردم. مخازن رایگان شده اند، اما تاکنون این دلیل کافی برای انتقال من به GitHub نیست.

• چرا خطوط لوله Azure DevOps نه؟

از آنجا که تنظیمات در آنجا ابتدایی است - دانش خط فرمان حتی مورد نیاز نیست. ادغام با ارائه دهندگان گیت خارجی - در چند کلیک، وارد کردن کلیدهای SSH برای ارسال تعهدات به مخزن - همچنین، خط لوله به راحتی پیکربندی می شود، حتی نه از یک الگو.

موقعیت شروع: آنچه دارید و آنچه می خواهید

ما داریم:

• مخزن در GitLab

ما میخواهیم:

• مونتاژ و آزمایش خودکار برای هر درخواست ادغام،
• ساختن بسته‌ها برای هر درخواست ادغام و فشار دادن به Master، به شرطی که یک خط مشخص در پیام commit وجود داشته باشد.
• ارسال بسته های ساخته شده به یک فید خصوصی در Azure DevOps،
• مونتاژ اسناد و انتشار در صفحات GitLab،
• نشان ها! 11

الزامات توصیف شده به طور ارگانیک بر روی مدل خط لوله زیر قرار می گیرند:

• مرحله 1 - مونتاژ
  • ما کد را جمع آوری می کنیم، فایل های خروجی را به عنوان مصنوع منتشر می کنیم
• مرحله 2 - آزمایش
  • ما مصنوعات را از مرحله ساخت دریافت می کنیم، آزمایش ها را اجرا می کنیم، داده های پوشش کد را جمع آوری می کنیم
• مرحله 3 - ارسال
  • وظیفه 1 - بسته nuget را بسازید و به Azure DevOps ارسال کنید
  • وظیفه 2 - ما سایت را از xmldoc در کد منبع جمع آوری می کنیم و آن را در صفحات GitLab منتشر می کنیم.

بیایید شروع کنیم

جمع آوری پیکربندی

آماده سازی حساب ها

1. ایجاد یک حساب کاربری در مایکروسافت لاورو

2. قابل اعتماد و متخصص Azure DevOps

3. ما یک پروژه جدید ایجاد می کنیم

   1. نام - هر
   2. دید - هر
      

4. با کلیک بر روی دکمه Create پروژه ایجاد می شود و به صفحه آن هدایت می شوید. در این صفحه می توانید با رفتن به تنظیمات پروژه (لینک پایین در لیست سمت چپ -> نمای کلی -> بلوک خدمات Azure DevOps) ویژگی های غیر ضروری را غیرفعال کنید.
   

5. به Atrifacts بروید، روی ایجاد فید کلیک کنید

   1. نام منبع را وارد کنید
   2. دید را انتخاب کنید
   3. علامت را بردارید شامل بسته هایی از منابع عمومی رایج، به طوری که منبع به یک Dump Nuget Clone تبدیل نشود
      

6. روی Connect to feed کلیک کنید، Visual Studio را انتخاب کنید، Source را از بلوک Machine Setup کپی کنید
   

7. به تنظیمات حساب بروید، Personal Access Token را انتخاب کنید
   

8. یک نشانه دسترسی جدید ایجاد کنید

   1. نام - دلخواه
   2. سازمان - فعلی
   3. حداکثر تا 1 سال معتبر است
   4. محدوده - بسته بندی / خواندن و نوشتن
      

9. توکن ایجاد شده را کپی کنید - پس از بسته شدن پنجره مدال، مقدار در دسترس نخواهد بود

10. به تنظیمات مخزن در GitLab بروید، تنظیمات CI / CD را انتخاب کنید
    

11. بلوک متغیرها را گسترش دهید، یک بلوک جدید اضافه کنید

    1. نام - هر بدون فاصله (در پوسته فرمان در دسترس خواهد بود)
    2. ارزش - نشانه دسترسی از بند 9
    3. متغیر Mask را انتخاب کنید
       

این تنظیمات اولیه را تکمیل می کند.

آماده سازی چارچوب پیکربندی

به طور پیش فرض، پیکربندی 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

اکنون هنگامی که خط لوله از مخزن تصویر مایکروسافت راه اندازی می شود، تصویر مشخص شده دانلود می شود که در آن تمام وظایف از پیکربندی اجرا می شود.

مرحله بعدی اضافه کردن است مرحله's به طور پیش فرض، 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

باقی مانده است که حداقل یک کار اضافه شود تا زمانی که commit ها ارسال شدند، خط لوله شروع شود. در حال حاضر، بیایید یک کار خالی برای نشان دادن اضافه کنیم:

dummy job:
  script:
    - echo ok

اعتبار سنجی را شروع می کنیم، پیامی دریافت می کنیم که همه چیز خوب است، تعهد می کنیم، فشار می دهیم، نتایج را در سایت نگاه می کنیم ... و یک خطای اسکریپت دریافت می کنیم - bash: .PSVersion: command not found. WTF؟

همه چیز منطقی است - به طور پیش فرض، runner ها (مسئول اجرای اسکریپت های وظیفه و ارائه شده توسط 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 ایجاد می شود و هر بار که commit ها به شعبه ای که منبع درخواست ادغام است ارسال می شود و نام شاخه ها (از جمله استفاده از عبارات منظم) وظیفه را تنظیم می کند تا اجرا شود. rules به شما امکان می دهد مجموعه ای از شرایط را سفارشی کنید و به صورت اختیاری، شرایط اجرای کار را بسته به موفقیت کارهای قبلی تغییر دهید (when در GitLab CI/CD).

بیایید مجموعه ای از الزامات را به یاد بیاوریم - مونتاژ و آزمایش فقط برای درخواست ادغام، بسته بندی و ارسال به Azure DevOps - برای درخواست ادغام و فشار به Master، تولید اسناد - برای فشار به Master.

ابتدا، بیایید وظیفه ساخت کد را با اضافه کردن یک قانون تنظیم کنیم که فقط در صورت درخواست ادغام فعال می شود:

build job:
  # snip
  only:
    - merge_request

حالا بیایید وظیفه بسته بندی را تنظیم کنیم تا در درخواست ادغام فعال شود و commit ها را به master اضافه کنیم:

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 - آدرس منبع از مرحله آماده سازی حساب ها، ص 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 به طور پیش فرض محتویات پوشه عمومی در ریشه مخزن را به عنوان منبعی برای Pages می گیرد. زیرا پروژه در یک پوشه تو در تو در مخزن قرار خواهد گرفت - یک خروجی به سطح بالا در مسیر اضافه کنید.
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، باید بر روی Create badge برای بسته انتخابی کلیک کنید و علامت نشانه گذاری را کپی کنید:

افزودن زیبایی

برجسته کردن قطعات پیکربندی رایج

در حین نوشتن پیکربندی و جستجو در اسناد، با ویژگی جالب YAML مواجه شدم - استفاده مجدد از قطعات.

همانطور که از تنظیمات کار می بینید، همه آنها به برچسب نیاز دارند windows در runner، و هنگامی که یک درخواست ادغام به Master ارسال می شود/ایجاد می شود (به جز مستندات) فعال می شوند. بیایید این را به قطعه ای که دوباره استفاده خواهیم کرد اضافه کنیم:

.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 و تعیین خودکار محیط هدف است که در مقاله بعدی به آن پرداخته خواهد شد.

منبع: www.habr.com