ວິທີທີ່ພວກເຮົາປ່ອຍຊອບແວ patches ໃນ GitLab

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

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

ແຕ່, ຕາມການປະຕິບັດສະແດງໃຫ້ເຫັນ, ການພັດທະນາຊອບແວແມ່ນບໍ່ຄ່ອຍບໍ່ມີຂໍ້ບົກພ່ອງ. ເມື່ອພົບຂໍ້ບົກພ່ອງ ຫຼືຄວາມອ່ອນແອດ້ານຄວາມປອດໄພ, ຜູ້ຈັດການການປ່ອຍຕົວໃນທີມຈັດສົ່ງຈະສ້າງແພັກໃຫ້ຜູ້ໃຊ້ຂອງພວກເຮົາດ້ວຍການຕິດຕັ້ງຂອງເຂົາເຈົ້າ. Gitlab.com ຖືກປັບປຸງໃນລະຫວ່າງການຂະບວນການ CD. ພວກເຮົາໂທຫາຂະບວນການ CD ອັດຕະໂນມັດນີ້ເພື່ອຫຼີກເວັ້ນການສັບສົນກັບຄຸນນະສົມບັດ CD ໃນ GitLab. ຂະບວນການນີ້ສາມາດລວມເອົາຄໍາແນະນໍາຈາກການຮ້ອງຂໍດຶງທີ່ສົ່ງໂດຍຜູ້ໃຊ້, ລູກຄ້າ, ແລະທີມງານພັດທະນາພາຍໃນຂອງພວກເຮົາ, ດັ່ງນັ້ນການແກ້ໄຂບັນຫາທີ່ຫນ້າເບື່ອຂອງການປ່ອຍ patches ໄດ້ຖືກແກ້ໄຂໃນສອງວິທີທີ່ແຕກຕ່າງກັນຫຼາຍ.

«ພວກເຮົາຮັບປະກັນວ່າທຸກສິ່ງທີ່ຜູ້ພັດທະນາສ້າງແມ່ນຖືກນຳໃຊ້ກັບທຸກສະພາບແວດລ້ອມທຸກໆມື້ ກ່ອນທີ່ຈະນຳມັນອອກສູ່ GitLab.com", ອະທິບາຍ Marin Jankovki, ຜູ້ຈັດການດ້ານວິຊາການອາວຸໂສ, ພະແນກພື້ນຖານໂຄງລ່າງ. "ຄິດວ່າການປ່ອຍຕົວສໍາລັບການຕິດຕັ້ງຂອງເຈົ້າເປັນພາບຖ່າຍສໍາລັບການຕິດຕັ້ງ gitlab.com, ເຊິ່ງພວກເຮົາໄດ້ເພີ່ມຂັ້ນຕອນແຍກຕ່າງຫາກເພື່ອສ້າງຊຸດເພື່ອໃຫ້ຜູ້ໃຊ້ຂອງພວກເຮົາສາມາດນໍາໃຊ້ມັນໃນການຕິດຕັ້ງຂອງພວກເຂົາ.".

ໂດຍບໍ່ຄໍານຶງເຖິງ bug ຫຼືຊ່ອງໂຫວ່, ລູກຄ້າ gitlab.com ຈະໄດ້ຮັບການແກ້ໄຂໃນໄວໆນີ້ຫຼັງຈາກທີ່ພວກເຂົາຖືກເຜີຍແຜ່, ເຊິ່ງເປັນຜົນປະໂຫຍດຂອງຂະບວນການ CD ອັດຕະໂນມັດ. Patches ສໍາລັບຜູ້ໃຊ້ທີ່ມີການຕິດຕັ້ງຂອງຕົນເອງຮຽກຮ້ອງໃຫ້ມີການກະກຽມແຍກຕ່າງຫາກໂດຍຜູ້ຈັດການການປ່ອຍ.

ທີມງານຈັດສົ່ງກໍາລັງເຮັດວຽກຫນັກເພື່ອອັດຕະໂນມັດຂະບວນການສ່ວນໃຫຍ່ທີ່ກ່ຽວຂ້ອງກັບການສ້າງການປ່ອຍເພື່ອຫຼຸດຜ່ອນ MTTP (ຫມາຍຄວາມວ່າເວລາໃນການຜະລິດ, ເຊັ່ນ: ເວລາທີ່ໃຊ້ໃນການຜະລິດ), ໄລຍະເວລາຈາກການດໍາເນີນການຮ້ອງຂໍການລວມກັນໂດຍຜູ້ພັດທະນາເພື່ອນໍາໃຊ້ໃນ gitlab.com.

