Có công cụ CI nào đảm bảo không có hồi quy ở mức chất lượng chi nhánh không?

Theo truyền thống, các hệ thống CI chỉ thực hiện giám sát các mức chất lượng trong nhánh tích hợp, bằng cách thực hiện xác minh QA trên cơ sở mã nơi các thay đổi đã được cam kết, theo dõi hồi quy và gửi thông báo cho sự can thiệp của con người.

Nhưng khi các hồi quy này được phát hiện, chi nhánh đã gặp rắc rối ít nhất kể từ khi xác minh QA tương ứng bắt đầu và sẽ vẫn ở trạng thái như vậy (hoặc thậm chí trở nên tồi tệ hơn!) Cho đến khi tất cả các thủ phạm được xác định, sửa chữa cho chúng đã cam kết và xác minh QA mới xác nhận mức chất lượng chi nhánh đã được khôi phục. Chi nhánh có thể được coi là bị chặn để phát triển bình thường trong suốt thời gian này.

Có một công cụ CI nào có khả năng thực sự ngăn chặn các hồi quy như vậy xảy ra hay không, nó sẽ thực hiện xác minh QA trước khi cam kết và chỉ cho phép các cam kết khi mã cơ sở được cập nhật với các xác nhận tương ứng cũng sẽ vượt qua các xác minh QA đã cam kết trước đó, do đó đảm bảo tối thiểu Chi nhánh chất lượng?

Cập nhật: giả định là các xác minh QA tự động phù hợp với độ bao phủ phù hợp để có thể phát hiện các hồi quy tương ứng có sẵn để gọi (các) công cụ CI.

Theo như tôi có thể nói, bạn đang tìm kiếm một công cụ sẽ từ chối các cam kết phá vỡ bản dựng, một công cụ CI có thể sẽ không thể ngăn chặn hồi quy bằng cách thực sự sửa mã của bạn, nhưng nó có thể ngăn bạn thêm mã xấu vào kho lưu trữ.

Atlassian có một vài ứng dụng thú vị của móc Git :

Các móc nhận trước phía máy chủ là một lời khen đặc biệt mạnh mẽ đối với việc tích hợp liên tục vì chúng có thể ngăn các nhà phát triển đẩy mã thành chủ, trừ khi mã đáp ứng một số điều kiện nhất định - như những người bảo vệ ninja ưu tú, bảo vệ nó khỏi mã xấu.

Nếu bạn đang sử dụng Git, các hook rất mạnh mẽ (và có các hook tương tự cho các hệ thống kiểm soát phiên bản SVN , Mercurial và các phiên bản khác) và bạn có thể thấy hữu ích khi sử dụng chúng để chạy kiểm tra trước khi xác nhận.

Tài liệu Git có một trang về việc tạo ra một cái móc để từ chối các cú đẩy nếu chúng không đáp ứng một tiêu chí nhất định có thể dễ dàng thích nghi với trường hợp sử dụng này.

Tuy nhiên, nhiều người sẽ tranh luận rằng từ chối các cam kết là một ý tưởng tồi đối với một featurechi nhánh, bạn sẽ chỉ lãng phí thời gian để chống lại hệ thống CI của mình khi bản dựng bị hỏng vì một lý do nào đó, thay vì thực sự sửa lỗi.

Trên masternhánh, có thể có ý nghĩa để từ chối các hợp nhất bị hỏng, bởi vì bạn có thể muốn đảm bảo nó luôn được xây dựng. Đối với một featurechi nhánh, bạn chắc chắn sẽ phá vỡ mọi thứ và vì mã bây giờ không được sản xuất , nên cảnh báo bạn nhiều hơn là thực sự từ chối cam kết của bạn.

Không có công cụ nào có thể đảm bảo không có hồi quy - điều đó phụ thuộc nhiều vào các bài kiểm tra của bạn hơn là công cụ thực hiện chúng. Tuy nhiên, bạn có thể giúp ngăn chặn các hồi quy sẽ bị bắt khi tham gia vào nhánh tích hợp. Bạn có thể thực hiện việc này với các móc nối trước, nhưng thường dễ dàng hơn với các yêu cầu kéo (hy vọng bạn đã sử dụng để đánh giá mã ngang hàng).

Nếu một nhánh được cập nhật với dòng ngược của nó (nơi PR được hợp nhất) và các thử nghiệm của nó vượt qua, thì chúng vẫn sẽ vượt qua sau khi hợp nhất; trạng thái của nhánh đích sau khi hợp nhất sẽ khớp với trạng thái của nhánh nguồn trước khi hợp nhất.

Nhìn chung, điều này không đặc biệt khó khăn (tùy thuộc vào các công cụ được sử dụng) để chỉ ra cả liệu nhánh nguồn trong PR có được cập nhật với mục tiêu hay không và liệu nó có xây dựng CI không. Bạn có thể sử dụng điều này như một yêu cầu (theo chính sách và / hoặc được thi hành trong phần mềm) để hợp nhất yêu cầu kéo.

Các công cụ tích hợp liên tục thực sự (trái ngược với chỉ kiểm tra liên tục) như Reitveld và Zuul có thể giúp ích, mặc dù chúng chỉ tốt như các bài kiểm tra bạn viết và đánh giá mã bạn làm.

Sử dụng GitLAB, bạn có thể đặt trong cài đặt dự án để chỉ cho phép hợp nhất khi đường ống thành công, do đó, có thể có Tích hợp liên tục thực sự, kết hợp với việc thêm QA của bạn vào danh sách phê duyệt hợp nhất và với Môi trường động, bạn có thể đảm bảo chất lượng trước khi bạn hợp nhất với chủ.

ApartCI là một hệ thống CI được thiết kế chính xác để ngăn chặn hồi quy, do đó đảm bảo mức chất lượng phẳng hoặc tăng chi nhánh. Vẫn đang trong giai đoạn thử nghiệm.

Nó phối hợp xác minh tiền cam kết tập trung theo cách để đảm bảo rằng thay đổi chỉ được thực hiện sau khi được xác minh, cùng với tất cả các thay đổi khác được cam kết trước đó, để đáp ứng hoặc vượt quá mức chất lượng chi nhánh mới nhất.

Đây là điểm khác biệt chính so với các xác minh trước cam kết do nhà phát triển truyền thống, thường được thực hiện song song, để lại chỗ cho các hồi quy gây ra bởi việc can thiệp các thay đổi không bao giờ được thử nghiệm cùng nhau.

Công cụ này cũng được thiết kế để dễ dàng mở rộng quy mô - có khả năng duy trì tỷ lệ thay đổi ứng viên đến rất cao và hỗ trợ 100/1000 nhà phát triển làm việc trong cùng một nhánh tích hợp.

Tuyên bố miễn trừ trách nhiệm: Tôi là tác giả của công cụ và người sáng lập công ty cung cấp nó. Xin lỗi cho quảng cáo.