ວິທີການຫຼີກເວັ້ນການຍິງຕົວເອງໃນຕີນໂດຍໃຊ້ Liquibase

ບໍ່​ເຄີຍ​ເກີດ​ຂຶ້ນ​ມາ​ກ່ອນ​, ແລະ​ນີ້​ພວກ​ເຮົາ​ໄປ​ອີກ​ເທື່ອ​ຫນຶ່ງ​!

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

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

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

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

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

• ການນໍາໃຊ້ Liquibase ເພື່ອຈັດການໂຄງສ້າງຖານຂໍ້ມູນໃນແອັບພລິເຄຊັນ Spring Boot. ພາກທີ 1
• ການນໍາໃຊ້ Liquibase ເພື່ອຈັດການໂຄງສ້າງຖານຂໍ້ມູນໃນແອັບພລິເຄຊັນ Spring Boot. ພາກທີ 2
• Liquibase ແລະ Maven
• ແນວທາງການປ່ຽນແປງຖານຂໍ້ມູນສະບັບ
• ພວກເຮົາເປີດຕົວ Spring MVC/Security, REST, Hibernate, Liquibase ໃນສອງສາຍ

ນອກຈາກນັ້ນ, ມີບົດຄວາມທີ່ດີເລີດກ່ຽວກັບຫົວຂໍ້ຂອງຄໍາແນະນໍາທີ່ເປັນປະໂຫຍດ:

• ໃຊ້ Liquibase ໂດຍບໍ່ມີການເຈັບຫົວ. 10 ຄໍາແນະນໍາຈາກປະສົບການການພັດທະນາທີ່ແທ້ຈິງ

ຄໍາແນະນໍາ

ຂ້ອຍຕ້ອງການແບ່ງປັນຄໍາແນະນໍາແລະຄໍາຄິດເຫັນຂອງຂ້ອຍ, ເຊິ່ງເກີດມາໂດຍຜ່ານການເຫື່ອອອກ, ເລືອດແລະຄວາມເຈັບປວດຂອງການແກ້ໄຂບັນຫາການເຄື່ອນຍ້າຍ.

1. ກ່ອນທີ່ຈະເລີ່ມຕົ້ນການເຮັດວຽກ, ທ່ານຄວນຄຸ້ນເຄີຍກັບຕົວທ່ານເອງກັບພາກປະຕິບັດທີ່ດີທີ່ສຸດກ່ຽວກັບ site Liquibase

ຢູ່ທີ່ນັ້ນ ສິ່ງທີ່ງ່າຍດາຍແຕ່ມີຄວາມສໍາຄັນຫຼາຍແມ່ນໄດ້ຖືກອະທິບາຍ, ໂດຍບໍ່ມີການນໍາໃຊ້ຫ້ອງສະຫມຸດສາມາດສັບສົນຊີວິດຂອງທ່ານ. ຕົວຢ່າງ, ວິທີການທີ່ບໍ່ມີໂຄງສ້າງໃນການຈັດການຊຸດການປ່ຽນແປງໃນໄວໆນີ້ຈະນໍາໄປສູ່ຄວາມສັບສົນແລະການເຄື່ອນຍ້າຍທີ່ແຕກຫັກ. ຖ້າທ່ານບໍ່ເປີດເຜີຍການປ່ຽນແປງທີ່ອີງໃສ່ເຊິ່ງກັນແລະກັນກັບໂຄງສ້າງຖານຂໍ້ມູນແລະເຫດຜົນການບໍລິການໃນເວລາດຽວກັນ, ມີຄວາມເປັນໄປໄດ້ສູງທີ່ຈະນໍາໄປສູ່ການທົດສອບສີແດງຫຼືສະພາບແວດລ້ອມທີ່ແຕກຫັກ. ນອກຈາກນັ້ນ, ຄໍາແນະນໍາສໍາລັບການນໍາໃຊ້ Liquibase ຢູ່ໃນເວັບໄຊທ໌ທາງການມີຂໍ້ສະເຫນີກ່ຽວກັບການພັດທະນາແລະການທົດສອບ rollback scripts ພ້ອມກັບສະຄິບການເຄື່ອນຍ້າຍຕົ້ນຕໍ. ດີ, ໃນບົດຄວາມ https://habr.com/ru/post/178665/ ມີຕົວຢ່າງລະຫັດກ່ຽວກັບການເຄື່ອນຍ້າຍແລະກົນໄກການກັບຄືນ.