«ເປົ້າຫມາຍຂອງທີມງານຈັດສົ່ງແມ່ນເພື່ອເຮັດໃຫ້ແນ່ໃຈວ່າພວກເຮົາສາມາດຍ້າຍໄວຂຶ້ນເປັນບໍລິສັດ, ຫຼືຢ່າງຫນ້ອຍເຮັດໃຫ້ການຈັດສົ່ງຄົນເຮັດວຽກໄວ, ສິດ.?, Marin ເວົ້າ.

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

ຜູ້ຈັດການການປ່ອຍຕົວເຮັດຫຍັງ?

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

ການປ່ອຍການຕິດຕັ້ງດ້ວຍຕົນເອງແລະການປ່ອຍ gitlab.com ໃຊ້ຂະບວນການເຮັດວຽກທີ່ຄ້າຍຄືກັນແຕ່ດໍາເນີນການໃນເວລາທີ່ແຕກຕ່າງກັນ, Marin ອະທິບາຍ.

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

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

ຜູ້​ຈັດ​ການ​ປ່ອຍ​ຕົວ​ຕ້ອງ​ຕັດ​ສິນ​ໃຈ​ວ່າ​ຈະ​ກະ​ກຽມ​ການ​ແກ້​ໄຂ​, ຫຼື​ໃນ​ເວ​ລາ​ທີ່​ຈະ​ນໍາ​ໃຊ້​ມັນ - ແລະ​ນີ້​ແມ່ນ​ສູງ​ຂຶ້ນ​ກັບ​ສະ​ພາບ​ການ​ຂອງ​ການ​, "ໃນ​ຂະ​ນະ​ດຽວ​ກັນ, ເຄື່ອງ​ຈັກ​ຍັງ​ບໍ່​ດີ​ໃນ​ການ​ຄຸ້ມ​ຄອງ​ສະ​ພາບ​ການ​ເປັນ​ຄົນ" Marin ເວົ້າ.

ມັນທັງຫມົດກ່ຽວກັບການແກ້ໄຂ

ແຜ່ນແພແມ່ນຫຍັງ ແລະເປັນຫຍັງພວກເຮົາຕ້ອງການພວກມັນ?

ຜູ້ຈັດການການປ່ອຍຕົວຕັດສິນໃຈວ່າຈະປ່ອຍການແກ້ໄຂໂດຍອີງໃສ່ຄວາມຮຸນແຮງຂອງແມງໄມ້.

ຄວາມຜິດພາດແຕກຕ່າງກັນໄປຕາມຄວາມຮຸນແຮງຂອງມັນ. ດັ່ງນັ້ນຄວາມຜິດພາດ S4 ຫຼື S3 ສາມາດເປັນ stylistic, ເຊັ່ນ pixels ຫຼື icon displacement. ນີ້ບໍ່ມີຄວາມສໍາຄັນຫນ້ອຍ, ແຕ່ບໍ່ມີຜົນກະທົບທີ່ສໍາຄັນຕໍ່ຂະບວນການເຮັດວຽກຂອງໃຜ, ຊຶ່ງຫມາຍຄວາມວ່າຄວາມເປັນໄປໄດ້ທີ່ການແກ້ໄຂຈະຖືກສ້າງຂື້ນສໍາລັບຄວາມຜິດພາດ S3 ຫຼື S4 ດັ່ງກ່າວແມ່ນຫນ້ອຍ, Marin ອະທິບາຍ.

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

ເມື່ອ patch ສໍາລັບຊ່ອງໂຫວ່ S1 ຫຼື S2 ພ້ອມແລ້ວ, ຜູ້ຈັດການການປ່ອຍຈະເລີ່ມປ່ອຍ patch.

ຕົວຢ່າງເຊັ່ນ, patch GitLab 12.10.1 ໄດ້ຖືກສ້າງຂື້ນຫຼັງຈາກບັນຫາການຂັດຂວາງຫຼາຍໆຄັ້ງໄດ້ຖືກລະບຸແລະນັກພັດທະນາໄດ້ແກ້ໄຂບັນຫາພື້ນຖານທີ່ເຮັດໃຫ້ເກີດພວກມັນ. ຜູ້ຈັດການການປ່ອຍຕົວໄດ້ປະເມີນຄວາມຖືກຕ້ອງຂອງລະດັບຄວາມຮຸນແຮງທີ່ໄດ້ຮັບມອບຫມາຍ, ແລະຫຼັງຈາກການຢືນຢັນ, ຂະບວນການປ່ອຍການແກ້ໄຂໄດ້ຖືກເປີດຕົວ, ເຊິ່ງກຽມພ້ອມພາຍໃນ XNUMX ຊົ່ວໂມງຫຼັງຈາກບັນຫາການຂັດຂວາງໄດ້ຖືກຄົ້ນພົບ.

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

