ຄູ່ມືກ່ຽວກັບ CI/CD ໃນ GitLab ສໍາລັບຜູ້ເລີ່ມຕົ້ນຢ່າງແທ້ຈິງ (ເກືອບ).

ຫຼືວິທີການໄດ້ຮັບ badges ທີ່ສວຍງາມສໍາລັບໂຄງການຂອງທ່ານໃນຕອນແລງຫນຶ່ງຂອງລະຫັດງ່າຍ

ອາດຈະເປັນ, ທຸກໆນັກພັດທະນາທີ່ມີຢ່າງຫນ້ອຍຫນຶ່ງໂຄງການສັດລ້ຽງໃນບາງຈຸດມີອາການຄັນກ່ຽວກັບ badges ທີ່ສວຍງາມທີ່ມີສະຖານະພາບ, ການຄຸ້ມຄອງລະຫັດ, ສະບັບຊຸດໃນ nuget ... ແລະອາການຄັນນີ້ເຮັດໃຫ້ຂ້ອຍຂຽນບົດຄວາມນີ້. ໃນການກະກຽມສໍາລັບການຂຽນມັນ, ຂ້າພະເຈົ້າໄດ້ຮັບຄວາມງາມນີ້ຢູ່ໃນຫນຶ່ງໃນໂຄງການຂອງຂ້າພະເຈົ້າ:

ບົດຄວາມນີ້ຈະແນະນໍາທ່ານຜ່ານການຕັ້ງຄ່າພື້ນຖານຂອງການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງແລະການຈັດສົ່ງສໍາລັບໂຄງການຫ້ອງສະຫມຸດຊັ້ນ .Net Core ໃນ GitLab, ເຜີຍແຜ່ເອກະສານໄປຍັງ GitLab Pages, ແລະການຊຸກຍູ້ການຫຸ້ມຫໍ່ທີ່ສ້າງຂຶ້ນເປັນອາຫານສ່ວນຕົວໃນ Azure DevOps.

ລະຫັດ VS ຖືກໃຊ້ເປັນສະພາບແວດລ້ອມການພັດທະນາດ້ວຍການຂະຫຍາຍ GitLab Workflow (ສໍາລັບການກວດສອບໄຟລ໌ການຕັ້ງຄ່າໂດຍກົງຈາກສະພາບແວດລ້ອມການພັດທະນາ).

ແນະນໍາໂດຍຫຍໍ້

CD - ມັນແມ່ນເວລາທີ່ທ່ານພຽງແຕ່ pushed, ແລະທຸກສິ່ງທຸກຢ່າງໄດ້ຫຼຸດລົງແລ້ວກ່ຽວກັບລູກຄ້າ?

CI / CD ແມ່ນຫຍັງແລະເປັນຫຍັງທ່ານຕ້ອງການມັນ - ທ່ານສາມາດ google ມັນໄດ້ຢ່າງງ່າຍດາຍ. ຊອກຫາເອກະສານຄົບຖ້ວນກ່ຽວກັບການຕັ້ງຄ່າທໍ່ໃນ GitLab ຍັງງ່າຍ. ໃນທີ່ນີ້ຂ້ອຍຈະສັ້ນໆແລະຖ້າເປັນໄປໄດ້, ໂດຍບໍ່ມີຂໍ້ບົກພ່ອງອະທິບາຍຂະບວນການຂອງລະບົບຈາກທັດສະນະຂອງນົກຊະນິດ:

• ຜູ້​ພັດ​ທະ​ນາ​ສົ່ງ​ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​ກັບ repository​, ສ້າງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ລວມ​ໂດຍ​ຜ່ານ​ເວັບ​ໄຊ​ໄດ້​, ຫຼືໃນທາງອື່ນ, ຢ່າງຊັດເຈນ ຫຼື implicitly ເລີ່ມທໍ່,
• ວຽກ​ງານ​ທັງ​ຫມົດ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ຄັດ​ເລືອກ​ຈາກ​ການ​ຕັ້ງ​ຄ່າ​, ເງື່ອນ​ໄຂ​ທີ່​ອະ​ນຸ​ຍາດ​ໃຫ້​ເຂົາ​ເຈົ້າ​ຈະ​ໄດ້​ຮັບ​ການ​ເປີດ​ຕົວ​ໃນ​ສະ​ພາບ​ທີ່​ໄດ້​ຮັບ​,
• ວຽກ​ງານ​ໄດ້​ຖືກ​ຈັດ​ຕັ້ງ​ຕາມ​ໄລ​ຍະ​ຂອງ​ຕົນ​,
• ຂັ້ນຕອນຖືກປະຕິບັດໃນທາງກັບກັນ - i.e. ຂະຫນານ ວຽກ​ງານ​ທັງ​ຫມົດ​ຂອງ​ຂັ້ນ​ຕອນ​ນີ້​ແມ່ນ​ສໍາ​ເລັດ​,
• ຖ້າຂັ້ນຕອນລົ້ມເຫລວ (i.e., ຢ່າງຫນ້ອຍຫນຶ່ງຂອງວຽກງານຂອງເວທີລົ້ມເຫລວ), ທໍ່ຈະຢຸດ (.ເກືອບສະເຫມີ),
• ຖ້າທຸກຂັ້ນຕອນໄດ້ຖືກປະຕິບັດຢ່າງສໍາເລັດຜົນ, ທໍ່ນັ້ນຖືວ່າປະສົບຜົນສໍາເລັດ.

