(ഏതാണ്ട്) സമ്പൂർണ്ണ തുടക്കക്കാർക്കായി GitLab-ലെ CI/CD-യിലേക്കുള്ള ഒരു ഗൈഡ്

അല്ലെങ്കിൽ ലളിതമായ കോഡിംഗിന്റെ ഒരു സായാഹ്നത്തിൽ നിങ്ങളുടെ പ്രോജക്റ്റിനായി മനോഹരമായ ബാഡ്ജുകൾ എങ്ങനെ നേടാം

ഒരുപക്ഷേ, കുറഞ്ഞത് ഒരു പെറ്റ് പ്രോജക്‌റ്റെങ്കിലും ഉള്ള ഓരോ ഡെവലപ്പർക്കും സ്റ്റാറ്റസുകളുള്ള മനോഹരമായ ബാഡ്‌ജുകൾ, കോഡ് കവറേജ്, ന്യൂജെറ്റിലെ പാക്കേജ് പതിപ്പുകൾ എന്നിവയെക്കുറിച്ച് ഒരു ചൊറിച്ചിൽ ഉണ്ടായിരിക്കാം ... ഈ ചൊറിച്ചിലാണ് ഈ ലേഖനം എഴുതാൻ എന്നെ പ്രേരിപ്പിച്ചത്. ഇത് എഴുതാനുള്ള തയ്യാറെടുപ്പിൽ, എന്റെ പ്രോജക്റ്റുകളിലൊന്നിൽ എനിക്ക് ഈ സൗന്ദര്യം ലഭിച്ചു:

ഈ ലേഖനം GitLab-ലെ ഒരു .Net Core ക്ലാസ് ലൈബ്രറി പ്രോജക്റ്റിനായുള്ള തുടർച്ചയായ സംയോജനത്തിന്റെയും ഡെലിവറിയുടെയും അടിസ്ഥാന സജ്ജീകരണത്തിലൂടെ നിങ്ങളെ നയിക്കും, GitLab പേജുകളിലേക്ക് ഡോക്യുമെന്റേഷൻ പ്രസിദ്ധീകരിക്കുന്നു, കൂടാതെ Azure DevOps-ലെ ഒരു സ്വകാര്യ ഫീഡിലേക്ക് ബിൽറ്റ് പാക്കേജുകൾ തള്ളുന്നു.

വിപുലീകരണത്തിനൊപ്പം വികസന അന്തരീക്ഷമായി വിഎസ് കോഡ് ഉപയോഗിച്ചു GitLab വർക്ക്ഫ്ലോ (വികസന പരിതസ്ഥിതിയിൽ നിന്ന് നേരിട്ട് ക്രമീകരണ ഫയൽ സാധൂകരിക്കുന്നതിന്).

സംക്ഷിപ്ത ആമുഖം

സിഡി - നിങ്ങൾ തള്ളുമ്പോഴാണോ, എല്ലാം ഇതിനകം ക്ലയന്റിലേക്ക് വീണിട്ടുണ്ടോ?

എന്താണ് CI / CD, നിങ്ങൾക്ക് അത് എന്തുകൊണ്ട് ആവശ്യമാണ് - നിങ്ങൾക്ക് അത് എളുപ്പത്തിൽ ഗൂഗിൾ ചെയ്യാൻ കഴിയും. GitLab-ൽ പൈപ്പ്ലൈനുകൾ ക്രമീകരിക്കുന്നതിനുള്ള പൂർണ്ണമായ ഡോക്യുമെന്റേഷൻ കണ്ടെത്തുക എളുപ്പവും. ഇവിടെ ഞാൻ ചുരുക്കമായി, സാധ്യമെങ്കിൽ, പിഴവുകളില്ലാതെ, ഒരു പക്ഷിയുടെ കാഴ്ചയിൽ നിന്ന് സിസ്റ്റത്തിന്റെ പ്രക്രിയ വിവരിക്കും:

