လုံးဝအစပြုသူ (နီးပါး) အတွက် GitLab ရှိ CI/CD လမ်းညွှန်

သို့မဟုတ် လွယ်ကူသော coding ဖြင့် တစ်ညနေခင်းတွင် သင့်ပရောဂျက်အတွက် လှပသောတံဆိပ်များ မည်သို့ရနိုင်မည်နည်း။

ဖြစ်နိုင်သည်မှာ၊ တစ်ချိန်ချိန်တွင် အနည်းဆုံး အိမ်မွေးတိရစ္ဆာန်ပရောဂျက်တစ်ခုရှိသည့် developer တိုင်းသည် အခြေအနေများ၊ ကုဒ်အကျုံးဝင်မှု၊ nuget ရှိ ပက်ကေ့ဂျ်ဗားရှင်းများပါသည့် လှပသောတံဆိပ်များအကြောင်း ဗောက်ဖြစ်တတ်သည်... ပြီးတော့ ဒီဗောက်က ကျွန်မကို ဒီဆောင်းပါးကို ရေးဖြစ်ခဲ့ပါတယ်။ စာရေးဖို့ပြင်ဆင်ရာမှာ ကျွန်တော့်ရဲ့ ပရောဂျက်တစ်ခုထဲမှာ ဒီအလှကို ရခဲ့တယ်

ဤဆောင်းပါးသည် GitLab ရှိ .Net Core အတန်းအစားစာကြည့်တိုက်ပရောဂျက်အတွက် စဉ်ဆက်မပြတ်ပေါင်းစပ်ခြင်းနှင့် ပေးပို့ခြင်းဆိုင်ရာ အခြေခံစနစ်ထည့်သွင်းခြင်း၊ စာရွက်စာတမ်းများကို GitLab စာမျက်နှာများဆီသို့ ထုတ်ဝေခြင်းနှင့် Azure DevOps ရှိ သီးသန့်ဖိဒ်တစ်ခုသို့ တည်ဆောက်ထားသော ပက်ကေ့ဂျ်များကို တွန်းပို့ပေးပါမည်။

VS Code ကို တိုးချဲ့မှုနှင့်အတူ ဖွံ့ဖြိုးတိုးတက်မှုပတ်ဝန်းကျင်အဖြစ် အသုံးပြုခဲ့သည်။ GitLab အလုပ်အသွားအလာ (ဖွံ့ဖြိုးတိုးတက်မှုပတ်ဝန်းကျင်မှ တိုက်ရိုက်ဆက်တင်ဖိုင်ကို တရားဝင်စစ်ဆေးရန်အတွက်)။

အကျဉ်းမိတ်ဆက်

CD - တွန်းလိုက်တာနဲ့ အရာအားလုံးက client ပေါ်ကျသွားပြီလား။

CI/CD ဆိုတာ ဘာလဲ ၊ ဘာကြောင့် လိုအပ်တာလဲ ၊ အဲဒါကို အလွယ်တကူ google မှာ လုပ်နိုင်ပါတယ်။ GitLab ရှိ ပိုက်လိုင်းများ ပြင်ဆင်ခြင်းဆိုင်ရာ စာရွက်စာတမ်းအပြည့်အစုံကို ရှာပါ။ လွယ်ပါတယ်။. ဤနေရာတွင် ကျွန်ုပ်သည် အတိုချုံးပြီး ဖြစ်နိုင်ပါက၊ ချို့ယွင်းချက်မရှိဘဲ ငှက်မျက်လုံးဖြင့် စနစ်၏ လုပ်ငန်းစဉ်ကို ဖော်ပြပါမည်။

• developer သည် repository သို့ commit တစ်ခု ပေးပို့ပြီး၊ site မှတဆင့် ပေါင်းစည်းရန် တောင်းဆိုမှုကို ဖန်တီးသည်၊ သို့မဟုတ် တစ်နည်းတစ်ဖုံ ပြတ်သားစွာ သို့မဟုတ် သွယ်ဝိုက်သောနည်းဖြင့် ပိုက်လိုင်းကို စတင်သည်။,
• လုပ်ငန်းဆောင်တာအားလုံးကို ဖွဲ့စည်းမှုစနစ်မှ ရွေးချယ်ထားပြီး၊ ၎င်းတို့အား ပေးထားသည့် အခြေအနေတွင် စတင်လုပ်ဆောင်ခွင့်ပြုသည့် အခြေအနေများ၊
• လုပ်ငန်းများကို အဆင့်ဆင့်အလိုက် စီစဉ်ဆောင်ရွက်ပေးခြင်း၊
• အဆင့်များကို အလှည့်ကျလုပ်ဆောင်သည် - i.e. အပြိုင် ဒီအဆင့်ရဲ့ လုပ်ငန်းဆောင်တာအားလုံး ပြီးမြောက်ပြီ၊
• အဆင့်မအောင်မြင်ပါက (ဆိုလိုသည်မှာ အဆင့်၏အလုပ်များထဲမှ အနည်းဆုံးတစ်ခု ကျရှုံးပါက) ပိုက်လိုင်းသည် ရပ်သွားသည် (အမြဲတမ်းနီးပါး),
• အဆင့်အားလုံးကို အောင်မြင်စွာ ပြီးစီးပါက ပိုက်လိုင်း အောင်မြင်သည်ဟု ယူဆပါသည်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့တွင်-