ດັ່ງນັ້ນ, ພວກເຮົາມີ:

• pipeline - ຊຸດຂອງວຽກງານທີ່ຈັດເປັນຂັ້ນຕອນທີ່ທ່ານສາມາດສ້າງ, ທົດສອບ, ລະຫັດຊຸດ, ນໍາໃຊ້ການກໍ່ສ້າງສໍາເລັດຮູບກັບການບໍລິການຟັງ, ແລະອື່ນໆ.
• ເວທີ (ຂັ້ນຕອນຂອງການ) — ຫນ່ວຍ​ບໍ​ລິ​ການ​ທໍ່​, ປະ​ກອບ​ດ້ວຍ 1+ ວຽກ​ງານ​,
• ວຽກງານ (ວຽກ​ເຮັດ​ງານ​ທໍາ) ເປັນຫນ່ວຍງານຂອງການເຮັດວຽກໃນທໍ່. ມັນປະກອບດ້ວຍສະຄຣິບ (ບັງຄັບ), ເງື່ອນໄຂການເປີດຕົວ, ການຕັ້ງຄ່າສໍາລັບການເຜີຍແຜ່ / ການເກັບຂໍ້ມູນປອມ, ແລະອື່ນໆອີກ.

ຕາມ​ນັ້ນ​ແລ້ວ, ວຽກ​ງານ​ເມື່ອ​ສ້າງ​ຕັ້ງ CI/CD ລົງ​ມາ​ແມ່ນ​ສ້າງ​ຕັ້ງ​ໜ້າ​ທີ່​ປະຕິບັດ​ບັນດາ​ການ​ກະທຳ​ທີ່​ຈຳ​ເປັນ​ໃນ​ການ​ກໍ່ສ້າງ, ທົດ​ສອບ ​ແລະ ​ເຜີຍ​ແຜ່​ບັນດາ​ຂໍ້​ກຳນົດ ​ແລະ ວັດຖຸ​ພັນ.

ກ່ອນທີ່ຈະເລີ່ມຕົ້ນ: ເປັນຫຍັງ?

• ເປັນຫຍັງ Gitlab?

ເນື່ອງຈາກວ່າໃນເວລາທີ່ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະສ້າງ repositories ເອກະຊົນສໍາລັບໂຄງການສັດລ້ຽງ, ພວກເຂົາເຈົ້າໄດ້ຮັບຄ່າຈ້າງໃນ GitHub, ແລະຂ້າພະເຈົ້າ greedy. repositories ໄດ້ກາຍເປັນບໍ່ເສຍຄ່າ, ແຕ່ມາຮອດປັດຈຸບັນນີ້ບໍ່ມີເຫດຜົນພຽງພໍສໍາລັບຂ້ອຍທີ່ຈະຍ້າຍໄປ GitHub.

• ເປັນຫຍັງບໍ່ Azure DevOps Pipelines?

ເນື່ອງຈາກວ່າມີການຕັ້ງຄ່າແມ່ນປະຖົມ - ຄວາມຮູ້ຂອງເສັ້ນຄໍາສັ່ງແມ່ນບໍ່ຈໍາເປັນ. ການປະສົມປະສານກັບຜູ້ໃຫ້ບໍລິການ git ພາຍນອກ - ໃນສອງສາມຄລິກ, ການນໍາເຂົ້າກະແຈ SSH ເພື່ອສົ່ງຄໍາຫມັ້ນສັນຍາກັບ repository - ເຊັ່ນດຽວກັນ, ທໍ່ໄດ້ຖືກຕັ້ງຄ່າໄດ້ງ່າຍເຖິງແມ່ນວ່າບໍ່ໄດ້ມາຈາກແມ່ແບບ.

ຕໍາແຫນ່ງເລີ່ມຕົ້ນ: ສິ່ງທີ່ທ່ານມີແລະສິ່ງທີ່ທ່ານຕ້ອງການ

ພວກ​ເຮົາ​ມີ:

• repository ໃນ GitLab.

ພວກ​ເຮົາ​ຕ້ອງ​ການ:

• ການປະກອບອັດຕະໂນມັດແລະການທົດສອບສໍາລັບແຕ່ລະຄໍາຮ້ອງຂໍການຜະສົມຜະສານ,
• ການ​ສ້າງ​ຊຸດ​ສໍາ​ລັບ​ການ​ຮ້ອງ​ຂໍ​ການ​ຜະ​ສົມ​ຜະ​ສານ​ແຕ່​ລະ​ຄົນ​ແລະ​ການ​ຊຸກ​ຍູ້​ໃຫ້​ແມ່​ບົດ​, ສະ​ຫນອງ​ໃຫ້​ວ່າ​ມີ​ເສັ້ນ​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​ໃນ​ຂໍ້​ຄວາມ​ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​,
• ການສົ່ງຊຸດທີ່ສ້າງຂຶ້ນໄປຫາອາຫານສ່ວນຕົວໃນ Azure DevOps,
• ການປະກອບເອກະສານແລະການພິມເຜີຍແຜ່ໃນ GitLab Pages,
• ປ້າຍ!11

