Làm hỏng bản dựng: nó là gì, nguyên nhân và cách tránh trong dự án

Làm hỏng bản dựng trong phát triển là gì

Làm hỏng bản dựng là tình huống mà sau khi thực hiện thay đổi, dự án ngừng xây dựng. Trong bối cảnh CI/CD, điều này có nghĩa là đường ống xây dựng thất bại và không có tệp tạo ra nào được tạo.

Trong thế giới phát triển di động và web, bản dựng là quá trình chuyển đổi mã nguồn thành tệp thực thi hoặc gói. Đối với Android, đó là xây dựng APK hoặc AAB qua Gradle; đối với iOS, biên dịch qua Xcode; đối với các dự án web, đóng gói qua Webpack hoặc Vite. Bạn có thể làm hỏng bản dựng ở bất kỳ giai đoạn nào trong số này.

Các hệ thống kiểm soát phiên bản hiện đại và công cụ CI/CD như Jenkins, GitHub Actions và GitLab CI tự động phát hiện bản dựng hỏng và thông báo cho nhóm. Hầu hết các dự án đều có quy tắc: nếu bản dựng bị hỏng, ưu tiên của tất cả các nhiệm vụ khác sẽ giảm cho đến khi bản dựng được sửa.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Dòng này làm hỏng bản dựng
    val number: Int = "not a number"
}

Trong ví dụ này, gán một chuỗi cho một biến kiểu Int gây ra lỗi biên dịch. Không khớp kiểu là một trong những nguyên nhân phổ biến nhất gây hỏng bản dựng trong các ngôn ngữ kiểu tĩnh.

Nguyên nhân chính gây lỗi bản dựng

Có một số loại lỗi dẫn đến bản dựng hỏng. Theo phân tích của GitLab năm 2024, sự phân bố các nguyên nhân như sau.

Loại nguy hiểm nhất là vấn đề phụ thuộc. Cập nhật thư viện trong một mô-đun có thể làm hỏng bản dựng ở mô-đun lân cận nếu API hoặc hành vi của phương thức thay đổi.

Mặt khác, lỗi cú pháp được phát hiện nhanh chóng — trình biên dịch chỉ ra dòng chính xác và loại lỗi. Đây là lý do tại sao các ngôn ngữ kiểu tĩnh được coi là đáng tin cậy hơn về độ ổn định bản dựng so với các ngôn ngữ kiểu động.

Bản dựng hỏng ảnh hưởng đến nhóm như thế nào

Bản dựng hỏng ảnh hưởng trực tiếp đến năng suất của nhóm. Khi bản dựng thất bại, các nhà phát triển không thể lấy được phiên bản mới nhất của dự án từ kho lưu trữ và đường ống CI bị chặn cho tất cả các thay đổi tiếp theo.

Một nghiên cứu của Atlassian năm 2023 cho thấy các dự án có bản dựng hỏng hơn bốn giờ sẽ mất trung bình 25% thời gian làm việc hiệu quả của nhóm. Các nhà phát triển buộc phải chuyển hướng sự chú ý để chẩn đoán vấn đề thay vì hoàn thành nhiệm vụ của mình.

Ngoài năng suất, bầu không khí trong nhóm cũng bị ảnh hưởng. Nhà phát triển làm hỏng bản dựng chịu áp lực từ đồng nghiệp. Trong các nhóm lành mạnh, quy tắc là: không trừng phạt vì bản dựng hỏng, nhưng yêu cầu sửa chữa ngay lập tức. Văn hóa không đổ lỗi là một cách tiếp cận trong đó sự cố được phân tích như một vấn đề hệ thống chứ không phải lỗi của ai đó.

Trong các nhóm phân tán, bản dựng hỏng có thể chặn công việc của đồng nghiệp ở múi giờ khác. Nếu một nhà phát triển ở Châu Âu làm hỏng bản dựng trước khi ra về, nhóm ở Châu Á có thể mất cả ngày làm việc chờ sửa chữa.

Cách ngăn chặn bản dựng hỏng

Việc ngăn chặn bản dựng hỏng bắt đầu bằng các kiểm tra cục bộ trước khi commit. Mỗi nhà phát triển nên chạy kiểm tra và bản dựng trước khi đẩy thay đổi. Các phương pháp phòng ngừa chính được chia thành nhiều cấp độ.

• Hook pre-commit — kiểm tra tự động trước khi tạo commit, bao gồm công cụ phân tích và định dạng
• Bản dựng cục bộ — chạy biên dịch trước khi đẩy, đặc biệt cho các ngôn ngữ kiểu tĩnh
• Kiểm tra đơn vị — bao phủ các mô-đun chính bằng kiểm tra để phát hiện sớm các hồi quy
• Đánh giá mã — đồng nghiệp xem xét thay đổi trước khi hợp nhất vào nhánh chính

Cấp độ thứ hai là cấu hình đường ống CI/CD. Mỗi Yêu cầu kéo phải vượt qua bản dựng và kiểm tra tự động trước khi hợp nhất. Nếu bản dựng thất bại, PR sẽ bị chặn cho đến khi được sửa. Cách tiếp cận này được gọi là gated commit và được sử dụng trong hầu hết các dự án hiện đại.

Cấp độ thứ ba là giám sát và thống kê. Các nhóm theo dõi chỉ số MTTR (Thời gian sửa chữa trung bình). Chỉ số này càng thấp, nhóm càng phản ứng nhanh với bản dựng hỏng. Giá trị mục tiêu không quá 30 phút.

Làm gì nếu bản dựng bị hỏng

Khi bản dựng bị hỏng, bước đầu tiên là xác định nhà phát triển nào đã thực hiện các thay đổi cuối cùng. Git cung cấp công cụ git bisect, cho phép tìm commit đã làm hỏng bản dựng thông qua tìm kiếm nhị phân.

# Bắt đầu bisect với các commit tốt và xấu đã biết
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git kiểm tra một commit ở giữa
# Xây dựng và kiểm tra, sau đó đánh dấu:
git bisect good  # if build passes
git bisect bad   # if build fails

# Sau ~log2(n) bước, git hiện thị thủ phạm
git bisect reset

Sau khi tìm thấy commit có vấn đề, có hai hướng hành động khả thi. Cách thứ nhất là hoàn tác các thay đổi bằng git revert nếu việc sửa chữa cần thời gian. Đây là cách tiếp cận an toàn nhất, đặc biệt khi bản dựng chặn toàn bộ nhóm.

Cách thứ hai là sửa chữa ngay lập tức với một commit mới. Cách tiếp cận này được ưu tiên nếu vấn đề là cục bộ và rõ ràng. Sau khi sửa, hãy đẩy các thay đổi và xác nhận bản dựng thành công. Trong mọi trường hợp, thời gian khôi phục bản dựng không được vượt quá một giờ.