• ပိုက်လိုင်း - သင်တည်ဆောက်နိုင်သည်၊ စမ်းသပ်နိုင်သည်၊ ပက်ကေ့ချ်ကုဒ်၊ အချောသတ်တည်ဆောက်မှုကို cloud ဝန်ဆောင်မှုသို့ အသုံးချနိုင်သည် စသည်ဖြင့် အဆင့်များအလိုက် ဖွဲ့စည်းထားသော အလုပ်အစုံ၊
• အဆင့် (စင်) — ပိုက်လိုင်းအဖွဲ့အစည်းယူနစ်၊ အလုပ် 1+ ပါရှိသည်၊
• တာဝန် (အလုပ်) သည် ပိုက်လိုင်းတွင် အလုပ်လုပ်သော ယူနစ်တစ်ခုဖြစ်သည်။ ၎င်းတွင် ဇာတ်ညွှန်းတစ်ခု (မဖြစ်မနေ)၊ စတင်ခြင်းအခြေအနေများ၊ ထုတ်ဝေခြင်း/သိမ်းဆည်းခြင်းအတွက် ဆက်တင်များနှင့် အခြားအရာများစွာ ပါဝင်ပါသည်။

ထို့ကြောင့်၊ CI/CD ကိုစဖွင့်သောအခါတွင် လုပ်ဆောင်ရမည့်တာဝန်သည် တည်ဆောက်ခြင်း၊ စမ်းသပ်ခြင်းနှင့် ကုဒ်နှင့် ရှေးဟောင်းပစ္စည်းများ တည်ဆောက်ခြင်းအတွက် လိုအပ်သော လုပ်ဆောင်ချက်များအားလုံးကို အကောင်အထည်ဖော်သည့် အလုပ်အစုံကို ဖန်တီးရန်ဖြစ်သည်။

မစတင်မီ- ဘာကြောင့်လဲ။

• ဘာကြောင့် Gitlab

အိမ်မွေးတိရစ္ဆာန်ပရောဂျက်များအတွက် သီးသန့်သိုလှောင်မှုများကို ဖန်တီးရန် လိုအပ်လာသောအခါတွင် ၎င်းတို့ကို GitHub တွင် ပေးချေခဲ့ပြီး ကျွန်ုပ်သည် လောဘကြီးခဲ့သည်။ သိုလှောင်မှုများသည် အခမဲ့ဖြစ်လာသော်လည်း ယခုအချိန်အထိ GitHub သို့ပြောင်းရွှေ့ရန် ကျွန်ုပ်အတွက် လုံလောက်သောအကြောင်းပြချက်မဟုတ်သေးပါ။

• Azure DevOps Pipelines များကို အဘယ်ကြောင့် မလုပ်ဆောင်ရသနည်း။

ထိုနေရာတွင် ဆက်တင်သည် အခြေခံဖြစ်သောကြောင့် - command line ကို သိရန်ပင်မလိုအပ်ပါ။ ပြင်ပ git ဝန်ဆောင်မှုပေးသူများနှင့် ပေါင်းစည်းခြင်း - ကလစ်အနည်းငယ်အတွင်း၊ repository သို့ commits များပေးပို့ရန် SSH သော့များတင်သွင်းခြင်း - ပိုက်လိုင်းကို ပုံစံပလိတ်တစ်ခုမှမဟုတ်သော်လည်း အလွယ်တကူ စီစဉ်သတ်မှတ်ထားပါသည်။

စတင်သည့်နေရာ- မင်းမှာ ဘာနဲ့ လိုချင်တာလဲ။

ကြှနျုပျတို့မှာ ... ရှိသညျ:

• GitLab ရှိ သိုလှောင်မှု။

ကျွန်ုပ်တို့ လိုချင်သည်-

• ပေါင်းစည်းတောင်းဆိုမှုတစ်ခုစီအတွက် အလိုအလျောက် တပ်ဆင်ခြင်းနှင့် စမ်းသပ်ခြင်း၊
• ပေါင်းစည်းရန် တောင်းဆိုချက်တစ်ခုစီအတွက် တည်ဆောက်မှု ပက်ကေ့ဂျ်များ နှင့် ကွန်မန့်မက်ဆေ့ဂျ်တွင် မျဉ်းအချို့ပါရှိသဖြင့် မာစတာထံ တွန်းပို့ခြင်း၊
• Azure DevOps ရှိ သီးသန့် feed တစ်ခုသို့ တည်ဆောက်ထားသော packages များကို ပေးပို့ခြင်း၊
• GitLab စာမျက်နှာများတွင် စာတမ်းပြုစုခြင်းနှင့် ထုတ်ဝေခြင်း စုဝေးခြင်း၊
• တံဆိပ်များ ၁၁