ຜູ້ຈັດການການປ່ອຍຕົວສ້າງແພັດ

ພວກເຮົາໃຊ້ GitLab CI ແລະຄຸນສົມບັດອື່ນໆເຊັ່ນ: ChatOps ຂອງພວກເຮົາເພື່ອສ້າງ patches. ຜູ້ຈັດການການປ່ອຍຕົວເລີ່ມຕົ້ນການປ່ອຍການແກ້ໄຂໂດຍການເປີດໃຊ້ທີມ ChatOps ໃນຊ່ອງທາງພາຍໃນຂອງພວກເຮົາ #releases ໃນ Slack.

/chatops run release prepare 12.10.1

ChatOps ເຮັດວຽກພາຍໃນ Slack ເພື່ອກະຕຸ້ນເຫດການຕ່າງໆ, ເຊິ່ງຫຼັງຈາກນັ້ນຈະຖືກປຸງແຕ່ງແລະປະຕິບັດໂດຍ GitLab. ຕົວຢ່າງ, ທີມງານຈັດສົ່ງໄດ້ຕັ້ງ ChatOps ເພື່ອອັດຕະໂນມັດສິ່ງຕ່າງໆເພື່ອປົດປ່ອຍ patches.

ເມື່ອຜູ້ຈັດການການປ່ອຍຕົວເລີ່ມຕົ້ນທີມ ChatOps ໃນ Slack, ສ່ວນທີ່ເຫຼືອຂອງການເຮັດວຽກຈະເກີດຂື້ນໂດຍອັດຕະໂນມັດໃນ GitLab ໂດຍໃຊ້ CICD. ມີການສື່ສານສອງທາງລະຫວ່າງ ChatOps ໃນ Slack ແລະ GitLab ໃນລະຫວ່າງຂະບວນການປ່ອຍຕົວຍ້ອນວ່າຜູ້ຈັດການການປ່ອຍຕົວກະຕຸ້ນບາງຂັ້ນຕອນທີ່ສໍາຄັນໃນຂະບວນການ.

ວິດີໂອຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນຂະບວນການດ້ານວິຊາການຂອງການກະກຽມ patch ສໍາລັບ GitLab.

ວິທີການນຳໃຊ້ອັດຕະໂນມັດເຮັດວຽກຢູ່ໃນ gitlab.com

ຂະບວນການແລະເຄື່ອງມືທີ່ໃຊ້ໃນການປັບປຸງ gitlab.com ແມ່ນຄ້າຍຄືກັນກັບທີ່ໃຊ້ເພື່ອສ້າງ patches. ການປັບປຸງ gitlab.com ຮຽກຮ້ອງໃຫ້ມີການເຮັດວຽກຄູ່ມືຫນ້ອຍລົງຈາກທັດສະນະຂອງຜູ້ຈັດການການປ່ອຍ.

ແທນ​ທີ່​ຈະ​ແລ່ນ​ການ​ນໍາ​ໃຊ້​ການ​ນໍາ​ໃຊ້ ChatOps, ພວກ​ເຮົາ​ນໍາ​ໃຊ້​ຄຸນ​ສົມ​ບັດ CI ເຊັ່ນ​:. ທໍ່​ທີ່​ກໍາ​ນົດ​ໄວ້​, ເຊິ່ງຜູ້ຈັດການການປ່ອຍຕົວສາມາດກໍານົດການປະຕິບັດບາງຢ່າງທີ່ຈະປະຕິບັດໃນເວລາທີ່ກໍານົດໄວ້. ແທນທີ່ຈະເປັນຂະບວນການຄູ່ມື, ມີທໍ່ທີ່ເຮັດວຽກເປັນໄລຍະຫນຶ່ງຊົ່ວໂມງທີ່ດາວໂຫລດການປ່ຽນແປງໃຫມ່ທີ່ເຮັດກັບໂຄງການ GitLab, ຫຸ້ມຫໍ່ພວກມັນແລະກໍານົດເວລາຂອງການນໍາໃຊ້, ແລະດໍາເນີນການທົດສອບອັດຕະໂນມັດ, QA ແລະຂັ້ນຕອນທີ່ຈໍາເປັນອື່ນໆ.

Marin ກ່າວວ່າ "ດັ່ງນັ້ນພວກເຮົາມີການປະຕິບັດຫຼາຍຢ່າງທີ່ເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມທີ່ແຕກຕ່າງກັນກ່ອນ gitlab.com, ແລະຫຼັງຈາກສະພາບແວດລ້ອມເຫຼົ່ານັ້ນຢູ່ໃນສະພາບທີ່ດີແລະການທົດສອບສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບທີ່ດີ, ຜູ້ຈັດການການປ່ອຍຕົວເລີ່ມຕົ້ນການປະຕິບັດການຈັດຕັ້ງປະຕິບັດ gitlab.com," Marin ເວົ້າ.

