Monorepo ທຽບກັບ multirepo

ສາລະບານ:

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

ບົດສະຫຼຸບ

ບັນຫາ

ໂຄງການຂອງພວກເຮົາກ່ຽວຂ້ອງກັບການພັດທະນາຊອບແວສາມໝວດຫຼັກ:

• GUI ຝັ່ງໜ້າ
• ບໍລິການ middleware
• ເຊີບເວີຝັ່ງຫຼັງ

ເມື່ອພວກເຮົາພັດທະນາ ລະບົບຄວບຄຸມເວີຊັນ (VCS) ຂອງການຈັດການຊອດໂຄ້ດ (SCM) ຂອງພວກເຮົາແມ່ນ git.

ພວກເຮົາຕ້ອງເລືອກວິທີໃຊ້ git ເພື່ອຈັດລະບຽບໂຄ້ດຂອງພວກເຮົາ.

ທາງເລືອກລະດັບສູງສຸດແມ່ນການຈັດລະບຽບເປັນ "monorepo" ຫຼື "polyrepo" ຫຼື "hybrid":

• Monorepo ໝາຍຄວາມວ່າພວກເຮົາວາງທຸກສ່ວນໄວ້ໃນ repo ໃຫຍ່ອັນດຽວ
• Polyrepo ໝາຍຄວາມວ່າພວກເຮົາວາງແຕ່ລະສ່ວນໄວ້ໃນ repo ຂອງຕົນເອງ
• Hybrid ໝາຍເຖິງການປະສົມບາງຢ່າງລະຫວ່າງ monorepo ແລະ polyrepo

ສຳລັບຂໍ້ມູນເພີ່ມເຕີມ ກະລຸນາເບິ່ງ https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

ການຕັດສິນໃຈ

Monorepo ເມື່ອອົງກອນ/ທີມ/ໂຄງການຂ້ອນຂ້າງນ້ອຍ ແລະ ການວົນຊ້ຳຢ່າງວ່ອງໄວມີບູລິມະສິດສູງກວ່າການຮັກສາຄວາມໝັ້ນຄົງ.

Polyrepo ເມື່ອອົງກອນ/ທີມ/ໂຄງການຂ້ອນຂ້າງໃຫຍ່ ແລະ ການຮັກສາຄວາມໝັ້ນຄົງມີບູລິມະສິດສູງກວ່າການວົນຊ້ຳຢ່າງວ່ອງໄວ.

ສະຖານະ

ຕັດສິນໃຈແລ້ວ. ເປີດຮັບການທົບທວນຄືນເມື່ອ/ຖ້າມີເຄື່ອງມືໃໝ່ສຳລັບຈັດການ monorepo ແລະ/ຫຼື polyrepo.

ລາຍລະອຽດ

ສົມມຸດຕິຖານ

ໂຄ້ດທັງໝົດທີ່ພວກເຮົາກຳລັງພັດທະນາແມ່ນສຳລັບຜະລິດຕະພັນຂອງອົງກອນດຽວ ແລະ ບໍ່ແມ່ນສຳລັບປະຊາຊົນທົ່ວໄປ. ນັ້ນຄື Broker-Dealer ບໍ່ໄດ້ມີເປົ້າໝາຍທີ່ຈະມີຫຍັງຄ້າຍກັບນັກພັດທະນາອາສາສະໝັກຈາກສາທາລະນະທົ່ວໄປ.

ຂໍ້ຈຳກັດ

ຂໍ້ຈຳກັດຖືກບັນທຶກໄວ້ຢ່າງດີທີ່ https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

ຈຸດຢືນ

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

ພວກເຮົາໄດ້ພິຈາລະນາ polyrepo ແບບໂຄງການຊອດເປີດ Git ທົ່ວໄປ ເຊັ່ນ Google Android, Facebook React ແລະ ອື່ນໆ. ພວກເຮົາຄິດວ່ານີ້ເປັນທາງເລືອກທີ່ດີທີ່ສຸດສຳລັບການມີສ່ວນຮ່ວມຂອງສາທາລະນະທົ່ວໄປ (ເຊັ່ນ ທຸກຄົນໃນໂລກສາມາດເຮັດວຽກກັບໂຄ້ດ) ແລະ ການໃຊ້ງານໄດ້ເປັນສ່ວນບຸກຄົນ (ເຊັ່ນ ໂຄງການຖືກໃຊ້ດ້ວຍຕົວມັນເອງ ໂດຍບໍ່ມີສ່ວນອື່ນ).

ຂໍ້ໂຕ້ແຍ້ງ

