Giảm flaky build xuống còn 1/18
(github.blog)Tại GitHub, họ định nghĩa flaky build là những bản build mà với cùng một đoạn mã, có lúc bị lỗi nhưng có lúc lại vượt qua. GitHub cho biết họ đã giảm flaky build xuống còn 1/18 bằng cách áp dụng tự động hóa để người viết ra đoạn mã đó phải tự xử lý và không ảnh hưởng đến người khác.
Trong hệ thống CI nội bộ của GitHub, họ theo dõi flaky build, sắp xếp lại tình huống sự cố rồi gán cho người được cho là đã tạo ra vấn đề đó.
-
Khi theo dõi flaky build, họ thấy tần suất rất khác nhau; những flaky build thất bại hơn 100 lần chỉ chiếm 0,4% tổng số. Vì vậy họ quyết định tập trung vào 0,4% này.
-
Khi triển khai vào năm 2016, họ tiếp cận bằng hai cách sau.
-
Khi build kết thúc, tìm các build chạy với cùng commit và nếu kết quả khác nhau thì đánh dấu là flaky build
-
Nếu retry trong cùng một build mà kết quả khác nhau thì đánh dấu là flaky build
-
-
Với cách này, họ chỉ có thể phân biệt được 25% tổng số flaky build.
Cải thiện
-
Sử dụng phương pháp chạy lại 3 lần
-
Retry trong cùng một process. Loại flaky build này xảy ra do tính ngẫu nhiên trong mã hoặc race condition.
-
Vẫn là cùng một process nhưng retry sau khi đã trôi qua một khoảng thời gian. Loại flaky build này xảy ra khi có giả định sai về thời gian.
-
Retry trên một host hoàn toàn khác. Loại flaky build này xảy ra do phụ thuộc vào thứ tự kiểm thử hoặc shared state.
-
Với phương pháp này, họ có thể tự động phát hiện được 90%.
Đo lường mức độ ảnh hưởng
Để xác định mức ưu tiên, họ cần một cách định lượng mức độ ảnh hưởng.
Họ chấm điểm mức độ ảnh hưởng dựa trên các thông tin như build, branch, tác giả, commit... để đo xem thất bại xảy ra nhiều đến mức nào và ảnh hưởng tới các branch hay lập trình viên khác ra sao.
Nếu vượt qua một ngưỡng điểm nhất định, họ sẽ tạo issue để các lập trình viên có thể sửa và gán issue đó cho người phụ trách.
1 bình luận
Trong trường hợp của tôi, flaky build thường xuyên xuất hiện trong các unittest của Gradle nên tôi đã áp dụng các giải pháp dưới đây.
Nếu dùng plugin https://plugins.gradle.org/plugin/org.gradle.test-retry thì sẽ rất hữu ích trong việc theo dõi flaky build của unittest.
Nếu dùng https://docs.gradle.org/current/dsl/… thì do tác vụ sẽ được chạy trong tiến trình mới sau một khoảng thời gian nhất định, flaky build có thể được giảm bớt.
Nếu áp dụng Gradle Enterprise thì có thể dễ dàng xem xu hướng của flaky build. https://gradle.com/blog/flaky-tests/