ຈາກສະຄຣິບໄປຫາເວທີຂອງພວກເຮົາເອງ: ວິທີທີ່ພວກເຮົາພັດທະນາອັດຕະໂນມັດຢູ່ CIAN

ໃນ RIT 2019, ເພື່ອນຮ່ວມງານຂອງພວກເຮົາ Alexander Korotkov ໄດ້ ລາຍງານ ກ່ຽວ​ກັບ​ການ​ພັດ​ທະ​ນາ​ອັດ​ຕະ​ໂນ​ມັດ​ຢູ່ CIAN​: ເພື່ອ​ເຮັດ​ໃຫ້​ຊີ​ວິດ​ແລະ​ການ​ເຮັດ​ວຽກ​ງ່າຍ​ດາຍ​, ພວກ​ເຮົາ​ນໍາ​ໃຊ້​ເວ​ທີ Integro ຂອງ​ພວກ​ເຮົາ​ເອງ​. ມັນຕິດຕາມວົງຈອນຊີວິດຂອງວຽກງານ, ບັນເທົາການພັດທະນາຂອງການດໍາເນີນງານປົກກະຕິແລະຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຂອງແມງໄມ້ໃນການຜະລິດ. ໃນບົດຂຽນນີ້, ພວກເຮົາຈະຕື່ມບົດລາຍງານຂອງ Alexander ແລະບອກທ່ານວ່າພວກເຮົາໄດ້ມາຈາກສະຄິບງ່າຍໆເພື່ອປະສົມປະສານຜະລິດຕະພັນແຫຼ່ງເປີດໂດຍຜ່ານເວທີຂອງພວກເຮົາເອງແລະສິ່ງທີ່ທີມງານອັດຕະໂນມັດຂອງພວກເຮົາເຮັດ.
 

ລະດັບສູນ

"ມັນບໍ່ມີລະດັບສູນ, ຂ້ອຍບໍ່ຮູ້ເລື່ອງດັ່ງກ່າວ"
ອາຈານ Shifu ຈາກຮູບເງົາ "Kung Fu Panda"

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

ໃນເວລານັ້ນ, ພວກເຮົາມີ monolith ຂະຫນາດໃຫຍ່ຂອງ Python, C# ແລະ PHP, ຖືກນໍາໃຊ້ໃນເຄື່ອງແມ່ຂ່າຍຂອງ Linux / Windows. ເພື່ອນຳໃຊ້ monster ນີ້, ພວກເຮົາມີຊຸດສະຄຣິບທີ່ພວກເຮົາແລ່ນດ້ວຍຕົນເອງ. ນອກຈາກນີ້ຍັງມີການປະກອບຂອງ monolith, ເຊິ່ງໄດ້ນໍາເອົາຄວາມເຈັບປວດແລະຄວາມທຸກທໍລະມານຍ້ອນຄວາມຂັດແຍ້ງໃນເວລາທີ່ການລວມສາຂາ, ແກ້ໄຂຂໍ້ບົກພ່ອງ, ແລະການກໍ່ສ້າງໃຫມ່ "ດ້ວຍວຽກງານທີ່ແຕກຕ່າງກັນໃນການກໍ່ສ້າງ." ຂະບວນການທີ່ງ່າຍດາຍເບິ່ງຄືວ່ານີ້:

ພວກເຮົາບໍ່ພໍໃຈກັບອັນນີ້, ແລະພວກເຮົາຕ້ອງການສ້າງຂະບວນການສ້າງ ແລະ ນຳໃຊ້ທີ່ເຮັດຊ້ຳ, ອັດຕະໂນມັດ ແລະ ສາມາດຈັດການໄດ້. ສໍາລັບການນີ້, ພວກເຮົາຕ້ອງການລະບົບ CI / CD, ແລະພວກເຮົາເລືອກລະຫວ່າງ Teamcity ສະບັບຟຣີແລະ Jenkins ສະບັບຟຣີ, ເນື່ອງຈາກວ່າພວກເຮົາເຮັດວຽກກັບພວກເຂົາແລະທັງສອງເຫມາະສົມກັບພວກເຮົາໃນຂໍ້ກໍານົດຂອງຫນ້າທີ່. ພວກເຮົາເລືອກ Teamcity ເປັນຜະລິດຕະພັນຫຼ້າສຸດ. ໃນເວລານັ້ນ, ພວກເຮົາຍັງບໍ່ທັນໄດ້ນໍາໃຊ້ສະຖາປັດຕະຍະກໍາ microservice ແລະບໍ່ໄດ້ຄາດຫວັງວ່າວຽກງານແລະໂຄງການຈໍານວນຫລາຍ.