• ഡെവലപ്പർ റിപ്പോസിറ്ററിയിലേക്ക് ഒരു പ്രതിബദ്ധത അയയ്ക്കുന്നു, സൈറ്റിലൂടെ ഒരു ലയന അഭ്യർത്ഥന സൃഷ്ടിക്കുന്നു, അല്ലെങ്കിൽ മറ്റേതെങ്കിലും വിധത്തിൽ, വ്യക്തമായും അല്ലെങ്കിൽ പരോക്ഷമായും പൈപ്പ്ലൈൻ ആരംഭിക്കുന്നു,
• എല്ലാ ടാസ്ക്കുകളും കോൺഫിഗറേഷനിൽ നിന്നാണ് തിരഞ്ഞെടുത്തിരിക്കുന്നത്, നൽകിയിരിക്കുന്ന സന്ദർഭത്തിൽ അവ സമാരംഭിക്കാൻ അനുവദിക്കുന്ന വ്യവസ്ഥകൾ,
• ചുമതലകൾ അവയുടെ ഘട്ടങ്ങൾക്കനുസരിച്ച് ക്രമീകരിച്ചിരിക്കുന്നു,
• ഘട്ടങ്ങൾ ക്രമത്തിൽ നടപ്പിലാക്കുന്നു - അതായത്. സമാന്തരമായി ഈ ഘട്ടത്തിലെ എല്ലാ ജോലികളും പൂർത്തിയായി,
• സ്റ്റേജ് പരാജയപ്പെടുകയാണെങ്കിൽ (അതായത്, സ്റ്റേജിന്റെ ഒരു ജോലിയെങ്കിലും പരാജയപ്പെടുകയാണെങ്കിൽ), പൈപ്പ്ലൈൻ നിർത്തുന്നു (ഏറെക്കുറെ എല്ലായ്പ്പോഴും),
• എല്ലാ ഘട്ടങ്ങളും വിജയകരമായി പൂർത്തിയാക്കിയാൽ, പൈപ്പ്ലൈൻ വിജയകരമാണെന്ന് കണക്കാക്കുന്നു.

അതിനാൽ, ഞങ്ങൾക്ക് ഉണ്ട്:

• പൈപ്പ്‌ലൈൻ - നിങ്ങൾക്ക് നിർമ്മിക്കാനും ടെസ്റ്റ് ചെയ്യാനും പാക്കേജ് കോഡ് ചെയ്യാനും ഒരു ക്ലൗഡ് സേവനത്തിലേക്ക് പൂർത്തിയായ ബിൽഡ് വിന്യസിക്കാനും കഴിയുന്ന ഘട്ടങ്ങളായി ക്രമീകരിച്ചിരിക്കുന്ന ഒരു കൂട്ടം ജോലികൾ.
• ഘട്ടം (സ്റ്റേജ്) - പൈപ്പ്ലൈൻ ഓർഗനൈസേഷൻ യൂണിറ്റ്, 1+ ടാസ്ക്ക് ഉൾക്കൊള്ളുന്നു,
• ചുമതല (ജോലി) പൈപ്പ്ലൈനിലെ ജോലിയുടെ ഒരു യൂണിറ്റാണ്. ഇതിൽ ഒരു സ്ക്രിപ്റ്റ് (നിർബന്ധം), ലോഞ്ച് വ്യവസ്ഥകൾ, പുരാവസ്തുക്കൾ പ്രസിദ്ധീകരിക്കുന്നതിനുള്ള/കാഷെ ചെയ്യുന്നതിനുള്ള ക്രമീകരണങ്ങൾ എന്നിവയും അതിലേറെയും അടങ്ങിയിരിക്കുന്നു.