ဖော်ပြထားသော လိုအပ်ချက်များသည် အောက်ဖော်ပြပါ ပိုက်လိုင်းပုံစံပေါ်တွင် သဘာဝအလျောက် အကျုံးဝင်သည်-

• အဆင့် 1 - စည်းဝေးပွဲ
  • ကျွန်ုပ်တို့သည် ကုဒ်ကိုစုဆောင်းကာ အထွက်ဖိုင်များကို ရှေးဟောင်းပစ္စည်းအဖြစ် ထုတ်ဝေသည်။
• အဆင့် 2 - စမ်းသပ်ခြင်း။
  • ကျွန်ုပ်တို့သည် တည်ဆောက်မှုအဆင့်မှ ရှေးဟောင်းပစ္စည်းများကို ရယူပြီး၊ စမ်းသပ်မှုများ လုပ်ဆောင်ရန်၊ ကုဒ်လွှမ်းခြုံမှုဒေတာကို စုဆောင်းပါ။
• အဆင့် 3 - တင်ပြပါ။
  • Task 1 - nuget package ကိုတည်ဆောက်ပြီး Azure DevOps သို့ပေးပို့ပါ။
  • Task 2 - ကျွန်ုပ်တို့သည် အရင်းအမြစ်ကုဒ်တွင် xmldoc မှ ဆိုက်ကို စုဆောင်းပြီး GitLab စာမျက်နှာများတွင် ထုတ်ဝေသည်

စလိုက်ကြစို့!

ဖွဲ့စည်းမှုပုံစံကိုစုဆောင်းခြင်း။

အကောင့်များပြင်ဆင်ခြင်း။

1. အကောင့်တစ်ခုဖန်တီးပါ။ မိုက်ကရိုဆော့ဖ Azure

2. သွားပါ။ Azure DevOps

3. ကျွန်ုပ်တို့သည် ပရောဂျက်အသစ်တစ်ခုကို ဖန်တီးသည်။

   1. အမည် - တစ်ခုခု
   2. မြင်နိုင်စွမ်း - တစ်ခုခု
      

4. Create ခလုတ်ကို နှိပ်လိုက်သောအခါ၊ ပရောဂျက်ကို ဖန်တီးပြီး ၎င်း၏ စာမျက်နှာသို့ ပြန်ညွှန်းသွားမည်ဖြစ်သည်။ ဤစာမျက်နှာတွင်၊ ပရောဂျက်ဆက်တင်များသို့သွားခြင်းဖြင့် မလိုအပ်သောအင်္ဂါရပ်များကို သင်ပိတ်နိုင်သည် (ဘယ်ဘက်ရှိစာရင်းအောက်ရှိလင့်ခ် -> ခြုံငုံသုံးသပ်ချက် -> Azure DevOps ဝန်ဆောင်မှုများပိတ်ဆို့ခြင်း)
   

5. Attrifacts သို့သွားပါ၊ Create feed ကိုနှိပ်ပါ။

   1. အရင်းအမြစ်၏အမည်ကိုထည့်ပါ။
   2. မြင်နိုင်စွမ်းကို ရွေးပါ။
   3. အမှန်ခြစ်ဖြုတ်ပါ။ အများသူငှာ အရင်းအမြစ်များမှ ပက်ကေ့ဂျ်များကို ထည့်သွင်းပါ။သို့မှသာ အရင်းအမြစ်သည် အမှိုက်ပုံကြီးအဖြစ်သို့ ပြောင်းလဲမသွားစေရန်
      

6. ချိတ်ဆက်ရန် နှိပ်ပါ၊ Visual Studio ကိုရွေးချယ်ပါ၊ အရင်းအမြစ်ကို စက်တပ်ဆင်မှုပိတ်ဆို့ခြင်းမှ ကူးယူပါ။
   

7. အကောင့်ဆက်တင်များသို့သွားပါ၊ Personal Access Token ကိုရွေးချယ်ပါ။
   

8. ဝင်ရောက်ခွင့် တိုကင်အသစ်တစ်ခု ဖန်တီးပါ။

   1. အမည် - မင်းထက်
   2. အဖွဲ့အစည်း - လက်ရှိ
   3. အများဆုံး ၁ နှစ်အထိ သက်တမ်းရှိသည်။
   4. နယ်ပယ် - ထုပ်ပိုးခြင်း/စာဖတ်ခြင်းနှင့်ရေးခြင်း
      

9. ဖန်တီးထားသော တိုကင်ကို ကူးယူပါ - modal window ကိုပိတ်ပြီးနောက်၊ တန်ဖိုးသည် မရနိုင်ပါ။

10. GitLab ရှိ repository ဆက်တင်များသို့သွား၍ CI/CD ဆက်တင်များကို ရွေးချယ်ပါ။
    

11. Variables ဘလောက်ကိုချဲ့ပြီး အသစ်တစ်ခုထည့်ပါ။

    1. အမည် - နေရာလွတ်မရှိသောမည်သည့်အရာကိုမဆို (command shell တွင်ရနိုင်ပါမည်)
    2. တန်ဖိုး - စာပိုဒ် ၉ မှ ဝင်ရောက်ခွင့် တိုကင်
    3. Mask variable ကို ရွေးပါ။
       