ພວກເຮົາມາແນວຄວາມຄິດຂອງລະບົບຂອງພວກເຮົາເອງ

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

Teamcity ຈັດການກັບອັດຕະໂນມັດໃນລະດັບການເປີດຕົວຂະບວນການສ້າງແລະການນໍາໃຊ້, ໃນຂະນະທີ່ Integro ສຸມໃສ່ການອັດຕະໂນມັດລະດັບສູງສຸດຂອງຂະບວນການພັດທະນາ. ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະສົມທົບການເຮັດວຽກກັບບັນຫາໃນ Jira ກັບການປຸງແຕ່ງລະຫັດແຫຼ່ງທີ່ກ່ຽວຂ້ອງໃນ Bitbucket. ໃນຂັ້ນຕອນນີ້, Integro ໄດ້ເລີ່ມຕົ້ນທີ່ຈະມີຂະບວນການເຮັດວຽກຂອງຕົນເອງສໍາລັບການເຮັດວຽກຂອງປະເພດຕ່າງໆ. 

ເນື່ອງຈາກການເພີ່ມຂຶ້ນຂອງອັດຕະໂນມັດໃນຂະບວນການທຸລະກິດ, ຈໍານວນຂອງໂຄງການແລະການດໍາເນີນງານໃນ Teamcity ໄດ້ເພີ່ມຂຶ້ນ. ດັ່ງນັ້ນບັນຫາໃຫມ່ມາ: ຕົວຢ່າງ Teamcity ຟຣີຫນຶ່ງບໍ່ພຽງພໍ (3 ຕົວແທນແລະ 100 ໂຄງການ), ພວກເຮົາໄດ້ເພີ່ມຕົວຢ່າງອື່ນ (3 ຕົວແທນແລະ 100 ໂຄງການ), ຫຼັງຈາກນັ້ນອີກອັນຫນຶ່ງ. ດັ່ງນັ້ນ, ພວກເຮົາຈົບລົງດ້ວຍລະບົບຫຼາຍກຸ່ມ, ເຊິ່ງມີຄວາມຫຍຸ້ງຍາກໃນການຈັດການ:

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

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

ພວກເຮົາເຮັດການທົດສອບອັດຕະໂນມັດ

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

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

ທີມງານອັດຕະໂນມັດ

ປະຈຸບັນພວກເຮົາມີພະນັກງານຂອງນັກພັດທະນາ 130 ຄົນ, ແລະພວກເຮົາສືບຕໍ່ ການຂະຫຍາຍຕົວ. ທີມງານສໍາລັບການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງແລະການຈັດສົ່ງລະຫັດ (ຕໍ່ໄປນີ້ເອີ້ນວ່າ Deploy and Integration ຫຼືທີມງານ DI) ປະກອບດ້ວຍ 7 ຄົນແລະເຮັດວຽກໃນ 2 ທິດທາງ: ການພັດທະນາເວທີອັດຕະໂນມັດ Integro ແລະ DevOps. 

