ការណែនាំអំពី CI/CD នៅក្នុង GitLab សម្រាប់អ្នកចាប់ផ្តើមដំបូងដាច់ខាត (ស្ទើរតែ)

ឬរបៀបដើម្បីទទួលបានផ្លាកសញ្ញាដ៏ស្រស់ស្អាតសម្រាប់គម្រោងរបស់អ្នកនៅពេលល្ងាចនៃការសរសេរកូដងាយស្រួល

ប្រហែលជាអ្នកអភិវឌ្ឍន៍ទាំងអស់ដែលមានគម្រោងសត្វចិញ្ចឹមយ៉ាងហោចណាស់មួយនៅចំណុចខ្លះមានការរមាស់អំពីផ្លាកសញ្ញាដ៏ស្រស់ស្អាតជាមួយនឹងស្ថានភាព ការគ្របដណ្តប់កូដ កំណែកញ្ចប់នៅក្នុង nuget ... ហើយការរមាស់នេះបាននាំឱ្យខ្ញុំសរសេរអត្ថបទនេះ។ ក្នុង​ការ​រៀប​ចំ​សម្រាប់​ការ​សរសេរ​វា ខ្ញុំ​ទទួល​បាន​សម្រស់​នេះ​ក្នុង​គម្រោង​មួយ​របស់​ខ្ញុំ៖

អត្ថបទនេះនឹងណែនាំអ្នកអំពីការរៀបចំជាមូលដ្ឋាននៃការរួមបញ្ចូល និងការចែកចាយជាបន្តបន្ទាប់សម្រាប់គម្រោងបណ្ណាល័យថ្នាក់ .Net Core នៅក្នុង GitLab ការបោះពុម្ពឯកសារទៅកាន់ទំព័រ GitLab និងការជំរុញកញ្ចប់ដែលបានបង្កើតទៅជាចំណីឯកជននៅក្នុង Azure DevOps ។

VS Code ត្រូវបានប្រើជាបរិយាកាសអភិវឌ្ឍន៍ជាមួយផ្នែកបន្ថែម លំហូរការងារ GitLab (សម្រាប់សុពលភាពឯកសារការកំណត់ដោយផ្ទាល់ពីបរិស្ថានអភិវឌ្ឍន៍)។

ការណែនាំសង្ខេប

ស៊ីឌី - តើវានៅពេលអ្នកទើបតែរុញ ហើយអ្វីៗបានធ្លាក់លើម៉ាស៊ីនភ្ញៀវហើយឬនៅ?

តើអ្វីទៅជា CI/CD ហើយហេតុអ្វីបានជាអ្នកត្រូវការវា - អ្នកអាច google វាបានយ៉ាងងាយស្រួល។ ស្វែងរកឯកសារពេញលេញស្តីពីការកំណត់រចនាសម្ព័ន្ធបំពង់នៅក្នុង GitLab ងាយស្រួលផងដែរ។. នៅទីនេះខ្ញុំនឹងសង្ខេបហើយប្រសិនបើអាចធ្វើទៅបានដោយគ្មានគុណវិបត្តិពិពណ៌នាអំពីដំណើរការនៃប្រព័ន្ធពីទិដ្ឋភាពភ្នែករបស់បក្សី:

• អ្នកអភិវឌ្ឍន៍ផ្ញើការប្តេជ្ញាចិត្តទៅកាន់ឃ្លាំង បង្កើតសំណើបញ្ចូលគ្នាតាមរយៈគេហទំព័រ ឬតាមមធ្យោបាយផ្សេងទៀត ជាក់លាក់ ឬដោយចេតនាចាប់ផ្តើមបំពង់បង្ហូរប្រេង,
• កិច្ចការទាំងអស់ត្រូវបានជ្រើសរើសពីការកំណត់រចនាសម្ព័ន្ធ លក្ខខណ្ឌដែលអនុញ្ញាតឱ្យពួកវាត្រូវបានដាក់ឱ្យដំណើរការក្នុងបរិបទដែលបានផ្តល់ឱ្យ
• ភារកិច្ចត្រូវបានរៀបចំតាមដំណាក់កាលរបស់ពួកគេ
• ដំណាក់កាលត្រូវបានប្រតិបត្តិជាវេន - i.e. ប៉ារ៉ាឡែល ការងារទាំងអស់នៃដំណាក់កាលនេះត្រូវបានបញ្ចប់
• ប្រសិនបើដំណាក់កាលបរាជ័យ (ឧ. យ៉ាងហោចណាស់កិច្ចការមួយនៃដំណាក់កាលបរាជ័យ) បំពង់បង្ហូរប្រេងនឹងឈប់ (ស្ទើ​តែ​រហូត),
• ប្រសិនបើដំណាក់កាលទាំងអស់ត្រូវបានបញ្ចប់ដោយជោគជ័យ បំពង់បង្ហូរប្រេងត្រូវបានចាត់ទុកថាជោគជ័យ។