അതനുസരിച്ച്, CI / CD സജ്ജീകരിക്കുമ്പോൾ, കോഡും ആർട്ടിഫാക്റ്റുകളും നിർമ്മിക്കുന്നതിനും പരിശോധിക്കുന്നതിനും പ്രസിദ്ധീകരിക്കുന്നതിനും ആവശ്യമായ എല്ലാ പ്രവർത്തനങ്ങളും നടപ്പിലാക്കുന്ന ഒരു കൂട്ടം ടാസ്‌ക്കുകൾ സൃഷ്ടിക്കുന്നതിലേക്ക് വരുന്നു.

ആരംഭിക്കുന്നതിന് മുമ്പ്: എന്തുകൊണ്ട്?

• എന്തുകൊണ്ട് Gitlab?

കാരണം വളർത്തുമൃഗങ്ങളുടെ പ്രോജക്റ്റുകൾക്കായി സ്വകാര്യ ശേഖരണങ്ങൾ സൃഷ്ടിക്കേണ്ടത് ആവശ്യമായി വന്നപ്പോൾ, അവർക്ക് GitHub-ൽ പണം നൽകി, ഞാൻ അത്യാഗ്രഹിയായിരുന്നു. റിപ്പോസിറ്ററികൾ സൌജന്യമായി മാറിയിരിക്കുന്നു, എന്നാൽ ഇതുവരെ എനിക്ക് GitHub-ലേക്ക് മാറാൻ ഇത് മതിയായ കാരണമല്ല.

• എന്തുകൊണ്ട് Azure DevOps പൈപ്പ്ലൈനുകൾ പാടില്ല?

കാരണം അവിടെ ക്രമീകരണം പ്രാഥമികമാണ് - കമാൻഡ് ലൈനിനെക്കുറിച്ചുള്ള അറിവ് പോലും ആവശ്യമില്ല. എക്‌സ്‌റ്റേണൽ ജിറ്റ് ദാതാക്കളുമായുള്ള സംയോജനം - രണ്ട് ക്ലിക്കുകളിലൂടെ, റിപ്പോസിറ്ററിയിലേക്ക് അയയ്‌ക്കുന്നതിനുള്ള SSH കീകൾ ഇറക്കുമതി ചെയ്യുക - കൂടാതെ, ഒരു ടെംപ്ലേറ്റിൽ നിന്നല്ലെങ്കിലും പൈപ്പ്ലൈൻ എളുപ്പത്തിൽ കോൺഫിഗർ ചെയ്യപ്പെടുന്നു.

ആരംഭ സ്ഥാനം: നിങ്ങൾക്ക് ഉള്ളതും നിങ്ങൾക്ക് ആവശ്യമുള്ളതും

നമുക്ക് ഉണ്ട്:

• GitLab-ലെ ശേഖരം.

ഞങ്ങൾ ആഗ്രഹിക്കുന്നു:

• ഓരോ ലയന അഭ്യർത്ഥനയ്ക്കും സ്വയമേവയുള്ള അസംബ്ലിയും പരിശോധനയും,
• ഓരോ ലയന അഭ്യർത്ഥനയ്ക്കും പാക്കേജുകൾ നിർമ്മിക്കുകയും മാസ്റ്ററിലേക്ക് തള്ളുകയും ചെയ്യുന്നു, കമ്മിറ്റ് സന്ദേശത്തിൽ ഒരു നിശ്ചിത ലൈൻ ഉണ്ടെങ്കിൽ,
• Azure DevOps-ലെ ഒരു സ്വകാര്യ ഫീഡിലേക്ക് ബിൽറ്റ് പാക്കേജുകൾ അയയ്ക്കുന്നു,
• GitLab പേജുകളിൽ ഡോക്യുമെന്റേഷന്റെയും പ്രസിദ്ധീകരണത്തിന്റെയും അസംബ്ലി,
• ബാഡ്ജുകൾ!11

വിവരിച്ച ആവശ്യകതകൾ ജൈവികമായി ഇനിപ്പറയുന്ന പൈപ്പ്ലൈൻ മോഡലിൽ ഉൾപ്പെടുന്നു:

• ഘട്ടം 1 - അസംബ്ലി
  • ഞങ്ങൾ കോഡ് ശേഖരിക്കുന്നു, ഔട്ട്പുട്ട് ഫയലുകൾ ആർട്ടിഫാക്റ്റുകളായി പ്രസിദ്ധീകരിക്കുന്നു
• ഘട്ടം 2 - പരിശോധന
  • നിർമ്മാണ ഘട്ടത്തിൽ നിന്ന് ഞങ്ങൾക്ക് പുരാവസ്തുക്കൾ ലഭിക്കുന്നു, ടെസ്റ്റുകൾ നടത്തുന്നു, കോഡ് കവറേജ് ഡാറ്റ ശേഖരിക്കുന്നു
• ഘട്ടം 3 - സമർപ്പിക്കുക
  • ടാസ്ക് 1 - ന്യൂഗറ്റ് പാക്കേജ് നിർമ്മിച്ച് അത് Azure DevOps-ലേക്ക് അയയ്ക്കുക
  • ടാസ്ക് 2 - ഞങ്ങൾ സോഴ്സ് കോഡിലെ xmldoc ൽ നിന്ന് സൈറ്റ് ശേഖരിക്കുകയും അത് GitLab പേജുകളിൽ പ്രസിദ്ധീകരിക്കുകയും ചെയ്യുന്നു

നമുക്ക് തുടങ്ങാം!

കോൺഫിഗറേഷൻ ശേഖരിക്കുന്നു

അക്കൗണ്ടുകൾ തയ്യാറാക്കുന്നു

1. ഒരു അക്കൗണ്ട് സൃഷ്ടിക്കുക Microsoft Azure

2. പോകുക അസുർ ഡെവൊപ്‌സ്

3. ഞങ്ങൾ ഒരു പുതിയ പ്രോജക്റ്റ് സൃഷ്ടിക്കുന്നു

   1. പേര് - ഏതെങ്കിലും
   2. ദൃശ്യപരത - ഏതെങ്കിലും
      

4. നിങ്ങൾ സൃഷ്ടിക്കുക ബട്ടണിൽ ക്ലിക്കുചെയ്യുമ്പോൾ, പ്രോജക്റ്റ് സൃഷ്ടിക്കപ്പെടും, നിങ്ങളെ അതിന്റെ പേജിലേക്ക് റീഡയറക്‌ടുചെയ്യും. ഈ പേജിൽ, പ്രോജക്റ്റ് ക്രമീകരണങ്ങളിലേക്ക് പോയി നിങ്ങൾക്ക് അനാവശ്യ സവിശേഷതകൾ പ്രവർത്തനരഹിതമാക്കാം (ഇടതുവശത്തുള്ള ലിസ്റ്റിലെ താഴ്ന്ന ലിങ്ക് -> അവലോകനം -> Azure DevOps Services block)
   

5. Atrifacts-ലേക്ക് പോകുക, ഫീഡ് സൃഷ്‌ടിക്കുക ക്ലിക്കുചെയ്യുക

   1. ഉറവിടത്തിന്റെ പേര് നൽകുക
   2. ദൃശ്യപരത തിരഞ്ഞെടുക്കുക
   3. അൺചെക്ക് ചെയ്യുക പൊതു പൊതു ഉറവിടങ്ങളിൽ നിന്നുള്ള പാക്കേജുകൾ ഉൾപ്പെടുത്തുക, അതിനാൽ ഉറവിടം ഒരു ഡംപ് ന്യൂഗറ്റ് ക്ലോണായി മാറില്ല
      

6. ഫീഡ് ചെയ്യാൻ ബന്ധിപ്പിക്കുക ക്ലിക്കുചെയ്യുക, വിഷ്വൽ സ്റ്റുഡിയോ തിരഞ്ഞെടുക്കുക, മെഷീൻ സെറ്റപ്പ് ബ്ലോക്കിൽ നിന്ന് ഉറവിടം പകർത്തുക
   