DevOps ຮັບຜິດຊອບຕໍ່ສະພາບແວດລ້ອມ Dev/Beta ຂອງເວັບໄຊທ໌ CIAN, ສະພາບແວດລ້ອມ Integro, ຊ່ວຍໃຫ້ນັກພັດທະນາແກ້ໄຂບັນຫາ ແລະພັດທະນາວິທີການໃໝ່ໆເພື່ອປັບຂະໜາດສະພາບແວດລ້ອມ. ທິດທາງການພັດທະນາ Integro ຈັດການກັບທັງ Integro ຕົວມັນເອງແລະການບໍລິການທີ່ກ່ຽວຂ້ອງ, ສໍາລັບການຍົກຕົວຢ່າງ, plugins ສໍາລັບ Jenkins, Jira, Confluence, ແລະຍັງພັດທະນາອຸປະກອນເສີມແລະຄໍາຮ້ອງສະຫມັກສໍາລັບທີມງານພັດທະນາ. 

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

ເຄັກຊັ້ນຂອງອັດຕະໂນມັດຢູ່ CIAN

ລະບົບທັງຫມົດທີ່ກ່ຽວຂ້ອງກັບອັດຕະໂນມັດສາມາດແບ່ງອອກເປັນຫຼາຍຊັ້ນ:

1. ລະບົບພາຍນອກ (Jira, Bitbucket, ແລະອື່ນໆ). ທີມງານພັດທະນາເຮັດວຽກກັບພວກເຂົາ.
2. ເວທີ Integro. ສ່ວນຫຼາຍມັກ, ນັກພັດທະນາບໍ່ໄດ້ເຮັດວຽກກັບມັນໂດຍກົງ, ແຕ່ວ່າມັນເປັນສິ່ງທີ່ເຮັດໃຫ້ອັດຕະໂນມັດທັງຫມົດເຮັດວຽກ.
3. ການບໍລິການຈັດສົ່ງ, orchestration ແລະການຄົ້ນພົບ (ຕົວຢ່າງ, Jeknins, Consul, Nomad). ດ້ວຍການຊ່ວຍເຫຼືອຂອງພວກເຂົາ, ພວກເຮົາໃຊ້ລະຫັດໃນເຄື່ອງແມ່ຂ່າຍແລະຮັບປະກັນວ່າການບໍລິການເຮັດວຽກຮ່ວມກັນ.
4. ຊັ້ນທາງກາຍະພາບ (ເຊີບເວີ, OS, ຊອບແວທີ່ກ່ຽວຂ້ອງ). ລະຫັດຂອງພວກເຮົາດໍາເນີນການຢູ່ໃນລະດັບນີ້. ນີ້ສາມາດເປັນເຊີບເວີທາງກາຍະພາບຫຼື virtual ຫນຶ່ງ (LXC, KVM, Docker).

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

ບໍ່ສະອາດ

ໃຫ້ສຸມໃສ່ Integro ແລະເລີ່ມຕົ້ນດ້ວຍ stack ເຕັກໂນໂລຢີ:

• CentOS 7
• Docker + Nomad + Consul + Vault
• Java 11 (Integro monolith ເກົ່າຈະຍັງຄົງຢູ່ໃນ Java 8)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• ກະຕ່າຍ 
• Apache Ignite
• Camunda (ຝັງ)
• Grafana + Graphite + Prometheus + Jaeger + ELK
• Web UI: React (CSR) + MobX
• SSO: Keycloak

ພວກເຮົາປະຕິບັດຕາມຫຼັກການຂອງການພັດທະນາ microservice, ເຖິງແມ່ນວ່າພວກເຮົາມີມໍລະດົກໃນຮູບແບບຂອງ monolith ຂອງ Integro ສະບັບຕົ້ນ. ແຕ່ລະ microservice ເຮັດວຽກຢູ່ໃນຖັງ Docker ຂອງຕົນເອງ, ແລະການບໍລິການຕິດຕໍ່ສື່ສານເຊິ່ງກັນແລະກັນໂດຍຜ່ານການຮ້ອງຂໍ HTTP ແລະຂໍ້ຄວາມ RabbitMQ. Microservices ຊອກຫາກັນແລະກັນຜ່ານ Consul ແລະເຮັດການຮ້ອງຂໍໃຫ້ມັນ, ຜ່ານການອະນຸຍາດຜ່ານ SSO (Keycloak, OAuth 2/OpenID Connect).

