🥇 (जवळजवळ) परिपूर्ण नवशिक्यासाठी गिटलॅबमधील CI/CD चे मार्गदर्शक

किंवा सोप्या कोडिंगच्या एका संध्याकाळी तुमच्या प्रोजेक्टसाठी सुंदर बॅज कसे मिळवायचे

कदाचित, प्रत्येक विकसक ज्याच्याकडे कमीत कमी एक पाळीव प्राणी प्रकल्प आहे त्याच्याकडे स्टेटस, कोड कव्हरेज, न्युगेटमधील पॅकेज आवृत्त्यांसह सुंदर बॅजबद्दल खाज सुटली आहे ... आणि या खाजमुळे मला हा लेख लिहायला प्रवृत्त केले. ते लिहिण्याच्या तयारीत, मला माझ्या एका प्रकल्पात हे सौंदर्य मिळाले:

हा लेख तुम्हाला GitLab मधील .Net Core क्लास लायब्ररी प्रकल्पासाठी सतत एकत्रीकरण आणि वितरण, GitLab Pages वर दस्तऐवजीकरण प्रकाशित करणे आणि Azure DevOps मधील खाजगी फीडमध्ये बिल्ट पॅकेजेस पुश करण्याच्या मूलभूत सेटअपमधून मार्गदर्शन करेल.

विस्तारासह विकास वातावरण म्हणून VS कोड वापरला गेला GitLab वर्कफ्लो (विकास वातावरणातून थेट सेटिंग्ज फाइल सत्यापित करण्यासाठी).

संक्षिप्त परिचय

सीडी - जेव्हा तुम्ही नुकतेच ढकलले होते आणि सर्वकाही क्लायंटवर आधीच पडले आहे?

सीआय / सीडी म्हणजे काय आणि आपल्याला त्याची आवश्यकता का आहे - आपण ते सहजपणे गुगल करू शकता. GitLab मध्ये पाइपलाइन कॉन्फिगर करण्याबद्दल संपूर्ण कागदपत्रे शोधा सोपे देखील. येथे मी थोडक्यात आणि शक्य असल्यास, दोषांशिवाय पक्ष्यांच्या डोळ्याच्या दृश्यातून सिस्टमच्या प्रक्रियेचे वर्णन करेन:

डेव्हलपर रेपॉजिटरीला कमिट पाठवतो, साइटद्वारे मर्ज विनंती तयार करतो, किंवा इतर कोणत्याही प्रकारे, स्पष्टपणे किंवा अप्रत्यक्षपणे पाइपलाइन सुरू करते,
सर्व कार्ये कॉन्फिगरेशनमधून निवडली जातात, ज्याच्या अटी त्यांना दिलेल्या संदर्भात लॉन्च करण्याची परवानगी देतात,
कार्ये त्यांच्या टप्प्यांनुसार आयोजित केली जातात,
टप्प्याटप्प्याने कार्यान्वित केले जातात - म्हणजे समांतर या टप्प्यातील सर्व कामे पूर्ण झाली आहेत,
जर स्टेज अयशस्वी झाला (म्हणजे, स्टेजचे किमान एक कार्य अयशस्वी झाले), पाइपलाइन थांबते (जवळजवळ नेहमीच),
सर्व टप्पे यशस्वीरित्या पूर्ण झाल्यास, पाइपलाइन यशस्वी मानली जाते.

अशा प्रकारे, आमच्याकडे आहे:

पाइपलाइन - टप्प्यांमध्ये आयोजित केलेल्या कार्यांचा एक संच ज्यामध्ये तुम्ही तयार करू शकता, चाचणी करू शकता, पॅकेज कोड करू शकता, तयार बिल्ड क्लाउड सेवेवर तैनात करू शकता, इ.
टप्पा (टप्पा) — पाइपलाइन संस्था युनिट, 1+ कार्य समाविष्टीत आहे,
कार्य (नोकरी) हे पाइपलाइनमधील कामाचे एकक आहे. यात स्क्रिप्ट (अनिवार्य), लॉन्च अटी, कलाकृती प्रकाशित/कॅश करण्यासाठी सेटिंग्ज आणि बरेच काही समाविष्ट आहे.

त्यानुसार, सीआय/सीडी सेट करताना, कोड आणि कलाकृती तयार करण्यासाठी, चाचणी आणि प्रकाशनासाठी आवश्यक असलेल्या सर्व क्रियांची अंमलबजावणी करणाऱ्या कार्यांचा संच तयार करणे हे काम खाली येते.

सुरू करण्यापूर्वी: का?

गिटलॅब का?

कारण जेव्हा पाळीव प्राणी प्रकल्पांसाठी खाजगी भांडार तयार करणे आवश्यक होते, तेव्हा त्यांना गिटहबवर पैसे दिले गेले आणि मी लोभी होतो. रेपॉजिटरीज विनामूल्य झाले आहेत, परंतु आतापर्यंत हे माझ्यासाठी गिटहबवर जाण्याचे पुरेसे कारण नाही.