ដូច្នេះ យើងមាន៖

• បំពង់ - សំណុំនៃកិច្ចការដែលបានរៀបចំជាដំណាក់កាលដែលអ្នកអាចបង្កើត សាកល្បង កូដកញ្ចប់ ដាក់ពង្រាយការស្ថាបនាដែលបានបញ្ចប់ទៅសេវាកម្មពពក។ល។
• ដំណាក់កាល (ឆាក) - អង្គភាពបំពង់បង្ហូរប្រេង មានភារកិច្ច 1+
• ភារកិច្ច (ការ​ងារ) គឺជាឯកតានៃការងារនៅក្នុងបំពង់។ វាមានស្គ្រីប (ទាមទារ) លក្ខខណ្ឌនៃការបើកដំណើរការ ការកំណត់សម្រាប់ការបោះពុម្ព/ឃ្លាំងសម្ងាត់វត្ថុបុរាណ និងច្រើនទៀត។

ដូច្នោះហើយ ភារកិច្ចនៅពេលរៀបចំ CI/CD ចុះមកដើម្បីបង្កើតសំណុំនៃកិច្ចការដែលអនុវត្តសកម្មភាពចាំបាច់ទាំងអស់សម្រាប់ការកសាង សាកល្បង និងបោះពុម្ពកូដ និងវត្ថុបុរាណ។

មុនពេលចាប់ផ្តើម៖ ហេតុអ្វី?

• ហេតុអ្វី Gitlab?

ដោយសារតែនៅពេលដែលវាក្លាយជាការចាំបាច់ដើម្បីបង្កើតឃ្លាំងឯកជនសម្រាប់គម្រោងសត្វចិញ្ចឹម ពួកគេត្រូវបានបង់នៅលើ GitHub ហើយខ្ញុំមានការលោភលន់។ ឃ្លាំងបានក្លាយទៅជាឥតគិតថ្លៃ ប៉ុន្តែរហូតមកដល់ពេលនេះ វាមិនមែនជាហេតុផលគ្រប់គ្រាន់សម្រាប់ខ្ញុំក្នុងការផ្លាស់ទីទៅ GitHub នោះទេ។

• ហេតុអ្វីបានជាមិន Azure DevOps Pipelines?

ដោយសារតែនៅទីនោះការកំណត់គឺបឋម - ចំណេះដឹងនៃបន្ទាត់ពាក្យបញ្ជាមិនត្រូវបានទាមទារសូម្បីតែ។ ការរួមបញ្ចូលជាមួយអ្នកផ្តល់សេវា git ខាងក្រៅ - ដោយការចុចពីរបីដង ការនាំចូលសោ SSH ដើម្បីផ្ញើការប្តេជ្ញាចិត្តទៅកាន់ឃ្លាំង - ផងដែរ បំពង់ត្រូវបានតំឡើងយ៉ាងងាយស្រួល ទោះបីជាមិនមែនមកពីគំរូក៏ដោយ។

ទីតាំងចាប់ផ្តើម៖ អ្វីដែលអ្នកមាន និងអ្វីដែលអ្នកចង់បាន

យើង​មាន:

• ឃ្លាំងនៅក្នុង GitLab ។

យើងចង់បាន៖

• ការជួបប្រជុំគ្នាដោយស្វ័យប្រវត្តិ និងការធ្វើតេស្តសម្រាប់សំណើបញ្ចូលគ្នានីមួយៗ,
• ការកសាងកញ្ចប់សម្រាប់សំណើបញ្ចូលគ្នានីមួយៗ និងការជំរុញទៅមេ ផ្តល់ថាមានបន្ទាត់ជាក់លាក់មួយនៅក្នុងសារប្តេជ្ញា
• ការផ្ញើកញ្ចប់ដែលបានបង្កើតទៅមតិព័ត៌មានឯកជននៅក្នុង Azure DevOps,
• ការប្រមូលផ្តុំឯកសារ និងការបោះពុម្ពផ្សាយនៅក្នុងទំព័រ GitLab,
• ផ្លាកសញ្ញា !11