2. ຖ້າທ່ານເລີ່ມໃຊ້ເຄື່ອງມືການເຄື່ອນຍ້າຍ, ຢ່າອະນຸຍາດໃຫ້ແກ້ໄຂຄູ່ມືໃນໂຄງສ້າງຖານຂໍ້ມູນ

ດັ່ງຄຳເວົ້າທີ່ວ່າ: "ຄັ້ງໜຶ່ງ Persil, Persil ສະເໝີ." ຖ້າພື້ນຖານຂອງແອັບພລິເຄຊັນຂອງທ່ານເລີ່ມຖືກຈັດການໂດຍ Liquibase, ການປ່ຽນແປງຄູ່ມືໃດໆກໍ່ນໍາໄປສູ່ສະຖານະທີ່ບໍ່ສອດຄ່ອງ, ແລະລະດັບຄວາມໄວ້ວາງໃຈໃນຊຸດການປ່ຽນແປງຈະກາຍເປັນສູນ. ຄວາມສ່ຽງທີ່ອາດເກີດຂຶ້ນລວມມີເວລາຫຼາຍຊົ່ວໂມງໃນການຟື້ນຟູຖານຂໍ້ມູນ; ໃນກໍລະນີຮ້າຍແຮງທີ່ສຸດ, ເຄື່ອງແມ່ຂ່າຍທີ່ຕາຍແລ້ວ. ຖ້າທ່ານມີ "ໂຮງຮຽນເກົ່າ" DBA ສະຖາປະນິກຢູ່ໃນທີມງານຂອງທ່ານ, ດ້ວຍຄວາມອົດທົນແລະຄິດຢ່າງລະອຽດອະທິບາຍໃຫ້ລາວຮູ້ວ່າສິ່ງທີ່ບໍ່ດີຈະເປັນແນວໃດຖ້າລາວພຽງແຕ່ແກ້ໄຂຖານຂໍ້ມູນຕາມຄວາມເຂົ້າໃຈຂອງຕົນເອງຈາກຜູ້ພັດທະນາ SQL ທີ່ມີເງື່ອນໄຂ.

3. ຖ້າຊຸດການປ່ຽນແປງໄດ້ຖືກ pushed ເຂົ້າໄປໃນ repository ແລ້ວ, ຫຼີກເວັ້ນການດັດແກ້

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

4. ມີການກວດສອບການສໍາຮອງຂໍ້ມູນຖານຂໍ້ມູນຖ້າເປັນໄປໄດ້

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

5. ໃຊ້ການສໍາຮອງຖານຂໍ້ມູນທີ່ພິສູດແລ້ວໃນການພັດທະນາ, ຖ້າເປັນໄປໄດ້

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

6. ຕິດຕໍ່ສື່ສານກັບຜູ້ພັດທະນາອື່ນໆໃນທີມງານ

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

7. ຄິດກ່ຽວກັບສິ່ງທີ່ທ່ານກໍາລັງເຮັດ!

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

ໃສ່ກັບດັກ

ຕອນນີ້ໃຫ້ເຮົາມາເບິ່ງການໃສ່ກັບດັກແບບທຳມະດາທີ່ເຈົ້າສາມາດຕົກຢູ່ໄດ້ ຖ້າເຈົ້າບໍ່ປະຕິບັດຕາມຄຳແນະນຳຂ້າງເທິງນີ້ ແລະເຈົ້າຄວນເຮັດແນວໃດ?

ສະຖານະການ 1: ສອງນັກພັດທະນາກໍາລັງພະຍາຍາມເພີ່ມການປ່ຽນແປງໃຫມ່ໃນເວລາດຽວກັນ

Vasya ແລະ Petya ຕ້ອງການສ້າງ changeset ຮຸ່ນ 4, ໂດຍບໍ່ຮູ້ຕົວ. ພວກເຂົາເຈົ້າໄດ້ເຮັດການປ່ຽນແປງໂຄງສ້າງຖານຂໍ້ມູນແລະອອກຄໍາຮ້ອງຂໍດຶງກັບໄຟລ໌ changeset ທີ່ແຕກຕ່າງກັນ. ກົນໄກການປະຕິບັດຕໍ່ໄປນີ້ໄດ້ຖືກສະເຫນີ:

ວິທີການແກ້ໄຂ

1. ບາງຢ່າງ, ເພື່ອນຮ່ວມງານຕ້ອງຕົກລົງເຫັນດີກັບຄໍາສັ່ງທີ່ຊຸດການປ່ຽນແປງຂອງພວກເຂົາຄວນຈະໄປ, ຕົວຢ່າງ, Petin ຄວນຖືກນໍາໃຊ້ກ່ອນ.
2. ບາງຄົນຄວນເພີ່ມອັນທີສອງໃຫ້ກັບຕົວເອງແລະຫມາຍການປ່ຽນແປງຂອງ Vasya ກັບຮຸ່ນ 5. ນີ້ສາມາດເຮັດໄດ້ໂດຍຜ່ານ Cherry Pick ຫຼືການລວມເຂົ້າກັນຢ່າງແຫນ້ນຫນາ.
3. ຫຼັງຈາກການປ່ຽນແປງ, ທ່ານຄວນກວດເບິ່ງຄວາມຖືກຕ້ອງຂອງການກະທໍາທີ່ປະຕິບັດຢ່າງແນ່ນອນ.
   ໃນຄວາມເປັນຈິງ, ກົນໄກ Liquibase ຈະຊ່ວຍໃຫ້ທ່ານມີ 4 ຮຸ່ນ 4 ການປ່ຽນແປງຢູ່ໃນບ່ອນເກັບມ້ຽນ, ດັ່ງນັ້ນທ່ານສາມາດປ່ອຍໃຫ້ທຸກສິ່ງທຸກຢ່າງເປັນ. ນັ້ນ​ແມ່ນ​, ທ່ານ​ພຽງ​ແຕ່​ຈະ​ມີ​ສອງ​ການ​ປ່ຽນ​ແປງ​ສະ​ບັບ XNUMX ທີ່​ມີ​ຊື່​ທີ່​ແຕກ​ຕ່າງ​ກັນ​. ດ້ວຍວິທີການນີ້, ມັນຕໍ່ມາມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະນໍາທາງສະບັບຖານຂໍ້ມູນ.

ນອກຈາກນັ້ນ, Liquibase, ຄືກັບເຮືອນຂອງ hobbits, ຮັກສາຄວາມລັບຫຼາຍຢ່າງ. ຫນຶ່ງໃນນັ້ນແມ່ນລະຫັດ validCheckSum, ເຊິ່ງປາກົດຢູ່ໃນສະບັບ 1.7 ແລະອະນຸຍາດໃຫ້ທ່ານລະບຸຄ່າ hash ທີ່ຖືກຕ້ອງສໍາລັບຊຸດການປ່ຽນແປງສະເພາະ, ໂດຍບໍ່ຄໍານຶງເຖິງສິ່ງທີ່ຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນ. ເອກະສານ https://www.liquibase.org/documentation/changeset.html ເວົ້າຕໍ່ໄປນີ້:

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

ແມ່ນແລ້ວ, ແມ່ນແລ້ວ, ຂັ້ນຕອນນີ້ບໍ່ໄດ້ຖືກແນະນໍາ. ແຕ່ບາງຄັ້ງ magician ແສງສະຫວ່າງທີ່ເຂັ້ມແຂງຍັງ masters ເຕັກນິກການຊ້ໍາ

ສະຖານະການ 2: ການເຄື່ອນຍ້າຍທີ່ຂຶ້ນກັບຂໍ້ມູນ

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

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

ວິທີການແກ້ໄຂ

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

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

ສະຖານະການ 3. Liquibase ເລີ່ມຕົ້ນທີ່ຈະຖືກນໍາໃຊ້ຫຼັງຈາກທີ່ມັນເຂົ້າໄປໃນການຜະລິດ

ສົມມຸດວ່າຜູ້ນໍາທີມໄດ້ຂໍໃຫ້ Petya ລວມເອົາ Liquibase ໃນໂຄງການ, ແຕ່ໂຄງການແມ່ນການຜະລິດແລ້ວແລະມີໂຄງສ້າງຖານຂໍ້ມູນທີ່ມີຢູ່ແລ້ວ.

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

ວິທີການແກ້ໄຂ

ຍັງມີຫຼາຍວິທີ:

• ທໍາອິດແລະຊັດເຈນທີ່ສຸດແມ່ນການມີສະຄິບແຍກຕ່າງຫາກທີ່ຕ້ອງຖືກນໍາໃຊ້ດ້ວຍຕົນເອງໃນເວລາທີ່ເລີ່ມຕົ້ນສະພາບແວດລ້ອມໃຫມ່.
• ອັນທີສອງແມ່ນເຫັນໄດ້ຊັດເຈນຫນ້ອຍ, ມີການເຄື່ອນຍ້າຍ Liquibase ທີ່ຢູ່ໃນສະພາບການ Liquibase ອື່ນ, ແລະນໍາໃຊ້ມັນ. ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບ Liquibase Context ໄດ້ທີ່ນີ້: https://www.liquibase.org/documentation/contexts.html. ໂດຍທົ່ວໄປ, ນີ້ແມ່ນກົນໄກທີ່ຫນ້າສົນໃຈທີ່ສາມາດຖືກນໍາໃຊ້ຢ່າງສໍາເລັດຜົນ, ສໍາລັບການຍົກຕົວຢ່າງ, ສໍາລັບການທົດສອບ.
• ເສັ້ນທາງທີສາມປະກອບດ້ວຍຫຼາຍຂັ້ນຕອນ. ທໍາອິດ, ການໂອນຍ້າຍຕ້ອງຖືກສ້າງຂຶ້ນສໍາລັບຕາຕະລາງທີ່ມີຢູ່. ຫຼັງຈາກນັ້ນ, ມັນຕ້ອງໄດ້ຮັບການນໍາໃຊ້ກັບບາງສະພາບແວດລ້ອມແລະດັ່ງນັ້ນຜົນລວມ hash ຂອງມັນຈະໄດ້ຮັບ. ຂັ້ນຕອນຕໍ່ໄປແມ່ນການເລີ່ມຕົ້ນຕາຕະລາງ Liquibase ຫວ່າງເປົ່າຢູ່ໃນເຄື່ອງແມ່ຂ່າຍທີ່ບໍ່ຫວ່າງຂອງພວກເຮົາ, ແລະໃນຕາຕະລາງທີ່ມີປະຫວັດຂອງການນໍາໃຊ້ການປ່ຽນແປງ, ທ່ານສາມາດຂຽນບັນທຶກກ່ຽວກັບ "ຄືກັບວ່ານໍາໃຊ້" ການປ່ຽນແປງດ້ວຍຕົນເອງກັບການປ່ຽນແປງທີ່ມີຢູ່ໃນຖານຂໍ້ມູນ. . ດັ່ງນັ້ນ, ໃນເຄື່ອງແມ່ຂ່າຍທີ່ມີຢູ່ແລ້ວ, ການນັບຖອຍຫລັງປະຫວັດສາດຈະເລີ່ມຕົ້ນຈາກຮຸ່ນ 2, ແລະສະພາບແວດລ້ອມໃຫມ່ທັງຫມົດຈະປະຕິບັດຕົວດຽວກັນ.
  

ສະຖານະການ 4. ການເຄື່ອນຍ້າຍກາຍເປັນຂະຫນາດໃຫຍ່ແລະບໍ່ມີເວລາທີ່ຈະສໍາເລັດ

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

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

ວິທີການແກ້ໄຂ

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

ໃນໂຫມດແບບສະແຕນຄົນດຽວ, ທ່ານສາມາດອອກຈາກການປະຕິບັດການເຄື່ອນຍ້າຍໄປສູ່ສະພາບແວດລ້ອມ CI / CD ຂອງທ່ານຫຼືໃສ່ບ່າທີ່ເຂັ້ມແຂງຂອງຜູ້ເບິ່ງແຍງລະບົບແລະຜູ້ຊ່ຽວຊານດ້ານການປະຕິບັດ. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຕ້ອງການເສັ້ນຄໍາສັ່ງ Liquibase https://www.liquibase.org/documentation/command_line.html. ໃນໂຫມດນີ້, ມັນເປັນໄປໄດ້ທີ່ຈະເປີດຕົວແອັບພລິເຄຊັນຫຼັງຈາກການເຄື່ອນຍ້າຍທີ່ຈໍາເປັນທັງຫມົດໄດ້ຖືກປະຕິບັດ.

ສະຫລຸບ

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

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