Nơi để đẩy một bài kiểm tra thất bại?

Tôi vừa thay đổi cài đặt nhánh trên kho GitHub của mình, để nhánh [tiếp theo] của tôi yêu cầu xây dựng CI thông qua yêu cầu kéo.

Một cuộc thảo luận theo sau với một số thành viên trong nhóm, về các bài kiểm tra thất bại.

Vì bối cảnh ...

Kho lưu trữ có một nhánh [chính] chỉ PRED khi có bản phát hành, vì vậy [master] chứa mã như bản phát hành cuối cùng, bất kể đó là chính, phụ, hotfix, beta, alpha / xây dựng trước khi phát hành.

Nhánh [next] là nhánh "mặc định", nơi chúng tôi dự định giữ mã "sẵn sàng phát hành"; về mặt kỹ thuật, chi nhánh đó có thể được đưa vào [master] bất cứ lúc nào và được phát hành.

Các nhánh riêng lẻ có các nhánh dev riêng và những người đóng góp PR cho [tiếp theo].

Khi tôi xem xét một PR không tầm thường, tôi sẽ hợp nhất nhánh nhà phát triển của cộng tác viên vào nhánh "đánh giá" của mình và nếu tôi thấy những điều tôi có thể khắc phục nhanh chóng, tôi sẽ cam kết / đẩy các thay đổi và thử nghiệm mới (đôi khi không thành công) và PR trở lại chi nhánh dev của người đóng góp; khi họ hợp nhất các thay đổi của tôi vào, làm cho các thử nghiệm thất bại mới vượt qua, rồi đẩy, PR của chúng được đồng bộ hóa, và sau đó tôi sẽ hợp nhất PR vào [tiếp theo].

Nhưng câu hỏi này không phải là về việc vượt qua các bài kiểm tra, mà là về những bài thi thất bại .

Không kiểm tra tài liệu những gì cần phải được sửa chữa.

Các lỗi đã biết nên có các bài kiểm tra được viết cho, để chúng tôi biết những gì không hoạt động.

Về mặt kỹ thuật, danh sách các vấn đề GitHub (được lọc cho lỗi và / hoặc nhãn quan trọng ) cũng làm điều đó. Đó có phải là một thực hành tốt để cũng có một loạt các bài kiểm tra thất bại để ghi lại lỗi?

Một thất bại xây dựng trên [tiếp theo] có nghĩa là chúng ta không tiết lộ sẵn sàng ... nhưng sau đó "được phát hành-ready" là một chút như "đang sẵn sàng" để có con - bạn không bao giờ khá sẵn sàng cho điều này, và một cái gì đó, ở đâu đó (có tầm quan trọng thay đổi) chắc chắn sẽ đi sai với bản phát hành.

Vì vậy, chúng tôi chỉ đẩy các bài kiểm tra đến [tiếp theo]. Sau đó đẩy bài kiểm tra thất bại ở đâu? Ý tôi là, ngoài quy trình PR / xem xét?

Ví dụ: người dùng báo cáo một lỗi mới trong danh sách các vấn đề và tôi muốn viết một bộ kiểm tra không thành công cho nó - để chỉ định những gì cần phải làm và ở đâu, giúp những người đóng góp mới dễ dàng nhận ra hơn và cuối cùng PR một sửa chữa.

Tôi nên đẩy những bài kiểm tra thất bại này ở đâu? Hoặc thậm chí là một ý tưởng tốt để đẩy các bài kiểm tra thất bại ở bất cứ đâu?

Những gì tôi sẽ làm trong tình huống này là đánh dấu các bài kiểm tra thất bại là "bị bỏ qua" - theo cách đó bạn vẫn có bài kiểm tra để bạn biết những gì bạn cần khắc phục trong tương lai, nhưng bạn sẽ không kết thúc với các bản dựng bị hỏng .

Nếu bạn cũng gắn thẻ từng bài kiểm tra với tham chiếu theo dõi vấn đề để khắc phục sự cố, điều đó mang lại cho bạn một cách dễ dàng để gắn kết mọi thứ lại với nhau.

Tiết lộ đầy đủ: Tôi là một trong những người tham gia thảo luận.

Chi nhánh chính của kho lưu trữ không phải là chi nhánh chính. Việc hợp nhất thành chủ không phục vụ bất kỳ "mục đích thực tế" nào và chi nhánh đó không làm những việc mà một chi nhánh nên làm (cụ thể là di chuyển ).
Bạn đang lạm dụng chi nhánh này làm Thẻ cho bản phát hành mới nhất.

Thay vì sử dụng một nhánh, hãy sử dụng Thẻ. Khi bạn muốn phát hành, bạn thực hiện các bước cần thiết trong "Chi nhánh phát hành", giống như một nhánh chủ đề. Sau đó, bạn hợp nhất nó vào [tiếp theo] và đặt một Thẻ trên đó.

Vai trò [tiếp theo] hoàn thành, là của một nhánh chính. Chỉ có mã phát hành sẵn sàng đi vào đó. Bất cứ điều gì khác sẽ là một nhánh [phát triển]. Một nhánh phát triển chứa công việc sẽ được ổn định . Điều này có nghĩa là: xóa [chính], tái sử dụng [tiếp theo] theo cách bạn đã làm và tạo một nhánh khác cho công việc "kém ổn định".

Vì đó là ngoại lệ nhiều hơn so với quy tắc cần phải thử nghiệm thất bại, nhắc nhở về các lỗi còn tồn tại, nên không có quá nhiều vấn đề để tạo và phá hủy nhánh kém ổn định đó khi cần