🥇 (लगभग) पूर्ण नवजातिका लागि GitLab मा CI/CD को लागि गाइड

वा आराम कोडिङको एक साँझमा तपाईंको परियोजनाको लागि सुन्दर ब्याजहरू कसरी प्राप्त गर्ने

सायद, प्रत्येक विकासकर्तासँग कम्तिमा एउटा पाल्तु जनावर परियोजना भएको कुनै न कुनै बेला स्थिति, कोड कभरेज, प्याकेज संस्करणहरू न्युगेटमा भएका सुन्दर ब्याजहरूका लागि खुजली छ... र यही खुजलीले मलाई यो लेख लेख्न प्रेरित गर्‍यो। यसलाई लेख्ने तयारीको क्रममा, मैले मेरो एउटा परियोजनामा यो सुन्दरता प्राप्त गरें:

यस लेखले GitLab मा .Net Core कक्षाको पुस्तकालय परियोजनाको लागि निरन्तर एकीकरण र डेलिभरीको आधारभूत सेटअप, GitLab पृष्ठहरूमा कागजातहरू प्रकाशन गर्ने र Azure DevOps मा निजी फिडमा सङ्कलन गरिएका प्याकेजहरू पठाउने आधारभूत सेटअपलाई समेट्नेछ।

विस्तारको साथ VS कोड विकास वातावरणको रूपमा प्रयोग गरिएको थियो GitLab कार्यप्रवाह (विकास वातावरणबाट सीधा सेटिङ फाइल प्रमाणीकरण गर्न)।

छोटो परिचय

सीडी हो जब तपाइँ भर्खरै धकेल्नु भयो, तर ग्राहक पहिले नै सबै गुमाइसकेको छ?

CI/CD भनेको के हो र यो किन चाहिन्छ? तपाई सजिलै गुगल गर्न सक्नुहुन्छ। GitLab मा पाइपलाइनहरू सेटअपमा पूरा कागजातहरू फेला पार्नुहोस् पनि सजिलो। यहाँ म छोटकरीमा र, यदि सम्भव भएमा, त्रुटिहरू बिना, चराको आँखा दृश्यबाट प्रणालीको प्रक्रिया वर्णन गर्नेछु:

विकासकर्ताले भण्डारमा प्रतिबद्धता पठाउँदछ, वेबसाइट मार्फत मर्ज अनुरोध सिर्जना गर्दछ, वा कुनै अन्य तरिकामा स्पष्ट वा अस्पष्ट रूपमा पाइपलाइन सुरू गर्दछ,
कन्फिगरेसनबाट, सबै कार्यहरू चयन गरिएका छन् जसका सर्तहरूले तिनीहरूलाई दिइएको सन्दर्भमा सुरू गर्न अनुमति दिन्छ,
कार्यहरू तिनीहरूको चरणहरू अनुसार व्यवस्थित हुन्छन्,
चरणहरू बारीमा कार्यान्वयन गरिन्छ - अर्थात् समानान्तर यस चरणका सबै कार्यहरू पूरा भएका छन्,
यदि एक चरण असफल भयो (अर्थात् चरणको कम्तिमा एउटा कार्य असफल भयो) - पाइपलाइन रोकिन्छ (प्रायजसो सधैं),
यदि सबै चरणहरू सफलतापूर्वक पूरा भएमा, पाइपलाइन सफल मानिन्छ।

यसरी हामीसँग छ:

पाइपलाइन चरणहरूमा संगठित कार्यहरूको एक सेट हो जसमा तपाइँ जम्मा गर्न, परीक्षण गर्न, प्याकेज कोड, क्लाउड सेवामा समाप्त भएको एसेम्बली डिप्लोय गर्न सक्नुहुन्छ, आदि।
चरण (चरण) — पाइपलाइन संगठनको एकाइ, 1+ कार्य समावेश गर्दछ,
कार्य (काम) पाइपलाइनमा काम गर्ने एकाइ हो। स्क्रिप्ट (आवश्यक), सुरुवात सर्तहरू, प्रकाशन/क्यासिङ कलाकृतिहरूका लागि सेटिङहरू र अधिक समावेश गर्दछ।