ຄວາມຕ້ອງການທີ່ອະທິບາຍໄວ້ໂດຍພື້ນຖານແມ່ນຢູ່ໃນຮູບແບບທໍ່ຕໍ່ໄປນີ້:

• ຂັ້ນຕອນ 1 - ສະພາແຫ່ງ
  • ພວກເຮົາເກັບກໍາລະຫັດ, ເຜີຍແຜ່ໄຟລ໌ຜົນຜະລິດເປັນປອມ
• ຂັ້ນ​ຕອນ​ທີ 2 - ການ​ທົດ​ສອບ​
  • ພວກເຮົາໄດ້ຮັບສິ່ງປະດິດຈາກຂັ້ນຕອນການກໍ່ສ້າງ, ດໍາເນີນການທົດສອບ, ເກັບກໍາຂໍ້ມູນການຄຸ້ມຄອງລະຫັດ
• ຂັ້ນຕອນ 3 - ສົ່ງ
  • ວຽກທີ່ 1 - ສ້າງຊຸດ nuget ແລະສົ່ງໄປທີ່ Azure DevOps
  • ວຽກງານ 2 - ພວກເຮົາເກັບກໍາເວັບໄຊທ໌ຈາກ xmldoc ໃນລະຫັດແຫຼ່ງແລະເຜີຍແຜ່ໃນ GitLab Pages

ໃຫ້ເລີ່ມຕົ້ນ!

ການ​ເກັບ​ກໍາ​ການ​ຕັ້ງ​ຄ່າ​

ກຳລັງກະກຽມບັນຊີ

1. ສ້າງບັນຊີໃນ Microsoft Azure

2. ໄປ​ຫາ Azure DevOps

3. ພວກເຮົາສ້າງໂຄງການໃຫມ່

   1. ຊື່ - ໃດ
   2. ການເບິ່ງເຫັນ - ໃດ
      

4. ເມື່ອທ່ານຄລິກໃສ່ປຸ່ມສ້າງ, ໂຄງການຈະຖືກສ້າງຂື້ນແລະທ່ານຈະຖືກໂອນໄປຫາຫນ້າຂອງມັນ. ໃນຫນ້ານີ້, ທ່ານສາມາດປິດການທໍາງານລັກສະນະທີ່ບໍ່ຈໍາເປັນໂດຍການໄປທີ່ການຕັ້ງຄ່າໂຄງການ (ການເຊື່ອມຕໍ່ຕ່ໍາກວ່າໃນບັນຊີລາຍຊື່ທາງຊ້າຍ -> ພາບລວມ -> Azure DevOps Services block)
   

5. ໄປທີ່ Attrifacts, ຄລິກ ສ້າງ feed

   1. ໃສ່ຊື່ຂອງແຫຼ່ງ
   2. ເລືອກການເບິ່ງເຫັນ
   3. ຍົກເລີກການເລືອກ ລວມເອົາແພັກເກດຈາກແຫຼ່ງສາທາລະນະທົ່ວໄປ, ດັ່ງນັ້ນແຫຼ່ງບໍ່ໄດ້ປ່ຽນເປັນ clone nuget dump
      

6. ກົດ Connect to feed, ເລືອກ Visual Studio, ຄັດລອກແຫຼ່ງທີ່ມາຈາກບລັອກການຕິດຕັ້ງເຄື່ອງ
   

7. ໄປທີ່ການຕັ້ງຄ່າບັນຊີ, ເລືອກ Personal Access Token
   

8. ສ້າງໂທເຄັນການເຂົ້າເຖິງໃໝ່

   1. ຊື່ - ມັກ
   2. ອົງການຈັດຕັ້ງ - ປະຈຸບັນ
   3. ໃຊ້ໄດ້ສູງສຸດ 1 ປີ
   4. ຂອບເຂດ - ການຫຸ້ມຫໍ່ / ອ່ານແລະຂຽນ
      

9. ສຳເນົາ token ທີ່ສ້າງຂຶ້ນ - ຫຼັງຈາກປ່ອງຢ້ຽມ modal ຖືກປິດ, ມູນຄ່າຈະບໍ່ສາມາດໃຊ້ໄດ້

10. ໄປທີ່ການຕັ້ງຄ່າ repository ໃນ GitLab, ເລືອກການຕັ້ງຄ່າ CI / CD
    

