(લગભગ) સંપૂર્ણ શિખાઉ માણસ માટે ગિટલેબમાં CI/CD માટેની માર્ગદર્શિકા

અથવા સરળ કોડિંગની એક સાંજે તમારા પ્રોજેક્ટ માટે સુંદર બેજ કેવી રીતે મેળવવી

સંભવતઃ, દરેક ડેવલપર કે જેમની પાસે કોઈક સમયે ઓછામાં ઓછું એક પાલતુ પ્રોજેક્ટ છે, તે સ્થિતિઓ, કોડ કવરેજ, ન્યુગેટમાં પેકેજ સંસ્કરણો સાથેના સુંદર બેજેસ વિશે ખંજવાળ ધરાવે છે ... અને આ ખંજવાળ મને આ લેખ લખવા તરફ દોરી જાય છે. તેને લખવાની તૈયારીમાં, મને મારા એક પ્રોજેક્ટમાં આ સુંદરતા મળી:

આ લેખ તમને ગિટલેબમાં .નેટ કોર ક્લાસ લાઇબ્રેરી પ્રોજેક્ટ માટે સતત એકીકરણ અને ડિલિવરીના મૂળભૂત સેટઅપ, ગિટલેબ પૃષ્ઠો પર દસ્તાવેજીકરણ પ્રકાશિત કરવા અને Azure DevOps માં ખાનગી ફીડમાં બિલ્ટ પેકેજોને દબાણ કરવા વિશે માર્ગદર્શન આપશે.

VS કોડનો ઉપયોગ એક્સ્ટેંશન સાથે વિકાસ વાતાવરણ તરીકે કરવામાં આવ્યો હતો GitLab વર્કફ્લો (ડેવલપમેન્ટ એન્વાયર્નમેન્ટમાંથી સીધા સેટિંગ્સ ફાઇલને માન્ય કરવા માટે).

સંક્ષિપ્ત પરિચય

સીડી - શું તે છે જ્યારે તમે હમણાં જ દબાણ કર્યું, અને બધું પહેલેથી જ ક્લાયંટ પર આવી ગયું છે?

CI/CD શું છે અને તમને તેની શા માટે જરૂર છે - તમે તેને સરળતાથી ગૂગલ કરી શકો છો. GitLab માં પાઈપલાઈન ગોઠવવા પર સંપૂર્ણ દસ્તાવેજો શોધો પણ સરળ. અહીં હું સંક્ષિપ્તમાં અને, જો શક્ય હોય તો, પક્ષીઓની આંખના દૃષ્ટિકોણથી સિસ્ટમની પ્રક્રિયાને ભૂલો વિના વર્ણવીશ:

• ડેવલપર રીપોઝીટરીને કમિટ મોકલે છે, સાઇટ દ્વારા મર્જ વિનંતી બનાવે છે, અથવા અન્ય કોઈ રીતે, સ્પષ્ટ અથવા ગર્ભિત રીતે પાઇપલાઇન શરૂ કરે છે,
• બધા કાર્યો રૂપરેખાંકનમાંથી પસંદ કરવામાં આવે છે, જેની શરતો તેમને આપેલ સંદર્ભમાં શરૂ કરવાની મંજૂરી આપે છે,
• કાર્યો તેમના તબક્કાઓ અનુસાર ગોઠવવામાં આવે છે,
• તબક્કાઓ બદલામાં ચલાવવામાં આવે છે - એટલે કે સમાંતર આ તબક્કાના તમામ કાર્યો પૂર્ણ થયા છે,
• જો સ્ટેજ નિષ્ફળ જાય (એટલે ​​​​કે, સ્ટેજનું ઓછામાં ઓછું એક કાર્ય નિષ્ફળ જાય), તો પાઇપલાઇન અટકી જાય છે (મોટે ભાગે હંમેશા),
• જો તમામ તબક્કાઓ સફળતાપૂર્વક પૂર્ણ થાય, તો પાઇપલાઇન સફળ ગણવામાં આવે છે.

