ວິທີການສ້າງການພັດທະນາພາຍໃນເຮືອນແບບເຕັມຮູບແບບໂດຍໃຊ້ປະສົບການ DevOps - VTB

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

 

Prologue: DevOps ແມ່ນປັດຊະຍາ

ໃນປີທີ່ຜ່ານມາ, ພວກເຮົາໄດ້ເຮັດວຽກຫຼາຍຢ່າງເພື່ອຈັດຕັ້ງການພັດທະນາພາຍໃນແລະການປະຕິບັດການປະຕິບັດ DevOps ຢູ່ VTB:

• ພວກເຮົາໄດ້ສ້າງຂະບວນການພັດທະນາພາຍໃນ 12 ລະບົບ;
• ພວກ​ເຮົາ​ໄດ້​ເປີດ​ຕົວ​ທໍ່​ສົ່ງ 15 ​ແຫ່ງ, ​ໃນ​ນັ້ນ​ມີ XNUMX ​ແຫ່ງ​ໄດ້​ນຳ​ໄປ​ຜະລິດ;
• ອັດຕະໂນມັດ 1445 ສະຖານະການທົດສອບ;
• ພວກ​ເຮົາ​ໄດ້​ປະ​ຕິ​ບັດ​ສໍາ​ເລັດ​ການ​ອອກ​ຈໍາ​ນວນ​ຫນຶ່ງ​ທີ່​ກະ​ກຽມ​ໂດຍ​ທີມ​ງານ​ພາຍ​ໃນ​.

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

ໃນຕອນທໍາອິດ, ຂັ້ນຕອນການປະຕິບັດເບິ່ງຄືວ່າງ່າຍດາຍແລະຊັດເຈນ:

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

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

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

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

ການພັດທະນາພາຍໃນເລີ່ມຕົ້ນຢູ່ໃສ? 

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

• ພາສາແປກໆ (MUMPS);
• ການໂຕ້ຕອບ console;
• ການຂາດການເຊື່ອມໂຍງກັບເຄື່ອງມືອັດຕະໂນມັດທີ່ນິຍົມແລະກອບ;
• ປະລິມານຂໍ້ມູນໃນສິບ terabytes;
• ການໂຫຼດຂອງຫຼາຍກວ່າ 2 ລ້ານການດໍາເນີນງານຕໍ່ຊົ່ວໂມງ;
• ຄວາມສໍາຄັນ - ທຸລະກິດທີ່ສໍາຄັນ.

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

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

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

ການເຄື່ອນຍ້າຍບ່ອນເກັບມ້ຽນແລະການທົດສອບອັດຕະໂນມັດ

ວຽກງານ DevOps ທໍາອິດແມ່ນ repository. ພວກເຮົາຕົກລົງເຫັນດີຢ່າງໄວວາກ່ຽວກັບການສະຫນອງການເຂົ້າເຖິງ, ແຕ່ມັນຈໍາເປັນຕ້ອງໄດ້ຍ້າຍຈາກ SVN ໃນປະຈຸບັນດ້ວຍສາຂາລໍາຕົ້ນຫນຶ່ງໄປຫາ Git ເປົ້າຫມາຍຂອງພວກເຮົາດ້ວຍການຫັນປ່ຽນໄປສູ່ຮູບແບບຂອງຫຼາຍໆສາຂາແລະການພັດທະນາ Git Flow. ພວກເຮົາຍັງມີ 2 ທີມທີ່ມີໂຄງສ້າງພື້ນຖານຂອງຕົນເອງ, ບວກກັບທີມງານຂອງຜູ້ຂາຍຢູ່ຕ່າງປະເທດ. ຂ້ອຍຕ້ອງອາໄສຢູ່ກັບສອງ Gits ແລະຮັບປະກັນການ synchronization. ໃນສະຖານະການດັ່ງກ່າວ, ມັນແມ່ນຄວາມຊົ່ວຮ້າຍຫນ້ອຍກວ່າສອງຢ່າງ.

