ทำลายบีลด์: มันคืออะไร สาเหตุ และวิธีหลีกเลี่ยงในโครงการ

การทำลายบีลด์ในการพัฒนาคืออะไร

การทำลายบีลด์คือสถานการณ์ที่หลังจากการเปลี่ยนแปลง โครงการหยุดสร้าง ในบริบทของ CI/CD ซึ่งหมายความว่าไฟป์ไลน์การสร้างล้มเหลว และไม่มีสรุปราณะถูกสร้างขึ้น

ในโลกของการพัฒนามือถือและเว็บ บีลด์คือกระบวนการแปลงโค้ดต้นฉบับไปเป็นไฟล์ที่สามารถประการหรือแพ็คเกจ สำหรับ Android คือการสร้าง APK หรือ AAB ผ่าน Gradle สำหรับ iOS คือการคอม์ไพล์ผ่าน Xcode สำหรับโครงการเว็บ คือการบันเดิลผ่าน Webpack หรือ Vite คุณสามารถทำลายบีลด์ได้ในทุกขั้นตอนเหล่านี้

ระบบควบคุมรุ่นทันสมัยใหม่และเครื่องมือ CI/CD เช่น Jenkins, GitHub Actions และ GitLab CI จะตรวจจับบีลด์ที่พังโดยอัตโนมัติและแจ้งให้ทีมทราบ ในโครงการส่วนใหญ่มีกฎว่า: หากบีลด์พัง ลำดับความสำคัญของงานอื่นๆทั้งหมดจะถูกลดลงจนกว่าจะแก้ไขบีลด์ได้

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // บรรทัดนี้ทำลายบีลด์
    val number: Int = "not a number"
}

ในตัวอย่างนี้ การกำหนดค่าสตริงให้กับตัวแปรชนิด Int ทำให้เกิดข้อผิดพลาดการคอม์ไพล์ Type mismatch เป็นหนึ่งในสาเหตุที่พบบ่อยที่สุดของการทำลายบีลด์ในภาษาแบบ static type

สาเหตุหลักของความล้มเหลวบีลด์

มีหมวดหมู่ข้อผิดพลาดหลายประเภทที่นำไปสู่บีลด์ที่พัง ตามการวิเคราะห์ของ GitLab ในปี 2024 การแจกจำน่ายของสาเหตุเป็นดังนี้

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

ในทางกลับกัน ข้อผิดพลาดทางไวยากรณ์จะถูกตรวจพบได้อย่างรวดเร็ว — ตัวคอม์ไพลเลอร์จะชี้บรรทัดและประเภทข้อผิดพลาดที่แน่นอน นี่คือสาเหตุที่ภาษาแบบ static type ถูกถือว่ามีความน่าเชื่อถือมากกว่าในแง่ของความมั่นคงของบีลด์เมื่อเทียบกับภาษาแบบ dynamic type

บีลด์ที่พังส่งผลกระทบต่อทีมอย่างไร

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

การศึกษาของ Atlassian ในปี 2023 แสดงว่า โครงการที่บีลด์อยู่ในสภาพพังเกินสี่ชั่วโมงจะสูญเสียเวลาการทำงานของทีมโดยเฉลี่ยส่วนกลาง 25% นักพัฒนาถูกบังคับให้หันไปเพื่อวินิจฉัยปัญหาแทนที่จะทำงานของตนให้เสร็จสมบูรณ์

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

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

วิธีป้องกันบีลด์ที่พัง

การป้องกันบีลด์ที่พังเริ่มต้นด้วยการตรวจสอบในเครื่องแรกก่อนการ commit นักพัฒนาทุกคนควรทำการทดสอบและสร้างก่อนส่งการเปลี่ยนแปลง วิธีการป้องกันหลักแบ่งออกเป็นหลายระดับ

• Pre-commit hooks — การตรวจสอบอัตโนมัติก่อนการสร้าง commit รวมถึงไลน์เตอร์และตัวจัดรูปแบบ
• การสร้างในเครื่องแรก — การเริ่มต้นการคอม์ไพล์ก่อนการ push โดยเฉพาะสำหรับภาษาแบบ static type
• การทดสอบหน่วย — ครอบคุมโมดูลหลักด้วยการทดสอบเพื่อการตรวจจับการถดถอยในช่วงต้น
• การตรวจสอบโค้ด — การตรวจสอบการเปลี่ยนแปลงโดยเพื่อนร่วมงานก่อนการรวมเข้ากับสาขาหลัก

ระดับที่สองคือการกำหนดค่าไฟป์ไลน์ CI/CD แต่ละ Pull Request ต้องผ่านการสร้างและการทดสอบอัตโนมัติก่อนการรวม หากบีลด์ล้มเหลว PR จะถูกกีดกั้นจนกว่าจะได้รับการแก้ไข แนวทางนี้เรียกว่า gated commit และใช้ในโครงการส่วนใหญ่ที่ทันสมัย

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

สิ่งที่ควรทำหากบีลด์พัง

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

# เริ่ม bisect ด้วย commit ที่ดีและแย่ที่รู้จัก
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git ตรวจสอบ commit ตรงกลาง
# สร้างและทดสอบ จากนั้นทำเครื่องหมาย:
git bisect good  # if build passes
git bisect bad   # if build fails

# หลัง ~log2(n) ขั้นตอน git จะแสดงตัวการ
git bisect reset

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

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