តម្រូវការដែលបានពិពណ៌នាមានលក្ខណៈសរីរាង្គធ្លាក់លើគំរូបំពង់ខាងក្រោម៖

• ដំណាក់កាលទី 1 - ការជួបប្រជុំគ្នា។
  • យើងប្រមូលកូដ បោះពុម្ពឯកសារលទ្ធផលជាវត្ថុបុរាណ
• ដំណាក់កាលទី 2 - ការធ្វើតេស្ត
  • យើងទទួលបានវត្ថុបុរាណពីដំណាក់កាលសាងសង់ ដំណើរការសាកល្បង ប្រមូលទិន្នន័យគ្របដណ្តប់កូដ
• ដំណាក់កាលទី 3 - ដាក់ស្នើ
  • កិច្ចការទី 1 - បង្កើតកញ្ចប់ nuget ហើយផ្ញើវាទៅ Azure DevOps
  • កិច្ចការទី 2 - យើងប្រមូលគេហទំព័រពី xmldoc នៅក្នុងកូដប្រភព ហើយបោះផ្សាយវានៅក្នុង GitLab Pages

តោះចាប់ផ្តើម!

ការប្រមូលការកំណត់រចនាសម្ព័ន្ធ

កំពុងរៀបចំគណនី

1. បង្កើតគណនីនៅក្នុង Microsoft Azure

2. ទៅ Azure DevOps

3. យើងបង្កើតគម្រោងថ្មីមួយ

   1. ឈ្មោះ - ណាមួយ។
   2. ភាពមើលឃើញ - ណាមួយ។
      

4. នៅពេលអ្នកចុចលើប៊ូតុងបង្កើត គម្រោងនឹងត្រូវបានបង្កើត ហើយអ្នកនឹងត្រូវបានបញ្ជូនបន្តទៅកាន់ទំព័ររបស់វា។ នៅលើទំព័រនេះ អ្នកអាចបិទមុខងារដែលមិនចាំបាច់ដោយចូលទៅកាន់ការកំណត់គម្រោង (តំណខាងក្រោមក្នុងបញ្ជីនៅខាងឆ្វេង -> ទិដ្ឋភាពទូទៅ -> ប្លុកសេវាកម្ម Azure DevOps)
   

5. ចូលទៅកាន់ Attrifacts ចុច Create feed

   1. បញ្ចូលឈ្មោះប្រភព
   2. ជ្រើសរើសភាពមើលឃើញ
   3. ដោះធីក រួមបញ្ចូលកញ្ចប់ពីប្រភពសាធារណៈទូទៅដូច្នេះ​ប្រភព​មិន​ប្រែ​ក្លាយ​ទៅ​ជា​ក្លូន​នុយក្លេអ៊ែ
      

6. ចុច Connect to feed ជ្រើសរើស Visual Studio ចម្លងប្រភពពីប្លុកដំឡើងម៉ាស៊ីន
   

7. ចូលទៅកាន់ការកំណត់គណនី ជ្រើសរើស Personal Access Token
   

8. បង្កើតនិមិត្តសញ្ញាចូលប្រើថ្មី។

   1. ឈ្មោះ - បំពាន
   2. អង្គការ - បច្ចុប្បន្ន
   3. មានសុពលភាពអតិបរមា 1 ឆ្នាំ។
   4. វិសាលភាព - ការវេចខ្ចប់/អាន និងសរសេរ
      

9. ចម្លងនិមិត្តសញ្ញាដែលបានបង្កើត - បន្ទាប់ពីបង្អួចម៉ូឌុលត្រូវបានបិទ តម្លៃនឹងមិនមាន

10. ចូលទៅកាន់ការកំណត់ឃ្លាំងនៅក្នុង GitLab ជ្រើសរើសការកំណត់ CI/CD
    

11. ពង្រីកប្លុកអថេរ បន្ថែមថ្មីមួយ

    1. ឈ្មោះ - ណាមួយដោយគ្មានចន្លោះ (នឹងមាននៅក្នុងសែលពាក្យបញ្ជា)
    2. តម្លៃ - សញ្ញាសម្ងាត់ចូលប្រើពីកថាខណ្ឌទី 9
    3. ជ្រើសរើសអថេររបាំងមុខ
       

នេះបញ្ចប់ការកំណត់ជាមុន។