7. അക്കൗണ്ട് ക്രമീകരണങ്ങളിലേക്ക് പോകുക, വ്യക്തിഗത ആക്സസ് ടോക്കൺ തിരഞ്ഞെടുക്കുക
   

8. ഒരു പുതിയ ആക്‌സസ് ടോക്കൺ സൃഷ്‌ടിക്കുക

   1. പേര് - ഏകപക്ഷീയമായ
   2. ഓർഗനൈസേഷൻ - നിലവിലുള്ളത്
   3. പരമാവധി 1 വർഷത്തേക്ക് സാധുതയുണ്ട്
   4. വ്യാപ്തി - പാക്കേജിംഗ്/വായിക്കുക & എഴുതുക
      

9. സൃഷ്ടിച്ച ടോക്കൺ പകർത്തുക - മോഡൽ വിൻഡോ അടച്ച ശേഷം, മൂല്യം ലഭ്യമല്ല

10. GitLab-ലെ റിപ്പോസിറ്ററി ക്രമീകരണങ്ങളിലേക്ക് പോകുക, CI / CD ക്രമീകരണങ്ങൾ തിരഞ്ഞെടുക്കുക
    

11. വേരിയബിൾ ബ്ലോക്ക് വികസിപ്പിക്കുക, പുതിയൊരെണ്ണം ചേർക്കുക

    1. പേര് - സ്‌പെയ്‌സുകളില്ലാത്തവ (കമാൻഡ് ഷെല്ലിൽ ലഭ്യമാകും)
    2. മൂല്യം - ഖണ്ഡിക 9-ൽ നിന്നുള്ള ആക്സസ് ടോക്കൺ
    3. മാസ്ക് വേരിയബിൾ തിരഞ്ഞെടുക്കുക
       

ഇത് പ്രീ-കോൺഫിഗറേഷൻ പൂർത്തിയാക്കുന്നു.

കോൺഫിഗറേഷൻ ചട്ടക്കൂട് തയ്യാറാക്കുന്നു

