Các nhánh phát triển song song, Xây dựng các kho lưu trữ đồ tạo tác và phát hành QA

Question

Phát triển/phân nhánh song song trong hiệu ứng VCS của bạn như thế nào trong việc xây dựng kho lưu trữ và phát hành cho QA?

Tại công ty chúng tôi, chúng tôi phân nhánh VCS cho các nỗ lực phát triển song song và chúng tôi thường không có nhiều cảnh báo về chi nhánh sẽ giao hàng theo thứ tự nào.

Để đánh số phiên bản, tôi muốn đặt một mã định danh chi nhánh để hiển thị QA nhánh nào xây dựng đến từ đó. Bất kỳ xây dựng từ thân cây sẽ có một số phiên bản 'bình thường' không có nhận dạng chi nhánh trong đó:

trunk: 1.1.0 
branch: 1.1.0.MyBranch 
branch: 1.1.0.AnotherBranch 

Nguyên Tôi nghĩ để có một kho vật build mỗi chi nhánh, và một kho lưu trữ chính cho thân cây.

Nhưng nếu số phiên bản của tôi bao gồm chi nhánh, thì số phiên bản sẽ sai đối với sản phẩm (nếu tôi đang xây dựng và phát hành từ chi nhánh).

Cách này chỉ để giải phóng khỏi thân cây?

Ngoài ra, tại thời điểm nào tôi nên bắt đầu giao hàng nhóm QA xây dựng từ thân cây thay vì xây dựng từ chi nhánh?

Ý tưởng hiện tại của tôi là thuyết phục ban quản lý chỉ định một nhóm phát triển cho một lệnh phát hành (nói một tuần từ bản phát hành) và hợp nhất nhánh của họ với thân cây. Sau đó, QA bắt đầu xây dựng thân cây thay vì xây dựng chi nhánh, và nhóm dev có chi nhánh đã được sáp nhập sửa chữa bất kỳ lỗi trực tiếp trong thân cây và không phải là chi nhánh.

* CẬP NHẬT *

Cụ thể hơn, tôi đang sử dụng SVN cho VCS, và Artifactory cho kho của tôi. Tôi đang sử dụng Ivy để quản lý sự phụ thuộc.

Nhìn vào sự giúp đỡ Artifactory trên Repository Layouts (Repository Layouts):

"a sequence of literals that identifies the base revision part of the artifact 
version, excluding any integration information" 
"'1.5.10', or in case of an integration revision '1.2-SNAPSHOT' the base revision 
    is '1.2'" 

này và bố trí mặc định cho Maven và Ivy gợi ý với tôi rằng đây là phổ biến hơn:

MyRepo 
MyLib 
    1.1.0 (this is the dll from trunk) 
    -MyLib.dll 
    1.1.0.MyBranch-SNAPSHOT (dev builds from the "MyBranch" branch) 
    -MyLib.dll 
    1.1.0.AnotherBranch-SNAPSHOT (dev builds from the "AnotherBranch" branch) 
    -MyLib.dll 

Đây có phải là cách bố trí repo điển hình cho việc sử dụng Ivy? Tôi sẽ giả định rằng điều này sẽ yêu cầu sử dụng tính năng chi nhánh của Ivy để giải quyết các phụ thuộc vào thời gian xây dựng vào thư mục nhánh chính xác trong repo?

* CẬP NHẬT 2 *

Dưới đây là cấu trúc Artifactory hiện tại của tôi:

MySnapshotRepo 
CompanyName 
    CompanyName.MyLib 
    1.0-SNAPSHOT 
    MyLib.dll (snapshot builds from the dev branch) 
MyReleaseRepo 
CompanyName 
    CompanyName.MyLib 
    1.0.0 
    MyLib.dll (release builds from the trunk) 
    1.0.1 
    MyLib.dll (release builds from the trunk) 
    1.0.2 
    MyLib.dll (release builds from the trunk) 

