แจกแจงกลยุทธ์คลังเก็บโค้ด

Mono-repo และ Multi-repo เป็นสองกลยุทธ์หลักสำหรับการโฮสต์และจัดการโค้ดผ่าน Git เราหารือทั้งกลยุทธ์และข้อดีและข้อเสียอย่างละเอียด

บทนำ

โครงการที่ทันสมัยส่วนใหญ่ได้รับการจัดการและโฮสต์บน Git Git ได้กลายเป็นแพลตฟอร์มมาตรฐานสำหรับการจัดการซอร์สโค้ดแบบกระจาย การควบคุมเวอร์ชัน และการทำงานร่วมกันจากทุกที่ในโลก Git นั้นรวดเร็วและมีประสิทธิภาพ มีสองวิธีหลักในการโฮสต์และจัดการรหัส Git ของคุณ:

ก่อนเจาะลึกแนวทางเหล่านี้ เรามาทำความเข้าใจว่า repo ทำงานอย่างไร

Repos คืออะไร?

ที่เก็บ (Repo) มีโฟลเดอร์และไฟล์ทั้งหมดของโครงการของคุณ นอกจากนี้ยังมีข้อมูลเกี่ยวกับผู้ใช้ ผู้คน และคอมพิวเตอร์

ข้อมูลที่เก็บมีการควบคุมเวอร์ชัน repo สามารถเป็นเจ้าของโดยบุคคลหรือกลุ่มสมาชิกในทีม

Git เป็นที่เก็บข้อมูล อาจเป็นสาธารณะ ส่วนตัว หรือภายในก็ได้ GitHub เป็นบริการโฮสต์ของที่เก็บ Git และมีส่วนต่อประสานกับผู้ใช้

Git ให้คุณสมบัติการควบคุมเวอร์ชันและการแชร์โค้ด อย่างไรก็ตาม สิ่งที่ทำให้ Git แตกต่างก็คือหากนักพัฒนาต้องการเปลี่ยนแปลงไฟล์ของตน พวกเขาสามารถคัดลอกที่เก็บทั้งหมดไปยังระบบภายในเครื่องได้ ดังนั้น แม้ว่านักพัฒนาจะไม่มีสิทธิ์เขียนในโครงการใดโครงการหนึ่ง พวกเขาสามารถคัดลอกเนื้อหาในเครื่องและแก้ไขได้ (เรียกว่าการฟอร์ก)

นอกจากนี้ หากนักพัฒนาต้องการแชร์การเปลี่ยนแปลงที่ทำในเครื่อง พวกเขาสามารถส่ง “คำขอดึง” ไปยังเจ้าของโครงการได้

โครงการสามารถมีบริการเดียว ถ้าโปรเจ็กต์ของคุณมีหลายเวิร์กโฟลว์ คุณสามารถสร้างบริการได้หลายรายการสำหรับแต่ละเวิร์กโฟลว์ นักพัฒนาส่วนใหญ่ต้องการแยกโปรเจ็กต์ขนาดใหญ่ออกเป็นบริการอิสระที่มีขนาดเล็กกว่า โดยมีฟังก์ชันตั้งแต่หนึ่งฟังก์ชันขึ้นไป แต่ละบริการสามารถแก้ปัญหาทางธุรกิจต่างๆ ด้วยความนิยมของเฟรมเวิร์กแบบไร้เซิร์ฟเวอร์ ผู้ใช้สามารถเข้าถึงฟังก์ชันต่างๆ ที่เป็นบริการได้

เมื่อคุณสร้างและใช้งานฟังก์ชันเหล่านี้แล้ว ขั้นตอนต่อไปคือการกำหนดโครงสร้างและเวอร์ชันควบคุม – คุณสามารถมีบริการทั้งหมดของคุณในที่เก็บข้อมูลเดียว (mono-repo) หรือมีพื้นที่เก็บข้อมูลแยกต่างหากสำหรับแต่ละบริการที่คุณมี ( หลาย repo)!

Mono-repo คืออะไร?

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

