(దాదాపు) సంపూర్ణ ప్రారంభకులకు GitLabలో CI/CDకి గైడ్

లేదా ఒక సాయంత్రం సులభమైన కోడింగ్‌లో మీ ప్రాజెక్ట్ కోసం అందమైన బ్యాడ్జ్‌లను ఎలా పొందాలి

బహుశా, కనీసం ఒక పెట్ ప్రాజెక్ట్‌ని కలిగి ఉన్న ప్రతి డెవలపర్‌కు ఏదో ఒక సమయంలో అందమైన బ్యాడ్జ్‌లు, కోడ్ కవరేజ్, న్యూగెట్‌లో ప్యాకేజీ వెర్షన్‌ల గురించి దురద ఉంటుంది ... మరియు ఈ దురద నన్ను ఈ కథనాన్ని వ్రాయడానికి దారితీసింది. దీన్ని వ్రాయడానికి సన్నాహకంగా, నా ప్రాజెక్ట్‌లలో ఒకదానిలో నేను ఈ అందాన్ని పొందాను:

ఈ కథనం GitLabలో .Net కోర్ క్లాస్ లైబ్రరీ ప్రాజెక్ట్ కోసం నిరంతర ఏకీకరణ మరియు డెలివరీ యొక్క ప్రాథమిక సెటప్ ద్వారా మిమ్మల్ని నడిపిస్తుంది, GitLab పేజీలకు డాక్యుమెంటేషన్‌ను ప్రచురించడం మరియు Azure DevOpsలో ప్రైవేట్ ఫీడ్‌కి బిల్ట్ ప్యాకేజీలను నెట్టడం.

పొడిగింపుతో అభివృద్ధి వాతావరణంగా VS కోడ్ ఉపయోగించబడింది GitLab వర్క్‌ఫ్లో (అభివృద్ధి వాతావరణం నుండి నేరుగా సెట్టింగ్‌ల ఫైల్‌ని ధృవీకరించడం కోసం).

సంక్షిప్త పరిచయం

CD - మీరు ఇప్పుడే నెట్టివేసినప్పుడు మరియు ప్రతిదీ ఇప్పటికే క్లయింట్‌పై పడిందా?

CI / CD అంటే ఏమిటి మరియు మీకు ఇది ఎందుకు అవసరం - మీరు దీన్ని సులభంగా గూగుల్ చేయవచ్చు. GitLabలో పైప్‌లైన్‌లను కాన్ఫిగర్ చేయడంపై పూర్తి డాక్యుమెంటేషన్‌ను కనుగొనండి కూడా సులభం. ఇక్కడ నేను క్లుప్తంగా మరియు వీలైతే, లోపాలు లేకుండా పక్షి దృష్టి నుండి సిస్టమ్ యొక్క ప్రక్రియను వివరిస్తాను:

• డెవలపర్ రిపోజిటరీకి నిబద్ధతను పంపుతాడు, సైట్ ద్వారా విలీన అభ్యర్థనను సృష్టిస్తాడు, లేదా వేరే విధంగా, స్పష్టంగా లేదా పరోక్షంగా పైప్‌లైన్‌ను ప్రారంభిస్తుంది,
• అన్ని టాస్క్‌లు కాన్ఫిగరేషన్ నుండి ఎంపిక చేయబడ్డాయి, ఇచ్చిన సందర్భంలో వాటిని ప్రారంభించటానికి అనుమతించే షరతులు,
• పనులు వారి దశల ప్రకారం నిర్వహించబడతాయి,
• దశలు క్రమంగా అమలు చేయబడతాయి - అనగా. సమాంతరంగా ఈ దశలో అన్ని పనులు పూర్తయ్యాయి,
• స్టేజ్ విఫలమైతే (అంటే, స్టేజ్ యొక్క కనీసం ఒక పని విఫలమైతే), పైప్‌లైన్ ఆగిపోతుంది (దాదాపు ఎల్లప్పుడూ),
• అన్ని దశలు విజయవంతంగా పూర్తయితే, పైప్‌లైన్ విజయవంతంగా పరిగణించబడుతుంది.

కాబట్టి, మనకు ఉన్నాయి:

• పైప్‌లైన్ - మీరు నిర్మించడం, పరీక్షించడం, ప్యాకేజీ కోడ్, క్లౌడ్ సేవకు పూర్తి చేసిన బిల్డ్‌ని అమలు చేయడం మొదలైన దశల్లో నిర్వహించబడిన పనుల సమితి.
• వేదిక (రంగస్థల) — పైప్‌లైన్ సంస్థ యూనిట్, 1+ టాస్క్‌ను కలిగి ఉంది,
• పని (ఉద్యోగం) అనేది పైప్‌లైన్‌లో పని యొక్క యూనిట్. ఇది స్క్రిప్ట్ (తప్పనిసరి), లాంచ్ షరతులు, కళాఖండాలను ప్రచురించడం/కాషింగ్ చేయడం కోసం సెట్టింగ్‌లు మరియు మరిన్నింటిని కలిగి ఉంటుంది.