ເມື່ອອົງກອນ/ທີມ/ໂຄງການຂ້ອນຂ້າງນ້ອຍ ພວກເຮົາເລືອກ monorepo ເພາະການວົນຊ້ຳຢ່າງວ່ອງໄວມີບູລິມະສິດສູງກວ່າການຮັກສາຄວາມໝັ້ນຄົງຢ່າງເຫັນໄດ້ຊັດ

ເມື່ອອົງກອນ/ທີມ/ໂຄງການຂ້ອນຂ້າງໃຫຍ່ ພວກເຮົາເລືອກ polyrepo ເພາະການຮັກສາຄວາມໝັ້ນຄົງມີບູລິມະສິດສູງກວ່າການວົນຊ້ຳຢ່າງວ່ອງໄວຢ່າງເຫັນໄດ້ຊັດ.

ຜົນໄດ້ຮັບ

ຖ້າມີທໍ່ CI+CD ຢູ່ແລ້ວ ພວກເຮົາອາດຕ້ອງປັບມັນເພື່ອທົດສອບຫຼາຍໂຄງການພາຍໃນ repo ດຽວ.

CI+CD ອາດໃຊ້ເວລາຫຼາຍຂຶ້ນສຳລັບການ build ເຕັມຂອງ monorepo ເພາະ CI+CD ອາດ build ທຸກໂຄງການໃນ monorepo.

ຖ້າອົງກອນ/ທີມ/ໂຄງການເຕີບໃຫຍ່ຂຶ້ນ monorepo ຈະມີບັນຫາການຂະຫຍາຍ.

ບັນຫາການຂະຫຍາຍຂອງ monorepo ອາດເຮັດໃຫ້ການປ່ຽນໄປ polyrepo ມີຄຸນຄ່າຫຼາຍຂຶ້ນເລື້ອຍໆ.

ການປ່ຽນຈາກ monorepo ໄປ polyrepo ເປັນວຽກ devops ທີ່ສຳຄັນ ແລະ ຈະຕ້ອງໄດ້ວາງແຜນ, ຄຸ້ມຄອງ ແລະ ຂຽນໂປຣແກຣມ.

ທີ່ກ່ຽວຂ້ອງ

ການຕັດສິນໃຈທີ່ກ່ຽວຂ້ອງ

ພວກເຮົາຈະສ້າງການຕັດສິນໃຈສຳລັບເຄື່ອງມືທີ່ກ່ຽວຂ້ອງເພື່ອຈັດການ monorepo (ເຊັ່ນ Google Bazel) ແລະ polyrepo (ເຊັ່ນ Lyft Refactorator).

ຄວາມຕ້ອງການທີ່ກ່ຽວຂ້ອງ

ພວກເຮົາຕ້ອງພັດທະນາທໍ່ CI+CD ໃຫ້ເຮັດວຽກໄດ້ດີກັບ git.

ຜະລິດຕະພັນທີ່ກ່ຽວຂ້ອງ

ພວກເຮົາຄາດວ່າການຈັດລະບຽບ repo ຈະມີຜະລິດຕະພັນທີ່ກ່ຽວຂ້ອງສຳລັບການຈັດຫາ, ການຄຸ້ມຄອງການຕັ້ງຄ່າ, ການທົດສອບ ແລະ ຂອບເຂດ devops ທີ່ຄ້າຍກັນ.

ຫຼັກການທີ່ກ່ຽວຂ້ອງ

ຍ້ອນກັບໄດ້ງ່າຍ. ຖ້າ monorepo ບໍ່ໄດ້ຜົນໃນການປະຕິບັດ ຫຼື ຝ່າຍນຳບໍ່ຕ້ອງການ ກໍງ່າຍທີ່ຈະປ່ຽນເປັນ polyrepo.

ຄວາມຫຼົງໄຫຼລູກຄ້າ. ພວກເຮົາໃຫ້ຄຸນຄ່າກັບການນຳໂຄງການໄປສູ່ມືລູກຄ້າ ແລະ ພວກເຮົາເຊື່ອວ່າ monorepo ສາມາດພາພວກເຮົາໄປຮອດໄດ້ໄວກວ່າ polyrepo ແລະ ຍັງຊ່ວຍໃຫ້ພວກເຮົາວົນຊ້ຳໄດ້ໄວຂຶ້ນ.

ຄິດໃຫຍ່. Google ແລະ Facebook ເປັນຜູ້ສະໜັບສະໜູນ monorepo ຫຼາຍກວ່າ polyrepo ຢ່າງແຂງແຮງ ເພາະຜະລິດຕະພັນຫຼັກທັງໝົດສາມາດຖືກພັດທະນາ/ທົດສອບ/ຕິດຕັ້ງໄປພ້ອມກັນ.

ໝາຍເຫດ

ເພີ່ມໝາຍເຫດໃດໆໃສ່ຢູ່ນີ້.