આમ, અમારી પાસે છે:

• પાઇપલાઇન - તબક્કામાં ગોઠવાયેલા કાર્યોનો સમૂહ જેમાં તમે બિલ્ડ કરી શકો છો, પરીક્ષણ કરી શકો છો, પેકેજ કોડ બનાવી શકો છો, ક્લાઉડ સેવામાં સમાપ્ત બિલ્ડનો ઉપયોગ કરી શકો છો, વગેરે.
• સ્ટેજ (મંચ) — પાઇપલાઇન સંસ્થા એકમ, 1+ કાર્ય સમાવે છે,
• કાર્ય (કામ) એ પાઇપલાઇનમાં કામનું એક એકમ છે. તેમાં સ્ક્રિપ્ટ (ફરજિયાત), લોંચની શરતો, કલાકૃતિઓ પ્રકાશિત/કેશ કરવા માટેની સેટિંગ્સ અને ઘણું બધું હોય છે.

તદનુસાર, CI / CD સેટ કરતી વખતે કાર્ય એ કાર્યોનો સમૂહ બનાવવા માટે નીચે આવે છે જે કોડ અને આર્ટિફેક્ટ્સના નિર્માણ, પરીક્ષણ અને પ્રકાશન માટે તમામ જરૂરી ક્રિયાઓને અમલમાં મૂકે છે.

શરૂ કરતા પહેલા: શા માટે?

• Gitlab શા માટે?

કારણ કે જ્યારે પાલતુ પ્રોજેક્ટ્સ માટે ખાનગી ભંડાર બનાવવું જરૂરી બન્યું, ત્યારે તેમને GitHub પર ચૂકવણી કરવામાં આવી હતી, અને હું લોભી હતો. રીપોઝીટરીઝ મફત બની ગઈ છે, પરંતુ અત્યાર સુધી મારા માટે ગિટહબ પર જવા માટે આ પૂરતું કારણ નથી.

• Azure DevOps પાઇપલાઇન્સ શા માટે નથી?

કારણ કે ત્યાં સેટિંગ પ્રાથમિક છે - આદેશ વાક્યનું જ્ઞાન પણ જરૂરી નથી. બાહ્ય ગિટ પ્રદાતાઓ સાથે એકીકરણ - થોડા ક્લિક્સમાં, રીપોઝીટરીમાં કમિટ મોકલવા માટે SSH કીની આયાત - પણ, પાઇપલાઇનને ટેમ્પલેટમાંથી નહીં પણ સરળતાથી ગોઠવવામાં આવે છે.

પ્રારંભિક સ્થિતિ: તમારી પાસે શું છે અને તમને શું જોઈએ છે

અમારી પાસે:

• GitLab માં રીપોઝીટરી.

અમે ઈચ્છીએ છીએ:

• દરેક મર્જ વિનંતી માટે સ્વચાલિત એસેમ્બલી અને પરીક્ષણ,
• દરેક મર્જ વિનંતી માટે પેકેજો બનાવવું અને માસ્ટર પર દબાણ કરવું, જો કે કમિટ મેસેજમાં ચોક્કસ લાઇન હોય,
• Azure DevOps માં ખાનગી ફીડ પર બિલ્ટ પેકેજો મોકલવા,
• GitLab પૃષ્ઠોમાં દસ્તાવેજીકરણ અને પ્રકાશનની એસેમ્બલી,
• બેજ!11

વર્ણવેલ આવશ્યકતાઓ સજીવ રીતે નીચેના પાઇપલાઇન મોડેલ પર આવે છે:

• સ્ટેજ 1 - એસેમ્બલી
  • અમે કોડ એકત્રિત કરીએ છીએ, આઉટપુટ ફાઇલોને આર્ટિફેક્ટ તરીકે પ્રકાશિત કરીએ છીએ
