monorepo หรือ multirepo

สารบัญ:

• สรุป
  • ประเด็น
  • การตัดสินใจ
  • สถานะ
• รายละเอียด
  • สมมติฐาน
  • ข้อจำกัด
  • จุดยืน
  • ข้อโต้แย้ง
  • นัยยะ
• ที่เกี่ยวข้อง
  • การตัดสินใจที่เกี่ยวข้อง
  • ข้อกำหนดที่เกี่ยวข้อง
  • ผลงานที่เกี่ยวข้อง
  • หลักการที่เกี่ยวข้อง
• หมายเหตุ

สรุป

ประเด็น

โครงการของเราเกี่ยวข้องกับการพัฒนาซอฟต์แวร์สามประเภทหลัก:

• GUI ส่วนหน้า
• บริการมิดเดิลแวร์
• เซิร์ฟเวอร์ส่วนหลัง

เมื่อพัฒนา ระบบควบคุมเวอร์ชัน (VCS) สำหรับการจัดการซอร์สโค้ด (SCM) ของเราคือ git

เราต้องเลือกวิธีใช้ git เพื่อจัดระเบียบโค้ดของเรา

ตัวเลือกระดับบนสุดคือจัดระเบียบเป็น "monorepo", "polyrepo" หรือ "ไฮบริด":

• Monorepo หมายถึงเราใส่ทุกส่วนไว้ในที่เก็บใหญ่เดียว
• Polyrepo หมายถึงเราใส่แต่ละส่วนไว้ในที่เก็บของตนเอง
• ไฮบริด หมายถึงการผสมของ monorepo และ polyrepo

สำหรับข้อมูลเพิ่มเติมดู https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

การตัดสินใจ

Monorepo เมื่อองค์กร/ทีม/โครงการค่อนข้างเล็ก และการวนซ้ำอย่างรวดเร็วมีลำดับความสำคัญสูงกว่าการรักษาเสถียรภาพ

Polyrepo เมื่อองค์กร/ทีม/โครงการค่อนข้างใหญ่ และการรักษาเสถียรภาพมีลำดับความสำคัญสูงกว่าการวนซ้ำอย่างรวดเร็ว

สถานะ

ตัดสินใจแล้ว เปิดรับการทบทวนหาก/เมื่อมีเครื่องมือใหม่สำหรับจัดการ monorepo และ/หรือ polyrepo

รายละเอียด

สมมติฐาน

โค้ดทั้งหมดที่เราพัฒนาเป็นสำหรับข้อเสนอขององค์กรเดียว ไม่ใช่สำหรับสาธารณชนทั่วไป กล่าวคือโบรกเกอร์-ดีลเลอร์ไม่ได้มุ่งหวังจะมีสิ่งใดคล้ายนักพัฒนาอาสาสมัครจากสาธารณชน

ข้อจำกัด

ข้อจำกัดได้รับการบันทึกไว้อย่างดีที่ https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

จุดยืน

เราพิจารณา monorepo ในสไตล์ของ Google, Facebook ฯลฯ เราคิดว่าปัญหาการปรับขนาดของ monorepo อยู่ไกลในอนาคตมากจนเมื่อถึงเวลาที่ต้องการ เราจะสามารถใช้แนวปฏิบัติเดียวกับ Google และ Facebook ได้

เราพิจารณา polyrepo ในสไตล์ของโครงการโอเพนซอร์ส Git ทั่วไป เช่น Google Android, Facebook React ฯลฯ เราคิดว่านี่คือตัวเลือกที่ดีที่สุดสำหรับการมีส่วนร่วมของสาธารณชน (เช่น ทุกคนในโลกทำงานกับโค้ดได้) และความพร้อมใช้งานเป็นรายบุคคล (เช่น โครงการถูกใช้โดยลำพังโดยไม่มีส่วนอื่น)

ข้อโต้แย้ง

เมื่อองค์กร/ทีม/โครงการค่อนข้างเล็ก เราเลือก monorepo เพราะการวนซ้ำอย่างรวดเร็วมีลำดับความสำคัญสูงกว่าการรักษาเสถียรภาพอย่างมีนัยสำคัญ

เมื่อองค์กร/ทีม/โครงการค่อนข้างใหญ่ เราเลือก polyrepo เพราะการรักษาเสถียรภาพมีลำดับความสำคัญสูงกว่าการวนซ้ำอย่างรวดเร็วอย่างมีนัยสำคัญ

นัยยะ

หากมีไปป์ไลน์สำหรับ CI+CD อยู่แล้ว เราอาจต้องปรับเพื่อทดสอบหลายโครงการภายในที่เก็บเดียว

CI+CD อาจใช้เวลานานกว่าสำหรับการสร้างเต็มรูปแบบของ monorepo เพราะ CI+CD อาจสร้างทุกโครงการใน monorepo

หากองค์กร/ทีม/โครงการเติบโต monorepo จะมีปัญหาการปรับขนาด

ปัญหาการปรับขนาดของ monorepo อาจทำให้การเปลี่ยนไปใช้ polyrepo มีคุณค่ามากขึ้นเรื่อย ๆ

การเปลี่ยนจาก monorepo เป็น polyrepo เป็นงาน devops ที่สำคัญ และต้องมีการวางแผน จัดการ และเขียนโปรแกรม

ที่เกี่ยวข้อง

การตัดสินใจที่เกี่ยวข้อง

เราจะสร้างการตัดสินใจสำหรับเครื่องมือที่เกี่ยวข้องเพื่อจัดการ monorepo (เช่น Google Bazel) และ polyrepo (เช่น Lyft Refactorator)

ข้อกำหนดที่เกี่ยวข้อง

เราต้องพัฒนาไปป์ไลน์ CI+CD ให้ทำงานได้ดีกับ git

ผลงานที่เกี่ยวข้อง

เราคาดว่าการจัดระเบียบที่เก็บจะมีผลงานที่เกี่ยวข้องสำหรับการจัดสรรทรัพยากร การจัดการการกำหนดค่า การทดสอบ และด้าน devops ที่คล้ายกัน

หลักการที่เกี่ยวข้อง

ย้อนกลับได้ง่าย หาก monorepo ใช้งานจริงไม่ได้ผลหรือผู้นำไม่ต้องการ การเปลี่ยนเป็น polyrepo ทำได้ง่าย

หมกมุ่นกับลูกค้า เราให้คุณค่ากับการนำโครงการไปไว้ในมือลูกค้า และเราเชื่อว่า monorepo พาเราไปถึงจุดนั้นได้เร็วกว่า polyrepo และช่วยให้เราวนซ้ำได้เร็วขึ้นด้วย

คิดการใหญ่ Google และ Facebook เป็นผู้สนับสนุน monorepo เหนือ polyrepo อย่างแข็งขัน เพราะข้อเสนอหลักทั้งหมดพัฒนา/ทดสอบ/ติดตั้งใช้งานไปพร้อมกันได้

หมายเหตุ

เพิ่มหมายเหตุใด ๆ ที่นี่