កំពុងរៀបចំក្របខ័ណ្ឌកំណត់រចនាសម្ព័ន្ធ

តាមលំនាំដើម ការកំណត់រចនាសម្ព័ន្ធ CI/CD នៅក្នុង GitLab ប្រើឯកសារ .gitlab-ci.yml ពីឫសនៃឃ្លាំង។ អ្នកអាចកំណត់ផ្លូវបំពានទៅឯកសារនេះនៅក្នុងការកំណត់ឃ្លាំង ប៉ុន្តែក្នុងករណីនេះវាមិនចាំបាច់ទេ។

ដូចដែលអ្នកអាចមើលឃើញពីផ្នែកបន្ថែម ឯកសារមានការកំណត់រចនាសម្ព័ន្ធក្នុងទម្រង់ YAML. ឯកសារលម្អិតអំពីសោដែលអាចត្រូវបានផ្ទុកនៅកម្រិតកំពូលនៃការកំណត់រចនាសម្ព័ន្ធ និងនៅកម្រិតនីមួយៗនៃស្រទាប់។

ជាដំបូង យើងបន្ថែមតំណភ្ជាប់ទៅរូបភាព docker នៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធ ដែលភារកិច្ចនឹងត្រូវបានអនុវត្ត។ សម្រាប់រឿងនេះយើងរកឃើញ ទំព័ររូបភាព .Net Core នៅលើ Docker Hub។ នេះ GitHub មានការណែនាំលម្អិតអំពីរូបភាពដែលត្រូវជ្រើសរើសសម្រាប់កិច្ចការផ្សេងៗ។ រូបភាពដែលមាន .Net Core 3.1 គឺស័ក្តិសមសម្រាប់យើងក្នុងការបង្កើត ដូច្នេះអ្នកអាចបន្ថែមបន្ទាត់ទីមួយទៅក្នុងការកំណត់រចនាសម្ព័ន្ធ។

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

ឥឡូវនេះ នៅពេលដែលបំពង់បង្ហូរប្រេងត្រូវបានដាក់ឱ្យដំណើរការពីឃ្លាំងរូបភាពរបស់ Microsoft រូបភាពដែលបានបញ្ជាក់នឹងត្រូវបានទាញយក ដែលកិច្ចការទាំងអស់ពីការកំណត់រចនាសម្ព័ន្ធនឹងត្រូវបានប្រតិបត្តិ។

ជំហានបន្ទាប់គឺត្រូវបន្ថែម ឆាករបស់ តាមលំនាំដើម 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

ជាធម្មតា មានការ nuances មួយចំនួនដោយសារតែការដែលយើងនឹងធ្វើឱ្យពាក្យបញ្ជាស្មុគស្មាញបន្តិច។

1. យើង​ចង់​បាន​ការ​បង្កើត​ចេញ​មិន​មែន​បង្កើត​បំបាត់​កំហុស​ទេ ដូច្នេះ​យើង​បន្ថែម​ទៅ​ពាក្យ​បញ្ជា​នីមួយៗ -c Release
2. នៅពេលធ្វើតេស្ត យើងចង់ប្រមូលទិន្នន័យគ្របដណ្តប់កូដ ដូច្នេះយើងត្រូវបញ្ចូលឧបករណ៍វិភាគការគ្របដណ្តប់នៅក្នុងបណ្ណាល័យសាកល្បង៖
   1. បន្ថែមកញ្ចប់ទៅបណ្ណាល័យសាកល្បងទាំងអស់។ coverlet.msbuild: dotnet add package coverlet.msbuild ពីថតគម្រោង
   2. បន្ថែមទៅពាក្យបញ្ជាដំណើរការសាកល្បង /p:CollectCoverage=true
   3. បន្ថែមសោទៅការកំណត់រចនាសម្ព័ន្ធកិច្ចការសាកល្បង ដើម្បីទទួលបានលទ្ធផលគ្របដណ្តប់ (សូមមើលខាងក្រោម)
3. នៅពេលខ្ចប់លេខកូដទៅក្នុងកញ្ចប់ nuget កំណត់ថតលទ្ធផលសម្រាប់កញ្ចប់៖ -o .

ការប្រមូលទិន្នន័យគ្របដណ្តប់កូដ

បន្ទាប់ពីដំណើរការសាកល្បង ការបោះពុម្ព Coverlet ដំណើរការស្ថិតិទៅកាន់កុងសូល៖

Calculating coverage result...
  Generating report 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Module      | Line   | Branch | Method |