11. ຂະຫຍາຍຕົວແປ, ເພີ່ມອັນໃໝ່

    1. ຊື່ - ໃດໆທີ່ບໍ່ມີຊ່ອງຫວ່າງ (ຈະມີຢູ່ໃນ shell ຄໍາສັ່ງ)
    2. ມູນຄ່າ - token ການເຂົ້າເຖິງຈາກວັກ 9
    3. ເລືອກຕົວແປ Mask
       

ນີ້ເຮັດສໍາເລັດການຕັ້ງຄ່າກ່ອນ.

ການກະກຽມກອບການກໍາຫນົດຄ່າ

ໂດຍຄ່າເລີ່ມຕົ້ນ, ການຕັ້ງຄ່າ CI/CD ໃນ GitLab ໃຊ້ໄຟລ໌ .gitlab-ci.yml ຈາກຮາກຂອງບ່ອນເກັບມ້ຽນ. ທ່ານ​ສາ​ມາດ​ກໍາ​ນົດ​ເສັ້ນ​ທາງ​ທີ່​ຕົນ​ເອງ​ຂອງ​ໄຟລ​໌​ນີ້​ໃນ​ການ​ຕັ້ງ​ຄ່າ repository​, ແຕ່​ໃນ​ກໍ​ລະ​ນີ​ນີ້​ມັນ​ບໍ່​ຈໍາ​ເປັນ​.

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້ຈາກສ່ວນຂະຫຍາຍ, ໄຟລ໌ມີການຕັ້ງຄ່າໃນຮູບແບບ YAML. ເອກະສານລາຍລະອຽດວ່າກະແຈໃດສາມາດບັນຈຸໄດ້ໃນລະດັບສູງສຸດຂອງການຕັ້ງຄ່າ, ແລະໃນແຕ່ລະລະດັບທີ່ຕິດກັນ.

ທໍາອິດ, ໃຫ້ເພີ່ມການເຊື່ອມຕໍ່ກັບຮູບພາບ docker ໃນໄຟລ໌ການຕັ້ງຄ່າ, ໃນທີ່ວຽກງານຕ່າງໆຈະຖືກປະຕິບັດ. ສໍາລັບນີ້ພວກເຮົາຊອກຫາ ໜ້າຮູບພາບຫຼັກ .Net ໃນ Docker Hub. ການ GitHub ມີຄູ່ມືລາຍລະອຽດກ່ຽວກັບຮູບພາບທີ່ຈະເລືອກເອົາສໍາລັບວຽກງານທີ່ແຕກຕ່າງກັນ. ຮູບພາບທີ່ມີ .Net Core 3.1 ແມ່ນເຫມາະສົມສໍາລັບພວກເຮົາທີ່ຈະສ້າງ, ດັ່ງນັ້ນກະລຸນາເພີ່ມແຖວທໍາອິດໃສ່ການຕັ້ງຄ່າ.

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

ໃນປັດຈຸບັນ, ເມື່ອທໍ່ຖືກເປີດຕົວຈາກບ່ອນເກັບຮູບພາບຂອງ Microsoft, ຮູບພາບທີ່ລະບຸຈະຖືກດາວໂຫລດ, ເຊິ່ງໃນຫນ້າວຽກທັງຫມົດຈາກການຕັ້ງຄ່າຈະຖືກປະຕິບັດ.

ຂັ້ນຕອນຕໍ່ໄປແມ່ນການເພີ່ມ ຂັ້ນຕອນຂອງການ's. ໂດຍຄ່າເລີ່ມຕົ້ນ, GitLab ກໍານົດ 5 ຂັ້ນຕອນ:

• .pre - ປະ​ຕິ​ບັດ​ເຖິງ​ທຸກ​ຂັ້ນ​ຕອນ​,
• .post - ປະ​ຕິ​ບັດ​ຫຼັງ​ຈາກ​ໄລ​ຍະ​ທັງ​ຫມົດ​,
• build - ທໍາອິດຫຼັງຈາກ .pre ເວທີ,
• test - ໄລ​ຍະ​ທີ​ສອງ​,
• deploy - ຂັ້ນ​ຕອນ​ທີ​ສາມ​.

ຢ່າງໃດກໍຕາມ, ບໍ່ມີຫຍັງຂັດຂວາງທ່ານຈາກການປະກາດພວກມັນຢ່າງຈະແຈ້ງ. ຄໍາສັ່ງທີ່ຂັ້ນຕອນຖືກລະບຸໄວ້ມີຜົນກະທົບຕໍ່ຄໍາສັ່ງທີ່ພວກເຂົາຖືກປະຕິບັດ. ເພື່ອຄວາມສົມບູນ, ໃຫ້ຕື່ມໃສ່ການຕັ້ງຄ່າ:

stages:
  - build
  - test
  - deploy

ສໍາລັບການ debugging, ມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບສະພາບແວດລ້ອມທີ່ວຽກງານໄດ້ຖືກປະຕິບັດ. ໃຫ້ເພີ່ມຊຸດຄໍາສັ່ງທົ່ວໂລກທີ່ຈະຖືກປະຕິບັດກ່ອນຫນ້າວຽກແຕ່ລະຄົນ before_script:

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