ການເຄື່ອນຍ້າຍຂອງ repository ໄດ້ຖືກເລື່ອນເວລາຫຼາຍຄັ້ງ; ມັນສໍາເລັດພຽງແຕ່ໃນເດືອນເມສາ, ໂດຍການຊ່ວຍເຫຼືອຂອງເພື່ອນຮ່ວມງານຈາກແຖວຫນ້າ. ດ້ວຍ Git Flow, ພວກເຮົາໄດ້ຕັດສິນໃຈຮັກສາສິ່ງທີ່ງ່າຍດາຍສໍາລັບການເລີ່ມຕົ້ນແລະຕົກລົງໃນໂຄງການຄລາສສິກທີ່ມີ hotfix, ພັດທະນາແລະປ່ອຍ. ພວກເຂົາເຈົ້າໄດ້ຕັດສິນໃຈປະຖິ້ມຕົ້ນສະບັບ (aka prod-like). ຂ້າງລຸ່ມນີ້ພວກເຮົາຈະອະທິບາຍວ່າເປັນຫຍັງທາງເລືອກນີ້ຈຶ່ງເຮັດໃຫ້ດີທີ່ສຸດສໍາລັບພວກເຮົາ. ຄັງເກັບຂໍ້ມູນພາຍນອກທີ່ເປັນຂອງຜູ້ຂາຍ, ທົ່ວໄປສໍາລັບສອງທີມ, ໄດ້ຖືກນໍາໃຊ້ເປັນພະນັກງານ. ມັນ synchronized ກັບ repository ພາຍໃນຕາມຕາຕະລາງ. ໃນປັດຈຸບັນກັບ Git ແລະ Gitlab ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດໃຫ້ຂະບວນການອັດຕະໂນມັດ.

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

ມັນເປັນແນວໃດ: ຮູບແບບກ່ອນທີ່ຈະອັດຕະໂນມັດ

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

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

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

ເພື່ອໃຫ້ໄດ້ລະຫັດສະບັບທີ່ຕ້ອງການ, ມັນຈໍາເປັນຕ້ອງປະຕິບັດຕາມຄໍາສັ່ງຕິດຕັ້ງຢ່າງເຂັ້ມງວດ, ໃນໄລຍະນັ້ນວັດຖຸໄດ້ຖືກຂຽນຄືນໃຫມ່ຫຼາຍຄັ້ງ, ບາງ 10-12 ເທື່ອ.

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

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

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

ການປັບປຸງຄັ້ງທໍາອິດ: ຄໍາຫມັ້ນສັນຍາການປະກອບແລະການຈັດສົ່ງ

ອັດຕະໂນມັດໄດ້ເລີ່ມຕົ້ນໂດຍການສົ່ງລະຫັດຜ່ານທໍ່ຕາມເສັ້ນທາງນີ້:

• ເອົາການຈັດສົ່ງສໍາເລັດຮູບຈາກການເກັບຮັກສາ;
• ຕິດຕັ້ງມັນຢູ່ໃນສະພາບແວດລ້ອມທີ່ອຸທິດຕົນ;
• ດໍາເນີນການ autotests;
• ການ​ປະ​ເມີນ​ຜົນ​ການ​ຕິດ​ຕັ້ງ​;
• ໂທຫາທໍ່ຕໍ່ໄປນີ້ຢູ່ດ້ານຂ້າງຂອງຄໍາສັ່ງການທົດສອບ.

