Khi nào nên sử dụng tính năng Đăng ký Gated?

Question

Tôi đang sử dụng TFS 2010. Hiện tại tôi sử dụng Gated Check-in được xây dựng trên nhánh thân cây (MAIN). Và, tôi sử dụng CI trên DEV và RELEASE chi nhánh.

• Tại sao không sử dụng tính năng Tạo đăng ký Gated trên tất cả các nhánh?
• Trong trường hợp nào, bạn không nên sử dụng tính năng Tạo đăng ký Gated trên các nhánh DEV và RELEASE?
• Có tốt hơn khi luôn sử dụng tính năng Xây dựng đăng ký Gated trên mọi chi nhánh không?

Answer 1

Trong nhóm rất lớn của chúng tôi, chúng tôi cũng gated trong nhánh chính và CI trong các chi nhánh dev/feature (nhiều người trong số họ).

Gated cung cấp bảo vệ nhiều hơn cho chi nhánh nhưng với một nhóm rất lớn và cơ sở mã lớn, nó có thể sao lưu hàng đợi nếu toàn bộ nhóm dev đang thực hiện thay đổi trong nhánh đó.

CI cung cấp sự bảo vệ với sự tin tưởng hơn một chút trong các nhà phát triển cũng biết rằng mọi vấn đề sẽ bị bắt nhanh chóng. Đó là một chút lạc quan hơn và cho phép nhóm di chuyển nhanh hơn rất nhiều, phù hợp với chi nhánh dev.

Trong cả hai trường hợp, các nhà phát triển chạy thử nghiệm đơn vị và kiểm tra mã họ đang thay đổi. CI (ảnh hưởng đến nhóm) và Gated (tiêu tốn thời gian trong hàng đợi) không nên thay thế kiểm thử - có một lời giải thích hợp lý phức tạp hơn tôi không thử.

Toàn bộ nhóm nằm trong chi nhánh/dev sử dụng CI cho phần lớn chu kỳ và ở các nhánh cao hơn với nhiều người hơn trong quá trình ổn định trò chơi cuối cùng - cả hai điều kiện sau đều hỗ trợ cho trường hợp bị kiểm soát. Trong một nhóm lớn, chúng tôi cũng cần phải xây dựng CI và các bài kiểm tra cán phải được thực hiện song song để tìm các vấn đề nhanh hơn khi thời gian xây dựng không phải là tầm thường và các bộ thử nghiệm đầy đủ cũng không phải là tầm thường. Trong kịch bản đó, các folks đang kiểm tra, CI sẽ lấy lô kiểm tra cuối cùng, chạy một bản dựng và khi một bản vẽ hạ xuống, một máy khác đang chọn và chạy các bộ kiểm thử.

Answer 2

Không thực sự là lý do mà tôi biết tại sao không phải để thực hiện Đăng ký Gated trên mọi thay đổi bạn thực hiện. Tuy nhiên, có một điều kiện tiên quyết để làm Gated Check-in: thời gian xây dựng tổng thể của bạn không được lâu hơn một vài phút, bao gồm bất kỳ bài kiểm tra (unit) nào bạn muốn thực hiện trước khi check-in được chấp nhận . Nếu không, phải mất nhiều thời gian để đăng ký để được chấp nhận hoặc tệ hơn cho nhà phát triển, để bị từ chối. Đối với một nhóm dev, nó cũng phức tạp hơn một chút, hoặc ít nhất là một cái gì đó để làm quen với nó.

Tích hợp liên tục (theo ý kiến ​​của tôi được tối ưu hóa dưới dạng bản dựng cán) cho phép nhà phát triển kiểm tra mã của mình mà không có sự không chắc chắn nếu nó được chấp nhận hay không. Quan trọng là nhà phát triển sẽ luôn phải đối mặt càng sớm càng tốt với kết quả tiêu cực cuối cùng của việc đăng ký. Nếu bạn có thể đạt được điều đó, tôi thích nó tốt hơn so với đăng ký Gated.

Answer 3

Tôi thích tính năng Đăng ký Gated ở khắp mọi nơi vì nó hạn chế nỗi đau đối với nhà phát triển đăng ký thay vì chia sẻ nỗi đau đó với toàn bộ nhóm khi ai đó (không tránh khỏi) phạm sai lầm.

Như đã đề cập ở trên, điều quan trọng là phải nhanh chóng kiểm tra thông tin đăng ký Gated. Đôi khi tôi sẽ có một Gated Checkin chạy các kiểm tra quan trọng nhất, sau đó một CI build khởi động sau khi Gated Checkin thành công chạy nhiều lần kiểm tra tốn thời gian hơn.