၎င်းသည် ကြိုတင်ဖွဲ့စည်းမှုအား ပြီးမြောက်စေသည်။

ဖွဲ့စည်းမှုဘောင်ကို ပြင်ဆင်ခြင်း။

မူရင်းအားဖြင့်၊ GitLab ရှိ CI/CD ဖွဲ့စည်းမှုပုံစံသည် ဖိုင်ကို အသုံးပြုသည်။ .gitlab-ci.yml repository ၏အမြစ်မှ။ repository ဆက်တင်များတွင် ဤဖိုင်သို့ မတရားလမ်းကြောင်းတစ်ခု သတ်မှတ်နိုင်သော်လည်း ဤကိစ္စတွင် ၎င်းကို မလိုအပ်ပါ။

တိုးချဲ့မှုမှ သင်တွေ့မြင်ရသည့်အတိုင်း၊ ဖိုင်တွင် ဖော်မတ်ပုံစံ ဖွဲ့စည်းမှုတစ်ခုပါရှိသည်။ YAML. ဖွဲ့စည်းမှုဖွဲ့စည်းမှု၏ ထိပ်တန်းအဆင့်တွင် မည်သည့်သော့များပါ၀င်နိုင်သည်ကို စာရွက်စာတမ်းအသေးစိတ်အချက်အလက်များနှင့် nested အဆင့်တစ်ခုစီတွင် ဖော်ပြထားသည်။

ပထမဦးစွာ၊ လုပ်ဆောင်စရာများကိုလုပ်ဆောင်မည့် configuration file ရှိ docker image သို့ လင့်ခ်တစ်ခုထည့်ကြပါစို့။ ဒီအတွက် ကျွန်တော်ရှာတယ်။ Docker Hub ရှိ .Net Core ပုံများ စာမျက်နှာ။ အဆိုပါ GitHub မတူညီသောလုပ်ငန်းဆောင်တာများအတွက် မည်သည့်ရုပ်ပုံကို ရွေးချယ်ရန် အသေးစိတ်လမ်းညွှန်ချက်ပါရှိပါသည်။ .Net Core 3.1 ပါသော ရုပ်ပုံသည် ကျွန်ုပ်တို့ တည်ဆောက်ရန် သင့်လျော်သောကြောင့် ဖွဲ့စည်းမှုတွင် ပထမစာကြောင်းကို အားမနာဘဲ ထည့်ပါ

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

ယခု၊ ပိုက်လိုင်းကို Microsoft image repository မှ စတင်လိုက်သောအခါ၊ သတ်မှတ်ပုံအား ဒေါင်းလုဒ်လုပ်မည်ဖြစ်ပြီး၊ ဖွဲ့စည်းမှုပုံစံမှ လုပ်ဆောင်စရာများအားလုံးကို လုပ်ဆောင်မည်ဖြစ်သည်။

နောက်တစ်ဆင့်ကတော့ ထပ်ထည့်ဖို့ပါပဲ။ စင်၎။ ပုံမှန်အားဖြင့်၊ GitLab သည် အဆင့် ၅ ဆင့် သတ်မှတ်သည်-

• .pre - အဆင့်တိုင်းအထိ ဖျော်ဖြေ၊
• .post - အားလုံးပြီးရင် ဖျော်ဖြေ၊
• build - ပြီးမှ ပထမ .pre ဇာတ်ခုံ၊
• test - ဒုတိယအဆင့်၊
• deploy - တတိယအဆင့်။

သို့သော် ၎င်းတို့ကို အတိအလင်းကြေညာခြင်းမှ သင့်အား မည်သည့်အရာကမှ တားဆီးထားခြင်းမရှိပါ။ အဆင့်များကိုဖော်ပြထားသည့်အစီအစဥ်သည် ၎င်းတို့လုပ်ဆောင်သည့်အစီအစဥ်အပေါ်သက်ရောက်သည်။ ပြီးပြည့်စုံမှုအတွက်၊ ဖွဲ့စည်းမှုသို့ ထည့်ကြပါစို့။

stages:
  - build
  - test
  - deploy

အမှားရှာပြင်ခြင်းအတွက်၊ အလုပ်များလုပ်ဆောင်သည့်ပတ်ဝန်းကျင်နှင့်ပတ်သက်သော အချက်အလက်များကို ရယူခြင်းသည် အဓိပ္ပာယ်ရှိစေသည်။ အလုပ်တစ်ခုစီမတိုင်ခင် လုပ်ဆောင်ရမယ့် ကမ္ဘာလုံးဆိုင်ရာ command အစုံကို ထည့်ကြည့်ရအောင် before_script:

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

ကတိကဝတ်များ ပေးပို့သည့်အခါ၊ ပိုက်လိုင်း စတင်နိုင်စေရန် အနည်းဆုံး လုပ်ဆောင်စရာတစ်ခု ထပ်ထည့်ရန် ကျန်ရှိနေပါသည်။ ယခုတွင်၊ သရုပ်ပြရန် အလွတ်အလုပ်တစ်ခုကို ထည့်ကြပါစို့။

