เมื่อดูหน้าก่อนๆ จะเห็นว่ามีธีมหนึ่งที่ปรากฏซ้ำๆ คือ การจัดการโค้ดของคุณเองนั้นค่อนข้างตรงไปตรงมา แต่การจัดการทรัพยากร Dependency นั้นยากกว่ามาก ทรัพยากร Dependency มีหลายประเภท บางครั้งก็ขึ้นอยู่กับงาน (เช่น "เผยแพร่เอกสารก่อนที่ฉันจะทำเครื่องหมายว่าการเผยแพร่เสร็จสมบูรณ์") และบางครั้งก็ขึ้นอยู่กับอาร์ติแฟกต์ (เช่น "ฉันต้องมีไลบรารีคอมพิวเตอร์วิทัศน์เวอร์ชันล่าสุดเพื่อสร้างโค้ด") บางครั้งคุณก็มีทรัพยากร Dependency ภายในที่ขึ้นอยู่กับส่วนอื่นๆ ของฐานของโค้ด และบางครั้งก็มีทรัพยากร Dependency ภายนอกที่ขึ้นอยู่กับโค้ดหรือข้อมูลที่เป็นของทีมอื่น (ไม่ว่าจะเป็นในองค์กรของคุณหรือบุคคลที่สาม) แต่ไม่ว่าในกรณีใด แนวคิดที่ว่า "ฉันต้องมีสิ่งนี้ก่อนจึงจะมีสิ่งนั้นได้" เป็นสิ่งที่เกิดขึ้นซ้ำๆ ในการออกแบบระบบบิลด์ และการจัดการทรัพยากร Dependency อาจเป็นงานพื้นฐานที่สุดของระบบบิลด์
การจัดการโมดูลและทรัพยากร Dependency
โปรเจ็กต์ที่ใช้ระบบบิลด์แบบอิงตามอาร์ติแฟกต์ เช่น Bazel จะแบ่งออกเป็นชุดโมดูล โดยโมดูลจะแสดงทรัพยากร Dependency ที่ขึ้นต่อกันผ่านไฟล์ BUILD การจัดระเบียบโมดูลและทรัพยากร Dependency เหล่านี้อย่างเหมาะสมอาจส่งผลอย่างมากต่อทั้งประสิทธิภาพของระบบบิลด์และปริมาณงานที่ต้องใช้ในการดูแลรักษา
การใช้โมดูลแบบละเอียดและกฎ 1:1:1
คำถามแรกที่เกิดขึ้นเมื่อสร้างโครงสร้างบิลด์แบบอิงตามอาร์ติแฟกต์คือการตัดสินใจว่าโมดูลแต่ละโมดูลควรครอบคลุมฟังก์ชันการทำงานมากน้อยเพียงใด ใน Bazel โมดูล จะแสดงด้วยเป้าหมายที่ระบุหน่วยที่สร้างได้ เช่น java_library หรือ go_binary ในกรณีที่มากที่สุด โปรเจ็กต์ทั้งหมดอาจอยู่ในโมดูลเดียวโดยวางไฟล์ BUILD หนึ่งไฟล์ไว้ที่รูทและรวมไฟล์ซอร์สทั้งหมดของโปรเจ็กต์นั้นแบบเรียกซ้ำ ในกรณีที่น้อยที่สุด ไฟล์ซอร์สเกือบทุกไฟล์อาจกลายเป็นโมดูลของตัวเอง ซึ่งกำหนดให้แต่ละไฟล์ต้องแสดงรายการทุกไฟล์อื่นๆ ที่ขึ้นอยู่กับไฟล์นั้นในไฟล์ BUILD
โปรเจ็กต์ส่วนใหญ่อยู่ระหว่าง 2 กรณีนี้ และการเลือกเกี่ยวข้องกับการแลกเปลี่ยนระหว่างประสิทธิภาพและความสามารถในการดูแลรักษา การใช้โมดูลเดียวสำหรับโปรเจ็กต์ทั้งหมดอาจหมายความว่าคุณไม่จำเป็นต้องแตะไฟล์ BUILD เลย ยกเว้นเมื่อเพิ่มทรัพยากร Dependency ภายนอก แต่หมายความว่าระบบบิลด์ต้องสร้างโปรเจ็กต์ทั้งหมดพร้อมกันเสมอ ซึ่งหมายความว่าระบบจะไม่สามารถขนานกันหรือกระจายส่วนต่างๆ ของบิลด์ได้ และจะไม่สามารถแคชส่วนที่สร้างไว้แล้วได้ การใช้ 1 โมดูลต่อ 1 ไฟล์นั้นตรงกันข้าม โดยระบบบิลด์จะมีความยืดหยุ่นสูงสุดในการแคชและกำหนดเวลาขั้นตอนต่างๆ ของบิลด์ แต่วิศวกรต้องใช้ความพยายามมากขึ้นในการดูแลรักษารายการทรัพยากร Dependency ทุกครั้งที่เปลี่ยนไฟล์ที่อ้างอิง
แม้ว่าความละเอียดที่แน่นอนจะแตกต่างกันไปตามภาษา (และมักจะแตกต่างกันไปในแต่ละภาษาด้วย) แต่ Google มักจะชอบโมดูลที่มีขนาดเล็กกว่ามากเมื่อเทียบกับโมดูลที่อาจเขียนขึ้นโดยทั่วไปในระบบบิลด์แบบอิงตามงาน ไบนารีเวอร์ชันที่ใช้งานจริงทั่วไปที่ Google มักจะขึ้นอยู่กับเป้าหมายหลายหมื่นรายการ และแม้แต่ทีมขนาดปานกลางก็อาจเป็นเจ้าของเป้าหมายหลายร้อยรายการภายในฐานของโค้ด สำหรับภาษาอย่าง Java ที่มีแนวคิดเรื่องการแพ็กเกจในตัวที่ชัดเจน ไดเรกทอรีแต่ละรายการมักจะมีแพ็กเกจ เป้าหมาย และไฟล์ BUILD เดียว (Pants ซึ่งเป็นระบบบิลด์อีกระบบหนึ่งที่อิงตาม Bazel เรียกสิ่งนี้ว่ากฎ 1:1:1) ภาษาที่มีข้อกำหนดการแพ็กเกจที่ยืดหยุ่นกว่ามักจะกำหนดเป้าหมายหลายรายการต่อไฟล์ BUILD
ประโยชน์ของเป้าหมายบิลด์ขนาดเล็กจะเริ่มเห็นได้ชัดเจนเมื่อขยายขนาด เนื่องจากเป้าหมายเหล่านี้ทำให้บิลด์แบบกระจายเร็วขึ้นและไม่จำเป็นต้องสร้างเป้าหมายใหม่บ่อยนัก
ข้อดีจะยิ่งชัดเจนมากขึ้นหลังจากมีการทดสอบ เนื่องจากเป้าหมายที่ละเอียดขึ้นหมายความว่าระบบบิลด์จะฉลาดขึ้นมากในการเรียกใช้เฉพาะชุดย่อยของการทดสอบที่จำกัดซึ่งอาจได้รับผลกระทบจากการเปลี่ยนแปลงที่กำหนด เนื่องจาก Google เชื่อมั่นในประโยชน์ที่เป็นระบบของการใช้เป้าหมายขนาดเล็ก เราจึงได้พยายามลดข้อเสียโดยการลงทุนในเครื่องมือเพื่อจัดการไฟล์ BUILD โดยอัตโนมัติเพื่อไม่ให้เป็นภาระแก่นักพัฒนาแอป
เครื่องมือบางอย่าง เช่น buildifier และ buildozer มีให้ใช้งานกับ
Bazel ใน
buildtools ไดเรกทอรี
การลดระดับการเข้าถึงโมดูล
Bazel และระบบบิลด์อื่นๆ อนุญาตให้แต่ละเป้าหมายระบุระดับการเข้าถึง ซึ่งเป็นพร็อพเพอร์ตี้ที่กำหนดว่าเป้าหมายอื่นๆ ใดบ้างที่อาจขึ้นอยู่กับเป้าหมายนั้น เป้าหมายส่วนตัวจะอ้างอิงได้เฉพาะภายในไฟล์ BUILD ของตัวเองเท่านั้น เป้าหมายอาจให้ระดับการเข้าถึงที่กว้างขึ้นแก่เป้าหมายของรายการไฟล์ BUILD ที่กำหนดไว้อย่างชัดเจน หรือในกรณีที่ระดับการเข้าถึงเป็นสาธารณะ ก็จะให้แก่ทุกเป้าหมายในพื้นที่ทำงาน
เช่นเดียวกับภาษาโปรแกรมส่วนใหญ่ โดยปกติแล้วการลดระดับการเข้าถึงให้มากที่สุดเท่าที่จะทำได้จะเป็นวิธีที่ดีที่สุด โดยทั่วไป ทีมที่ Google จะตั้งค่าเป้าหมายเป็นสาธารณะก็ต่อเมื่อเป้าหมายเหล่านั้นแสดงถึงไลบรารีที่ใช้กันอย่างแพร่หลายซึ่งทีมใดก็ได้ที่ Google สามารถใช้ได้
ทีมที่ต้องการให้ทีมอื่นๆ ประสานงานกับทีมของตนก่อนที่จะใช้โค้ดจะดูแลรักษารายการที่อนุญาตของเป้าหมายลูกค้าเป็นระดับการเข้าถึงของเป้าหมาย เป้าหมายการติดตั้งใช้งานภายในของแต่ละทีมจะจำกัดไว้เฉพาะไดเรกทอรีที่เป็นของทีม และไฟล์ BUILD ส่วนใหญ่จะมีเป้าหมายเดียวที่ไม่ใช่เป้าหมายส่วนตัว
การจัดการทรัพยากร Dependency
โมดูลต้องอ้างอิงถึงกันได้ ข้อเสียของการแบ่งฐานของโค้ดออกเป็นโมดูลแบบละเอียดคือคุณต้องจัดการทรัพยากร Dependency ระหว่างโมดูลเหล่านั้น (แม้ว่าเครื่องมือจะช่วยทำให้กระบวนการนี้เป็นแบบอัตโนมัติได้) การแสดงทรัพยากร Dependency เหล่านี้มักจะเป็นเนื้อหาส่วนใหญ่ในไฟล์ BUILD
ทรัพยากร Dependency ภายใน
ในโปรเจ็กต์ขนาดใหญ่ที่แบ่งออกเป็นโมดูลแบบละเอียด ทรัพยากร Dependency ส่วนใหญ่มีแนวโน้มที่จะเป็นทรัพยากร Dependency ภายใน นั่นคือทรัพยากร Dependency ที่ขึ้นอยู่กับเป้าหมายอื่นที่กำหนดและสร้างขึ้นในที่เก็บซอร์สโค้ดเดียวกัน ทรัพยากร Dependency ภายในแตกต่างจากทรัพยากร Dependency ภายนอกตรงที่สร้างขึ้นจากซอร์สโค้ดแทนที่จะดาวน์โหลดเป็นอาร์ติแฟกต์ที่สร้างไว้ล่วงหน้าขณะเรียกใช้บิลด์ ซึ่งหมายความว่าทรัพยากร Dependency ภายในไม่มีแนวคิดเรื่อง "เวอร์ชัน" โดยเป้าหมายและทรัพยากร Dependency ภายในทั้งหมดจะสร้างขึ้นที่คอมมิต/การแก้ไขเดียวกันในที่เก็บเสมอ ปัญหาหนึ่งที่ควรจัดการอย่างระมัดระวังเกี่ยวกับทรัพยากร Dependency ภายในคือวิธีจัดการทรัพยากร Dependency แบบถ่ายทอด (รูปที่ 1) สมมติว่าเป้าหมาย A ขึ้นอยู่กับเป้าหมาย B ซึ่งขึ้นอยู่กับเป้าหมายไลบรารีทั่วไป C เป้าหมาย A ควรใช้คลาสที่กำหนดไว้ในเป้าหมาย C ได้หรือไม่
รูปที่ 1 ทรัพยากร Dependency แบบถ่ายทอด
เครื่องมือพื้นฐานไม่มีปัญหาในเรื่องนี้ เนื่องจากทั้ง B และ C จะลิงก์กับเป้าหมาย A เมื่อสร้างขึ้น ดังนั้น A จะรู้จักสัญลักษณ์ใดๆ ที่กำหนดไว้ใน C Bazel อนุญาตให้ทำเช่นนี้มาหลายปี แต่เมื่อ Google เติบโตขึ้น เราก็เริ่มเห็นปัญหา สมมติว่ามีการปรับโครงสร้าง B ใหม่เพื่อให้ B ไม่จำเป็นต้องขึ้นอยู่กับ C อีกต่อไป หากนำทรัพยากร Dependency ของ B ที่ขึ้นอยู่กับ C ออกแล้ว A และเป้าหมายอื่นๆ ที่ใช้ C ผ่านทรัพยากร Dependency ที่ขึ้นอยู่กับ B จะหยุดทำงาน กล่าวคือ ทรัพยากร Dependency ของเป้าหมายกลายเป็นส่วนหนึ่งของสัญญาแบบสาธารณะและไม่สามารถเปลี่ยนแปลงได้อย่างปลอดภัย ซึ่งหมายความว่าทรัพยากร Dependency สะสมมากขึ้นเมื่อเวลาผ่านไป และบิลด์ที่ Google เริ่มช้าลง
ในที่สุด Google ก็แก้ไขปัญหานี้โดยเปิดตัว "โหมดทรัพยากร Dependency แบบถ่ายทอดที่เข้มงวด" ใน Bazel ในโหมดนี้ Bazel จะตรวจหาว่าเป้าหมายพยายามอ้างอิงสัญลักษณ์โดยไม่ได้ขึ้นอยู่กับสัญลักษณ์นั้นโดยตรงหรือไม่ หากเป็นเช่นนั้น ระบบจะแสดงข้อผิดพลาดและคำสั่งเชลล์ที่ใช้แทรกทรัพยากร Dependency โดยอัตโนมัติ การเปิดตัวการเปลี่ยนแปลงนี้ในฐานโค้ดทั้งหมดของ Google และการเปลี่ยนโครงสร้างภายในโค้ดเป้าหมายบิลด์หลายล้านรายการเพื่อให้แสดงรายการทรัพยากร Dependency อย่างชัดเจนเป็นความพยายามที่ใช้เวลาหลายปี แต่ก็คุ้มค่า ตอนนี้บิลด์ของเราเร็วขึ้นมากเนื่องจากเป้าหมายมีทรัพยากร Dependency ที่ไม่จำเป็นน้อยลง และวิศวกรมีอำนาจในการนำทรัพยากร Dependency ที่ไม่ต้องการออกโดยไม่ต้องกังวลว่าเป้าหมายที่ขึ้นอยู่กับทรัพยากร Dependency เหล่านั้นจะหยุดทำงาน
เช่นเคย การบังคับใช้ทรัพยากร Dependency แบบถ่ายทอดที่เข้มงวดเกี่ยวข้องกับการแลกเปลี่ยน โดยทำให้ไฟล์บิลด์มีรายละเอียดมากขึ้น เนื่องจากตอนนี้ต้องแสดงรายการไลบรารีที่ใช้บ่อยอย่างชัดเจนในหลายๆ ที่แทนที่จะดึงข้อมูลมาโดยบังเอิญ และวิศวกรต้องใช้ความพยายามมากขึ้นในการเพิ่มทรัพยากร Dependency ลงในไฟล์ BUILD เราได้พัฒนาเครื่องมือที่ช่วยลดความยุ่งยากนี้โดยการตรวจหาทรัพยากร Dependency ที่ขาดหายไปจำนวนมากโดยอัตโนมัติและเพิ่มทรัพยากร Dependency เหล่านั้นลงในไฟล์ BUILD โดยไม่ต้องให้นักพัฒนาแอปเข้ามาเกี่ยวข้อง แต่แม้จะไม่มีเครื่องมือดังกล่าว เราก็พบว่าการแลกเปลี่ยนนี้คุ้มค่าเมื่อฐานของโค้ดขยายขนาดขึ้น การเพิ่มทรัพยากร Dependency ลงในไฟล์ BUILD อย่างชัดเจนเป็นค่าใช้จ่ายที่เกิดขึ้นครั้งเดียว แต่การจัดการทรัพยากร Dependency แบบถ่ายทอดโดยนัยอาจทำให้เกิดปัญหาต่อเนื่องตราบใดที่เป้าหมายบิลด์ยังคงอยู่ โดยค่าเริ่มต้น Bazel
จะบังคับใช้ทรัพยากร Dependency แบบถ่ายทอดที่เข้มงวด
กับโค้ด Java
ทรัพยากร Dependency ภายนอก
หากทรัพยากร Dependency ไม่ใช่ทรัพยากร Dependency ภายใน ก็ต้องเป็นทรัพยากร Dependency ภายนอก ทรัพยากร Dependency ภายนอกคือทรัพยากร Dependency ที่ขึ้นอยู่กับอาร์ติแฟกต์ที่สร้างและจัดเก็บไว้นอกระบบบิลด์ ระบบจะนำเข้าทรัพยากร Dependency โดยตรงจากที่เก็บอาร์ติแฟกต์ (โดยปกติจะเข้าถึงผ่านอินเทอร์เน็ต) และใช้ทรัพยากร Dependency ดังกล่าวตามที่เป็นอยู่แทนที่จะสร้างขึ้นจากซอร์สโค้ด ความแตกต่างที่สำคัญที่สุดอย่างหนึ่งระหว่างทรัพยากร Dependency ภายนอกและภายในคือทรัพยากร Dependency ภายนอกมีเวอร์ชัน และเวอร์ชันเหล่านั้นมีอยู่โดยไม่ขึ้นอยู่กับซอร์สโค้ดของโปรเจ็กต์
การจัดการทรัพยากร Dependency แบบอัตโนมัติเทียบกับการจัดการทรัพยากร Dependency ด้วยตนเอง
ระบบบิลด์สามารถอนุญาตให้จัดการเวอร์ชันของทรัพยากร Dependency ภายนอกด้วยตนเองหรือโดยอัตโนมัติ เมื่อจัดการด้วยตนเอง ไฟล์บิลด์
จะแสดงรายการเวอร์ชันที่ต้องการดาวน์โหลดจากที่เก็บอาร์ติแฟกต์อย่างชัดเจน
โดยมักจะใช้ สตริงเวอร์ชันเชิงความหมาย เช่น
1.1.4 เมื่อจัดการโดยอัตโนมัติ ไฟล์ซอร์สจะระบุช่วงเวอร์ชันที่ยอมรับได้ และระบบบิลด์จะดาวน์โหลดเวอร์ชันล่าสุดเสมอ ตัวอย่างเช่น Gradle อนุญาตให้ประกาศเวอร์ชันทรัพยากร Dependency เป็น "1.+" เพื่อระบุว่าเวอร์ชันย่อยหรือเวอร์ชันแพตช์ของทรัพยากร Dependency ใดก็ได้เป็นที่ยอมรับ ตราบใดที่เวอร์ชันหลักเป็น 1
ทรัพยากร Dependency ที่จัดการโดยอัตโนมัติอาจสะดวกสำหรับโปรเจ็กต์ขนาดเล็ก แต่โดยปกติแล้วจะเป็นสูตรที่ทำให้เกิดปัญหาในโปรเจ็กต์ที่มีขนาดไม่เล็กนักหรือมีวิศวกรมากกว่า 1 คนทำงานอยู่ ปัญหาเกี่ยวกับทรัพยากร Dependency ที่จัดการโดยอัตโนมัติคือคุณไม่สามารถควบคุมเวลาที่เวอร์ชันจะอัปเดตได้ ไม่มีวิธีใดที่จะรับประกันได้ว่าบุคคลภายนอกจะไม่ทำการอัปเดตที่ทำให้เกิดการเปลี่ยนแปลง (แม้ว่าจะอ้างว่าใช้การกำหนดเวอร์ชันเชิงความหมายก็ตาม) ดังนั้นบิลด์ที่ทำงานได้ในวันหนึ่งอาจหยุดทำงานในวันถัดไปโดยไม่มีวิธีง่ายๆ ในการตรวจหาว่ามีการเปลี่ยนแปลงอะไรบ้างหรือย้อนกลับไปเป็นสถานะที่ทำงานได้ แม้ว่าบิลด์จะไม่หยุดทำงาน แต่ก็อาจมีการเปลี่ยนแปลงพฤติกรรมหรือประสิทธิภาพเล็กน้อยซึ่งติดตามได้ยาก
ในทางตรงกันข้าม เนื่องจากทรัพยากร Dependency ที่จัดการด้วยตนเองต้องมีการเปลี่ยนแปลงในการควบคุมซอร์สโค้ด จึงค้นพบและย้อนกลับได้ง่าย และคุณสามารถเช็กเอาต์ที่เก็บเวอร์ชันเก่าเพื่อสร้างด้วยทรัพยากร Dependency เก่าได้ Bazel กำหนดให้ระบุเวอร์ชันของทรัพยากร Dependency ทั้งหมดด้วยตนเอง แม้ในระดับปานกลาง ค่าใช้จ่ายในการจัดการเวอร์ชันด้วยตนเองก็คุ้มค่ากับความเสถียรที่ได้รับ
กฎเวอร์ชันเดียว
โดยปกติแล้วไลบรารีเวอร์ชันต่างๆ จะแสดงด้วยอาร์ติแฟกต์ที่ต่างกัน ดังนั้นในทางทฤษฎีแล้วจึงไม่มีเหตุผลใดที่เวอร์ชันต่างๆ ของทรัพยากร Dependency ภายนอกเดียวกันจะประกาศในระบบบิลด์ภายใต้ชื่อต่างๆ ไม่ได้ ด้วยวิธีนี้ เป้าหมายแต่ละรายการจะเลือกเวอร์ชันของทรัพยากร Dependency ที่ต้องการใช้ได้ แต่ในทางปฏิบัติแล้ววิธีนี้ทำให้เกิดปัญหามากมาย ดังนั้น Google จึงบังคับใช้กฎ เวอร์ชันเดียว ที่เข้มงวดกับทรัพยากร Dependency ทั้งหมดของบุคคลที่สามในฐานโค้ดของเรา
ปัญหาที่ใหญ่ที่สุดของการอนุญาตให้ใช้หลายเวอร์ชันคือปัญหาทรัพยากร Dependency แบบไดมอนด์ สมมติว่าเป้าหมาย A ขึ้นอยู่กับเป้าหมาย B และไลบรารีภายนอกเวอร์ชัน 1 หากมีการปรับโครงสร้างเป้าหมาย B ใหม่ในภายหลังเพื่อเพิ่มทรัพยากร Dependency ที่ขึ้นอยู่กับไลบรารีภายนอกเวอร์ชัน 2 เป้าหมาย A จะหยุดทำงานเนื่องจากตอนนี้ขึ้นอยู่กับไลบรารีเดียวกัน 2 เวอร์ชันที่ต่างกันโดยนัย กล่าวคือ การเพิ่มทรัพยากร Dependency ใหม่จากเป้าหมายไปยังไลบรารีของบุคคลที่สามที่มีหลายเวอร์ชันนั้นไม่ปลอดภัยเลย เนื่องจากผู้ใช้เป้าหมายนั้นอาจขึ้นอยู่กับเวอร์ชันอื่นอยู่แล้ว การปฏิบัติตามกฎเวอร์ชันเดียวจะทำให้ความขัดแย้งนี้เกิดขึ้นไม่ได้ หากเป้าหมายเพิ่มทรัพยากร Dependency ที่ขึ้นอยู่กับไลบรารีของบุคคลที่สาม ทรัพยากร Dependency ที่มีอยู่ทั้งหมดจะอยู่ในเวอร์ชันเดียวกันอยู่แล้ว จึงสามารถอยู่ร่วมกันได้อย่างราบรื่น
ทรัพยากร Dependency ภายนอกแบบถ่ายทอด
การจัดการทรัพยากร Dependency แบบถ่ายทอดของทรัพยากร Dependency ภายนอกอาจเป็นเรื่องยากเป็นพิเศษ ที่เก็บอาร์ติแฟกต์หลายแห่ง เช่น Maven Central อนุญาตให้อาร์ติแฟกต์ระบุทรัพยากร Dependency ที่ขึ้นอยู่กับอาร์ติแฟกต์อื่นๆ ในที่เก็บเวอร์ชันที่เฉพาะเจาะจง เครื่องมือบิลด์ เช่น Maven หรือ Gradle มักจะดาวน์โหลดทรัพยากร Dependency แบบถ่ายทอดแต่ละรายการแบบเรียกซ้ำโดยค่าเริ่มต้น ซึ่งหมายความว่าการเพิ่มทรัพยากร Dependency เดียวในโปรเจ็กต์อาจทำให้มีการดาวน์โหลดอาร์ติแฟกต์หลายสิบรายการโดยรวม
วิธีนี้สะดวกมาก เมื่อเพิ่มทรัพยากร Dependency ที่ขึ้นอยู่กับไลบรารีใหม่ คุณจะต้องเสียเวลาติดตามทรัพยากร Dependency แบบถ่ายทอดของไลบรารีนั้นและเพิ่มทรัพยากร Dependency ทั้งหมดด้วยตนเอง แต่ก็มีข้อเสียอย่างมากเช่นกัน เนื่องจากไลบรารีต่างๆ อาจขึ้นอยู่กับไลบรารีเดียวกันของบุคคลที่สามเวอร์ชันต่างๆ กลยุทธ์นี้จึงละเมิดกฎเวอร์ชันเดียวและทำให้เกิดปัญหาทรัพยากร Dependency แบบไดมอนด์ หากเป้าหมายของคุณขึ้นอยู่กับไลบรารีภายนอก 2 รายการที่ใช้ทรัพยากร Dependency เดียวกันเวอร์ชันต่างๆ คุณจะไม่มีทางรู้ว่าจะได้รับเวอร์ชันใด ซึ่งหมายความว่าการอัปเดตทรัพยากร Dependency ภายนอกอาจทำให้เกิดข้อผิดพลาดที่ดูเหมือนไม่เกี่ยวข้องทั่วทั้งฐานของโค้ด หากเวอร์ชันใหม่เริ่มดึงทรัพยากร Dependency บางรายการเวอร์ชันที่ขัดแย้งกัน
ด้วยเหตุนี้ Bazel จึงไม่ดาวน์โหลดทรัพยากร Dependency แบบถ่ายทอดโดยอัตโนมัติ
และน่าเสียดายที่ไม่มีวิธีที่ง่ายและได้ผลลัพธ์ที่ต้องการเสมอไป ทางเลือกของ Bazel คือกำหนดให้มีไฟล์ส่วนกลางที่แสดงรายการทรัพยากร Dependency ภายนอกทั้งหมดของที่เก็บและเวอร์ชันที่ชัดเจนที่ใช้สำหรับทรัพยากร Dependency นั้นทั่วทั้งที่เก็บ โชคดีที่ Bazel มีเครื่องมือที่สามารถสร้างไฟล์ดังกล่าวโดยอัตโนมัติซึ่งมีทรัพยากร Dependency แบบถ่ายทอดของชุดอาร์ติแฟกต์ Maven คุณสามารถเรียกใช้เครื่องมือนี้เพียงครั้งเดียวเพื่อสร้างไฟล์ WORKSPACE เริ่มต้นสำหรับโปรเจ็กต์ จากนั้นจึงอัปเดตไฟล์นั้นด้วยตนเองเพื่อปรับเวอร์ชันของทรัพยากร Dependency แต่ละรายการ
อีกครั้งที่การเลือกในที่นี้เป็นการเลือกระหว่างความสะดวกและความสามารถในการขยายขนาด โปรเจ็กต์ขนาดเล็กอาจไม่ต้องการกังวลเกี่ยวกับการจัดการทรัพยากร Dependency แบบถ่ายทอดด้วยตนเองและอาจใช้ทรัพยากร Dependency แบบถ่ายทอดอัตโนมัติได้ กลยุทธ์นี้จะน่าสนใจน้อยลงเรื่อยๆ เมื่อองค์กรและฐานของโค้ดขยายขนาดขึ้น และความขัดแย้งและผลลัพธ์ที่ไม่คาดคิดเกิดขึ้นบ่อยขึ้นเรื่อยๆ ในระดับที่ใหญ่ขึ้น ค่าใช้จ่ายในการจัดการทรัพยากร Dependency ด้วยตนเองจะน้อยกว่าค่าใช้จ่ายในการจัดการปัญหาที่เกิดจากการจัดการทรัพยากร Dependency แบบอัตโนมัติมาก
การแคชผลลัพธ์บิลด์โดยใช้ทรัพยากร Dependency ภายนอก
ทรัพยากร Dependency ภายนอกส่วนใหญ่มักมาจากบุคคลที่สามที่เผยแพร่ไลบรารีเวอร์ชันเสถียร โดยอาจไม่ให้ซอร์สโค้ด นอกจากนี้ องค์กรบางแห่งอาจเลือกที่จะทำให้โค้ดบางส่วนของตนเองพร้อมใช้งานเป็นอาร์ติแฟกต์ ซึ่งอนุญาตให้โค้ดส่วนอื่นๆ ขึ้นอยู่กับโค้ดเหล่านั้นเป็นทรัพยากร Dependency ของบุคคลที่สามแทนที่จะเป็นทรัพยากร Dependency ภายใน ในทางทฤษฎีแล้ววิธีนี้จะช่วยเร่งความเร็วบิลด์ได้หากอาร์ติแฟกต์ใช้เวลานานในการสร้างแต่ดาวน์โหลดได้รวดเร็ว
อย่างไรก็ตาม วิธีนี้ยังทำให้เกิดค่าใช้จ่ายและความซับซ้อนมากมาย โดยต้องมีคนรับผิดชอบในการสร้างอาร์ติแฟกต์แต่ละรายการและอัปโหลดอาร์ติแฟกต์เหล่านั้นไปยังที่เก็บอาร์ติแฟกต์ และไคลเอ็นต์ต้องตรวจสอบว่าอาร์ติแฟกต์เป็นเวอร์ชันล่าสุด การแก้ไขข้อบกพร่องก็ยากขึ้นมากเช่นกัน เนื่องจากระบบส่วนต่างๆ จะสร้างขึ้นจากจุดต่างๆ ในที่เก็บ และไม่มีมุมมองที่สอดคล้องกันของแผนผังซอร์สอีกต่อไป
วิธีที่ดีกว่าในการแก้ปัญหาอาร์ติแฟกต์ที่ใช้เวลานานในการสร้างคือการใช้ระบบบิลด์ที่รองรับการแคชระยะไกลตามที่อธิบายไว้ก่อนหน้านี้ ระบบบิลด์ดังกล่าวจะบันทึกอาร์ติแฟกต์ที่เป็นผลลัพธ์จากทุกบิลด์ไปยังตำแหน่งที่แชร์กันระหว่างวิศวกร ดังนั้นหากนักพัฒนาแอปขึ้นอยู่กับอาร์ติแฟกต์ที่สร้างขึ้นโดยบุคคลอื่นเมื่อเร็วๆ นี้ ระบบบิลด์จะดาวน์โหลดอาร์ติแฟกต์นั้นโดยอัตโนมัติแทนที่จะสร้างขึ้น วิธีนี้ให้ประโยชน์ด้านประสิทธิภาพทั้งหมดของการขึ้นอยู่กับอาร์ติแฟกต์โดยตรง ในขณะที่ยังคงรับประกันว่าบิลด์จะสอดคล้องกันราวกับว่าสร้างขึ้นจากซอร์สเดียวกันเสมอ นี่คือกลยุทธ์ที่ Google ใช้ภายใน และคุณสามารถกำหนดค่า Bazel ให้ใช้แคชระยะไกลได้
ความปลอดภัยและความน่าเชื่อถือของทรัพยากร Dependency ภายนอก
การขึ้นอยู่กับอาร์ติแฟกต์จากแหล่งที่มาของบุคคลที่สามมีความเสี่ยงโดยธรรมชาติ มีความเสี่ยงด้านความพร้อมใช้งานหากแหล่งที่มาของบุคคลที่สาม (เช่น ที่เก็บอาร์ติแฟกต์) หยุดทำงาน เนื่องจากบิลด์ทั้งหมดอาจหยุดชะงักหากดาวน์โหลดทรัพยากร Dependency ภายนอกไม่ได้ นอกจากนี้ยังมีความเสี่ยงด้านความปลอดภัยด้วย หากระบบของบุคคลที่สามถูกผู้โจมตีบุกรุก ผู้โจมตีอาจแทนที่อาร์ติแฟกต์ที่อ้างอิงด้วยอาร์ติแฟกต์ที่ออกแบบเอง ซึ่งอนุญาตให้ผู้โจมตีแทรกโค้ดที่กำหนดเองลงในบิลด์ของคุณได้ คุณสามารถลดปัญหาทั้งสองนี้ได้โดยการทำมิเรอร์อาร์ติแฟกต์ที่คุณขึ้นอยู่ด้วยไปยังเซิร์ฟเวอร์ที่คุณควบคุม และบล็อกไม่ให้ระบบบิลด์เข้าถึงที่เก็บอาร์ติแฟกต์ของบุคคลที่สาม เช่น Maven Central การแลกเปลี่ยนคือมิเรอร์เหล่านี้ต้องใช้ความพยายามและทรัพยากรในการดูแลรักษา ดังนั้นการเลือกว่าจะใช้หรือไม่จึงมักขึ้นอยู่กับขนาดของโปรเจ็กต์ นอกจากนี้ คุณยังป้องกันปัญหาด้านความปลอดภัยได้อย่างสมบูรณ์โดยใช้ค่าใช้จ่ายเพียงเล็กน้อยด้วยการกำหนดให้ระบุแฮชของอาร์ติแฟกต์แต่ละรายการของบุคคลที่สามในที่เก็บซอร์สโค้ด ซึ่งจะทำให้บิลด์ล้มเหลวหากมีการแก้ไขอาร์ติแฟกต์ อีกทางเลือกหนึ่งที่หลีกเลี่ยงปัญหาได้อย่างสมบูรณ์คือการจัดหาทรัพยากร Dependency ของโปรเจ็กต์ เมื่อโปรเจ็กต์จัดหาทรัพยากร Dependency ระบบจะเช็กอินทรัพยากร Dependency เหล่านั้นลงในการควบคุมซอร์สโค้ดพร้อมกับซอร์สโค้ดของโปรเจ็กต์ ไม่ว่าจะเป็นซอร์สโค้ดหรือไบนารี ซึ่งหมายความว่าทรัพยากร Dependency ภายนอกทั้งหมดของโปรเจ็กต์จะแปลงเป็นทรัพยากร Dependency ภายใน Google ใช้แนวทางนี้ภายใน โดยเช็กอินไลบรารีของบุคคลที่สามทุกรายการที่อ้างอิงทั่วทั้ง Google ลงในไดเรกทอรี third_party ที่รูทของแผนผังซอร์สของ Google อย่างไรก็ตาม วิธีนี้ใช้ได้ที่ Google เท่านั้น เนื่องจากระบบควบคุมซอร์สโค้ดของ Google สร้างขึ้นเองเพื่อจัดการกับ Monorepo ขนาดใหญ่มาก ดังนั้นการจัดหาทรัพยากร Dependency อาจไม่ใช่ตัวเลือกสำหรับองค์กรทั้งหมด