บริษัทต่างๆ เช่น Facebook, Google และ Dropbox ใช้ mono-repo

ข้อดีของ Mono-repo

วิธี Mono-repo มีข้อดีหลายประการ:

• ที่เดียวในการจัดเก็บรหัสโครงการทั้งหมด และทุกคนในทีมสามารถเข้าถึงได้
• ใช้ซ้ำและแชร์รหัสได้ง่าย ทำงานร่วมกับทีม
• ง่ายต่อการเข้าใจผลกระทบของการเปลี่ยนแปลงของคุณที่มีต่อโครงการทั้งหมด
• ตัวเลือกที่ดีที่สุดสำหรับการรีแฟคเตอร์โค้ดและการเปลี่ยนแปลงครั้งใหญ่ในโค้ด
• สมาชิกในทีมสามารถดูภาพรวมของโครงการทั้งหมดได้
• ง่ายต่อการจัดการการพึ่งพา

ข้อเสียของ Mono-repo

แน่นอน mono-repo มีข้อเสียอยู่บ้าง หลักๆ อยู่ที่ประสิทธิภาพ หากโปรเจ็กต์ของคุณเติบโตและมีการเพิ่มไฟล์ทุกวัน ๆ การเช็คเอาท์ การดึง และการดำเนินการอื่นๆ อาจช้าลงและการค้นหาไฟล์อาจใช้เวลานานขึ้น

นอกจากนี้ หากคุณจ้างผู้รับเหมาอิสระจำนวนมากสำหรับโครงการของคุณ การให้พวกเขาเข้าถึงฐานรหัสทั้งหมดอาจไม่ปลอดภัยนัก

นอกจากนี้ ยังเป็นเรื่องยากที่จะใช้ Continuous Deployments (CD) เนื่องจากหลายคนสามารถเช็คอินการเปลี่ยนแปลงได้ และระบบ Continuous Integration (CI) ของคุณอาจต้องทำการสร้างใหม่หลายครั้ง

บริษัทขนาดใหญ่ที่ใช้ mono-repos ได้ปรับแต่งเครื่องมือเพื่อจัดการกับปัญหาการปรับขนาด ตัวอย่างเช่น Facebook ใช้ระบบไฟล์แบบกำหนดเองและการควบคุมแหล่งที่มา

Multi-repo คืออะไร?

ในแนวทางการซื้อซ้ำหลายรายการ มีที่เก็บหลายแห่งที่โฮสต์ไลบรารีและบริการต่างๆ ของโปรเจ็กต์ หากมีการเปลี่ยนแปลงบริการ นักพัฒนาจำเป็นต้องสร้างบริการนั้นใหม่เท่านั้น ไม่ใช่ทั้งโครงการ บุคคลและทีมสามารถทำงานในบริการเฉพาะของตน และเข้าถึงได้เฉพาะบริการที่จำเป็นเท่านั้น

บริษัทอย่าง Netflix และ Amazon ใช้หลาย repos

ข้อดีของ Multi-repo

จำนวนบริษัทที่นำ multi-repo มาใช้มากกว่าบริษัทที่ซื้อ mono-repo เนื่องจากเหตุผลดังต่อไปนี้:

• แต่ละบริการและไลบรารีมีการกำหนดเวอร์ชันของตัวเอง
• การเช็คเอาต์และดึงโค้ดมีขนาดเล็กและแยกจากกัน ดังนั้นจึงไม่มีปัญหาด้านประสิทธิภาพแม้ว่าขนาดโครงการจะเพิ่มขึ้น
• ทีมสามารถทำงานได้อย่างอิสระและไม่จำเป็นต้องเข้าถึง codebase ทั้งหมด
• การพัฒนาที่รวดเร็วและความยืดหยุ่น
• แต่ละบริการสามารถเผยแพร่แยกกันและมีวงจรการปรับใช้ของตัวเอง ทำให้ CI และ CD ง่ายต่อการใช้งาน
• การควบคุมการเข้าถึงที่ดีขึ้น – ทุกทีมไม่จำเป็นต้องมีสิทธิ์เข้าถึงไลบรารีทั้งหมดอย่างเต็มรูปแบบ – แต่สามารถเข้าอ่านได้หากต้องการ