dummy job:
  script:
    - echo ok

ကျွန်ုပ်တို့သည် တရားဝင်မှုကိုစတင်သည်၊ ကျွန်ုပ်တို့သည် အရာအားလုံးအဆင်ပြေသည်၊ ကျွန်ုပ်တို့ကတိပြုသည်၊ ကျွန်ုပ်တို့သည် တွန်းအားပေးသည်၊ ကျွန်ုပ်တို့သည် ဆိုက်ပေါ်ရှိရလဒ်များကိုကြည့်ရှုသည် ... ပြီးတော့ script error ကိုရပါသည် - bash: .PSVersion: command not found. wtf?

အရာအားလုံးသည် ယုတ္တိရှိပါသည် - မူရင်းအားဖြင့်၊ အပြေးသမားများ (အလုပ်စခရစ်များကို လုပ်ဆောင်ရန်နှင့် GitLab မှ ပံ့ပိုးပေးသည့် တာဝန်) ကို အသုံးပြုသည် bash အမိန့်များကိုလုပ်ဆောင်ရန်။ လုပ်ဆောင်နေသော ပိုက်လိုင်းအပြေးသမားတွင် မည်သည့် tags များ ပါရှိသင့်သည်ကို လုပ်ဆောင်စရာ ဖော်ပြချက်တွင် ပြတ်သားစွာ သတ်မှတ်ခြင်းဖြင့် ၎င်းကို သင်ဖြေရှင်းနိုင်သည်-

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

ကျွန်ုပ်တို့တွင် အထူးလုပ်ဆောင်မှု မရှိသော်လည်း မှန်ကန်သော ပိုက်လိုင်းတစ်ခု ရရှိခဲ့ပါသည်။

အစပျိုးမှုများကို စနစ်ထည့်သွင်းခြင်း။

လုပ်ဆောင်စရာတစ်ခုခုအတွက် အစပျိုးစစ်ထုတ်ခြင်းများကို မသတ်မှတ်ထားသောကြောင့်၊ ပိုက်လိုင်းသည် လုပ်ဆောင်မည်ဖြစ်သည်။ အပြည့်အဝ ကတိကဝတ်တစ်ခုကို သိုလှောင်ခန်းသို့ တွန်းပို့လိုက်တိုင်း ကတိကဝတ်ပြုသည်။ ၎င်းသည် ယေဘုယျအားဖြင့် အလိုရှိသော အပြုအမူမဟုတ်သောကြောင့်၊ လုပ်ဆောင်စရာများအတွက် အစပျိုးစစ်ထုတ်မှုများကို ကျွန်ုပ်တို့ သတ်မှတ်ပါမည်။