ໃນ​ຖາ​ນະ​ເປັນ​ຕົວ​ຢ່າງ​ໃນ​ຊີ​ວິດ​ທີ່​ແທ້​ຈິງ​, ພິ​ຈາ​ລະ​ນາ​ການ​ພົວ​ພັນ​ກັບ Jenkins​, ເຊິ່ງ​ປະ​ກອບ​ດ້ວຍ​ຂັ້ນ​ຕອນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

1. ການບໍລິການຈຸລະພາກການຈັດການວຽກ (ຕໍ່ໄປນີ້ເອີ້ນວ່າ Flow microservice) ຕ້ອງການດໍາເນີນການກໍ່ສ້າງໃນ Jenkins. ເພື່ອເຮັດສິ່ງນີ້, ລາວໃຊ້ Consul ເພື່ອຊອກຫາ IP: PORT ຂອງ microservice ສໍາລັບການເຊື່ອມໂຍງກັບ Jenkins (ຕໍ່ໄປນີ້ເອີ້ນວ່າ Jenkins microservice) ແລະສົ່ງຄໍາຮ້ອງຂໍ asynchronous ກັບມັນເພື່ອເລີ່ມຕົ້ນການກໍ່ສ້າງໃນ Jenkins.
2. ຫຼັງຈາກໄດ້ຮັບການຮ້ອງຂໍ, ການບໍລິການຈຸນລະພາກ Jenkins ສ້າງແລະຕອບສະຫນອງດ້ວຍ Job ID, ເຊິ່ງຫຼັງຈາກນັ້ນສາມາດຖືກນໍາໃຊ້ເພື່ອກໍານົດຜົນໄດ້ຮັບຂອງການເຮັດວຽກ. ໃນເວລາດຽວກັນ, ມັນເຮັດໃຫ້ເກີດການກໍ່ສ້າງໃນ Jenkins ຜ່ານການໂທ REST API.
3. Jenkins ດໍາເນີນການກໍ່ສ້າງແລະ, ຫຼັງຈາກສໍາເລັດ, ສົ່ງ webhook ກັບຜົນໄດ້ຮັບການປະຕິບັດກັບ Jenkins microservice.
4. ການບໍລິການຈຸລະພາກ Jenkins, ໄດ້ຮັບ webhook, ສ້າງຂໍ້ຄວາມກ່ຽວກັບການສໍາເລັດການດໍາເນີນການຮ້ອງຂໍແລະຄັດຕິດຜົນໄດ້ຮັບການປະຕິບັດກັບມັນ. ຂໍ້ຄວາມທີ່ສ້າງຂຶ້ນແມ່ນຖືກສົ່ງໄປຫາແຖວ RabbitMQ.
5. ຜ່ານ RabbitMQ, ຂໍ້ຄວາມທີ່ຖືກເຜີຍແຜ່ໄປຮອດ Flow microservice, ເຊິ່ງຮຽນຮູ້ກ່ຽວກັບຜົນຂອງການປຸງແຕ່ງວຽກງານຂອງມັນໂດຍການຈັບຄູ່ ID ວຽກເຮັດງານທໍາຈາກການຮ້ອງຂໍແລະຂໍ້ຄວາມທີ່ໄດ້ຮັບ.

ໃນປັດຈຸບັນພວກເຮົາມີປະມານ 30 microservices, ເຊິ່ງສາມາດແບ່ງອອກເປັນຫຼາຍກຸ່ມ:

1. ການຈັດການການຕັ້ງຄ່າ.
2. ຂໍ້ມູນແລະການພົວພັນກັບຜູ້ໃຊ້ (ຜູ້ສົ່ງຂ່າວ, ເມລ).
3. ເຮັດວຽກກັບລະຫັດແຫຼ່ງ.
4. ການ​ເຊື່ອມ​ໂຍງ​ກັບ​ເຄື່ອງ​ມື​ການ​ນໍາ​ໃຊ້ (jenkins​, nomad​, consul​, ແລະ​ອື່ນໆ​)​.
5. ການຕິດຕາມ (ການປ່ອຍ, ຄວາມຜິດພາດ, ແລະອື່ນໆ).
6. ຜົນປະໂຫຍດເວັບໄຊຕ໌ (UI ສໍາລັບການຄຸ້ມຄອງສະພາບແວດລ້ອມການທົດສອບ, ເກັບກໍາສະຖິຕິ, ແລະອື່ນໆ).
7. ການປະສົມປະສານກັບຕົວຕິດຕາມວຽກງານແລະລະບົບທີ່ຄ້າຍຄືກັນ.
8. ການຈັດການຂະບວນການເຮັດວຽກສໍາລັບວຽກງານທີ່ແຕກຕ່າງກັນ.