ທໍ່ຕໍ່ໄປຄວນລົງທະບຽນວຽກງານໃນ Jira ແລະລໍຖ້າຄໍາສັ່ງທີ່ຈະແຈກຢາຍໃຫ້ກັບ loops ການທົດສອບທີ່ເລືອກ, ເຊິ່ງຂຶ້ນກັບໄລຍະເວລາຂອງການຈັດຕັ້ງປະຕິບັດວຽກງານ. Trigger - ຈົດໝາຍກ່ຽວກັບຄວາມພ້ອມສຳລັບການຈັດສົ່ງໄປຫາທີ່ຢູ່ໃດໜຶ່ງ. ນີ້, ແນ່ນອນ, ແມ່ນໄມ້ຄ້ອນທີ່ຊັດເຈນ, ແຕ່ຂ້ອຍຕ້ອງເລີ່ມຕົ້ນບ່ອນໃດບ່ອນຫນຶ່ງ. ໃນເດືອນພຶດສະພາ 2019, ການໂອນລະຫັດເລີ່ມຕົ້ນດ້ວຍການກວດສອບສະພາບແວດລ້ອມຂອງພວກເຮົາ. ຂະບວນການດັ່ງກ່າວໄດ້ເລີ່ມຂຶ້ນແລ້ວ, ສິ່ງທີ່ຍັງເຫຼືອແມ່ນເພື່ອເຮັດໃຫ້ມັນເຂົ້າໄປໃນຮູບຮ່າງທີ່ເຫມາະສົມ:

• ແຕ່ລະການດັດແກ້ແມ່ນປະຕິບັດຢູ່ໃນສາຂາແຍກຕ່າງຫາກ, ເຊິ່ງສອດຄ່ອງກັບຊຸດການຕິດຕັ້ງແລະ merges ເຂົ້າໄປໃນສາຂາແມ່ບົດເປົ້າຫມາຍ;
• ຜົນກະທົບຕໍ່ການເປີດຕົວທໍ່ແມ່ນການປະກົດຕົວຂອງຄໍາຫມັ້ນສັນຍາໃຫມ່ໃນສາຂາຕົ້ນສະບັບໂດຍຜ່ານການຮ້ອງຂໍການຜະສົມຜະສານ, ເຊິ່ງຖືກປິດໂດຍຜູ້ຮັກສາຈາກທີມງານ inhouse;
• Repositories ແມ່ນ synchronized ທຸກໆຫ້ານາທີ;
• ການປະກອບຊຸດການຕິດຕັ້ງແມ່ນເລີ່ມຕົ້ນ - ໂດຍໃຊ້ຕົວປະກອບທີ່ໄດ້ຮັບຈາກຜູ້ຂາຍ.

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

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

ການແກ້ໄຂສຸດທ້າຍ: ຊຸດການຕິດຕັ້ງສະສົມ 

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

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

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

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

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

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

ຄັ້ງທໍາອິດ, ຢ່າງວ່ອງໄວແລະບໍ່ມີຄວາມຜິດພາດ

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

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

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

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

ຜົນໄດ້ຮັບແລະບົດສະຫຼຸບ

ໃນເວລາຫນ້ອຍກວ່າຫນຶ່ງປີ, ພວກເຮົາຈັດການ:

• ສ້າງ​ການ​ພັດ​ທະ​ນາ​ພາຍ​ໃນ​ຢ່າງ​ເຕັມ​ສ່ວນ​ໂດຍ​ນໍາ​ໃຊ້​ລະ​ບົບ exotic​;
• ລົບລ້າງຄວາມເພິ່ງພາອາໄສຂອງຜູ້ຂາຍທີ່ສໍາຄັນ;
• ເປີດ CI/CD ສໍາລັບມໍລະດົກທີ່ບໍ່ເປັນມິດຫຼາຍ;
• ຍົກ​ສູງ​ຂະ​ບວນ​ການ​ປະ​ຕິ​ບັດ​ຂຶ້ນ​ສູ່​ລະ​ດັບ​ເຕັກ​ນິກ​ໃໝ່;
• ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍທີ່ໃຊ້ເວລາໃນການປະຕິບັດ;
• ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຂອງຄວາມຜິດພາດການປະຕິບັດ;
• ປະກາດຢ່າງໝັ້ນໃຈວ່າຕົນເອງເປັນຜູ້ຊ່ຽວຊານດ້ານການພັດທະນາຊັ້ນນໍາ.

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

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