+-------------+--------+--------+--------+
| project 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| project 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| project 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Line   | Branch | Method |
+---------+--------+--------+--------+
| Total   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Average | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

GitLab អនុញ្ញាតឱ្យអ្នកបញ្ជាក់កន្សោមធម្មតាដើម្បីទទួលបានស្ថិតិ ដែលបន្ទាប់មកអាចទទួលបានក្នុងទម្រង់ជាផ្លាកសញ្ញា។ កន្សោមធម្មតាត្រូវបានបញ្ជាក់នៅក្នុងការកំណត់ភារកិច្ចដោយប្រើគ្រាប់ចុច coverage; កន្សោមត្រូវតែមានក្រុមចាប់យក តម្លៃដែលនឹងត្រូវបានបញ្ជូនទៅផ្លាកសញ្ញា៖

test and cover job:
  # snip
  coverage: /|s*Totals*|s*(d+[,.]d+%)/

នៅទីនេះយើងទទួលបានស្ថិតិពីបន្ទាត់ដែលមានបណ្តាញគ្របដណ្តប់សរុប។

ផ្សព្វផ្សាយកញ្ចប់ និងឯកសារ

សកម្មភាពទាំងពីរត្រូវបានកំណត់ពេលសម្រាប់ដំណាក់កាលចុងក្រោយនៃបំពង់បង្ហូរប្រេង - ចាប់តាំងពីការជួបប្រជុំគ្នា និងការសាកល្បងបានកន្លងផុតទៅ យើងអាចចែករំលែកការវិវត្តរបស់យើងជាមួយពិភពលោក។

ជាដំបូង ពិចារណាការបោះផ្សាយទៅប្រភពកញ្ចប់៖