Filters များကို ဖော်မတ်နှစ်မျိုးဖြင့် ပြင်ဆင်သတ်မှတ်နိုင်သည်- သာလျှင် / မှလွဲ и စည်းမျဉ်းစည်းကမ်းတွေကို. တိုတိုတုတ်တုတ်၊ only/except Triggers များဖြင့် filter များကို configure လုပ်ခွင့်ပေးသည် (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.

Artifact Saving ကို စီစဉ်သတ်မှတ်ခြင်း။

အလုပ်တစ်ခုအတွင်း build job နောက်ဆက်တွဲလုပ်ဆောင်စရာများတွင် ပြန်လည်အသုံးပြုနိုင်သည့် တည်ဆောက်မှုလက်ရာများ ကျွန်ုပ်တို့တွင် ရှိပါမည်။ ၎င်းကိုလုပ်ဆောင်ရန်၊ သင်လုပ်ဆောင်ရမည့်ဖွဲ့စည်းပုံစနစ်တွင် လမ်းကြောင်းများကို ပေါင်းထည့်ရန် လိုအပ်ပြီး အောက်ပါလုပ်ဆောင်စရာများတွင် သင်သိမ်းဆည်းရန်နှင့် ပြန်လည်အသုံးပြုရန် လိုအပ်မည့် ဖိုင်များကို သော့သို့၊ artifacts:

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

လမ်းကြောင်းများသည် ခရင်မ်ကတ်များကို ပံ့ပိုးပေးသောကြောင့် ၎င်းတို့ကို သတ်မှတ်ရန် ပိုမိုလွယ်ကူစေသည် ။

အလုပ်တစ်ခုသည် artifacts များကိုဖန်တီးပါက၊ နောက်ဆက်တွဲလုပ်ဆောင်စရာတစ်ခုစီသည် ၎င်းတို့ကိုဝင်ရောက်နိုင်လိမ့်မည် - ၎င်းတို့သည် မူလလုပ်ငန်းမှစုဆောင်းထားသော repository root နှင့်ဆက်စပ်သော တူညီသောလမ်းကြောင်းများတစ်လျှောက်တွင်တည်ရှိနေမည်ဖြစ်ပါသည်။ Artifacts များကိုလည်း site ပေါ်တွင် ဒေါင်းလုဒ်လုပ်နိုင်ပါသည်။

ယခု ကျွန်ုပ်တို့တွင် ပြင်ဆင်သတ်မှတ်မှုဘောင်တစ်ခု အဆင်သင့်ဖြစ်နေပြီ (စမ်းသပ်ပြီးသည်)၊ အလုပ်များအတွက် scripts များကို အမှန်တကယ် ဆက်လက်ရေးသားနိုင်ပါမည်။

ဇာတ်ညွှန်းတွေရေးတယ်။

တစ်ချိန်က၊ အဝေးကြီး၊ ဝေးကွာသော နဂါးငွေ့တန်းတစ်ခုတွင်၊ အမိန့်ပေးစာကြောင်းမှ (.net ပေါ်ရှိအရာများအပါအဝင်) တည်ဆောက်ရေးပရောဂျက်များသည် နာကျင်စရာဖြစ်ကောင်းဖြစ်နိုင်သည်။ ယခု သင်သည် ပရောဂျက်ကို အဖွဲ့ 3 ဖွဲ့ဖြင့် တည်ဆောက်၊ စမ်းသပ်ပြီး ထုတ်ဝေနိုင်ပါပြီ-

dotnet build
dotnet test
dotnet pack

ပုံမှန်အားဖြင့်၊ ကျွန်ုပ်တို့သည် command များကို အနည်းငယ်ရှုပ်ထွေးစေသောကြောင့် အချို့သော nuances များရှိပါသည်။

1. ကျွန်ုပ်တို့သည် အမှားအယွင်းတည်ဆောက်မှုမဟုတ်ဘဲ ထုတ်ဝေမှုတည်ဆောက်မှုကို လိုချင်သောကြောင့် ကျွန်ုပ်တို့သည် အမိန့်တစ်ခုစီသို့ ပေါင်းထည့်သည်။ -c Release
2. စမ်းသပ်သောအခါတွင်၊ ကျွန်ုပ်တို့သည် ကုဒ်လွှမ်းခြုံမှုဒေတာကို စုဆောင်းလိုသောကြောင့်၊ ကျွန်ုပ်တို့သည် စမ်းသပ်စာကြည့်တိုက်များတွင် လွှမ်းခြုံမှုခွဲခြမ်းစိတ်ဖြာမှုတစ်ခု ထည့်သွင်းရန် လိုအပ်သည်-
   1. ပက်ကေ့ဂျ်ကို စမ်းသပ်စာကြည့်တိုက်များအားလုံးတွင် ထည့်ပါ။ coverlet.msbuild: dotnet add package coverlet.msbuild ပရောဂျက်ဖိုင်တွဲမှ
   2. test run command တွင်ထည့်ပါ။ /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 configuration file မရှိပါက (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) သို့ပေါင်းထည့်ထားသောဝင်ရောက်ခွင့်တိုကင်ပါသော variable ၏အမည်။ ထုံးစံအတိုင်း ပုံစံနဲ့ $variableName
   5. -StorePasswordInClearText - access denied error ကို ကျော်ဖြတ်ရန် ဟက်ခ်တစ်ခု (ငါ ဒီထွန်တုံးပေါ် တက်ဖို့ ပထမဆုံး မဟုတ်ဘူး။)
   6. အမှားအယွင်းများရှိပါက ထည့်ရန် အသုံးဝင်နိုင်ပါသည်။ -verbosity detailed
3. အထုပ်ကို အရင်းအမြစ်သို့ ပို့နေသည်- nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
   1. ကျွန်ုပ်တို့သည် လက်ရှိလမ်းညွှန်မှ ပက်ကေ့ဂျ်များအားလုံးကို ပို့ပေးပါသည်။ *.nupkg.
   2. name - အပေါ်ကအဆင့်ကနေ။
   3. key - လိုင်းတစ်ခုခု။ Azure DevOps တွင်၊ Connect to feed window တွင်၊ ဥပမာသည် အမြဲတမ်းလိုင်းဖြစ်သည်။ az.
   4. -skipduplicate - ဤသော့မပါဘဲ ရှိနှင့်ပြီးသား ပက်ကေ့ခ်ျတစ်ခုကို ပို့ရန် ကြိုးစားသောအခါ၊ အရင်းအမြစ်သည် အမှားတစ်ခု ပြန်ပေါ်လာလိမ့်မည်။ 409 Conflict; သော့ဖြင့် ပေးပို့ခြင်းကို ကျော်သွားပါမည်။

ယခု စာရွက်စာတမ်းဖန်တီးမှုကို စဖွင့်ကြပါစို့။

1. ပထမဦးစွာ repository တွင်၊ master ဌာနခွဲတွင်၊ docfx ပရောဂျက်ကို စတင်လုပ်ဆောင်ပါသည်။ ဒီလိုလုပ်ဖို့၊ root မှ command ကို run docfx init စာရွက်စာတမ်းတည်ဆောက်ခြင်းအတွက် သော့ချက်ဘောင်များကို အပြန်အလှန်အားဖြင့် အပြန်အလှန်သတ်မှတ်ပါ။ အနည်းဆုံး ပရောဂျက်တည်ဆောက်မှု၏ အသေးစိတ်ဖော်ပြချက် ဒီမှာ.
   1. configure လုပ်သောအခါ၊ output directory ကိုသတ်မှတ်ရန်အရေးကြီးသည်။ ..public - ပုံမှန်အားဖြင့် GitLab သည် Pages အတွက် အရင်းအမြစ်အဖြစ် repository ၏ အမြစ်တွင် အများသူငှာ ဖိုဒါ၏ အကြောင်းအရာများကို ယူဆောင်သည်။ ဘာဖြစ်လို့လဲဆိုတော့ ပရောဂျက်သည် repository တွင် အသိုက်အမြုံရှိသော ဖိုင်တွဲတစ်ခုတွင် တည်ရှိလိမ့်မည် - လမ်းကြောင်းပေါ်ရှိ အဆင့်အထိ အထွက်တစ်ခု ထည့်ပါ။
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. Node များ-

pages:
  # snip
  artifacts:
    paths:
      - public

docfx နှင့်ပတ်သက်သော သီချင်းစာသား ကွဲလွဲမှု

ယခင်က၊ ပရောဂျက်တစ်ခုတည်ဆောက်သည့်အခါ၊ စာရွက်စာတမ်းအတွက် ကုဒ်ရင်းမြစ်ကို ဖြေရှင်းချက်ဖိုင်အဖြစ် သတ်မှတ်ခဲ့သည်။ အဓိက အားနည်းချက်ကတော့ စမ်းသပ်ပရောဂျက်တွေအတွက် စာရွက်စာတမ်းတွေကို ဖန်တီးထားတာ ဖြစ်ပါတယ်။ ၎င်းသည်မလိုအပ်ပါက၊ ဤတန်ဖိုးကို node တွင်သင်သတ်မှတ်နိုင်သည်။ metadata.src:

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

1. metadata.src.src: "../" - ကျွန်ုပ်တို့သည် တည်နေရာနှင့် နှိုင်းယှဉ်ပါက အဆင့်တစ်ဆင့်တက်ပါသည်။ docfx.json, ဘာဖြစ်လို့လဲဆိုတော့ ပုံစံများဖြင့်၊ directory tree ကိုရှာဖွေခြင်းသည် အလုပ်မဖြစ်ပါ။
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 Artifacts သည် သင့်အား နောက်ဆုံးထွက်ဗားရှင်းဖြင့် ပက်ကေ့ဂျ်များအတွက် တံဆိပ်များကို ဖန်တီးနိုင်စေပါသည်။ ထိုသို့လုပ်ဆောင်ရန်၊ Azure DevOps ဆိုက်ရှိရင်းမြစ်တွင်၊ ရွေးချယ်ထားသော အထုပ်အတွက် ဖန်တီးတံဆိပ်ကို နှိပ်ပြီး အမှတ်အသားပြုထားသော အမှတ်အသားကို ကူးယူရန် လိုအပ်သည်-

အလှတရားတွေ ထည့်ပေးတယ်။

ဘုံဖွဲ့စည်းမှုအပိုင်းအစများကို မီးမောင်းထိုးပြခြင်း။

ဖွဲ့စည်းမှုပုံစံကို ရေးသားပြီး စာရွက်စာတမ်းများကို ရှာဖွေနေစဉ် YAML ၏ အပိုင်းအစများကို ပြန်လည်အသုံးပြုခြင်း၏ စိတ်ဝင်စားဖွယ်လုပ်ဆောင်ချက်ကို တွေ့ခဲ့ရသည်။

အလုပ်ဆက်တင်များမှ သင်တွေ့မြင်ရသည့်အတိုင်း၊ ၎င်းတို့အားလုံးသည် တဂ်လိုအပ်သည်။ windows အပြေးသမားတွင်၊ ပေါင်းစည်းရန် တောင်းဆိုချက်ကို မာစတာ/ဖန်တီးသူထံ ပေးပို့သောအခါ (စာရွက်စာတမ်းအထောက်အထားမှလွဲ၍) အစပျိုးသည်။ ဒါကို ပြန်သုံးမယ့်အပိုင်းထဲကို ထည့်လိုက်ရအောင်။

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

ယခု ကျွန်ုပ်တို့သည် လုပ်ဆောင်စရာဖော်ပြချက်တွင် အစောပိုင်းက ကြေညာထားသည့်အပိုင်းအစကို ထည့်သွင်းနိုင်သည်-

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

လုပ်ငန်းတစ်ခုအဖြစ် အဓိပ္ပါယ်မဖွင့်ရန် Fragment အမည်များကို အစက်ဖြင့် စတင်ရပါမည်။

ပက်ကေ့ချ်ဗားရှင်းကို ပြောင်းလဲခြင်း။

ပက်ကေ့ဂျ်တစ်ခုဖန်တီးသောအခါတွင်၊ စုစည်းသူသည် command line switches များကိုစစ်ဆေးပြီး ၎င်းတို့မရှိသည့်အခါ၊ ပရောဂျက်ဖိုင်များ၊ Version node ကိုတွေ့သောအခါ၊ တည်ဆောက်နေသော package ၏ဗားရှင်းကဲ့သို့၎င်း၏တန်ဖိုးကိုယူသည်။ ဗားရှင်းအသစ်ဖြင့် ပက်ကေ့ဂျ်တစ်ခုကို တည်ဆောက်ရန်အတွက်၊ ၎င်းကို ပရောဂျက်ဖိုင်တွင် အပ်ဒိတ်လုပ်ရန် သို့မဟုတ် ၎င်းအား command line argument တစ်ခုအဖြစ် ဖြတ်သန်းရန် လိုအပ်ကြောင်း တွေ့ရှိရပါသည်။

နောက်ထပ် Wishlist တစ်ခု ထပ်ထည့်ကြပါစို့ - ဗားရှင်းရှိ ဂဏန်းနှစ်လုံးကို နှစ်နှင့် ပက်ကေ့ဂျ်၏ တည်ဆောက်မည့်ရက်စွဲအဖြစ် သတ်မှတ်ကာ အကြိုထုတ်လွှတ်သည့် ဗားရှင်းများကို ထည့်ပါ။ သေချာပါတယ်၊ သင်သည် ဤဒေတာကို ပရောဂျက်ဖိုင်တွင် ထည့်သွင်းပြီး တင်သွင်းမှုတစ်ခုစီမတိုင်မီ စစ်ဆေးနိုင်သည် - သို့သော် သင်သည် ၎င်းကို ပိုက်လိုင်းတွင် လုပ်ဆောင်နိုင်ပြီး အကြောင်းအရာမှ ပက်ကေ့ဂျ်ဗားရှင်းကို စုဆောင်းကာ command line argument မှတစ်ဆင့် ၎င်းကိုဖြတ်သန်းနိုင်သည်။

commit message တွင် စာကြောင်းကဲ့သို့ စာကြောင်းပါလျှင် သဘောတူကြပါစို့ release (v./ver./version) <version number> (rev./revision <revision>)?ထို့နောက် ကျွန်ုပ်တို့သည် ဤစာကြောင်းမှ ပက်ကေ့ဂျ်ဗားရှင်းကို ယူမည်ဖြစ်ပြီး၊ ၎င်းကို လက်ရှိရက်စွဲဖြင့် ဖြည့်စွက်ပြီး ၎င်းကို အမိန့်ပေးရန်အတွက် အကြောင်းပြချက်တစ်ခုအဖြစ် ပေးပို့ပါမည်။ dotnet pack. လိုင်းမရှိလျှင် ကျွန်ုပ်တို့သည် အထုပ်ကို ကောက်ယူမည်မဟုတ်ပါ။

အောက်ပါ script သည် ဤပြဿနာကို ဖြေရှင်းပေးသည်-

# регулярное выражение для поиска строки с версией
$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 commit message တွင် ပေးထားသော စာကြောင်းတစ်ခုရှေ့တွင် ပက်ကေ့ဂျ်များစုဝေးခြင်းကို တင်းကြပ်စွာ စောင့်ကြည့်ပါ။

စုစုပေါင်း

နာရီဝက် သို့မဟုတ် တစ်နာရီခန့် အချိန်ယူပြီး ဖွဲ့စည်းမှုပုံစံကို ရေးသားခြင်း၊ ဒေသတွင်း powershell တွင် အမှားရှာပြင်ခြင်းနှင့် မအောင်မြင်သော လွှတ်တင်မှုအချို့ကို လုပ်ဆောင်ပြီးနောက် ပုံမှန်လုပ်ဆောင်စရာများကို အလိုအလျောက်လုပ်ဆောင်ရန်အတွက် ရိုးရှင်းသောပုံစံတစ်ခုကို ကျွန်ုပ်တို့ရရှိသည်။

ဟုတ်ပါတယ်၊ GitLab CI / CD က ဒီလမ်းညွှန်ချက်ကို ဖတ်ပြီးရင် ထင်ထားတာထက် အများကြီး ပိုကျယ်ဝန်းပြီး ဘက်စုံသုံးပါတယ်။ အဲဒါ လုံးဝမမှန်ပါဘူး။. အဲဒီမှာတောင် Auto DevOps သည်ခွင့်ပြု

သင့်အက်ပ်လီကေးရှင်းများကို အလိုအလျောက်ရှာဖွေခြင်း၊ တည်ဆောက်ခြင်း၊ စမ်းသပ်ခြင်း၊ အသုံးပြုခြင်းနှင့် စောင့်ကြည့်စစ်ဆေးခြင်း။

ယခု အစီအစဉ်များသည် Pulumi ကို အသုံးပြု၍ Azure သို့ အပလီကေးရှင်းများ ဖြန့်ကျက်ခြင်းအတွက် ပိုက်လိုင်းတစ်ခုကို စီစဉ်သတ်မှတ်ပြီး နောက်ဆောင်းပါးတွင် ဖော်ပြမည့် ပစ်မှတ်ပတ်ဝန်းကျင်ကို အလိုအလျောက် ဆုံးဖြတ်ခြင်းဖြစ်ပါသည်။

source: www.habr.com