तदनुसार, CI/CD सेटअप गर्दा कार्यहरू संयोजन, परीक्षण र प्रकाशन कोड र कलाकृतिहरूको लागि सबै आवश्यक कार्यहरू कार्यान्वयन गर्ने कार्यहरूको सेट सिर्जना गर्न तल आउँछ।

हामीले सुरु गर्नु अघि: किन?

किन GitLab?

किनभने जब घरपालुवा जनावर परियोजनाहरूको लागि निजी भण्डारहरू सिर्जना गर्न आवश्यक भयो, तिनीहरू GitHub मा भुक्तानी गरियो, र म लोभी थिएँ। भण्डारहरू नि: शुल्क भएका छन्, तर अहिलेको लागि यो मेरो लागि GitHub मा जानको लागि पर्याप्त कारण होइन।

किन Azure DevOps पाइपलाइनहरू छैनन्?

किनभने सेटअप सरल छ - तपाईलाई कमाण्ड लाइन ज्ञान पनि आवश्यक पर्दैन। बाह्य git प्रदायकहरूसँग एकीकरण - केहि क्लिकहरूमा, भण्डारमा कमिटहरू पठाउनको लागि SSH कुञ्जीहरूको आयात - पनि, पाइपलाइन टेम्प्लेट बिना पनि सजिलै कन्फिगर गरिएको छ।

सुरूवात स्थिति: तपाईसँग के छ र तपाई के चाहनुहुन्छ

हामी संग छ:

GitLab मा भण्डार।

हामी चाहन्छौं:

प्रत्येक मर्ज अनुरोधको लागि स्वचालित असेंबली र परीक्षण,
प्रत्येक मर्ज अनुरोधको लागि प्याकेजहरू निर्माण गर्दै र मास्टरमा पुश गर्दै, कमिट सन्देशमा निश्चित लाइन भएमा,
Azure DevOps मा निजी फिडमा सङ्कलन प्याकेजहरू पठाउँदै,
GitLab पृष्ठहरूमा कागजात र प्रकाशनको संयोजन,
ब्याजहरू! 11

वर्णित आवश्यकताहरू निम्न पाइपलाइन मोडेलमा स्वाभाविक रूपमा फिट हुन्छन्:

चरण 1 - विधानसभा
- हामी कोड सङ्कलन गर्छौं, आउटपुट फाइलहरू कलाकृतिहरूको रूपमा प्रकाशित गर्छौं
चरण 2 - परीक्षण
- हामी निर्माण चरणबाट कलाकृतिहरू प्राप्त गर्छौं, परीक्षणहरू चलाउँछौं, कोड कभरेज डेटा सङ्कलन गर्छौं
चरण 3 - पठाउँदै
- टास्क १ - नुगेट प्याकेज सङ्कलन गर्नुहोस् र Azure DevOps मा पठाउनुहोस्
- कार्य २ - हामी स्रोत कोडमा 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

अब, जब तपाइँ पाइपलाइन सुरु गर्नुहुन्छ, निर्दिष्ट छवि Microsoft छवि भण्डारबाट डाउनलोड गरिनेछ, जसमा कन्फिगरेसनबाट सबै कार्यहरू कार्यान्वयन गरिनेछ।

अर्को चरण थप्न छ चरणको। पूर्वनिर्धारित रूपमा, GitLab ले 5 चरणहरू परिभाषित गर्दछ:

.pre - सबै चरणहरूमा सम्पन्न,
.post - सबै चरण पछि प्रदर्शन,
build - पहिले पछि .pre चरण,
test - दोस्रो चरण,
deploy - तेस्रो चरण।