1. ប្រសិនបើគម្រោងមិនមានឯកសារកំណត់រចនាសម្ព័ន្ធ nuet (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 នៅក្នុងបង្អួច Connect to feed ឧទាហរណ៍គឺតែងតែជាបន្ទាត់ az.
   4. -skipduplicate - នៅពេលព្យាយាមផ្ញើកញ្ចប់ដែលមានស្រាប់ដោយគ្មានសោនេះ ប្រភពនឹងត្រឡប់កំហុស 409 Conflict; ដោយប្រើសោ ការផ្ញើនឹងត្រូវបានរំលង។

ឥឡូវ​យើង​រៀបចំ​ការ​បង្កើត​ឯកសារ៖

1. ដំបូងនៅក្នុងឃ្លាំង នៅក្នុងសាខាមេ យើងចាប់ផ្តើមគម្រោង docfx ។ ដើម្បីធ្វើដូចនេះដំណើរការពាក្យបញ្ជាពី root docfx init និងធ្វើអន្តរកម្មកំណត់ប៉ារ៉ាម៉ែត្រសំខាន់ៗសម្រាប់ការកសាងឯកសារ។ ការពិពណ៌នាលម្អិតនៃការដំឡើងគម្រោងអប្បបរមា នៅទីនេះ.
   1. នៅពេលកំណត់រចនាសម្ព័ន្ធ វាមានសារៈសំខាន់ណាស់ក្នុងការបញ្ជាក់ថតលទ្ធផល ..public - GitLab តាមលំនាំដើមយកមាតិកានៃថតសាធារណៈនៅក្នុងឫសនៃឃ្លាំងជាប្រភពសម្រាប់ទំព័រ។ ដោយសារតែ គម្រោងនឹងមានទីតាំងនៅក្នុងថតដែលដាក់ក្នុងឃ្លាំង - បន្ថែមលទ្ធផលទៅកម្រិតឡើងលើផ្លូវ។
2. តោះជំរុញការផ្លាស់ប្តូរទៅ GitLab ។
3. បន្ថែមភារកិច្ចទៅការកំណត់រចនាសម្ព័ន្ធបំពង់ pages (ពាក្យដែលបានបម្រុងទុកសម្រាប់កិច្ចការផ្សព្វផ្សាយគេហទំព័រនៅក្នុង GitLab 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

និយាយអំពីផ្លាកសញ្ញា

ដោយសារតែពួកគេ, បន្ទាប់ពីទាំងអស់, អ្វីគ្រប់យ៉ាងត្រូវបានចាប់ផ្តើម!

ផ្លាកសញ្ញាដែលមានស្ថានភាពបំពង់ និងការគ្របដណ្តប់កូដមាននៅក្នុង GitLab នៅក្នុងការកំណត់ CI/CD នៅក្នុងប្លុក Gtntral pipelines៖

ខ្ញុំបានបង្កើតផ្លាកសញ្ញាមួយដែលមានតំណភ្ជាប់ទៅកាន់ឯកសារនៅលើវេទិកា 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

ឈ្មោះបំណែកត្រូវតែចាប់ផ្តើមដោយចំណុច ដើម្បីកុំឱ្យបកស្រាយថាជាកិច្ចការ។

កំណែកញ្ចប់

នៅពេលបង្កើតកញ្ចប់មួយ អ្នកចងក្រងពិនិត្យមើលការប្តូរបន្ទាត់ពាក្យបញ្ជា ហើយនៅក្នុងអវត្តមានរបស់ពួកគេ ឯកសារគម្រោង; នៅពេលដែលវារកឃើញថ្នាំងកំណែ វាយកតម្លៃរបស់វាជាកំណែនៃកញ្ចប់ដែលកំពុងត្រូវបានបង្កើតឡើង។ វាប្រែថាដើម្បីបង្កើតកញ្ចប់ជាមួយកំណែថ្មីអ្នកត្រូវធ្វើបច្ចុប្បន្នភាពវានៅក្នុងឯកសារគម្រោងឬឆ្លងកាត់វាជាអាគុយម៉ង់បន្ទាត់ពាក្យបញ្ជា។

ចូរបន្ថែមបញ្ជីប្រាថ្នាមួយបន្ថែមទៀត - អនុញ្ញាតឱ្យលេខតូចពីរនៅក្នុងកំណែជាឆ្នាំ និងកាលបរិច្ឆេទបង្កើតកញ្ចប់ ហើយបន្ថែមកំណែដែលបានចេញផ្សាយជាមុន។ ជាការពិតណាស់ អ្នកអាចបន្ថែមទិន្នន័យនេះទៅក្នុងឯកសារគម្រោង ហើយពិនិត្យមើលមុនពេលដាក់ស្នើនីមួយៗ ប៉ុន្តែអ្នកក៏អាចធ្វើវាបាននៅក្នុងបំពង់បង្ហូរប្រេង ដោយប្រមូលកំណែកញ្ចប់ពីបរិបទ ហើយឆ្លងកាត់វាតាមរយៈអាគុយម៉ង់បន្ទាត់ពាក្យបញ្ជា។

ចូរយើងយល់ស្របថាប្រសិនបើសារ commit មានបន្ទាត់ដូច 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 និងសង្កេតការជួបប្រជុំគ្នានៃកញ្ចប់យ៉ាងតឹងរ៉ឹងនៅក្នុងវត្តមាននៃខ្សែអក្សរដែលបានផ្តល់ឱ្យនៅក្នុងសារសន្យា។

សរុប

បន្ទាប់ពីចំណាយពេលប្រហែលកន្លះម៉ោង ឬមួយម៉ោងក្នុងការសរសេរការកំណត់ បំបាត់កំហុសនៅក្នុង powershell ក្នុងតំបន់ ហើយប្រហែលជាការបើកដំណើរការមិនជោគជ័យពីរបីដង យើងទទួលបានការកំណត់រចនាសម្ព័ន្ធសាមញ្ញមួយសម្រាប់ស្វ័យប្រវត្តិកម្មកិច្ចការទម្លាប់។

ជាការពិតណាស់ GitLab CI / CD មានលក្ខណៈទូលំទូលាយ និងមានលក្ខណៈចម្រុះជាងវាហាក់ដូចជាបន្ទាប់ពីបានអានការណែនាំនេះ - នោះមិនពិតទាល់តែសោះ. មានសូម្បីតែ Auto DevOps គឺអនុញ្ញាត

រកឃើញ បង្កើត សាកល្បង ប្រើប្រាស់ និងត្រួតពិនិត្យកម្មវិធីរបស់អ្នកដោយស្វ័យប្រវត្តិ

ឥឡូវនេះផែនការគឺដើម្បីកំណត់រចនាសម្ព័ន្ធបំពង់សម្រាប់ដាក់ពង្រាយកម្មវិធីទៅ Azure ដោយប្រើ Pulumi និងកំណត់បរិយាកាសគោលដៅដោយស្វ័យប្រវត្តិ ដែលនឹងត្រូវបានគ្របដណ្តប់នៅក្នុងអត្ថបទបន្ទាប់។

ប្រភព: www.habr.com