ເທກໂນໂລຍີ CICD ສໍາລັບການສະຫນັບສະຫນູນການປັບປຸງ gitlab.com ອັດຕະໂນມັດຂະບວນການທັງຫມົດເຖິງຈຸດທີ່ຜູ້ຈັດການການປ່ອຍຕົວຕ້ອງເປີດຕົວການນໍາໃຊ້ສະພາບແວດລ້ອມການຜະລິດດ້ວຍຕົນເອງກັບ gitlab.com.

Marin ເຂົ້າໄປໃນລາຍລະອຽດກ່ຽວກັບຂະບວນການປັບປຸງ gitlab.com ໃນວິດີໂອຂ້າງລຸ່ມນີ້.

ທີມງານຈັດສົ່ງຈະເຮັດຫຍັງອີກ?

ຄວາມແຕກຕ່າງທີ່ ສຳ ຄັນລະຫວ່າງຂະບວນການປັບປຸງ gitlab.com ແລະການປົດປ່ອຍ patches ໃຫ້ກັບລູກຄ້າໃນເຮືອນແມ່ນວ່າຂະບວນການສຸດທ້າຍຕ້ອງການເວລາແລະການເຮັດວຽກຄູ່ມືຫຼາຍຂື້ນຈາກຜູ້ຈັດການປ່ອຍ.

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

ຫນຶ່ງໃນເປົ້າຫມາຍໄລຍະສັ້ນຂອງທີມງານຈັດສົ່ງແມ່ນການຫຼຸດຜ່ອນຈໍານວນການເຮັດວຽກຄູ່ມືໃນສ່ວນຂອງຜູ້ຈັດການການປ່ອຍເພື່ອເລັ່ງການປ່ອຍຕົວ. ທີມງານກໍາລັງເຮັດວຽກເພື່ອເຮັດໃຫ້ງ່າຍ, ປັບປຸງ, ແລະອັດຕະໂນມັດຂະບວນການປ່ອຍ, ເຊິ່ງຈະຊ່ວຍໃຫ້ໄດ້ຮັບການແກ້ໄຂບັນຫາທີ່ມີຄວາມຮຸນແຮງຕ່ໍາ (S3 ແລະ S4, ປະມານ ນັກແປ). ການສຸມໃສ່ຄວາມໄວແມ່ນຕົວຊີ້ວັດການປະຕິບັດທີ່ສໍາຄັນ: ມັນຈໍາເປັນຕ້ອງຫຼຸດຜ່ອນ MTTP - ເວລາຈາກການໄດ້ຮັບຄໍາຮ້ອງຂໍການຜະສົມຜະສານກັບການນໍາໃຊ້ຜົນໄດ້ຮັບໄປຫາ gitlab.com - ຈາກປັດຈຸບັນ 50 ຊົ່ວໂມງເປັນ 8 ຊົ່ວໂມງ.

ທີມງານຈັດສົ່ງຍັງເຮັດວຽກກ່ຽວກັບການເຄື່ອນຍ້າຍ gitlab.com ໄປສູ່ໂຄງສ້າງພື້ນຖານຂອງ Kubernetes.

NB ຂອງບັນນາທິການ: ຖ້າທ່ານໄດ້ຍິນກ່ຽວກັບເທກໂນໂລຍີ Kubernetes ແລ້ວ (ແລະຂ້ອຍບໍ່ມີຄວາມສົງໃສວ່າເຈົ້າມີ), ແຕ່ຍັງບໍ່ທັນໄດ້ສໍາຜັດກັບມືຂອງເຈົ້າ, ຂ້ອຍຂໍແນະນໍາໃຫ້ມີສ່ວນຮ່ວມໃນຫຼັກສູດອອນໄລນ໌ ຖານ Kubernetes, ເຊິ່ງຈະຈັດຂຶ້ນໃນເດືອນກັນຍາ 28-30, ແລະ Kubernetes Megaເຊິ່ງຈະຈັດຂຶ້ນໃນວັນທີ 14-16 ຕຸລານີ້. ນີ້ຈະຊ່ວຍໃຫ້ທ່ານສາມາດນໍາທາງແລະເຮັດວຽກກັບເຕັກໂນໂລຢີຢ່າງຫມັ້ນໃຈ.

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

ແນວຄວາມຄິດຫຼືຄໍາແນະນໍາໃດໆສໍາລັບພວກເຮົາ?

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

ແຫຼ່ງຂໍ້ມູນ: www.habr.com