तथापि, तिनीहरूलाई स्पष्ट रूपमा घोषणा गर्नबाट तपाईंलाई कुनै पनि कुराले रोक्दैन। चरणहरू सूचीबद्ध गरिएका क्रमले तिनीहरू पूरा भएको क्रमलाई असर गर्छ। पूर्णताको लागि, कन्फिगरेसनमा थपौं:

stages:
  - build
  - test
  - deploy

डिबगिङको लागि, यसले कार्यहरू कार्यान्वयन गर्ने वातावरणको बारेमा जानकारी प्राप्त गर्न अर्थपूर्ण हुन्छ। आदेशहरूको विश्वव्यापी सेट थप्नुहोस् जुन प्रत्येक कार्य प्रयोग गर्नु अघि कार्यान्वयन गरिनेछ before_script:

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

यो कम्तिमा एउटा कार्य थप्न बाँकी छ ताकि जब कमिटहरू पठाइन्छ, पाइपलाइन सुरु हुनेछ। अहिलेको लागि, प्रदर्शनको लागि एउटा खाली कार्य थपौं:

dummy job:
  script:
    - echo ok

हामी प्रमाणीकरण सुरु गर्छौं, सन्देश प्राप्त गर्छौं कि सबै ठीक छ, कमिट गर्नुहोस्, धक्का दिनुहोस्, साइटमा नतिजाहरू हेर्नुहोस्... र हामीले लिपि त्रुटि पाउँछौं - bash: .PSVersion: command not found। WTF?

सबै कुरा तार्किक छ - पूर्वनिर्धारित रूपमा, धावकहरू (कार्य स्क्रिप्टहरू कार्यान्वयन गर्न जिम्मेवार र GitLab द्वारा प्रदान गरिएको) प्रयोग bash आदेशहरू कार्यान्वयन गर्न। तपाईंले कार्य विवरणमा कार्यान्वयन गर्ने पाइपलाइन धावकसँग कुन ट्यागहरू हुनुपर्छ भनेर स्पष्ट रूपमा संकेत गरेर यसलाई ठीक गर्न सक्नुहुन्छ:

dummy job on windows:
  script:
    - echo ok
  tags:
    - windows

महान! अहिले पाइपलाइन चलिरहेको छ ।

एक ध्यान दिएर पाठक, यी चरणहरू दोहोर्याउँदै, कार्य चरणमा पूरा भएको याद गर्नेछ test, यद्यपि हामीले चरण निर्दिष्ट गरेका छैनौं। तपाईले अनुमान गर्न सक्नुहुन्छ, test पूर्वनिर्धारित चरण हो।

माथि वर्णन गरिएका सबै कार्यहरू थपेर कन्फिगरेसन कंकाल सिर्जना गर्न जारी राखौं:

build job:
  script:
    - echo "building..."
  tags:
    - windows
  stage: build

test and cover job:
  script:
    - echo "running tests and coverage analysis..."
  tags:
    - windows
  stage: test

pack and deploy job:
  script:
    - echo "packing and pushing to nuget..."
  tags:
    - windows
  stage: deploy

pages:
  script:
    - echo "creating docs..."
  tags:
    - windows
  stage: deploy

हामीले विशेष रूपमा कार्यात्मक छैन, तर तैपनि सही पाइपलाइन पायौं।

ट्रिगरहरू सेटअप गर्दै

कुनै पनि कार्यको लागि कुनै ट्रिगर फिल्टर निर्दिष्ट गरिएको छैन भन्ने तथ्यको कारण, पाइपलाइन हुनेछ पुरा प्रत्येक पटक कमिटहरू भण्डारमा पठाइन्छ। यो सामान्य रूपमा वांछित व्यवहार नभएकोले, हामी कार्यहरूको लागि ट्रिगर फिल्टरहरू कन्फिगर गर्नेछौं।