സ്ഥിരസ്ഥിതിയായി, 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/*

പാതകൾ വൈൽഡ്കാർഡുകളെ പിന്തുണയ്ക്കുന്നു, അത് തീർച്ചയായും അവയെ സജ്ജീകരിക്കുന്നത് എളുപ്പമാക്കുന്നു.

ഒരു ടാസ്‌ക് ആർട്ടിഫാക്‌റ്റുകൾ സൃഷ്‌ടിക്കുന്നുവെങ്കിൽ, തുടർന്നുള്ള ഓരോ ടാസ്‌ക്കിനും അവ ആക്‌സസ് ചെയ്യാൻ കഴിയും - അവ യഥാർത്ഥ ടാസ്‌ക്കിൽ നിന്ന് ശേഖരിച്ച ശേഖരണ റൂട്ടുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ അതേ പാതയിൽ സ്ഥിതിചെയ്യും. പുരാവസ്തുക്കൾ സൈറ്റിൽ ഡൗൺലോഡ് ചെയ്യാനും ലഭ്യമാണ്.

ഇപ്പോൾ നമുക്ക് ഒരു കോൺഫിഗറേഷൻ ചട്ടക്കൂട് തയ്യാറായിക്കഴിഞ്ഞു (പരീക്ഷിച്ചു), ടാസ്‌ക്കുകൾക്കായി യഥാർത്ഥത്തിൽ സ്‌ക്രിപ്റ്റുകൾ എഴുതുന്നത് തുടരാം.

ഞങ്ങൾ സ്ക്രിപ്റ്റുകൾ എഴുതുന്നു

ഒരുപക്ഷേ, ഒരിക്കൽ, വളരെ ദൂരെയുള്ള ഒരു ഗാലക്സിയിൽ, കമാൻഡ് ലൈനിൽ നിന്ന് പ്രോജക്ടുകൾ നിർമ്മിക്കുന്നത് (.നെറ്റിൽ ഉള്ളവ ഉൾപ്പെടെ) ഒരു വേദനയായിരുന്നു. ഇപ്പോൾ നിങ്ങൾക്ക് 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. ന്യൂജെറ്റ് പാക്കേജുകളിലേക്ക് കോഡ് പാക്ക് ചെയ്യുമ്പോൾ, പാക്കേജുകൾക്കായി ഔട്ട്പുട്ട് ഡയറക്ടറി സജ്ജമാക്കുക: -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+%)/

മൊത്തം ലൈൻ കവറേജുള്ള ഒരു ലൈനിൽ നിന്നുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ ഇവിടെ ലഭിക്കും.

പാക്കേജുകളും ഡോക്യുമെന്റേഷനും പ്രസിദ്ധീകരിക്കുക

രണ്ട് പ്രവർത്തനങ്ങളും പൈപ്പ്ലൈനിന്റെ അവസാന ഘട്ടത്തിനായി ഷെഡ്യൂൾ ചെയ്തിട്ടുണ്ട് - അസംബ്ലിയും ടെസ്റ്റുകളും കടന്നുപോയതിനാൽ, ഞങ്ങളുടെ സംഭവവികാസങ്ങൾ ലോകവുമായി പങ്കിടാം.

ആദ്യം, പാക്കേജ് ഉറവിടത്തിൽ പ്രസിദ്ധീകരിക്കുന്നത് പരിഗണിക്കുക:

1. പ്രോജക്റ്റിന് ഒരു ന്യൂഗറ്റ് കോൺഫിഗറേഷൻ ഫയൽ ഇല്ലെങ്കിൽ (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

ഡോക്‌എഫ്‌എക്‌സിനെക്കുറിച്ചുള്ള ലിറിക്കൽ ഡൈഗ്രഷൻ

മുമ്പ്, ഒരു പ്രോജക്റ്റ് സജ്ജീകരിക്കുമ്പോൾ, ഡോക്യുമെന്റേഷന്റെ കോഡ് ഉറവിടം ഒരു പരിഹാര ഫയലായി ഞാൻ വ്യക്തമാക്കിയിരുന്നു. ടെസ്റ്റ് പ്രോജക്റ്റുകൾക്കായി ഡോക്യുമെന്റേഷനും സൃഷ്ടിച്ചിരിക്കുന്നു എന്നതാണ് പ്രധാന പോരായ്മ. ഇത് ആവശ്യമില്ലെങ്കിൽ, നിങ്ങൾക്ക് ഈ മൂല്യം നോഡിലേക്ക് സജ്ജമാക്കാൻ കഴിയും 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

ബാഡ്ജുകളെക്കുറിച്ച് സംസാരിക്കുന്നു

അവർ കാരണം, എല്ലാത്തിനുമുപരി, എല്ലാം ആരംഭിച്ചു!

പൈപ്പ്‌ലൈൻ സ്റ്റാറ്റസുകളും കോഡ് കവറേജുമുള്ള ബാഡ്ജുകൾ Gtntral പൈപ്പ്‌ലൈൻ ബ്ലോക്കിലെ CI/CD ക്രമീകരണങ്ങളിൽ GitLab-ൽ ലഭ്യമാണ്:

പ്ലാറ്റ്‌ഫോമിലെ ഡോക്യുമെന്റേഷനിലേക്കുള്ള ലിങ്കുള്ള ഒരു ബാഡ്ജ് ഞാൻ സൃഷ്‌ടിച്ചു Shields.io - അവിടെ എല്ലാം വളരെ ലളിതമാണ്, നിങ്ങൾക്ക് നിങ്ങളുടെ സ്വന്തം ബാഡ്ജ് സൃഷ്ടിക്കാനും ഒരു അഭ്യർത്ഥന ഉപയോഗിച്ച് അത് സ്വീകരിക്കാനും കഴിയും.

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

Azure DevOps ആർട്ടിഫാക്‌റ്റുകൾ ഏറ്റവും പുതിയ പതിപ്പിനൊപ്പം പാക്കേജുകൾക്കായി ബാഡ്ജുകൾ സൃഷ്ടിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു. ഇത് ചെയ്യുന്നതിന്, Azure DevOps സൈറ്റിലെ ഉറവിടത്തിൽ, നിങ്ങൾ തിരഞ്ഞെടുത്ത പാക്കേജിനായി സൃഷ്ടിക്കുക ബാഡ്ജിൽ ക്ലിക്കുചെയ്‌ത് മാർക്ക്ഡൗൺ മാർക്ക്അപ്പ് പകർത്തേണ്ടതുണ്ട്:

ഭംഗി കൂട്ടുന്നു

പൊതുവായ കോൺഫിഗറേഷൻ ശകലങ്ങൾ ഹൈലൈറ്റ് ചെയ്യുന്നു

കോൺഫിഗറേഷൻ എഴുതുകയും ഡോക്യുമെന്റേഷനിലൂടെ തിരയുകയും ചെയ്യുമ്പോൾ, YAML-ന്റെ ഒരു രസകരമായ സവിശേഷത ഞാൻ കണ്ടു - ശകലങ്ങൾ വീണ്ടും ഉപയോഗിക്കുന്നു.

ടാസ്‌ക് ക്രമീകരണങ്ങളിൽ നിന്ന് നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, അവയ്‌ക്കെല്ലാം ടാഗ് ആവശ്യമാണ് windows റണ്ണറിലും, മാസ്റ്ററിലേക്ക്/സൃഷ്ടിച്ച (ഡോക്യുമെന്റേഷൻ ഒഴികെ) ഒരു ലയന അഭ്യർത്ഥന അയയ്‌ക്കുമ്പോൾ അത് പ്രവർത്തനക്ഷമമാകും. ഞങ്ങൾ വീണ്ടും ഉപയോഗിക്കുന്ന ശകലത്തിലേക്ക് ഇത് ചേർക്കാം:

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

ഇപ്പോൾ നമുക്ക് ടാസ്ക് വിവരണത്തിൽ നേരത്തെ പ്രഖ്യാപിച്ച ശകലം ചേർക്കാം:

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

ശകലങ്ങളുടെ പേരുകൾ ഒരു ഡോട്ടിൽ തുടങ്ങണം, അതിനാൽ ഒരു ടാസ്ക് ആയി വ്യാഖ്യാനിക്കരുത്.

പാക്കേജ് പതിപ്പിംഗ്

ഒരു പാക്കേജ് സൃഷ്ടിക്കുമ്പോൾ, കംപൈലർ കമാൻഡ് ലൈൻ സ്വിച്ചുകൾ പരിശോധിക്കുന്നു, അവരുടെ അഭാവത്തിൽ, പ്രോജക്റ്റ് ഫയലുകൾ; ഒരു പതിപ്പ് നോഡ് കണ്ടെത്തുമ്പോൾ, അത് നിർമ്മിക്കുന്ന പാക്കേജിന്റെ പതിപ്പായി അതിന്റെ മൂല്യം എടുക്കുന്നു. ഒരു പുതിയ പതിപ്പ് ഉപയോഗിച്ച് ഒരു പാക്കേജ് നിർമ്മിക്കുന്നതിന്, നിങ്ങൾ അത് പ്രോജക്റ്റ് ഫയലിൽ അപ്ഡേറ്റ് ചെയ്യണം അല്ലെങ്കിൽ ഒരു കമാൻഡ് ലൈൻ ആർഗ്യുമെന്റായി കൈമാറണം.

നമുക്ക് ഒരു വിഷ്‌ലിസ്റ്റ് കൂടി ചേർക്കാം - പതിപ്പിലെ ചെറിയ രണ്ട് അക്കങ്ങൾ പാക്കേജിന്റെ വർഷവും ബിൽഡ് തീയതിയും ആയിരിക്കട്ടെ, കൂടാതെ പ്രീറിലീസ് പതിപ്പുകൾ ചേർക്കുക. തീർച്ചയായും, നിങ്ങൾക്ക് ഈ ഡാറ്റ പ്രോജക്റ്റ് ഫയലിലേക്ക് ചേർക്കാനും ഓരോ സമർപ്പണത്തിന് മുമ്പായി പരിശോധിക്കാനും കഴിയും - എന്നാൽ നിങ്ങൾക്ക് ഇത് പൈപ്പ്ലൈനിലും ചെയ്യാം, സന്ദർഭത്തിൽ നിന്ന് പാക്കേജ് പതിപ്പ് ശേഖരിച്ച് കമാൻഡ് ലൈൻ ആർഗ്യുമെന്റിലൂടെ കടന്നുപോകാം.

കമ്മിറ്റ് മെസേജിൽ ഇങ്ങനെ ഒരു ലൈൻ ഉണ്ടെന്ന് സമ്മതിക്കാം release (v./ver./version) <version number> (rev./revision <revision>)?, തുടർന്ന് ഞങ്ങൾ ഈ വരിയിൽ നിന്ന് പാക്കേജിന്റെ പതിപ്പ് എടുക്കും, അത് നിലവിലെ തീയതിയുമായി സപ്ലിമെന്റ് ചെയ്യുകയും കമാൻഡിലേക്ക് ഒരു ആർഗ്യുമെന്റായി കൈമാറുകയും ചെയ്യും. dotnet pack. ഒരു വരിയുടെ അഭാവത്തിൽ, ഞങ്ങൾ പാക്കേജ് ശേഖരിക്കില്ല.

ഇനിപ്പറയുന്ന സ്ക്രിപ്റ്റ് ഈ പ്രശ്നം പരിഹരിക്കുന്നു:

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

ഒരു ടാസ്ക്കിലേക്ക് ഒരു സ്ക്രിപ്റ്റ് ചേർക്കുന്നു pack and deploy job കമ്മിറ്റ് സന്ദേശത്തിൽ നൽകിയിരിക്കുന്ന സ്ട്രിംഗിന്റെ സാന്നിധ്യത്തിൽ പാക്കേജുകളുടെ അസംബ്ലി കർശനമായി നിരീക്ഷിക്കുക.

ആകെ

കോൺഫിഗറേഷൻ എഴുതുന്നതിനും പ്രാദേശിക പവർഷെല്ലിലെ ഡീബഗ്ഗിംഗിനും ഒരുപക്ഷേ, പരാജയപ്പെട്ട രണ്ട് ലോഞ്ചുകൾക്കും ശേഷം, പതിവ് ജോലികൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനുള്ള ഒരു ലളിതമായ കോൺഫിഗറേഷൻ ഞങ്ങൾക്ക് ലഭിച്ചു.

തീർച്ചയായും, ഈ ഗൈഡ് വായിച്ചതിനുശേഷം തോന്നിയേക്കാവുന്നതിനേക്കാൾ വളരെ വിപുലവും ബഹുമുഖവുമാണ് GitLab CI / CD - അത് ഒട്ടും ശരിയല്ല. അവിടെ പോലും Auto DevOps ആണ്അനുവദിക്കുന്നു

നിങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ സ്വയമേവ കണ്ടെത്തുക, നിർമ്മിക്കുക, പരിശോധിക്കുക, വിന്യസിക്കുക, നിരീക്ഷിക്കുക

ഇപ്പോൾ Azure-ലേക്ക് ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്നതിനും Pulumi ഉപയോഗിക്കുന്നതിനും ടാർഗെറ്റ് പരിതസ്ഥിതി സ്വയമേവ നിർണയിക്കുന്നതിനുമായി ഒരു പൈപ്പ്ലൈൻ കോൺഫിഗർ ചെയ്യാനാണ് പദ്ധതിയിടുന്നത്, അത് അടുത്ത ലേഖനത്തിൽ ഉൾപ്പെടുത്തും.

അവലംബം: www.habr.com