ມັນຍັງຄົງທີ່ຈະເພີ່ມຢ່າງຫນ້ອຍຫນຶ່ງຫນ້າວຽກເພື່ອວ່າເມື່ອຄໍາຫມັ້ນສັນຍາຖືກສົ່ງ, ທໍ່ຈະເລີ່ມຕົ້ນ. ຕອນນີ້, ໃຫ້ເພີ່ມໜ້າວຽກຫວ່າງເປົ່າເພື່ອສະແດງ:

dummy job:
  script:
    - echo ok

ພວກເຮົາເລີ່ມຕົ້ນການກວດສອບ, ພວກເຮົາໄດ້ຮັບຂໍ້ຄວາມວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນດີ, ພວກເຮົາຫມັ້ນສັນຍາ, ພວກເຮົາຍູ້, ພວກເຮົາເບິ່ງຜົນໄດ້ຮັບຢູ່ໃນເວັບໄຊທ໌ ... ແລະພວກເຮົາໄດ້ຮັບຄວາມຜິດພາດ script - 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

ພວກ​ເຮົາ​ໄດ້​ຮັບ​ການ​ບໍ່​ເປັນ​ປະ​ໂຫຍດ​ໂດຍ​ສະ​ເພາະ​ແມ່ນ​, ແຕ່​ຢ່າງ​ໃດ​ກໍ​ຕາມ​ທໍ່​ທີ່​ຖືກ​ຕ້ອງ​.

ການຕັ້ງຄ່າ triggers

ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າການກັ່ນຕອງຜົນກະທົບຕໍ່ບໍ່ໄດ້ຖືກກໍານົດສໍາລັບວຽກງານໃດຫນຶ່ງ, ທໍ່ຈະ ຢ່າງເຕັມທີ່ ຈະຖືກປະຕິບັດທຸກຄັ້ງທີ່ຄໍາຫມັ້ນສັນຍາຖືກ pushed ກັບ repository. ເນື່ອງຈາກນີ້ບໍ່ແມ່ນພຶດຕິກໍາທີ່ຕ້ອງການໂດຍທົ່ວໄປ, ພວກເຮົາຈະຕັ້ງຄ່າຕົວກອງຜົນກະທົບຕໍ່ວຽກງານ.

ການກັ່ນຕອງສາມາດຖືກຕັ້ງຄ່າໃນສອງຮູບແບບ: ເທົ່ານັ້ນ/ຍົກເວັ້ນ и ກົດລະບຽບ. ໂດຍຫຍໍ້, only/except ອະນຸຍາດໃຫ້ທ່ານຕັ້ງຄ່າການກັ່ນຕອງໂດຍ triggers (merge_request, ສໍາລັບການຍົກຕົວຢ່າງ - ກໍານົດວຽກງານທີ່ຈະປະຕິບັດທຸກຄັ້ງທີ່ຄໍາຮ້ອງຂໍດຶງໄດ້ຖືກສ້າງຂື້ນແລະທຸກຄັ້ງ commits ຖືກສົ່ງໄປຫາສາຂາທີ່ເປັນແຫຼ່ງໃນຄໍາຮ້ອງຂໍ merge) ແລະຊື່ສາຂາ (ລວມທັງການນໍາໃຊ້ການສະແດງອອກປົກກະຕິ); rules ອະນຸຍາດໃຫ້ທ່ານປັບແຕ່ງຊຸດຂອງເງື່ອນໄຂແລະ, ທາງເລືອກ, ປ່ຽນເງື່ອນໄຂການປະຕິບັດວຽກງານໂດຍອີງຕາມຜົນສໍາເລັດຂອງວຽກງານທີ່ຜ່ານມາ (when ໃນ GitLab CI/CD).

ຂໍໃຫ້ຈື່ຈໍາຊຸດຂອງຄວາມຕ້ອງການ - ການປະກອບແລະການທົດສອບພຽງແຕ່ສໍາລັບການຮ້ອງຂໍການຜະສົມຜະສານ, ການຫຸ້ມຫໍ່ແລະການສົ່ງກັບ Azure DevOps - ສໍາລັບການຮ້ອງຂໍການລວມແລະ pushes ກັບແມ່ບົດ, ການຜະລິດເອກະສານ - ສໍາລັບການ pushes ກັບແມ່ບົດ.

ທໍາອິດ, ໃຫ້ຕັ້ງຄ່າວຽກງານການສ້າງລະຫັດໂດຍການເພີ່ມກົດລະບຽບທີ່ໄຟໄຫມ້ພຽງແຕ່ໃນຄໍາຮ້ອງຂໍການລວມ:

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

ໃນລະຫວ່າງວຽກງານ build job ພວກ​ເຮົາ​ຈະ​ມີ​ການ​ກໍ່​ສ້າງ​ຂອງ​ປອມ​ທີ່​ສາ​ມາດ​ນໍາ​ໃຊ້​ຄືນ​ໃຫມ່​ໃນ​ວຽກ​ງານ​ຕໍ່​ໄປ​. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມເສັ້ນທາງໃນການຕັ້ງຄ່າຫນ້າວຽກ, ໄຟລ໌ທີ່ເຈົ້າຈະຕ້ອງບັນທຶກແລະໃຊ້ຄືນໃຫມ່ໃນຫນ້າວຽກຕໍ່ໄປນີ້, ໄປຫາທີ່ສໍາຄັນ. artifacts:

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

