Làm thế nào để quản lý nhiều nhánh phát hành trong lật đổ?

Question

Tại công ty tôi làm việc cho chúng tôi sử dụng subversion và TortoiseSVN để quản lý mã nguồn của chúng tôi. Mỗi dự án được phân nhánh ra khỏi thân cây. Khi chúng ta cần tích hợp các dự án khác nhau cho một bản phát hành, chúng ta tạo một nhánh phát hành có chứa mã sẽ được tích hợp, thử nghiệm và triển khai để sản xuất. Thông thường chúng tôi chỉ có một nhánh phát hành.

Gần đây, tuy nhiên, một số mục trong một trong các dự án đã bị trì hoãn và được lên kế hoạch đi vào bản phát hành tiếp theo. Kết quả là, ai đó đã yêu cầu một nhánh phát hành thứ hai được tạo ra để giữ các thay đổi bị trì hoãn và ngăn chúng không được hợp nhất vào bản phát hành hiện tại. Cho đến nay điều này đã gây ra cho chúng tôi rất nhiều đau buồn và rất nhiều xung đột cây vì một số mục trong nhánh phát hành trong tương lai phụ thuộc vào các mục trong nhánh phát hành hiện tại. Cách duy nhất chúng tôi có thể giải quyết những vấn đề này là đợi cho đến khi bản phát hành hiện tại được triển khai, hợp nhất nhánh phát hành vào trong thân cây, hợp nhất nhánh vào nhánh phát hành trong tương lai và sau đó hợp nhất các thay đổi từ nhánh dự án vào nhánh phát hành trong tương lai .

Do sự cố này, chúng tôi phải đề xuất rằng chúng tôi không bao giờ nên có nhiều chi nhánh phát hành vì nó gây ra sự cố hợp nhất.

Tuy nhiên, tôi tự hỏi đây có phải là cách chính xác không. Có ai biết nếu nó có thể quản lý nhiều chi nhánh phát hành trong lật đổ? Chắc chắn phải có khả năng quản lý các tính năng bị trì hoãn mà không ảnh hưởng đến khả năng kết hợp của một người.

Có ai ngoài kia có bất kỳ kinh nghiệm nào về kịch bản mà tôi đã trình bày mà bạn sẵn sàng chia sẻ không? Tôi chỉ muốn biết làm thế nào tôi có thể cải thiện cách phát hành được quản lý tại nơi làm việc của tôi để điều này không xảy ra nữa.

Answer 1

Thành thật mà nói, tôi không hoàn toàn chắc chắn cách hệ thống của bạn hoạt động từ mô tả. Tuy nhiên, tôi đã phải quản lý các dự án với một số phiên bản trực tiếp trong quá khứ. Cách chúng tôi thực hiện điều này là:

1. Không có nội dung nào được phát hành không có trong thân cây trước.
2. Mỗi phiên bản có nhánh phiên bản riêng.
3. Cách duy nhất để cập nhật chi nhánh phiên bản là hợp nhất từ ​​thân cây.

Bằng cách này, chúng ta có thể chọn lựa các tính năng trong phiên bản nào. Sử dụng tính năng theo dõi hợp nhất, nó cũng cho phép chúng tôi xây dựng một trang web cho chúng ta thấy đồ họa đã đi đến đâu.

Điều quan trọng là có một nhánh tích hợp đầy đủ mà bạn có thể chọn - đây là định nghĩa của tôi về thân cây.

Đây không phải là một hệ thống hoàn hảo. Nếu bạn bỏ qua các phiên bản, thì các phụ thuộc đã làm cho mọi việc trở nên phức tạp và chúng tôi thực sự cần đồ họa để chỉ cho chúng tôi thấy những gì đang ở đâu, nhưng nhìn chung hoạt động tốt.

Đồng thời xem câu trả lời của tôi here.

Answer 2

Đây không phải là nơi rùa vượt trội. Để thực hiện các kịch bản hợp nhất và chi nhánh phức tạp, bạn cần một cái gì đó như spec cấu hình clearcase để thực hiện điều khiển phiên bản của bạn.

Nếu bạn sử dụng rùa, bạn nên giữ thân cây như vậy và sau đó chạy tích hợp liên tục trên thân cây hoặc tạo nhánh cho mỗi đối tượng địa lý, hợp nhất chúng lại khi tính năng phát triển hoàn tất. Nếu bạn làm điều này thì bạn sẽ chỉ có mã trên thân được kiểm tra. Sau đó, bạn chọn một điểm phát hành, thực hiện tích hợp của bạn và mang lại các bản sửa lỗi cần thiết vào thân cây của bạn, nhưng cũng cho phép các nhóm của bạn tiếp tục phát triển.

Answer 3

Tôi nghĩ bạn muốn theo dõi hợp nhất, hoặc thông qua svnmerge.py hoặc thông qua theo dõi hợp nhất được tích hợp sẵn từ Subversion 1.5. Điều này cho phép bạn chặn các thay đổi nhất định khỏi việc sáp nhập vào một chi nhánh, sau đó có thể được thực hiện cho tất cả các thay đổi liên quan đến các tính năng mà bạn chỉ muốn kết hợp vào bản phát hành tiếp theo.

Answer 4

Bạn hầu như luôn muốn thay đổi trên nhánh bị trì hoãn đầu tiên hiện diện trong giây. Vì vậy, nhánh phát hành thứ hai nên được thực hiện từ nhánh phát hành đầu tiên và các thay đổi từ lần đầu tiên nên được hợp nhất theo định kỳ. Lý tưởng nhất là bởi những người đã làm cho họ ở nơi đầu tiên.

Phân nhánh Spepladder (?) Sẽ hoạt động tốt trong trường hợp này - chỉ cần bỏ qua thân cây và leo lên.

Answer 5

Công ty của tôi đã gặp sự cố tương tự.

Chúng tôi đã có một dự án trì hoãn một bản phát hành - chúng tôi sẽ gọi nó là 2.0 - trong vài tháng. Trong khi chờ đợi, chúng tôi đã có vấn đề về sản xuất trên nhánh hiện tại - hãy gọi 1.5 - bảo hành nhiều bản phát hành hơn. Chúng tôi không thể sử dụng thân cây, bởi vì nó có các tính năng cấm vận, nên chúng tôi bắt đầu phân nhánh từ các chi nhánh. Phiên bản 1.6 của chúng tôi phân nhánh từ 1.5, không phải là trunk. Khác với quy ước đặt tên bản phát hành 1.6 thực sự không có gì hơn 1.5.1. Vì đây không phải là SOP, chúng tôi đã rất cẩn thận để ghi lại những gì chúng tôi đang làm.

Và tôi không mong đợi điểm hợp nhất, nơi cuối cùng chúng tôi tập hợp chi nhánh 1.6 và 2.0. Chúng tôi không thể hợp nhất các thay đổi trên 1,6 trở lại lên thân cây hoặc 2.0, bởi vì điều đó chỉ làm cho QA trên các sự cố 2.0 trở nên tồi tệ hơn. Chúng tôi đang chạy Subversion 1.4.6, vì vậy không có sự trợ giúp nào từ phần mềm - nó sẽ là tất cả việc sáp nhập thủ công.