फिल्टरहरू दुई ढाँचाहरूमा कन्फिगर गर्न सकिन्छ: मात्र / बाहेक и नियमहरू। छोटकरीमा, only/except तपाईँलाई ट्रिगरहरूद्वारा फिल्टरहरू कन्फिगर गर्न अनुमति दिन्छ (merge_request, उदाहरणका लागि - प्रत्येक पटक मर्ज अनुरोध सिर्जना गर्दा कार्यान्वयन गर्न कार्य कन्फिगर गर्दछ र प्रत्येक पटक कमिटहरू शाखामा पठाइन्छ जुन मर्ज अनुरोधमा स्रोत हो) र शाखा नामहरू (नियमित अभिव्यक्तिहरू प्रयोग गर्ने सहित); rules तपाईंलाई सर्तहरूको सेट अनुकूलित गर्न र वैकल्पिक रूपमा, अघिल्लो कार्यहरूको सफलताको आधारमा कार्य कार्यान्वयन अवस्था परिवर्तन गर्न अनुमति दिन्छ (when GitLab CI/CD मा).

आवश्यकताहरूको सेट याद गरौं - मर्ज अनुरोधहरू, प्याकेजिङ र Azure DevOps मा पठाउनको लागि मात्र - एसेम्बली र परीक्षण - मर्ज अनुरोधहरू र मास्टरमा पुशहरू, कागजातहरूको उत्पादन - मास्टरमा पुशहरूका लागि।

पहिले, मर्ज अनुरोध मात्र ट्रिगर गर्ने ट्रिगर नियम थपेर कोड असेंबली कार्य सेट अप गरौं:

build job:
  # snip
  only:
    - merge_request

अब मर्ज अनुरोध ट्रिगर गर्न र मास्टरमा कमिटहरू थप्न प्याकेजिङ कार्य कन्फिगर गरौं:

pack and deploy job:
  # snip
  only:
    - merge_request
    - master

तपाईं देख्न सक्नुहुन्छ, सबै कुरा सरल र सीधा छ।

तपाइँले कार्यलाई ट्रिगर गर्नको लागि कन्फिगर गर्न सक्नुहुन्छ यदि एक विशिष्ट लक्ष्य वा स्रोत शाखासँग मर्ज अनुरोध सिर्जना गरिएको छ:

  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

परिस्थितिहरूमा यो प्रयोग गर्न सकिन्छ चरहरू यहाँ सूचीबद्ध छन्; नियमहरू rules नियमसँग मेल खाँदैन only/except.

कलाकृति बचत कन्फिगर गर्दै

कार्य चलिरहेको बेला build job हामीसँग सिर्जना गरिएका कलाकृतिहरू हुनेछन् जुन पछिका कार्यहरूमा पुन: प्रयोग गर्न सकिन्छ। यो गर्नको लागि, तपाईंले कार्य कन्फिगरेसनमा मार्गहरू थप्नु पर्छ, फाइलहरू बचत गर्न र पछिका कार्यहरूमा पुन: प्रयोग गर्न आवश्यक पर्ने कुञ्जीमा। artifacts:

build job:
  # snip
  artifacts:
    paths:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

पथहरूले वाइल्डकार्डहरूलाई समर्थन गर्दछ, जसले निश्चित रूपमा तिनीहरूलाई सेट गर्न सजिलो बनाउँदछ।

यदि कार्यले कलाकृतिहरू सिर्जना गर्दछ भने, त्यसपछि प्रत्येक पछिको कार्यले तिनीहरूलाई पहुँच गर्न सक्षम हुनेछ - तिनीहरू रिपोजिटरी रूटको सापेक्ष उही मार्गहरूमा अवस्थित हुनेछन् जसमा तिनीहरू मूल कार्यबाट सङ्कलन गरिएका थिए। कलाकृतिहरू वेबसाइटमा डाउनलोडको लागि पनि उपलब्ध छन्।

अब जब हामीसँग कन्फिगरेसन फ्रेमवर्क तयार छ (र प्रमाणित), हामी वास्तवमा कार्यहरूको लागि स्क्रिप्टहरू लेख्न जान सक्छौं।

हामी स्क्रिप्ट लेख्छौं