1. Làm thế nào để chỉ Ivy tại một repo cụ thể tại thời gian xây dựng? Để phát hành, tôi chỉ cần kéo các tệp nhị phân từ repo phát hành. Đối với một bản dựng snapshot, tôi có thể kéo các tập tin nhị phân nếu chúng hiển thị trong repo snapshot, nếu chúng bị thiếu, tôi có thể kéo chúng từ repo phát hành. Tôi hiểu làm thế nào để chuỗi kho, tôi chỉ không hiểu làm thế nào để chuyển đổi chúng.

Trong IvySettings của tôi.tệp xml tôi có:

<settings defaultResolver="defaultresolvechain"/> 

.. nhưng tôi không muốn mặc định. Tôi muốn chỉ định chuỗi giải quyết nào cần giải quyết khi tôi gọi lệnh giải quyết Ivy. Một cái gì đó như thế này:

<ivy:resolve transitive="false" resolveMode="snapshot-resolve" conf="compile,test"/> 

Đây có phải là cách sai để chuyển repos mà tôi cần phải giải quyết không?

Tác vụ xuất bản có thuộc tính "trình phân giải" hoạt động hoàn hảo cho tôi theo cách tương tự.

Ngoài ra, trong ví dụ cụ thể của tôi, tôi có thể có nhiều chi nhánh SVN tương ứng với nhiều bản sao lưu ảnh chụp nhanh. Tôi có thể tham số hóa cách tôi giải quyết cho bản repos nào không? Hoặc là cách chính xác hơn để đặt ảnh chụp nhanh từ tất cả các chi nhánh vào một repo, và sử dụng tính năng chi nhánh Ivy?

Vui lòng cho tôi biết nếu bạn cần bất kỳ thông tin nào khác để hỗ trợ.

Answer 1

Vì vậy, bạn có bản phát hành bản dựng và tính năng hoặc bản dựng phát triển. Bạn sẽ nhận được bản phát hành của bạn được xây dựng từ thân cây và tính năng được xây dựng từ các nhánh 1.1.0 tính năng. Không sử dụng thân cây để phát triển. Làm tất cả sự phát triển trên các chi nhánh tính năng đó khi chúng trưởng thành và bạn quyết định đưa chúng vào như một phần của bản phát hành hợp nhất chúng với thân cây. Tại thời điểm đó mã này xuất hiện trong các bản xây dựng QA đến từ thân cây. Khi bạn đang sẵn sàng để phát hành, bạn chi nhánh từ thân cây, trong khi bạn tiếp tục làm việc trên các chi nhánh tính năng khác và sáp nhập chúng vào thân cây.

Vì vậy, QA được xây dựng từ thân cây và từ các nhánh phát hành ổn định. Bạn có thể đơn giản hóa thêm bằng cách chỉ có một bản phát hành tại một thời điểm và luôn chỉ thực hiện QA từ thân cây và nhánh hoặc thẻ ngay tại thời điểm phát hành thực tế. Điều này sẽ có thể nếu có hoàn toàn không có phát triển đi vào thân cây, nhưng tất cả để các chi nhánh tính năng.

Đôi khi bạn sẽ cần để có thể chuyển một bản xây dựng phát triển cho QA. Thông thường trước khi hợp nhất chi nhánh tính năng với thân cây, chỉ để chắc chắn bạn không phá vỡ bất cứ thứ gì. Bạn có thể gắn thẻ trước khi hợp nhất, hợp nhất chi tiết đối tượng vào thân cây và thực hiện xây dựng QA từ thân cây trong trường hợp này và nếu có vấn đề nghiêm trọng, bạn có thể hoàn nguyên về thẻ. Nó sẽ ngăn chặn việc sáp nhập từ một chi nhánh tính năng khác, trong khi điều này đang diễn ra, nhưng nếu việc hợp nhất xuống thân cây là không thường xuyên, điều này có thể làm việc.

Bằng cách này bạn có thể có thiết lập đơn cho QA từ thân cây và bạn nên quản lý hầu hết những gì bạn cần làm.