Tích hợp liên tục với nhiều nhánh phát triển trong Subversion

Question

Trong dự án mà tôi đang làm việc, chúng tôi đang sử dụng SVN với chiến lược 'Ổn định'. Điều đó có nghĩa là đối với mỗi lỗi được tìm thấy, QA mở một bug ticket và gán nó cho một nhà phát triển. Sau đó, một nhà phát triển bản sửa lỗi mà lỗi và kiểm tra nó trong một chi nhánh (off thân cây, chúng ta hãy gọi đây là bug branch) và chi nhánh đó sẽ chỉ chứa sửa cho rằng đặc biệt bug ticket

Khi chúng tôi quyết định làm một thông cáo, đối với mỗi sửa lỗi mà chúng tôi muốn phát hành cho khách hàng, nhà phát triển sẽ hợp nhất tất cả các bản sửa lỗi từ một số bug branch thành trunk và tiếp tục với chu kỳ QA thông thường.

Vấn đề là chúng ta sử dụng trunk như codebase cho công việc CI của chúng tôi (Hudson, cụ thể), và do đó, cho tất cả các cam kết các bug branch, nó sẽ bỏ lỡ việc xây dựng hàng ngày cho đến khi nó được sáp nhập vào trunk khi chúng tôi quyết định phát hành phiên bản mới của phần mềm. Rõ ràng, điều đó đánh bại mục đích của việc có CI.

Cách thích hợp để khắc phục vấn đề này là gì?

Answer 1

Như bạn đã lưu ý, một mục đích của việc sử dụng một chi nhánh là để tách biệt các biến động mã cụ thể từ việc sửa lỗi và phát triển tính năng ra khỏi thân cây. Nhưng khi tính năng hoặc vé hoàn tất, bạn nên hợp nhất lại. Trong Subversion, các nhánh được sử dụng tốt hơn để theo dõi các tập hợp các tính năng liên quan (như các tính năng cho bản phát hành), chứ không phải các tính năng riêng lẻ. Nếu không, bạn sẽ nhanh chóng gió lên với số lượng chi nhánh không thể quản lý được.

Hơn nữa, tại sao trì hoãn tích hợp? Bạn càng đợi giữa các bản phát hành càng cao, khả năng thay đổi bị cô lập của bạn càng xung đột với một thay đổi khác được thực hiện kể từ đó và/hoặc tạo ra sự bất ổn hơn nữa trong hệ thống của bạn sau khi hợp nhất lại.

chiến lược ưa thích của tôi là để làm một cái gì đó như thế này:

[begin work on 0.4 branch] 
     | 
     | 
     v    
(*)---(*)-------(a)--(b)---(c)-- <-- Trunk is "unstable". 
     \  |   |  Contains all commits. 
    ver \ [merge from trunk]  Developers commit to trunk. 
<-- 0.3 \  v   v 
      +---(a)--------(c)-- <-- Branch is "stable". 
            Contains selected commits from trunk. 
            Know beforehand what's going onto branch. 

Bây giờ, khi bạn đã sẵn sàng cho phát hành:

[trunk] 
(*)---(*)---(*)----------------------------[development continues]---> 


[0.4 branch]      No further development on branch unless 
(*)---(*)---(*)---[0.4-release]  spot fixes are needed. Then re-tag (0.4.1) 
         ^  and re-release. 
          |   
          | 
         [make tag on branch; release from stable branch, 
         not unstable trunk] 

Tôi biết bạn hỏi về cách tốt nhất để ép buộc liên tục của bạn tích hợp hệ thống để làm điều này. Nhưng tôi xin trân trọng đề nghị rằng Hudson được công nhận là một hệ thống CI tương đối có khả năng, thực tế là bạn đang gặp rất nhiều khó khăn trong việc xây dựng mô hình phát triển của mình thành một dấu hiệu có thể là nó không phải là một quá trình tự vay tốt cho CI ngay từ đầu.

