புரோஹோஸ்டர் > Блог > நிர்வாகம் > (கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

(கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

அல்லது நிதானமான குறியீட்டு முறையின் ஒரு மாலை நேரத்தில் உங்கள் திட்டத்திற்கான அழகான பேட்ஜ்களை எவ்வாறு பெறுவது

அனேகமாக, குறைந்தபட்சம் ஒரு செல்லப் பிராஜெக்ட் வைத்திருக்கும் ஒவ்வொரு டெவலப்பரும் சில சமயங்களில் அழகான பேட்ஜ்களை ஸ்டேட்டஸ்கள், கோட் கவரேஜ், பேக்கேஜ் பதிப்புகள் nuget இல் உள்ள நமைச்சலைக் கொண்டிருப்பார்கள்... மேலும் இந்த அரிப்பு என்னை இந்தக் கட்டுரையை எழுத வழிவகுத்தது. அதை எழுதத் தயாராகும் பணியில், எனது திட்டங்களில் ஒன்றில் இந்த அழகைப் பெற்றேன்:

(கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

GitLab இல் .Net கோர் கிளாஸ் லைப்ரரி திட்டத்திற்கான தொடர்ச்சியான ஒருங்கிணைப்பு மற்றும் விநியோகம், GitLab பக்கங்களுக்கு ஆவணங்களை வெளியிடுதல் மற்றும் Azure DevOps இல் உள்ள தனிப்பட்ட ஊட்டத்திற்கு சேகரிக்கப்பட்ட தொகுப்புகளை அனுப்புதல் ஆகியவற்றின் அடிப்படை அமைப்பை இந்தக் கட்டுரை உள்ளடக்கும்.

விரிவாக்க சூழலுடன் VS குறியீடு பயன்படுத்தப்பட்டது GitLab பணிப்பாய்வு (மேம்பாடு சூழலில் இருந்து நேரடியாக அமைப்புகள் கோப்பை சரிபார்க்க).

சுருக்கமான அறிமுகம்

குறுவட்டு என்பது நீங்கள் அழுத்தியது, ஆனால் கிளையன்ட் ஏற்கனவே எல்லாவற்றையும் இழந்துவிட்டதா?

CI/CD என்றால் என்ன, அது ஏன் தேவைப்படுகிறது? நீங்கள் அதை எளிதாக கூகிள் செய்யலாம். GitLab இல் குழாய்களை அமைப்பதற்கான முழுமையான ஆவணங்களைக் கண்டறியவும் மேலும் எளிதானது. இங்கே நான் சுருக்கமாக, முடிந்தால், குறைபாடுகள் இல்லாமல், பறவையின் பார்வையில் இருந்து அமைப்பின் செயல்முறையை விவரிக்கிறேன்:

  • டெவலப்பர் களஞ்சியத்திற்கு ஒரு உறுதிமொழியை அனுப்புகிறார், இணையதளம் வழியாக ஒன்றிணைக்கும் கோரிக்கையை உருவாக்குகிறார், அல்லது வேறு வழியில் வெளிப்படையாகவோ அல்லது மறைமுகமாகவோ பைப்லைனைத் துவக்குகிறது,
  • உள்ளமைவிலிருந்து, அனைத்து பணிகளும் தேர்ந்தெடுக்கப்படுகின்றன, அதன் நிபந்தனைகள் கொடுக்கப்பட்ட சூழலில் தொடங்கப்பட அனுமதிக்கின்றன,
  • பணிகள் அவற்றின் நிலைகளுக்கு ஏற்ப ஒழுங்கமைக்கப்படுகின்றன,
  • நிலைகள் தொடர்ச்சியாக செயல்படுத்தப்படுகின்றன - அதாவது. இணையாக இந்த கட்டத்தின் அனைத்து பணிகளும் முடிக்கப்பட்டுள்ளன,
  • ஒரு நிலை தோல்வியுற்றால் (அதாவது மேடையின் பணிகளில் ஏதேனும் ஒன்று தோல்வியடைந்தால்) - குழாய் நிறுத்தப்படும் (எப்பொழுதும்),
  • அனைத்து நிலைகளும் வெற்றிகரமாக முடிந்தால், குழாய் வெற்றிகரமாக கருதப்படுகிறது.

இவ்வாறு எங்களிடம் உள்ளது:

  • பைப்லைன் என்பது கட்டங்களாக ஒழுங்கமைக்கப்பட்ட பணிகளின் தொகுப்பாகும், இதில் நீங்கள் ஒருங்கிணைக்கலாம், சோதனை செய்யலாம், பேக்கேஜ் குறியீட்டை உருவாக்கலாம், முடிக்கப்பட்ட அசெம்பிளியை கிளவுட் சேவைக்கு வரிசைப்படுத்தலாம்.
  • மேடை (நிலை) — பைப்லைன் அமைப்பின் அலகு, 1+ பணியைக் கொண்டுள்ளது,
  • பணி (வேலை) என்பது பைப்லைனில் வேலை செய்யும் ஒரு அலகு. ஸ்கிரிப்ட் (தேவை), வெளியீட்டு நிபந்தனைகள், கலைப்பொருட்களை வெளியிடுதல்/கேச்சிங் செய்வதற்கான அமைப்புகள் மற்றும் பலவற்றைக் கொண்டுள்ளது.

அதன்படி, CI/CD ஐ அமைக்கும் பணியானது, குறியீடு மற்றும் கலைப்பொருட்களை ஒன்று சேர்ப்பதற்கும், சோதனை செய்வதற்கும் மற்றும் வெளியிடுவதற்கும் தேவையான அனைத்து செயல்களையும் செயல்படுத்தும் பணிகளின் தொகுப்பை உருவாக்குகிறது.

நாம் தொடங்குவதற்கு முன்: ஏன்?

  • ஏன் GitLab?

ஏனென்றால், செல்லப் பிராணிகளுக்கான தனியார் களஞ்சியங்களை உருவாக்க வேண்டிய அவசியம் ஏற்பட்டபோது, ​​அவர்கள் கிட்ஹப்பில் பணம் செலுத்தினர், நான் பேராசை கொண்டேன். களஞ்சியங்கள் இலவசமாகிவிட்டன, ஆனால் தற்போதைக்கு இது எனக்கு GitHub க்கு செல்ல போதுமான காரணம் அல்ல.

  • ஏன் Azure DevOps பைப்லைன்கள் இல்லை?

அமைப்பு எளிதானது என்பதால் - உங்களுக்கு கட்டளை வரி அறிவு கூட தேவையில்லை. வெளிப்புற ஜிட் வழங்குநர்களுடன் ஒருங்கிணைப்பு - ஓரிரு கிளிக்குகளில், களஞ்சியத்திற்கு அனுப்புவதற்கான SSH விசைகளின் இறக்குமதி - மேலும், டெம்ப்ளேட் இல்லாமல் கூட பைப்லைன் எளிதாக கட்டமைக்கப்படுகிறது.

தொடக்க நிலை: உங்களிடம் என்ன இருக்கிறது மற்றும் உங்களுக்கு என்ன வேண்டும்

எங்களிடம் உள்ளது:

  • GitLab இல் களஞ்சியம்.

எங்களுக்கு வேண்டும்:

  • ஒவ்வொரு ஒன்றிணைப்பு கோரிக்கைக்கும் தானியங்கி அசெம்பிளி மற்றும் சோதனை,
  • ஒவ்வொரு ஒன்றிணைப்புக் கோரிக்கைக்கும் தொகுப்புகளை உருவாக்கி, உறுதிச் செய்தியில் ஒரு குறிப்பிட்ட வரி இருந்தால், மாஸ்டருக்குத் தள்ளுதல்,
  • Azure DevOps இல் ஒரு தனிப்பட்ட ஊட்டத்திற்கு சேகரிக்கப்பட்ட தொகுப்புகளை அனுப்புதல்,
  • GitLab பக்கங்களில் ஆவணங்கள் மற்றும் வெளியீடுகளின் தொகுப்பு,
  • பேட்ஜ்கள்!11

விவரிக்கப்பட்ட தேவைகள் இயற்கையாகவே பின்வரும் குழாய் மாதிரியில் பொருந்துகின்றன:

  • நிலை 1 - சட்டசபை
    • நாங்கள் குறியீட்டை சேகரித்து, வெளியீட்டு கோப்புகளை கலைப்பொருட்களாக வெளியிடுகிறோம்
  • நிலை 2 - சோதனை
    • நாங்கள் உருவாக்க நிலையிலிருந்து கலைப்பொருட்களைப் பெறுகிறோம், சோதனைகளை இயக்குகிறோம், குறியீடு கவரேஜ் தரவைச் சேகரிக்கிறோம்
  • நிலை 3 - அனுப்புதல்
    • பணி 1 - nuget தொகுப்பை சேகரித்து Azure DevOps க்கு அனுப்பவும்
    • பணி 2 - நாங்கள் xmldoc இலிருந்து தளத்தை மூலக் குறியீட்டில் சேகரித்து அதை GitLab பக்கங்களில் வெளியிடுகிறோம்

ஆரம்பிக்கலாம்!

கட்டமைப்பை அசெம்பிள் செய்தல்

கணக்குகளைத் தயாரித்தல்

  1. ஒரு கணக்கை உருவாக்கவும் மைக்ரோசாப்ட் அசூர்

  2. செல்க அசூர் டெவொப்ஸ்

  3. புதிய திட்டத்தை உருவாக்கவும்

    1. பெயர் - ஏதேனும்
    2. பார்வை - ஏதேனும்
      (கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

  4. நீங்கள் உருவாக்கு பொத்தானைக் கிளிக் செய்தால், திட்டம் உருவாக்கப்பட்டு அதன் பக்கத்திற்கு நீங்கள் அழைத்துச் செல்லப்படுவீர்கள். இந்தப் பக்கத்தில், திட்ட அமைப்புகளுக்குச் சென்று தேவையற்ற அம்சங்களை முடக்கலாம் (இடதுபுறத்தில் உள்ள பட்டியலில் கீழ் இணைப்பு -> மேலோட்டம் -> Azure DevOps Services block)
    (கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

  5. Atrifacts க்குச் சென்று, ஊட்டத்தை உருவாக்கு என்பதைக் கிளிக் செய்யவும்

    1. மூலப் பெயரை உள்ளிடவும்
    2. தெரிவுநிலையைத் தேர்ந்தெடுக்கவும்
    3. பெட்டியைத் தேர்வுநீக்கவும் பொதுவான பொது ஆதாரங்களில் இருந்து தொகுப்புகளைச் சேர்க்கவும்அதனால் மூலமானது ஒரு nuget குளோனின் குப்பைக் கிடங்காக மாறாது
      (கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

  6. ஊட்டத்திற்கு இணை என்பதைக் கிளிக் செய்யவும், விஷுவல் ஸ்டுடியோவைத் தேர்ந்தெடுக்கவும், இயந்திர அமைவுத் தொகுதியிலிருந்து மூலத்தை நகலெடுக்கவும்
    (கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

  7. கணக்கு அமைப்புகளுக்குச் சென்று, தனிப்பட்ட அணுகல் டோக்கனைத் தேர்ந்தெடுக்கவும்
    (கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

  8. புதிய அணுகல் டோக்கனை உருவாக்கவும்

    1. பெயர் - தன்னிச்சையானது
    2. அமைப்பு - தற்போதைய
    3. செல்லுபடியாகும் காலம்: அதிகபட்சம் 1 வருடம்
    4. நோக்கம் - பேக்கேஜிங்/படித்தல் & எழுதுதல்
      (கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

  9. உருவாக்கப்பட்ட டோக்கனை நகலெடுக்கவும் - மாதிரி சாளரத்தை மூடிய பிறகு மதிப்பு கிடைக்காது

  10. GitLab இல் உள்ள களஞ்சிய அமைப்புகளுக்குச் சென்று, CI/CD அமைப்புகளைத் தேர்ந்தெடுக்கவும்
    (கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

  11. மாறிகள் தொகுதியை விரிவுபடுத்தி புதிய ஒன்றைச் சேர்க்கவும்

    1. பெயர் - இடைவெளிகள் இல்லாதவை (கமாண்ட் ஷெல்லில் கிடைக்கும்)
    2. மதிப்பு என்பது படி 9 இலிருந்து அணுகல் டோக்கன் ஆகும்
    3. மாஸ்க் மாறியைத் தேர்ந்தெடுக்கவும்
      (கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

இது பூர்வாங்க அமைப்பை நிறைவு செய்கிறது.

உள்ளமைவு கட்டமைப்பைத் தயாரித்தல்

இயல்பாக, GitLab இல் CI/CD ஐ உள்ளமைக்கப் பயன்படுத்தப்படும் கோப்பு .gitlab-ci.yml களஞ்சியத்தின் மூலத்திலிருந்து. களஞ்சிய அமைப்புகளில் இந்தக் கோப்பிற்கான தனிப்பயன் பாதையை நீங்கள் கட்டமைக்கலாம், ஆனால் இந்த விஷயத்தில் அது தேவையில்லை.

நீட்டிப்பிலிருந்து பார்க்க முடிந்தால், கோப்பில் வடிவமைப்பில் உள்ளமைவு உள்ளது YAML. உள்ளமைவின் மேல் மட்டத்திலும் ஒவ்வொரு உள்ளமை நிலைகளிலும் என்ன விசைகள் இருக்க வேண்டும் என்பதை ஆவணங்கள் விரிவாக விவரிக்கிறது.

முதலில், உள்ளமைவு கோப்பில் டாக்கர் படத்திற்கான இணைப்பைச் சேர்ப்போம், அதில் பணிகள் செயல்படுத்தப்படும். இதைச் செய்ய, நாங்கள் கண்டுபிடிக்கிறோம் டோக்கர் ஹப்பில் நெட் கோர் படங்கள் பக்கம். தி மகிழ்ச்சியா வெவ்வேறு பணிகளுக்கு எந்த படத்தை தேர்வு செய்வது என்பது குறித்த விரிவான வழிகாட்டி உள்ளது. .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

இயற்கையாகவே, சில நுணுக்கங்கள் உள்ளன, இதன் காரணமாக கட்டளைகளை ஓரளவு சிக்கலாக்குவோம்.

  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 இல், கனெக்ட் டு ஃபீட் விண்டோவில், எப்பொழுதும் எடுத்துக்காட்டாக வரி இருக்கும் 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 இல் Gtntral பைப்லைன்ஸ் பிளாக்கில் உள்ள CI/CD அமைப்புகளில் கிடைக்கும்:

(கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

மேடையில் ஆவணப்படுத்தலுக்கான இணைப்புடன் ஒரு பேட்ஜை உருவாக்கினேன் shields.io — அங்கு எல்லாம் மிகவும் நேரடியானது, நீங்கள் உங்கள் சொந்த பேட்ஜை உருவாக்கலாம் மற்றும் கோரிக்கையைப் பயன்படுத்தி அதைப் பெறலாம்.

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

(கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

Azure DevOps கலைப்பொருட்கள் சமீபத்திய பதிப்பைக் குறிக்கும் தொகுப்புகளுக்கான பேட்ஜ்களை உருவாக்க உங்களை அனுமதிக்கிறது. இதைச் செய்ய, Azure DevOps இணையதளத்தில் உள்ள மூலத்தில், தேர்ந்தெடுக்கப்பட்ட தொகுப்பிற்கான பேட்ஜை உருவாக்கு என்பதைக் கிளிக் செய்து மார்க் டவுன் மார்க்அப்பை நகலெடுக்க வேண்டும்:

(கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

(கிட்டத்தட்ட) முழுமையான புதியவர்களுக்கு GitLab இல் CI/CDக்கான வழிகாட்டி

அழகு சேர்க்கிறது

பொதுவான கட்டமைப்பு துண்டுகளை நாங்கள் முன்னிலைப்படுத்துகிறோம்

கட்டமைப்பை எழுதும் போது மற்றும் ஆவணங்கள் மூலம் தேடும் போது, ​​நான் ஒரு சுவாரஸ்யமான 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 இந்த வழிகாட்டியைப் படித்த பிறகு தோன்றுவதை விட மிகவும் விரிவானது மற்றும் பன்முகத்தன்மை கொண்டது - அது உண்மையல்ல. கூட இருக்கிறது ஆட்டோ டெவொப்ஸ் ஆம்அனுமதிக்கிறது

உங்கள் பயன்பாடுகளைத் தானாகக் கண்டறியவும், உருவாக்கவும், சோதிக்கவும், வரிசைப்படுத்தவும் மற்றும் கண்காணிக்கவும்

இப்போது Azure இல் பயன்பாடுகளை வரிசைப்படுத்தவும், Pulumi ஐப் பயன்படுத்தவும் மற்றும் இலக்கு சூழலை தானாகக் கண்டறியவும் ஒரு பைப்லைனை உள்ளமைக்க திட்டமிடப்பட்டுள்ளது, இது அடுத்த கட்டுரையில் விவாதிக்கப்படும்.

ஆதாரம்: www.habr.com

கருத்தைச் சேர்