ວຽກງານຂະບວນການ

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

ໃຫ້ເບິ່ງຂັ້ນຕອນການເຮັດວຽກທີ່ພວກເຮົາໃຊ້ຫຼາຍທີ່ສຸດ:

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

ການທົດສອບຄູ່ມືຢ່າງສົມບູນກ່ຽວກັບ DEV + BETA ໂດຍບໍ່ມີການທົດສອບ canary (ປົກກະຕິແລ້ວນີ້ແມ່ນວິທີທີ່ພວກເຮົາປ່ອຍ monolith):

ອາດຈະມີການປະສົມການປ່ຽນແປງອື່ນໆ. ບາງຄັ້ງເສັ້ນທາງທີ່ບັນຫາຈະເກີດຂຶ້ນສາມາດເລືອກໄດ້ໂດຍຜ່ານທາງເລືອກໃນ Jira.

ການເຄື່ອນໄຫວວຽກງານ

ຂໍໃຫ້ເບິ່ງຂັ້ນຕອນຕົ້ນຕໍທີ່ປະຕິບັດໃນເວລາທີ່ການເຄື່ອນຍ້າຍວຽກງານຜ່ານ "ການທົດສອບ DEV + ການທົດສອບ Canary":

1. ນັກພັດທະນາຫຼື PM ສ້າງຫນ້າວຽກ.

2. ຜູ້ພັດທະນາເອົາວຽກງານໄປເຮັດວຽກ. ຫຼັງ​ຈາກ​ສໍາ​ເລັດ​, ມັນ​ສະ​ຫຼັບ​ກັບ​ສະ​ຖາ​ນະ​ພາບ​ໃນ​ການ​ທົບ​ທວນ​ຄືນ​.

3. Jira ສົ່ງ Webhook ກັບ Jira microservice (ຮັບຜິດຊອບສໍາລັບການເຊື່ອມໂຍງກັບ Jira).

4. ການບໍລິການຈຸລະພາກ Jira ສົ່ງຄໍາຮ້ອງຂໍໄປຍັງບໍລິການ Flow (ຮັບຜິດຊອບສໍາລັບຂະບວນການເຮັດວຽກພາຍໃນທີ່ການເຮັດວຽກໄດ້ຖືກປະຕິບັດ) ເພື່ອເລີ່ມຕົ້ນການເຮັດວຽກ.

5. ພາຍໃນບໍລິການ Flow:

• ຜູ້ທົບທວນຖືກມອບຫມາຍໃຫ້ວຽກງານ (ຜູ້ໃຊ້ microservice ທີ່ຮູ້ທຸກສິ່ງທຸກຢ່າງກ່ຽວກັບຜູ້ໃຊ້ + Jira microservice).
• ຜ່ານບໍລິການຈຸລະພາກແຫຼ່ງ (ມັນຮູ້ກ່ຽວກັບ repositories ແລະສາຂາ, ແຕ່ບໍ່ໄດ້ເຮັດວຽກກັບລະຫັດຕົວມັນເອງ), ການຄົ້ນຫາແມ່ນເຮັດສໍາລັບ repositories ທີ່ມີສາຂາຂອງບັນຫາຂອງພວກເຮົາ (ເພື່ອເຮັດໃຫ້ການຄົ້ນຫາງ່າຍ, ຊື່ຂອງສາຂາກົງກັບບັນຫາ. ເລກໃນ Jira). ສ່ວນຫຼາຍແລ້ວ, ວຽກງານໃດໜຶ່ງມີພຽງສາຂາດຽວໃນບ່ອນເກັບມ້ຽນອັນດຽວ; ນີ້ເຮັດໃຫ້ການຈັດການຄິວການນຳໃຊ້ງ່າຍ ແລະຫຼຸດການເຊື່ອມຕໍ່ລະຫວ່າງບ່ອນເກັບມ້ຽນ.
• ສໍາລັບແຕ່ລະສາຂາທີ່ພົບເຫັນ, ລໍາດັບການປະຕິບັດຕໍ່ໄປນີ້ແມ່ນປະຕິບັດ:

  i) ການປັບປຸງສາຂາຕົ້ນສະບັບ (Git microservice ສໍາລັບການເຮັດວຽກກັບລະຫັດ).
  ii) ສາຂາຖືກບລັອກຈາກການປ່ຽນແປງໂດຍນັກພັດທະນາ (Bitbucket microservice).
  iii) ການຮ້ອງຂໍດຶງແມ່ນຖືກສ້າງຂຶ້ນສໍາລັບສາຂານີ້ (ບໍລິການຈຸລະພາກ Bitbucket).
  iv) ຂໍ້ຄວາມກ່ຽວກັບ Pull Request ໃຫມ່ແມ່ນຖືກສົ່ງໄປຫາຜູ້ພັດທະນາການສົນທະນາ (ແຈ້ງ microservice ສໍາລັບການເຮັດວຽກກັບການແຈ້ງເຕືອນ).
  v) ການກໍ່ສ້າງ, ການທົດສອບແລະປະຕິບັດຫນ້າວຽກແມ່ນເລີ່ມຕົ້ນໃນ DEV (Jenkins microservice ສໍາລັບການເຮັດວຽກກັບ Jenkins).
  vi) ຖ້າຂັ້ນຕອນທີ່ຜ່ານມາທັງຫມົດແມ່ນສໍາເລັດຢ່າງສໍາເລັດຜົນ, ຫຼັງຈາກນັ້ນ Integro ເອົາການອະນຸມັດຂອງມັນຢູ່ໃນຄໍາຮ້ອງຂໍດຶງ (Bitbucket microservice).

• Integro ລໍຖ້າການອະນຸມັດໃນ Pull Request ຈາກຜູ້ກວດສອບທີ່ກໍານົດ.
• ທັນທີທີ່ໄດ້ຮັບການອະນຸມັດທີ່ຈໍາເປັນທັງຫມົດ (ລວມທັງການທົດສອບອັດຕະໂນມັດໄດ້ຜ່ານທາງບວກ), Integro ຈະໂອນຫນ້າວຽກໄປ Test on Dev (Jira microservice).

6. ນັກສອບເສັງທົດສອບວຽກງານ. ຖ້າບໍ່ມີບັນຫາ, ວຽກງານຈະຖືກໂອນໄປຫາສະຖານະ Ready For Build.

7. Integro "ເຫັນ" ວ່າວຽກງານແມ່ນກຽມພ້ອມສໍາລັບການປ່ອຍຕົວແລະເລີ່ມຕົ້ນການປະຕິບັດໃນໂຫມດ canary (Jenkins microservice). ການກຽມພ້ອມສໍາລັບການປ່ອຍແມ່ນຖືກກໍານົດໂດຍກົດລະບຽບທີ່ກໍານົດໄວ້. ຕົວຢ່າງເຊັ່ນ, ວຽກງານຢູ່ໃນສະຖານະທີ່ຕ້ອງການ, ບໍ່ມີການລັອກໃນຫນ້າວຽກອື່ນ, ປະຈຸບັນບໍ່ມີການອັບໂຫລດ microservice ນີ້, ແລະອື່ນໆ.

8. ວຽກງານຖືກໂອນໄປສູ່ສະຖານະ Canary (Jira microservice).

9. Jenkins ເປີດຕົວວຽກງານການຈັດຕັ້ງປະຕິບັດຜ່ານ Nomad ໃນຮູບແບບ canary (ປົກກະຕິ 1-3 instances) ແລະແຈ້ງການບໍລິການຕິດຕາມກວດກາການປ່ອຍ (DeployWatch microservice) ກ່ຽວກັບການຕິດຕັ້ງ.