దీని ప్రకారం, CI / CDని సెటప్ చేసేటప్పుడు పని కోడ్ మరియు కళాఖండాలను నిర్మించడానికి, పరీక్షించడానికి మరియు ప్రచురించడానికి అవసరమైన అన్ని చర్యలను అమలు చేసే పనుల సమితిని రూపొందించడానికి వస్తుంది.

ప్రారంభించడానికి ముందు: ఎందుకు?

• గిట్లాబ్ ఎందుకు?

ఎందుకంటే పెంపుడు జంతువుల ప్రాజెక్ట్‌ల కోసం ప్రైవేట్ రిపోజిటరీలను సృష్టించడం అవసరం అయినప్పుడు, అవి GitHubలో చెల్లించబడ్డాయి మరియు నేను అత్యాశతో ఉన్నాను. రిపోజిటరీలు ఉచితం, కానీ ఇప్పటివరకు ఇది నాకు GitHubకి మారడానికి తగినంత కారణం కాదు.

• Azure DevOps పైప్‌లైన్‌లు ఎందుకు కాదు?

అక్కడ సెట్టింగ్ ప్రాథమికంగా ఉన్నందున - కమాండ్ లైన్ యొక్క జ్ఞానం కూడా అవసరం లేదు. బాహ్య git ప్రొవైడర్‌లతో ఏకీకరణ - రెండు క్లిక్‌లలో, రిపోజిటరీకి కమిట్‌లను పంపడానికి 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. డాక్యుమెంటేషన్ కాన్ఫిగరేషన్ యొక్క ఉన్నత స్థాయిలో మరియు ప్రతి సమూహ స్థాయిలలో ఏ కీలను కలిగి ఉండవచ్చో వివరిస్తుంది.

మొదట, కాన్ఫిగరేషన్ ఫైల్‌లోని డాకర్ ఇమేజ్‌కి లింక్‌ను జోడిద్దాం, దీనిలో పనులు నిర్వహించబడతాయి. దీని కోసం మేము కనుగొంటాము డాకర్ హబ్‌లో .నెట్ కోర్ చిత్రాల పేజీ. ది గ్యాలరీలు వివిధ పనుల కోసం ఏ చిత్రాన్ని ఎంచుకోవాలనే దానిపై వివరణాత్మక గైడ్ ఉంది. .Net కోర్ 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కి జోడించబడింది ("ఖాతాలను సిద్ధం చేస్తోంది", p. 11). సహజంగా, ఆకృతిలో $variableName
   5. -StorePasswordInClearText - యాక్సెస్ నిరాకరించబడిన లోపాన్ని దాటవేయడానికి ఒక హ్యాక్ (ఈ రేక్‌పై అడుగుపెట్టిన మొదటి వ్యక్తిని నేను కాదు)
   6. లోపాల విషయంలో, జోడించడం ఉపయోగకరంగా ఉండవచ్చు -verbosity detailed
3. ప్యాకేజీని మూలానికి పంపుతోంది: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
   1. మేము ప్రస్తుత డైరెక్టరీ నుండి అన్ని ప్యాకేజీలను పంపుతాము *.nupkg.
   2. name - పై దశ నుండి.
   3. key - ఏదైనా లైన్. Azure DevOpsలో, Connect to feed విండోలో, ఉదాహరణ ఎల్లప్పుడూ లైన్‌గా ఉంటుంది 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 సెట్టింగ్‌లలో అందుబాటులో ఉన్నాయి:

నేను ప్లాట్‌ఫారమ్‌లోని డాక్యుమెంటేషన్‌కు లింక్‌తో బ్యాడ్జ్‌ని సృష్టించాను 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 ఈ మార్గదర్శిని చదివిన తర్వాత అనిపించే దానికంటే చాలా విస్తృతమైనది మరియు బహుముఖమైనది - అది అస్సలు నిజం కాదు. అక్కడ కూడా ఆటో డెవొప్స్అనుమతిస్తుంది

మీ అప్లికేషన్‌లను స్వయంచాలకంగా గుర్తించడం, నిర్మించడం, పరీక్షించడం, అమలు చేయడం మరియు పర్యవేక్షించడం

ఇప్పుడు అజూర్‌కి అప్లికేషన్‌లను అమర్చడం, Pulumiని ఉపయోగించడం మరియు లక్ష్య వాతావరణాన్ని స్వయంచాలకంగా నిర్ణయించడం కోసం పైప్‌లైన్‌ను కాన్ఫిగర్ చేయడం ప్రణాళికలు, ఇది తదుపరి కథనంలో కవర్ చేయబడుతుంది.

మూలం: www.habr.com