Subversion: Chi nhánh cho mỗi môi trường?

Question

Tôi hiện đang làm việc trên một dự án trong .NET bao gồm một số lớp logic và nhiều giao diện người dùng. Dưới đây là một biểu diễn thô sơ về cấu trúc SVN của chúng tôi:

trunk 
---doc 
---lib 
---src 
------console 
---------console.vbproj 
------domain 
---------domain.vbproj 
------... 
------web 
---------web.vbproj 
---.sln 

Tất cả phát triển hàng ngày của chúng tôi đều xuất hiện trong thân cây - đây là nơi tất cả các nhà phát triển thanh toán/cam kết.

Tôi đang tìm cách để làm sạch và dễ dàng triển khai giữa các môi trường (kiểm tra và sản xuất).

Suy nghĩ của tôi là tạo ra hai nhánh, thử nghiệm và sản xuất, từ thân cây - giải pháp và tất cả. Tôi biện minh này để bản thân mình vì những lý do sau đây:

1. tôi có toàn quyền kiểm soát mà thay đổi dòng chảy mà các môi trường bằng cách chỉ việc sáp nhập từ thân cây đến chi nhánh thử nghiệm và từ các chi nhánh thử nghiệm để các chi nhánh sản xuất
2. tôi có thể dễ dàng xem mã nào đang thực thi trong mỗi môi trường bằng cách chỉ cần nhìn vào nhật ký của chi nhánh tương ứng trong Subversion

Có ai có bất kỳ trải nghiệm nào với giải pháp tương tự như vậy không? Có bất kỳ cạm bẫy tiềm năng hoặc giám sát mà tôi đang thiếu?

Answer 1

Có ai có bất kỳ trải nghiệm nào có giải pháp tương tự như vậy không?

Có :-)

Có những cạm bẫy tiềm năng hoặc thiếu sót mà tôi đang thiếu?

Bạn sẽ phải đối mặt với vấn đề theo thời gian thử nghiệm và phát hành các chi nhánh sẽ trôi ra khỏi môi trường phát triển vì bạn rất có thể sẽ không hợp nhất mọi thay đổi từ thân cây. Các nhà phát triển sau đó sẽ làm việc trong một môi trường hơi khác và bạn sẽ lãng phí nhiều thời gian bằng cách giữ cho các chi nhánh đồng bộ. Điều này được gọi là merge-mania anti-pattern.

Tôi muốn khuyên bạn nên tạo chi nhánh phát hành từ thân cây cho mỗi bản phát hành đã lên kế hoạch khi bạn có tất cả các tính năng để triển khai. Tại thời điểm bạn chi nhánh cả hai đều bằng nhau. Sau đó có một đội để ổn định và kiểm tra trên nhánh phát hành. Sự phát triển đi song song trên thân cây. Sau khi bản phát hành của bạn được đánh bóng hợp nhất các bản sửa lỗi quay lại thân cây.

Lặp lại quy trình cho mỗi bản phát hành. Bằng cách này bạn sẽ giới hạn số lượng hợp nhất và có những người làm việc trên một cái gì đó mà luôn luôn là cạnh cắt.

Tôi hy vọng các khía cạnh này sẽ giúp bạn trong quyết định của bạn. Liên kết cũng cho thấy nhiều mẫu chống khác. Có một đọc cho tất cả trong số họ có thể bạn sẽ nhận ra một số bài học kinh nghiệm và sẽ nhận được một số gợi ý để giải quyết nó tốt hơn.

Answer 2

Chúng tôi đang sử dụng cùng một bố cục mà không gặp bất kỳ sự cố nào. Đảm bảo sử dụng phiên bản svn mới nhất. Phiên bản trước 1.5 không nên được sử dụng vì thiếu theo dõi hợp nhất.

Kết hợp với công cụ theo dõi lỗi như jira từ atlassian (Tôi không được tài trợ), thiết lập của bạn trở nên minh bạch hơn.