Paths ສະຫນັບສະຫນູນ wildcards, ເຊິ່ງແນ່ນອນເຮັດໃຫ້ພວກເຂົາງ່າຍຕໍ່ການຕັ້ງຄ່າ.

ຖ້າວຽກງານຫນຶ່ງສ້າງສິ່ງປະດິດ, ຫຼັງຈາກນັ້ນແຕ່ລະວຽກງານຕໍ່ມາຈະສາມາດເຂົ້າເຖິງພວກມັນໄດ້ - ພວກມັນຈະຕັ້ງຢູ່ຕາມເສັ້ນທາງດຽວກັນທີ່ກ່ຽວຂ້ອງກັບຮາກຂອງ repository ທີ່ເກັບກໍາຈາກວຽກງານຕົ້ນສະບັບ. ສິ່ງປະດິດຍັງມີໃຫ້ດາວໂຫຼດຢູ່ໃນເວັບໄຊ.

ຕອນນີ້ພວກເຮົາມີກອບການຕັ້ງຄ່າພ້ອມ (ແລະທົດສອບ), ພວກເຮົາສາມາດດໍາເນີນການຂຽນ scripts ສໍາລັບວຽກງານຕົວຈິງ.

ພວກເຮົາຂຽນສະຄິບ

ບາງທີ, ໃນຄັ້ງຫນຶ່ງ, ໃນ galaxy ໄກ, ຫ່າງໄກ, ໂຄງການກໍ່ສ້າງ (ລວມທັງຢູ່ໃນ .net) ຈາກເສັ້ນຄໍາສັ່ງແມ່ນເຈັບປວດ. ໃນປັດຈຸບັນທ່ານສາມາດສ້າງ, ທົດສອບແລະເຜີຍແຜ່ໂຄງການໃນ 3 ທີມ:

dotnet build
dotnet test
dotnet pack

ຕາມທໍາມະຊາດ, ມີບາງ nuances ເນື່ອງຈາກການທີ່ພວກເຮົາຈະ complicate ຄໍາສັ່ງບາງຢ່າງ.

1. ພວກເຮົາຕ້ອງການການສ້າງການປ່ອຍ, ບໍ່ແມ່ນການສ້າງ debug, ດັ່ງນັ້ນພວກເຮົາເພີ່ມໃສ່ແຕ່ລະຄໍາສັ່ງ -c Release
2. ໃນເວລາທີ່ການທົດສອບ, ພວກເຮົາຕ້ອງການທີ່ຈະເກັບກໍາຂໍ້ມູນການຄຸ້ມຄອງລະຫັດ, ດັ່ງນັ້ນພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ລວມເອົາການວິເຄາະການຄຸ້ມຄອງໃນຫ້ອງສະຫມຸດການທົດສອບ:
   1. ເພີ່ມຊຸດໃສ່ຫ້ອງສະໝຸດທົດສອບທັງໝົດ coverlet.msbuild: dotnet add package coverlet.msbuild ຈາກໂຟນເດີໂຄງການ
   2. ເພີ່ມໃສ່ຄໍາສັ່ງແລ່ນການທົດສອບ /p:CollectCoverage=true
   3. ເພີ່ມກະແຈໃສ່ການຕັ້ງຄ່າໜ້າວຽກການທົດສອບເພື່ອໃຫ້ໄດ້ຜົນການຄອບຄຸມ (ເບິ່ງຂ້າງລຸ່ມນີ້)
3. ເມື່ອບັນຈຸລະຫັດເຂົ້າໄປໃນຊຸດ nuget, ກໍານົດລາຍການຜົນຜະລິດສໍາລັບຊຸດ: -o .

ເກັບກໍາຂໍ້ມູນການຄຸ້ມຄອງລະຫັດ

ຫຼັງຈາກແລ່ນການທົດສອບ, Coverlet prints ແລ່ນສະຖິຕິໄປຫາ console:

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 ອະນຸຍາດໃຫ້ທ່ານລະບຸການສະແດງອອກປົກກະຕິເພື່ອໃຫ້ໄດ້ຮັບສະຖິຕິ, ເຊິ່ງຫຼັງຈາກນັ້ນສາມາດໄດ້ຮັບໃນຮູບແບບຂອງ badge. ການສະແດງຜົນປົກກະຕິແມ່ນລະບຸໄວ້ໃນການຕັ້ງຄ່າໜ້າວຽກດ້ວຍປຸ່ມກົດ coverage; ການສະແດງຜົນຕ້ອງມີກຸ່ມ capture, ມູນຄ່າທີ່ຈະຖືກສົ່ງໄປຫາ badge:

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

