Bazel: ควรใช้เมื่อไร? (2023)

 (earthly.dev)
10 คะแนน โดย xguru 2024-12-13 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • Bazel เป็นระบบบิลด์โอเพนซอร์สที่ Google พัฒนาขึ้นเพื่อบิลด์โมโนรีโปขนาดใหญ่ได้อย่างมีประสิทธิภาพ
  • สามารถบิลด์โปรเจ็กต์ที่ซับซ้อนได้อย่างแม่นยำและรวดเร็ว โดยมีประสิทธิภาพเป็นพิเศษเมื่อจัดการกับโค้ดเบสขนาดใหญ่และดีเพนเดนซีหลายภาษา
  • แนวคิดหลักของ Bazel
    • ความเร็วที่ตั้งอยู่บนความถูกต้องแม่นยำ: Bazel มองการบิลด์เป็นฟังก์ชันบริสุทธิ์ และรับประกันว่าอินพุตเดียวกันจะสร้างเอาต์พุตเดียวกัน
    • การแคชที่มีประสิทธิภาพ: ในสภาพแวดล้อมขนาดใหญ่แบบที่ Google ใช้ การแคชเป็นสิ่งจำเป็น และความถูกต้องแม่นยำคือสิ่งที่ทำให้สิ่งนี้เป็นไปได้
    • บิลด์ได้โดยไม่ต้องล้างข้อมูล: หลังจากแก้ไขซอร์สแล้วก็ยังบิลด์ได้อย่างเสถียรโดยไม่ต้องทำ "clean build"
  • ช่วงเวลาที่ควรใช้ Bazel
    • แนะนำให้ใช้
      • โมโนรีโปขนาดใหญ่: มีโค้ดหลายล้านบรรทัดและใช้หลายภาษา
      • การจัดการดีเพนเดนซีข้ามหลายภาษา: เช่น ฝึกโมเดลด้วย Python และประมวลผลข้อมูลด้วย Scala
      • ต้องการ CI/CD ที่รวดเร็วและแม่นยำ: ช่วยเพิ่มความเร็วในการพัฒนาและลดการชนกัน
    • ไม่แนะนำให้ใช้
      • โปรเจ็กต์ขนาดเล็ก: มีโค้ดไม่เกิน 100,000 บรรทัดและใช้ภาษาเดียว
      • ไลบรารีโอเพนซอร์ส: Bazel เหมาะกับการสร้างอาร์ติแฟกต์ที่พร้อมแจกจ่าย แต่ยังไม่เหมาะนักสำหรับการเผยแพร่ไลบรารีที่นำกลับไปใช้ซ้ำได้
  • สิ่งที่ควรพิจารณาเมื่อเริ่มใช้ Bazel
    • มีเส้นโค้งการเรียนรู้เริ่มต้นค่อนข้างสูง และต้องใช้ทรัพยากรเพิ่มเติมในการเขียนและดูแลไฟล์บิลด์
    • จำเป็นต้องมีการสร้างโครงสร้างพื้นฐาน เช่น เซิร์ฟเวอร์แคชและการตั้งค่า remote execution
  • กรณีตัวอย่างความสำเร็จของ Bazel
    • Netflix
      • ปัญหา: ในรีโปที่มีโค้ด 250,000-300,000 บรรทัด CI ใช้เวลา 45 นาทีถึง 1 ชั่วโมง
      • ทางแก้: หลังนำ Bazel มาใช้ เวลาบิลด์ลดลงจาก 20 นาทีเหลือ 6 นาที
      • ผลลัพธ์: ลด merge conflict และปรับปรุงความเร็วในการจัดการ PR
    • Open Systems
      • ปัญหา: เวลาบิลด์ช้าและเวิร์กโฟลว์ไม่มีประสิทธิภาพ
      • ทางแก้: หลังเปลี่ยนมาใช้ Bazel วงจรฟีดแบ็กลดลงจาก 20 นาทีเหลือ 5 นาที
      • บทเรียน: การอบรมนักพัฒนาและการสื่อสารมีความสำคัญ
  • ข้อดีและข้อเสียของการนำ Bazel มาใช้
    • ข้อดี
      • เวลาบิลด์ที่รวดเร็ว: เพิ่มความเร็วด้วยการแคชและ incremental build
      • ความถูกต้องและทำซ้ำได้: แสดงกราฟดีเพนเดนซีที่ซับซ้อนได้อย่างแม่นยำ
      • รองรับหลายภาษาแบบบูรณาการ: รองรับภาษาหลากหลาย เช่น Haskell, TypeScript, Python
    • ข้อเสีย
      • ต้นทุนการนำมาใช้สูง: การตั้งค่าเริ่มต้นและเส้นโค้งการเรียนรู้ค่อนข้างชัน
      • ต้องจัดการไฟล์บิลด์: ต้องระบุอินพุต/เอาต์พุตอย่างชัดเจน และควรใช้เครื่องมืออัตโนมัติช่วย
      • JavaScript และเครื่องมือฝั่งฟรอนต์เอนด์: เข้ากันได้ยากกับเวิร์กโฟลว์เดิม เช่น hot reloading
  • เคล็ดลับสำหรับการย้ายมาใช้ Bazel
    • จัดตั้งทีมหลัก: ต้องมีผู้เชี่ยวชาญที่เข้าใจและตั้งค่า Bazel ได้
    • การอบรมและการสื่อสาร: ในช่วงเริ่มต้น ต้องมีการฝึกอบรมนักพัฒนาและกำหนดความคาดหวังให้ชัดเจน
    • ความซับซ้อนตามภาษา: แต่ละภาษาต้องการการตั้งค่าบิลด์ที่ต่างกัน
    • ทำไฟล์บิลด์ให้อัตโนมัติ: ใช้เครื่องมืออย่าง Gazelle
  • สรุป
    • Bazel โดดเด่นมากในการจัดการโมโนรีโปขนาดใหญ่และดีเพนเดนซีที่ซับซ้อน แต่มีต้นทุนในการนำมาใช้สูง
    • เหมาะกับองค์กรที่ต้องจัดการโค้ดหลายล้านบรรทัดและหลายภาษา
    • หากเป็นโปรเจ็กต์ขนาดเล็กหรือต้องการเปลี่ยนผ่านแบบค่อยเป็นค่อยไป อาจพิจารณาทางเลือกอย่าง Earthly แทน