सायद, एक पटक, एक ग्यालेक्सीमा टाढा, टाढा, कमाण्ड लाइनबाट परियोजनाहरू (.net सहित) निर्माण गर्नु पीडा थियो। अब तपाइँ 3 टोलीहरूमा परियोजनालाई भेला गर्न, परीक्षण गर्न र प्रकाशित गर्न सक्नुहुन्छ:

dotnet build
dotnet test
dotnet pack

स्वाभाविक रूपमा, त्यहाँ केही सूक्ष्मताहरू छन् जसको कारण हामी आदेशहरूलाई केही हदसम्म जटिल बनाउँछौं।

हामी रिलीज चाहन्छौं, डिबग होइन, निर्माण, त्यसैले हामी प्रत्येक आदेशमा थप्छौं -c Release
परीक्षण गर्दा, हामी कोड कभरेजमा डाटा सङ्कलन गर्न चाहन्छौं, त्यसैले हामीले परीक्षण पुस्तकालयहरूमा कभरेज विश्लेषक जडान गर्न आवश्यक छ:
1. प्याकेज सबै परीक्षण पुस्तकालयहरूमा थपिनुपर्छ coverlet.msbuild: dotnet add package coverlet.msbuild परियोजना फोल्डरबाट
2. परीक्षण प्रक्षेपण आदेशमा थप्नुहोस् /p:CollectCoverage=true
3. कभरेज परिणामहरू प्राप्त गर्न परीक्षण कार्य कन्फिगरेसनमा एउटा कुञ्जी थपौं (तल हेर्नुहोस्)
नुगेट प्याकेजहरूमा कोड प्याकेज गर्दा, हामी प्याकेजहरूको लागि आउटपुट डाइरेक्टरी सेट गर्नेछौं: -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 मा थपिएको पहुँच टोकनको साथ चलको नाम (“खाताहरू तयार गर्दै”, p. 11)। स्वाभाविक रूपमा, ढाँचामा $variableName
5. -StorePasswordInClearText - पहुँच अस्वीकार गरिएको त्रुटिलाई बाइपास गर्न ह्याक (म यो रेकमा पाइला टेक्ने पहिलो होइन)
6. त्रुटिहरूको अवस्थामा यो थप्न उपयोगी हुन सक्छ -verbosity detailed
हामी स्रोतमा प्याकेज पठाउँछौं: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. हामी हालको डाइरेक्टरीबाट सबै प्याकेजहरू पठाउँछौं, त्यसैले *.nupkg.
2. name - माथिको चरणबाट।
3. key - कुनै पनि रेखा। Azure DevOps मा, Connect to feed विन्डोमा, उदाहरण रेखा सधैं हुन्छ az.
4. -skipduplicate यदि तपाइँ यो कुञ्जी बिना पहिले नै अवस्थित प्याकेज पठाउन प्रयास गर्नुहुन्छ भने, स्रोतले त्रुटि फर्काउनेछ 409 Conflict; कुञ्जीको साथ, पठाउने कार्य छोडिनेछ।

अब दस्तावेज को निर्माण सेट अप गरौं:

सुरु गर्नको लागि, भण्डारमा, मास्टर शाखामा, हामी docfx परियोजना सुरु गर्छौं। यो गर्नको लागि, तपाईंले रूटबाट आदेश चलाउन आवश्यक छ docfx init र अन्तरक्रियात्मक रूपमा कागजातहरू जम्मा गर्नका लागि मुख्य प्यारामिटरहरू सेट गर्नुहोस्। न्यूनतम परियोजना सेटअपको विस्तृत विवरण यहाँ.
1. सेटअप गर्दा, आउटपुट डाइरेक्टरी निर्दिष्ट गर्न महत्त्वपूर्ण छ ..public - पूर्वनिर्धारित रूपमा GitLab ले पृष्ठहरूको स्रोतको रूपमा भण्डारको मूलमा सार्वजनिक फोल्डरको सामग्री लिन्छ। किनभने परियोजना भण्डारमा नेस्ट गरिएको फोल्डरमा अवस्थित हुनेछ - मार्गमा अर्को स्तरमा बाहिर निस्कनुहोस्।
GitLab मा परिवर्तनहरू पुश गरौं।
पाइपलाइन कन्फिगरेसनमा कार्य थप्नुहोस् pages (GitLab पृष्ठहरूमा साइट प्रकाशन कार्यहरूको लागि आरक्षित शब्द):
1. लिपि:
  1. nuget install docfx.console -version 2.51.0 - docfx स्थापना गर्नुहोस्; प्याकेज स्थापना मार्गहरू सही छन् भनी सुनिश्चित गर्न संस्करण प्रदान गरिएको छ।
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - कागजात सङ्कलन
2. कलाकृति नोड:

pages:
  # snip
  artifacts:
    paths:
      - public

docfx को बारे मा लिरिकल डिग्रेशन

पहिले, परियोजना सेटअप गर्दा, मैले समाधान फाइलको रूपमा कागजातको लागि कोड स्रोत निर्दिष्ट गरें। मुख्य हानि यो छ कि कागजात पनि परीक्षण परियोजनाहरु को लागी बनाईएको छ। यदि यो आवश्यक छैन भने, तपाईंले यो मान नोडमा सेट गर्न सक्नुहुन्छ metadata.src:

{
  "metadata": [
    {
      "src": [
        {
          "src": "../",
          "files": [
            "**/*.csproj"
          ],
          "exclude":[
            "*.tests*/**"
          ]
        }
      ],
      // --- snip ---
    },
    // --- snip ---
  ],
  // --- snip ---
}

metadata.src.src: "../" - स्थान सापेक्ष एक स्तर माथि जानुहोस् docfx.json, किनभने डाइरेक्टरी रूख खोजी ढाँचामा काम गर्दैन।
metadata.src.files: ["**/*.csproj"] — एक विश्वव्यापी ढाँचा, हामी सबै डाइरेक्टरीहरूबाट सबै C# परियोजनाहरू सङ्कलन गर्छौं।
metadata.src.exclude: ["*.tests*/**"] - विश्वव्यापी ढाँचा, फोल्डरहरूबाट सबै कुरा बाहिर निकाल्नुहोस् .tests शीर्षक मा

उप कूल

यो साधारण कन्फिगरेसन शाब्दिक रूपमा आधा घण्टा र कफीको कपको एक जोडीमा सिर्जना गर्न सकिन्छ, जसले तपाईंलाई प्रत्येक मर्ज अनुरोधको साथ जाँच गर्न र कोड कम्पाइल भइरहेको छ र परीक्षणहरू उत्तीर्ण भइरहेको छ भनेर मास्टरलाई पठाउन अनुमति दिनेछ। प्याकेज, कागजात अद्यावधिक गर्दै र परियोजना README मा सुन्दर ब्याजहरू संग आँखा खुसी।

अन्तिम .gitlab-ci.yml

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

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

stages:
  - build
  - test
  - deploy

build job:
  stage: build
  script:
    - dotnet build -c Release
  tags:
    - windows
  only:
    - merge_requests
    - master
  artifacts:
    paths:
      - your/path/to/binaries

test and cover job:
  stage: test
  tags:
    - windows
  script:
    - dotnet test -c Release /p:CollectCoverage=true
  coverage: /|s*Totals*|s*(d+[,.]d+%)/
  only:
    - merge_requests
    - master

pack and deploy job:
  stage: deploy
  tags:
    - windows
  script:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  only:
    - master

pages:
  tags:
    - windows
  stage: deploy
  script:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

ब्याजको कुरा गर्दै

उनीहरुकै लागि सबै सुरु भएको हो !

पाइपलाइन स्थिति र कोड कभरेज भएका ब्याजहरू GitLab मा Gtntral पाइपलाइन ब्लकमा CI/CD सेटिङहरूमा उपलब्ध छन्:

मैले प्लेटफर्ममा कागजातहरूको लिङ्कको साथ ब्याज सिर्जना गरें shields.io - त्यहाँ सबै कुरा एकदम सीधा छ, तपाईं आफ्नै ब्याज सिर्जना गर्न र अनुरोध प्रयोग गरेर प्राप्त गर्न सक्नुहुन्छ।

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

Azure DevOps Artifacts ले तपाईंलाई नवीनतम संस्करण संकेत गर्ने प्याकेजहरूको लागि ब्याजहरू सिर्जना गर्न अनुमति दिन्छ। यो गर्नको लागि, Azure DevOps वेबसाइटको स्रोतमा, तपाईंले चयन गरिएको प्याकेजको लागि ब्याज सिर्जना गर्नुहोस् र मार्कडाउन मार्कअप प्रतिलिपि गर्न आवश्यक छ:

सौन्दर्य थप्दै

हामी सामान्य कन्फिगरेसन टुक्राहरू हाइलाइट गर्छौं

कन्फिगरेसन लेख्दा र कागजातहरू मार्फत खोजी गर्दा, मैले एउटा चाखलाग्दो YAML सुविधा भेटें - टुक्राहरू पुन: प्रयोग गर्दै।

तपाईंले कार्य सेटिङहरूबाट देख्न सक्नुहुन्छ, तिनीहरू सबैलाई ट्याग चाहिन्छ windows रनरबाट, र मास्टरलाई मर्ज अनुरोध पठाउँदा / मर्ज अनुरोध सिर्जना गर्दा ट्रिगर गरिन्छ (कागजातहरू बाहेक)। यसलाई हामीले पुन: प्रयोग गर्ने टुक्रामा थपौं:

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

र अब हामी कार्य विवरणमा पहिले घोषणा गरिएको टुक्रा घुसाउन सक्छौं:

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

टुक्रा नामहरू कार्यको रूपमा व्याख्या गर्नबाट बच्नको लागि अवधिको साथ सुरु हुनुपर्छ।

प्याकेज संस्करण

प्याकेज सिर्जना गर्दा, कम्पाइलरले कमाण्ड लाइन स्विचहरू जाँच गर्दछ, र तिनीहरूको अनुपस्थितिमा, परियोजना फाइलहरू; संस्करण नोड फेला पारेपछि, यसले प्याकेज निर्माण भइरहेको संस्करणको रूपमा यसको मान लिन्छ। यो बाहिर जान्छ कि नयाँ संस्करण संग प्याकेज निर्माण गर्न को लागी, तपाइँ या त यसलाई परियोजना फाइल मा अद्यावधिक वा आदेश लाइन तर्क को रूप मा पास गर्न आवश्यक छ।

एउटा थप इच्छा थपौं - संस्करणमा सबैभन्दा कम दुई नम्बरहरू प्याकेज निर्माणको वर्ष र मिति होस्, र प्रि-रिलीज संस्करणहरू थप्नुहोस्। निस्सन्देह, तपाइँ यो डाटा परियोजना फाइलमा थप्न सक्नुहुन्छ र प्रत्येक सबमिशन अघि यसलाई जाँच गर्न सक्नुहुन्छ - तर तपाइँ यो पाइपलाइनमा पनि गर्न सक्नुहुन्छ, सन्दर्भबाट प्याकेज संस्करण सङ्कलन गर्दै र यसलाई आदेश रेखा तर्क मार्फत पारित गर्नुहोस्।

यदि कमिट सन्देशमा जस्तै लाइन समावेश छ भने सहमत गरौं 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 मा अनुप्रयोगहरू प्रयोग गर्न, Pulumi प्रयोग गरी स्वचालित रूपमा लक्षित वातावरण पत्ता लगाउन पाइपलाइन कन्फिगर गर्ने छन्, जुन अर्को लेखमा समावेश गरिनेछ।

स्रोत: www.habr.com

(लगभग) पूर्ण शुरुवातकर्ताको लागि GitLab मा CI/CD को लागि गाइड