ข้อเสียของ Multi-repo

• ต้องซิงค์การพึ่งพาและไลบรารีที่ใช้ในบริการและโครงการเป็นประจำเพื่อรับเวอร์ชันล่าสุด
• ส่งเสริมวัฒนธรรมแบบแยกส่วนในบางจุด นำไปสู่โค้ดที่ซ้ำกัน และแต่ละทีมพยายามแก้ไขปัญหาเดียวกัน
• แต่ละทีมอาจปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดที่แตกต่างกันสำหรับรหัสของตน ซึ่งทำให้เกิดปัญหาในการปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดทั่วไป

ความแตกต่างระหว่าง Mono และ Multi Repo

ให้เราสรุปความแตกต่างระหว่าง mono-repo และ multi-repo:

โมโน-repo
หลาย repo
รหัสทั้งหมดของโครงการทั้งหมดขององค์กรอยู่ในที่เก็บส่วนกลาง
แต่ละบริการและโครงการมีที่เก็บแยกต่างหาก
ทีมสามารถทำงานร่วมกันและทำงานร่วมกันได้ เห็นความเปลี่ยนแปลงของกันและกัน
ทีมสามารถทำงานได้อย่างอิสระ การเปลี่ยนแปลงส่วนบุคคลไม่ส่งผลต่อการเปลี่ยนแปลงโดยทีมหรือโครงการอื่น
แต่ละคนเข้าถึงโครงสร้างโครงการทั้งหมด
ผู้ดูแลระบบสามารถจำกัดการควบคุมการเข้าถึงโครงการหรือบริการที่นักพัฒนาต้องการเข้าถึง
ปัญหาการขยายขนาดอาจเกิดขึ้นได้หากขนาดของโครงการเติบโตขึ้นเรื่อยๆ
ประสิทธิภาพที่ดีเพราะรหัสที่จำกัดและหน่วยบริการที่เล็กกว่า
ยากที่จะปรับใช้การปรับใช้อย่างต่อเนื่อง (CD) และการรวมอย่างต่อเนื่อง (CI)
นักพัฒนาสามารถบรรลุ CD และ CI ได้อย่างง่ายดายเพราะสามารถสร้างบริการได้อย่างอิสระ
นักพัฒนาสามารถแชร์ไลบรารี, API และโค้ดทั่วไปอื่นๆ ได้อย่างง่ายดายเมื่ออัปเดตในที่เก็บส่วนกลาง
การเปลี่ยนแปลงใดๆ ในไลบรารีและรหัสทั่วไปอื่นๆ ควรซิงค์เป็นระยะเพื่อหลีกเลี่ยงปัญหาในภายหลัง

บทสรุป

ทั้ง mono-repo และ multi-repo ได้รับความนิยมเท่ากัน และอันไหนดีกว่าขึ้นอยู่กับขนาดโปรเจ็กต์ ความต้องการของโปรเจ็กต์ และระดับของการกำหนดเวอร์ชันและการควบคุมการเข้าถึงที่คุณต้องการ

Mono-repo สนับสนุนความสม่ำเสมอในขณะที่ multi-repo เน้นที่การแยกส่วน ในขณะที่อยู่ใน repo เดียว ทั้งทีมสามารถเห็นการเปลี่ยนแปลงที่ทำโดยบุคคลหนึ่งคน โดย multi-repo จะสร้าง repo แยกกันสำหรับแต่ละทีม ซึ่งมีสิทธิ์เข้าถึงเฉพาะบริการที่จำเป็นเท่านั้น หากคุณต้องการใช้ mono-repo และ multi-repo ร่วมกันสำหรับโครงการของคุณ คุณสามารถไปที่ เมต้าเป็นเครื่องมือในการจัดการหลายโครงการและห้องสมุด

คุณอาจสนใจแหล่งข้อมูลฟรีเพื่อเรียนรู้ Git