บทความที่เกี่ยวข้อง

3 ความคิดเห็น

 
ganadist 2024-12-13

น่าจะดีถ้ามีการกล่าวถึงกรณีศึกษาความล้มเหลวในการนำ Bazel มาใช้ด้วย

ในกรณีของ AOSP ช่วงไม่กี่ปีที่ผ่านมา มีการนำเสนอหลายครั้งใน BazelCon เกี่ยวกับการย้ายจากระบบบิลด์เดิม (Soong) ไปเป็น Bazel

https://developers.googleblog.com/en/…

แต่ใน BazelCon ปีนี้ กลับไม่มีการแชร์เนื้อหาที่เกี่ยวกับ AOSP และในเอกสารล่าสุดที่เกี่ยวกับการบิลด์ของ AOSP ก็มี ประกาศว่าการย้ายไป Bazel ถูกยุติแล้ว

หากเป็นทีม AOSP ก็น่าจะได้รับความช่วยเหลืออย่างมากในเรื่องการย้ายไป Bazel แต่การที่พวกเขาตัดสินใจล้มเลิกการนำมาใช้นั้น ดูเหมือนจะแสดงให้เห็นประเด็นชวนคิดหลายอย่าง
 
iolothebard 2024-12-13

บางที… ซอฟต์แวร์ของคุณอาจไม่จำเป็นต้องใช้ Bazel
 
kandk 2024-12-13

ฮ่าๆ Earthly กำลังโฆษณา Earthly อยู่สินะ
Bazel เน้นที่การบิลด์ที่รวดเร็วและ "การทดสอบ" ที่รวดเร็ว ดูเหมือนจะไม่ได้พูดถึงเรื่องการทดสอบมากนัก