• સ્ટેજ 2 - પરીક્ષણ
  • અમે બિલ્ડ સ્ટેજ પરથી કલાકૃતિઓ મેળવીએ છીએ, પરીક્ષણો ચલાવીએ છીએ, કોડ કવરેજ ડેટા એકત્રિત કરીએ છીએ
• સ્ટેજ 3 - સબમિટ કરો
  • કાર્ય 1 - ન્યુગેટ પેકેજ બનાવો અને તેને Azure DevOps પર મોકલો
  • કાર્ય 2 - અમે સ્રોત કોડમાં xmldoc માંથી સાઇટ એકત્રિત કરીએ છીએ અને તેને GitLab પૃષ્ઠોમાં પ્રકાશિત કરીએ છીએ

ચાલો, શરુ કરીએ!

રૂપરેખાંકન એકત્રિત કરી રહ્યા છીએ

એકાઉન્ટ્સ તૈયાર કરી રહ્યા છીએ

1. માં એક એકાઉન્ટ બનાવો માઈક્રોસોફ્ટ ઍઝ્યોર

2. પર જાઓ એઝુર ડેવઓપ્સ

3. અમે એક નવો પ્રોજેક્ટ બનાવીએ છીએ

   1. નામ - કોઈપણ
   2. દૃશ્યતા - કોઈપણ
      

4. જ્યારે તમે બનાવો બટન પર ક્લિક કરો છો, ત્યારે પ્રોજેક્ટ બનાવવામાં આવશે અને તમને તેના પૃષ્ઠ પર રીડાયરેક્ટ કરવામાં આવશે. આ પૃષ્ઠ પર, તમે પ્રોજેક્ટ સેટિંગ્સ પર જઈને બિનજરૂરી સુવિધાઓને અક્ષમ કરી શકો છો (ડાબી બાજુની સૂચિમાં નીચેની લિંક -> વિહંગાવલોકન -> Azure DevOps સેવાઓ બ્લોક)
   

5. એટ્રિફેક્ટ્સ પર જાઓ, ફીડ બનાવો પર ક્લિક કરો

   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. દસ્તાવેજીકરણ વિગતો આપે છે કે રૂપરેખાંકનના ટોચના સ્તરે અને દરેક નેસ્ટેડ સ્તરો પર કઈ કી સમાવી શકાય છે.

પ્રથમ, ચાલો રૂપરેખાંકન ફાઈલમાં ડોકર ઈમેજની લિંક ઉમેરીએ, જેમાં કાર્યો કરવામાં આવશે. આ માટે આપણે શોધીએ છીએ ડોકર હબ પર .નેટ કોર છબીઓનું પૃષ્ઠ. આ 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

સ્વાભાવિક રીતે, ત્યાં કેટલીક ઘોંઘાટ છે જેના કારણે અમે આદેશોને કંઈક અંશે જટિલ બનાવીશું.

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 - ગિટલેબમાં ઉમેરવામાં આવેલ એક્સેસ ટોકન સાથેના ચલનું નામ ("એકાઉન્ટ્સની તૈયારી", પૃષ્ઠ 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 (ગીટલેબ પેજીસમાં સાઇટના પ્રકાશન કાર્યો માટે આરક્ષિત શબ્દ):
   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

બેજ વિશે બોલતા

તેમના કારણે, છેવટે, બધું શરૂ થયું!

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 છેપરવાનગી આપે છે

તમારી એપ્લિકેશનોને આપમેળે શોધો, બિલ્ડ કરો, પરીક્ષણ કરો, જમાવડો અને મોનિટર કરો

હવે યોજનાઓ એઝ્યુર પર એપ્લિકેશનો જમાવવા માટે, પુલુમીનો ઉપયોગ કરીને અને લક્ષ્ય વાતાવરણને આપમેળે નક્કી કરવા માટે પાઇપલાઇન ગોઠવવાની છે, જે આગામી લેખમાં આવરી લેવામાં આવશે.

સોર્સ: www.habr.com