ໃນທີ່ນີ້ພວກເຮົາໄດ້ຮັບສະຖິຕິຈາກເສັ້ນທີ່ມີການຄຸ້ມຄອງເສັ້ນທັງຫມົດ.

ເຜີຍແຜ່ແພັກເກດ ແລະເອກະສານ

ທັງສອງການປະຕິບັດແມ່ນກໍານົດສໍາລັບຂັ້ນຕອນສຸດທ້າຍຂອງທໍ່ - ນັບຕັ້ງແຕ່ການປະກອບແລະການທົດສອບໄດ້ຜ່ານໄປ, ພວກເຮົາສາມາດແບ່ງປັນການພັດທະນາຂອງພວກເຮົາກັບໂລກ.

ທໍາອິດ, ພິຈາລະນາການເຜີຍແຜ່ກັບແຫຼ່ງຊຸດ:

1. ຖ້າໂຄງການບໍ່ມີໄຟລ໌ການຕັ້ງຄ່າ nuget (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 - ຊື່ຂອງຕົວແປທີ່ມີ token ການເຂົ້າເຖິງທີ່ເພີ່ມໃສ່ GitLab ("ການກະກຽມບັນຊີ", ຫນ້າ 11). ຕາມທໍາມະຊາດ, ໃນຮູບແບບ $variableName
   5. -StorePasswordInClearText - hack ເພື່ອ​ຂ້າມ​ການ​ເຂົ້າ​ເຖິງ​ຂໍ້​ຜິດ​ພາດ​ຖືກ​ປະ​ຕິ​ເສດ (ຂ້ອຍບໍ່ແມ່ນຄົນທຳອິດທີ່ຈະກ້າວຂຶ້ນຄ້ອຍນີ້)
   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. ທໍາອິດ, ໃນ repository, ໃນສາຂາຕົ້ນສະບັບ, ພວກເຮົາເລີ່ມຕົ້ນໂຄງການ docfx. ເພື່ອເຮັດສິ່ງນີ້, ດໍາເນີນການຄໍາສັ່ງຈາກຮາກ docfx init ແລະໂຕ້ຕອບກໍານົດຕົວກໍານົດການທີ່ສໍາຄັນສໍາລັບການສ້າງເອກະສານ. ລາຍລະອຽດຂອງການຕິດຕັ້ງໂຄງການຕໍາ່ສຸດທີ່ ທີ່ນີ້.
   1. ໃນເວລາທີ່ກໍາຫນົດຄ່າ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະລະບຸໄດເລກະທໍລີຜົນຜະລິດ ..public - GitLab ໂດຍຄ່າເລີ່ມຕົ້ນຈະເອົາເນື້ອໃນຂອງໂຟນເດີສາທາລະນະຢູ່ໃນຮາກຂອງ repository ເປັນແຫຼ່ງສໍາລັບ Pages. ເນື່ອງຈາກວ່າ ໂຄງ​ການ​ດັ່ງ​ກ່າວ​ຈະ​ໄດ້​ຮັບ​ການ​ຕັ້ງ​ຢູ່​ໃນ​ໂຟນ​ເດີ​ທີ່​ຕັ້ງ​ຢູ່​ໃນ repository - ເພີ່ມ​ຜົນ​ຜະ​ລິດ​ໃນ​ລະ​ດັບ​ຂຶ້ນ​ໃນ​ເສັ້ນ​ທາງ​.
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. Node artifacts:

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, ເນື່ອງຈາກວ່າ ໃນ​ຮູບ​ແບບ​, ການ​ຊອກ​ຫາ​ຕົ້ນ​ໄມ້​ລະ​ບົບ​ບໍ່​ໄດ້​ເຮັດ​ວຽກ​.
2. metadata.src.files: ["**/*.csproj"] - ຮູບແບບທົ່ວໂລກ, ພວກເຮົາເກັບກໍາໂຄງການ C # ທັງຫມົດຈາກໄດເລກະທໍລີທັງຫມົດ.
3. metadata.src.exclude: ["*.tests*/**"] - ຮູບແບບທົ່ວໂລກ, ຍົກເວັ້ນທຸກສິ່ງທຸກຢ່າງຈາກໂຟນເດີທີ່ມີ .tests ໃນຫົວຂໍ້

Subtotal

ການຕັ້ງຄ່າທີ່ງ່າຍດາຍດັ່ງກ່າວສາມາດສ້າງໄດ້ໃນເວລາພຽງແຕ່ເຄິ່ງຊົ່ວໂມງແລະສອງສາມຈອກກາເຟ, ເຊິ່ງຈະຊ່ວຍໃຫ້ທ່ານສາມາດກວດເບິ່ງວ່າລະຫັດຖືກສ້າງຂຶ້ນແລະການທົດສອບຜ່ານ, ສ້າງຊຸດໃຫມ່, ປັບປຸງເອກະສານແລະກະລຸນາຕາທີ່ສວຍງາມ. badges ໃນ 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:

ຂ້ອຍສ້າງປ້າຍທີ່ມີການເຊື່ອມຕໍ່ກັບເອກະສານໃນເວທີ shields.io - ທຸກສິ່ງທຸກຢ່າງແມ່ນຂ້ອນຂ້າງກົງໄປກົງມາຢູ່ທີ່ນັ້ນ, ທ່ານສາມາດສ້າງປ້າຍຂອງທ່ານເອງແລະໄດ້ຮັບມັນໂດຍໃຊ້ຄໍາຮ້ອງຂໍ.

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

Azure DevOps Artifacts ຍັງອະນຸຍາດໃຫ້ທ່ານສ້າງ badges ສໍາລັບແພັກເກັດທີ່ມີສະບັບຫລ້າສຸດ. ເພື່ອເຮັດສິ່ງນີ້, ໃນແຫຼ່ງທີ່ຢູ່ໃນເວັບໄຊທ໌ Azure DevOps, ທ່ານຈໍາເປັນຕ້ອງຄລິກໃສ່ ສ້າງ badge ສໍາລັບຊຸດທີ່ເລືອກແລະຄັດລອກ markup markup:

ເພີ່ມຄວາມງາມ

ເນັ້ນໃສ່ຊິ້ນສ່ວນການຕັ້ງຄ່າທົ່ວໄປ

ໃນຂະນະທີ່ຂຽນການຕັ້ງຄ່າແລະການຄົ້ນຫາຜ່ານເອກະສານ, ຂ້າພະເຈົ້າໄດ້ພົບເຫັນລັກສະນະທີ່ຫນ້າສົນໃຈຂອງ YAML - reusing fragments .

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້ຈາກການຕັ້ງຄ່າຫນ້າວຽກ, ພວກເຂົາທັງຫມົດຕ້ອງການແທັກ windows ຢູ່ທີ່ຕົວແລ່ນ, ແລະຖືກກະຕຸ້ນເມື່ອມີການຮ້ອງຂໍການລວມກັນຖືກສົ່ງໄປຫາແມ່ບົດ / ສ້າງ (ຍົກເວັ້ນເອກະສານ). ໃຫ້ເພີ່ມນີ້ໃສ່ຊິ້ນສ່ວນທີ່ພວກເຮົາຈະໃຊ້ຄືນ:

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

ແລະຕອນນີ້ພວກເຮົາສາມາດໃສ່ຊິ້ນສ່ວນທີ່ປະກາດໄວ້ກ່ອນຫນ້ານີ້ໃນຄໍາອະທິບາຍຫນ້າວຽກ:

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

ຊື່ຊິ້ນສ່ວນຕ້ອງເລີ່ມຕົ້ນດ້ວຍຈຸດ, ເພື່ອບໍ່ໃຫ້ຖືກຕີຄວາມໝາຍວ່າເປັນໜ້າວຽກ.

ການສ້າງແພັກເກດ

ເມື່ອສ້າງຊຸດ, compiler ກວດເບິ່ງການປ່ຽນເສັ້ນຄໍາສັ່ງ, ແລະໃນເວລາທີ່ບໍ່ມີ, ໄຟລ໌ໂຄງການ; ເມື່ອມັນພົບເວີຊັ່ນ node, ມັນໃຊ້ເວລາມູນຄ່າຂອງມັນເທົ່າກັບເວີຊັນຂອງແພັກເກັດທີ່ຖືກສ້າງຂຶ້ນ. ມັນປະກົດວ່າເພື່ອສ້າງຊຸດທີ່ມີຮຸ່ນໃຫມ່, ທ່ານຈໍາເປັນຕ້ອງປັບປຸງມັນຢູ່ໃນໄຟລ໌ໂຄງການຫຼືຜ່ານມັນເປັນການໂຕ້ຖຽງເສັ້ນຄໍາສັ່ງ.

ຂໍໃຫ້ເພີ່ມລາຍການທີ່ຢາກໄດ້ອີກອັນໜຶ່ງ - ໃຫ້ຕົວເລກນ້ອຍສອງຕົວເລກໃນຮຸ່ນເປັນປີ ແລະວັນທີສ້າງຂອງແພັກເກັດ, ແລະເພີ່ມເວີຊັນທີ່ປ່ອຍອອກມາກ່ອນ. ແນ່ນອນ, ທ່ານສາມາດເພີ່ມຂໍ້ມູນນີ້ເຂົ້າໄປໃນໄຟລ໌ໂຄງການແລະກວດເບິ່ງກ່ອນທີ່ຈະສົ່ງແຕ່ລະຄັ້ງ - ແຕ່ທ່ານຍັງສາມາດເຮັດມັນຢູ່ໃນທໍ່, ເກັບກໍາສະບັບຂອງຊຸດຈາກສະພາບການແລະຜ່ານມັນໂດຍຜ່ານການໂຕ້ຖຽງເສັ້ນຄໍາສັ່ງ.

ໃຫ້ຂອງຕົກລົງກັນວ່າຖ້າຫາກວ່າຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາປະກອບດ້ວຍເສັ້ນຄ້າຍຄື 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