10. ໄມໂຄບໍລິການ DeployWatch ລວບລວມພື້ນຫລັງຂອງຄວາມຜິດພາດແລະປະຕິກິລິຍາກັບມັນ, ຖ້າຈໍາເປັນ. ຖ້າພື້ນຫລັງຄວາມຜິດພາດເກີນ (ມາດຕະຖານພື້ນຖານຖືກຄິດໄລ່ໂດຍອັດຕະໂນມັດ), ນັກພັດທະນາຈະຖືກແຈ້ງຜ່ານ Notify microservice. ຖ້າຫຼັງຈາກ 5 ນາທີນັກພັດທະນາບໍ່ໄດ້ຕອບສະຫນອງ (ຄລິກ Revert ຫຼື Stay), ຫຼັງຈາກນັ້ນການກັບຄືນອັດຕະໂນມັດຂອງ canary instances ຈະຖືກເປີດຕົວ. ຖ້າພື້ນຫຼັງບໍ່ເກີນ, ນັກພັດທະນາຈະຕ້ອງເປີດການນຳໃຊ້ວຽກໃຫ້ກັບການຜະລິດດ້ວຍຕົນເອງ (ໂດຍການຄລິກປຸ່ມໃດໜຶ່ງໃນ UI). ຖ້າຜູ້ພັດທະນາບໍ່ໄດ້ເປີດຕົວການນໍາໄປໃຊ້ໃນການຜະລິດພາຍໃນ 60 ນາທີ, ກໍລະນີ canary ຈະຖືກມ້ວນຄືນດ້ວຍເຫດຜົນດ້ານຄວາມປອດໄພ.

11. ຫຼັງ​ຈາກ​ການ​ເປີດ​ຕົວ​ການ​ນໍາ​ໃຊ້​ກັບ​ການ​ຜະ​ລິດ​:

• ວຽກງານຖືກໂອນໄປສູ່ສະຖານະການຜະລິດ (Jira microservice).
• ການບໍລິການຈຸນລະພາກ Jenkins ເລີ່ມຂະບວນການນຳໃຊ້ ແລະ ແຈ້ງບອກເຖິງບໍລິການຈຸລະພາກຂອງ DeployWatch ກ່ຽວກັບການນຳໃຊ້.
• ການບໍລິການຈຸລະພາກຂອງ DeployWatch ກວດເບິ່ງວ່າບັນຈຸທັງໝົດໃນການຜະລິດໄດ້ຖືກປັບປຸງແລ້ວ (ມີບາງກໍລະນີທີ່ບໍ່ໄດ້ອັບເດດທັງໝົດ).
• ໂດຍຜ່ານ Notify microservice, ການແຈ້ງເຕືອນກ່ຽວກັບຜົນໄດ້ຮັບຂອງການນໍາໃຊ້ແມ່ນຖືກສົ່ງໄປຫາການຜະລິດ.

12. ຜູ້ພັດທະນາຈະມີເວລາ 30 ນາທີເພື່ອເລີ່ມຕົ້ນການກັບຄືນໜ້າວຽກຈາກການຜະລິດ ຖ້າກວດພົບພຶດຕິກຳຂອງ microservice ທີ່ບໍ່ຖືກຕ້ອງ. ຫຼັງຈາກເວລານີ້, ວຽກງານຈະຖືກລວມເຂົ້າເປັນແມ່ແບບອັດຕະໂນມັດ (Git microservice).

13. ຫຼັງ​ຈາກ​ປະ​ສົມ​ສໍາ​ເລັດ​ເປັນ​ແມ່​ບົດ​, ສະ​ຖາ​ນະ​ພາບ​ວຽກ​ງານ​ຈະ​ໄດ້​ຮັບ​ການ​ປ່ຽນ​ແປງ​ເປັນ Closed (Jira microservice​)​.

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

ມີຫຍັງຕໍ່ໄປ

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

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

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