Quy trình đề xuất cho đánh giá mã với đồng bóng

Chúng tôi thường sử dụng Cộng tác viên mã của Perforce và SmartBear tại Big Corpvà bây giờ chúng tôi cũng sẽ sử dụng Mercurial cho một số dự án nhất định.

Bộ cộng tác mã hỗ trợ Mercurial (chúng tôi đang sử dụng phiên bản 5) và tôi đang cố gắng xác định thời điểm tốt nhất (trong quá trình cam kết / đẩy tới máy chủ) là thời gian tốt nhất / hiệu quả để đánh giá mã

cảm ơn

Chúng tôi thực sự đã trải qua gần như điều tương tự tại công ty của tôi gần đây. Đây là những gì chúng tôi đã làm:

• Chúng tôi giữ một bản sao chính xác trung tâm của tất cả các kho lưu trữ của chúng tôi trên một máy chủ. Khi các nhà phát triển muốn "kiểm tra" mã, họ đến máy chủ này và sao chép từ kho lưu trữ ở đó. Tương tự như vậy, khi chu trình phát triển hoàn tất, mã cũng được đẩy vào kho lưu trữ thích hợp ở đó.

• Chúng tôi tách các kho ổn định từ các kho phát triển . Chúng tôi yêu cầu mã đó được xem xét trước khi nó được đẩy vào một kho lưu trữ ổn định. (Điều này rất quan trọng vì chúng tôi cũng yêu cầu các kho lưu trữ ổn định của chúng tôi chứa mã hiện đang chạy trong sản xuất, chỉ khác với các chương trình khuyến mãi mã đang chờ xử lý.)

Để thực thi đánh giá mã, chúng tôi đã viết một pretxnchangegroupcái móc (tài liệu trong Sách HG ). Chúng tôi tận dụng thực tế là khi hook này chạy, nó có thể thấy kho lưu trữ như thể nếu mã thay đổi là vĩnh viễn, nhưng cũng cho chúng tôi khả năng ngăn chặn việc đẩy. Về cơ bản, quy trình như sau:

1. Nhà phát triển bắt đầu đẩy đến kho lưu trữ ổn định (vâng, đây thực sự là bước đầu tiên)
2. Móc chạy và lấy danh sách tất cả các thay đổi có trong giao dịch (bằng cách chạy nhật ký HG). Sau đó, nó truy vấn cơ sở dữ liệu mà chúng tôi đã xây dựng để xem liệu những thay đổi đó có được bao gồm trong đánh giá mã hay không. (Bảng khớp với hàm băm của bộ thay đổi với ID đánh giá mã).
   • Nếu đây là lần đầu tiên bất kỳ thay đổi nào trong số những thay đổi này được nhìn thấy, thì chúng tôi sẽ tạo một Đánh giá mã mới (sử dụng dòng lệnh Trình cộng tác mã), sau đó ghi lại các thay đổi này trong cơ sở dữ liệu bằng ID đánh giá mã đó.
   • Nếu chúng ta đã thấy một số (nhưng không phải tất cả) các thay đổi, chúng ta sẽ chạy lệnh (Bộ cộng tác mã) để đính kèm các thay đổi mới vào đánh giá hiện có và ghi lại các thay đổi mới này trong cơ sở dữ liệu.
   • Nếu tất cả các thay đổi được tìm thấy trong cơ sở dữ liệu (nghĩa là tất cả chúng đã được thêm vào đánh giá mã), thì chúng tôi xác minh rằng trạng thái của đánh giá mã là Hoàn tất. Tuy nhiên, nếu có bất kỳ thay đổi mới nào (hoặc đánh giá mã chưa hoàn thành), hook sẽ thoát với mã trạng thái khác không (khiến Mercurial quay lại giao dịch) và đưa ra thông báo thân thiện về Lỗi tiêu chuẩn giải thích cho nhà phát triển rằng việc xem xét mã cần phải được hoàn thành.

Về bản chất, điều này cung cấp cho nhà phát triển một quy trình khá hợp lý (tất cả những gì họ phải làm là đẩy hg) và hoàn toàn tự động hóa việc tạo đánh giá mã (và tải lên các tệp đã thay đổi bổ sung vào đánh giá), trong khi đảm bảo rằng tất cả mã được xem xét .

Lưu ý: Đây là một quy trình khá đơn giản (và tương đối mới đối với chúng tôi), vì vậy nó có thể không hoạt động cho tất cả mọi người và có thể có một số lỗi thiết kế mà chúng tôi chưa gặp phải. Nhưng cho đến nay, nó hoạt động khá độc đáo.

Nó phụ thuộc vào cách bạn có cấu trúc kho lưu trữ của bạn và những gì bạn đang cố gắng thực hiện. Chúng tôi muốn thực hiện đánh giá "trước khi cam kết", trong thế giới của DVCS thực sự có nghĩa là "đẩy trước". DVCS đẹp hơn trong môi trường này (khi so sánh với các SCM truyền thống) vì chúng có chức năng tích hợp để lưu các thay đổi cục bộ của bạn và lấy lại không gian làm việc của bạn để bạn có thể làm việc trên một thứ khác.

Nếu bạn muốn thực hiện đánh giá sau đẩy, quy trình làm việc lý tưởng phụ thuộc rất nhiều vào cấu trúc kho lưu trữ của bạn. Ví dụ: giả sử cấu trúc kho lưu trữ trông giống như cấu trúc được thảo luận trong bài viết này về bố cục kho lưu trữ Git . Trong trường hợp này, bạn có thể muốn xem lại các thay đổi đang được hợp nhất vào develop. Cam kết cá nhân trên các nhánh tính năng có thể không có ý nghĩa để xem xét. Rõ ràng tất cả hotfixescũng phải được xem xét cùng với việc sáp nhập vào master.

Nếu thay vào đó, bạn có một nhánh tích hợp duy nhất nơi mọi người đang đăng ký trực tiếp, bạn sẽ muốn xem lại tất cả các lần đẩy tới nhánh đó. Điều đó có lẽ hơi kém hiệu quả, nhưng vẫn có thể làm việc. Trong môi trường này, bạn sẽ phải đảm bảo rằng tất cả các thay đổi đã được đẩy đều được xem xét trước khi bạn cắt một bản phát hành. Điều đó có thể phức tạp hơn.

Đối với b) điều duy nhất tôi muốn đề xuất là gửi email cho bộ phận hỗ trợ SmartBear (support@smartbear.com) trực tiếp. Chúng tôi (vâng, tôi làm việc cho SmartBear) rất vui lòng giúp bạn giải quyết các vấn đề về đường dẫn của bạn, nhưng không có đủ thông tin trong câu hỏi này để khắc phục vấn đề của bạn. Quá trình bình thường là chỉ chạy trình cài đặt và mọi thứ chỉ hoạt động. Rõ ràng có điều gì đó đã đi sai trong quá trình đó.