Thực tiễn điển hình của chúng tôi là có hai bản dựng cơ bản cho mỗi dự án: một dựa vào thân cây và một đối với nhánh phát hành hiện tại. Bằng cách này bạn biết rằng:

• Dù đang được cập nhật đã được tích hợp một cách chính xác (trunk)
• Dù mục tiêu phát hành của bạn là, nếu bạn ngừng làm việc bây giờ bạn sẽ vẫn có một chính xác và làm việc (chỉ không đầy đủ tính năng) xây dựng.

Answer 2

Thay vì tạo nhánh để sửa lỗi, tại sao bạn không thử tạo nhánh cho phiên bản trước khi sửa lỗi, sau đó áp dụng sửa lỗi cho thân cây.

Bằng cách này, nếu bạn muốn cung cấp cho khách hàng của bạn sửa lỗi, bạn cung cấp cho họ phiên bản thân cây. Nếu bạn không muốn cung cấp cho họ sửa lỗi, bạn có thể cung cấp cho họ phiên bản chi nhánh trước khi bản sửa lỗi của bạn được áp dụng.

Bằng cách này, bạn có thể có Hudson tạo đường trục và các bản dựng hàng đêm của bạn sẽ bao gồm tất cả các bản sửa lỗi của bạn.

Answer 3

Thực hiện hợp nhất hàng đêm với "không ổn định-ác-đôi-thân cây" kết hợp tất cả các nhánh lỗi với cặp đôi độc ác.

Hoặc thiết lập các bản dựng hàng đêm trên mỗi nhánh lỗi (nghe giống như nhiều bản dựng hàng đêm).

Theo ý kiến ​​của tôi, điều này nghe có vẻ giống như rất nhiều phân nhánh cho giải pháp kiểm soát nguồn tập trung. Có thể bạn cần một hệ thống điều khiển phiên bản phân tán và máy chủ xây dựng trên mỗi máy trạm, có vẻ như nó sẽ thực hiện cùng một điều (kiểm tra riêng biệt cho từng nhà phát triển và hàng ngày dựa trên những gì nhà phát triển đăng ký)

Answer 4

Điều đó nghe có vẻ đau đớn và quá phức tạp (từ quan điểm chi nhánh/hợp nhất).

Tôi sẽ phân nhánh khi phát hành và yêu cầu nhà phát triển đăng ký vào thân cây. Bất cứ điều gì cần phải đi ra ngoài như một sửa chữa nóng có thể được sáp nhập với chi nhánh phát hành.

Answer 5

tôi trả lời này rất nhiều, và dưới đây là cách IBM khuyến cáo nó với ClearCase (UCM), và tôi làm điều đó trong thế giới thực:

- Project 
    |- development mainline 
    |- TAG: version-1.0 
     |- version-1.0-bugfix#123 
     |- version-1.0-bugfixes 
    |- TAG: version-1.0-sp1 
     |- version-1.0-sp1-bugfix#234 
     |- version-1.0.sp1-bugfixes 
    |- TAG: version-1.0-sp2 

Bất cứ điều gì không bắt đầu bằng TAG là một chi nhánh.

Answer 6

Đây là những gì chúng tôi (lấy cảm hứng từ Version Control for Multiple Agile Teams bởi Henrik Kniberg):

• phát triển được thực hiện trong một chi nhánh phát triển và các tính năng được đẩy lên thân cây khi "xong làm"
• thân là "done "Chi nhánh
• lúc phát hành, chúng tôi tag thân
• khi một khiếm khuyết đi lên, chúng ta tạo ra một chi nhánh phát hành từ thẻ
• khuyết tật được vá trong các chi nhánh phát hành
• vá được sáp nhập từ chi nhánh phát hành để thân cây ngay sau khi phát hành (bao gồm nó trong phiên bản tương lai)

CI chạy trên tất cả các chi nhánh (chi nhánh phát triển, thân cây, cành phát hành).