Azure DevOps पाइपलाइन का नाही?

कारण तेथे सेटिंग प्राथमिक आहे - कमांड लाइनचे ज्ञान देखील आवश्यक नाही. बाह्य गिट प्रदात्यांसह एकत्रीकरण - काही क्लिक्समध्ये, रेपॉजिटरीमध्ये कमिट पाठवण्यासाठी SSH की आयात करा - शिवाय, पाईपलाईन टेम्पलेटमधून देखील सहजपणे कॉन्फिगर केली जाते.

प्रारंभिक स्थिती: आपल्याकडे काय आहे आणि आपल्याला काय हवे आहे

आमच्याकडे आहे:

GitLab मध्ये भांडार.

आम्हाला पाहिजे:

प्रत्येक विलीनीकरण विनंतीसाठी स्वयंचलित असेंब्ली आणि चाचणी,
प्रत्येक विलीनीकरण विनंतीसाठी पॅकेज तयार करणे आणि मास्टरकडे ढकलणे, कमिट संदेशामध्ये विशिष्ट ओळ असल्यास,
Azure DevOps मधील खाजगी फीडवर बिल्ट पॅकेजेस पाठवणे,
GitLab पृष्ठांमध्ये दस्तऐवजीकरण आणि प्रकाशनाचे असेंब्ली,
बॅज!11

वर्णन केलेल्या आवश्यकता सेंद्रियपणे खालील पाइपलाइन मॉडेलवर येतात:

स्टेज 1 - विधानसभा
- आम्ही कोड गोळा करतो, आउटपुट फाइल्स आर्टिफॅक्ट्स म्हणून प्रकाशित करतो
स्टेज 2 - चाचणी
- आम्ही बिल्ड स्टेजवरून कलाकृती मिळवतो, चाचण्या चालवतो, कोड कव्हरेज डेटा गोळा करतो
स्टेज 3 - सबमिट करा
- कार्य 1 - न्युगेट पॅकेज तयार करा आणि ते Azure DevOps वर पाठवा
- कार्य 2 - आम्ही स्त्रोत कोडमध्ये xmldoc वरून साइट गोळा करतो आणि GitLab पृष्ठांमध्ये प्रकाशित करतो

चला सुरू करुया!

कॉन्फिगरेशन गोळा करत आहे

खाती तयार करत आहे

मध्ये खाते तयार करा मायक्रोसॉफ्ट अझर
जा अझर डेव्होप्स
आम्ही एक नवीन प्रकल्प तयार करतो
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 - "खाते तयार करणे", पृ. 6 या टप्प्यातील स्त्रोताची URL
3. organization - Azure DevOps मध्ये संस्थेचे नाव
4. gitlab variable - GitLab मध्ये जोडलेल्या ऍक्सेस टोकनसह व्हेरिएबलचे नाव ("खाते तयार करणे", p. 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 हे मार्गदर्शक वाचल्यानंतर वाटेल त्यापेक्षा अधिक व्यापक आणि बहुआयामी आहे - ते अजिबात खरे नाही. तिथेही ऑटो DevOps आहेपरवानगी देत आहे

तुमचे अनुप्रयोग स्वयंचलितपणे शोधणे, तयार करणे, चाचणी करणे, उपयोजित करणे आणि त्यांचे परीक्षण करणे

आता पुलुमीचा वापर करून, Azure वर ऍप्लिकेशन्स डिप्लॉय करण्यासाठी पाइपलाइन कॉन्फिगर करण्याची आणि लक्ष्य वातावरण आपोआप ठरवण्याची योजना आहे, ज्याचा पुढील लेखात समावेश केला जाईल.

स्त्रोत: www.habr.com

(जवळजवळ) परिपूर्ण नवशिक्यासाठी GitLab मधील CI/CD साठी मार्गदर्शक

संक्षिप्त परिचय

प्रारंभिक स्थिती: आपल्याकडे काय आहे आणि आपल्याला काय हवे आहे

कॉन्फिगरेशन गोळा करत आहे

खाती तयार करत आहे

कॉन्फिगरेशन फ्रेमवर्क तयार करत आहे

ट्रिगर सेट करत आहे

आर्टिफॅक्ट सेव्हिंग कॉन्फिगर करत आहे

आम्ही स्क्रिप्ट लिहितो

कोड कव्हरेज डेटा गोळा करत आहे

पॅकेजेस आणि कागदपत्रे प्रकाशित करा

docfx बद्दल गीतात्मक विषयांतर

एकूण

बॅजबद्दल बोलणे

सौंदर्य जोडणे

कॉमन कॉन्फिगरेशन फ्रॅगमेंट्स हायलाइट करणे

पॅकेज व्हर्जनिंग

एकूण

एक टिप्पणी जोडा Отменить ответ