Chiến lược phân nhánh với maven, teamcity và TFS

Question

Tôi đã được giao nhiệm vụ cập nhật quy trình xây dựng của mình ngay bây giờ để hiệu quả hơn và tôi đã dành một tuần để đọc các chiến lược và phương pháp hay nhất nhưng tôi vẫn chưa tìm được giải pháp cho vấn đề hiện tại của mình.

nền

Hiện nay chúng tôi có một build/ứng dụng nguyên khối mà thực sự cần phải được tách ra thành ít nhất 4 ứng dụng với một số thư viện chia sẻ. Chúng tôi hiện không chi nhánh trừ khi chúng tôi hoàn toàn phải làm vậy. Chúng tôi có một xây dựng teamcity được xây dựng trên mỗi lần đăng ký TFS. Khi chúng tôi đã sẵn sàng cho một bản phát hành, chúng tôi có một mã đóng băng và chỉ kiểm tra các bản sửa lỗi cho các lỗi được tìm thấy trong QA. Rõ ràng đây là một thực tế khủng khiếp và cuối cùng chúng tôi đã nhận được sự chấp thuận để thay đổi nó.

đề xuất giải pháp

Các giải pháp đề xuất sẽ được chia ra các ứng dụng và có chu kỳ phát hành khác nhau cho mỗi ứng dụng, di chuyển từ kiến ​​để maven và chi nhánh cho mỗi phiên bản.

Phân nhánh - Ngay bây giờ, chúng tôi chỉ có một thân chính trong điều khiển nguồn. Tôi nghĩ rằng chúng tôi muốn chi nhánh ra khỏi thân cây khi chúng tôi đã sẵn sàng cho một bản phát hành, và cập nhật các chi nhánh cho lỗi tìm thấy trong QA. Khi xây dựng đã sẵn sàng để được phát hành, hợp nhất các chi nhánh thay đổi trở lại vào thân cây.

Đây là cách tôi dự định thiết lập TFS.

+Apps 
    +App1 
     +Components 
      +Core 
      +Web 
     +Branches 
    +App2 
     +Components 
      +Core 
      +Web 
     +Branches 
    +Libraries 
     +Lib1 
     +Lib2 
     +Branches 

Suy nghĩ về việc quản lý tất cả POM và phiên bản trong POM dường như quá khó khăn. Tôi đã đọc lên trên các plugin phát hành maven, nhưng tôi không chắc chắn nếu nó có thể chi nhánh theo cách tôi nghĩ chúng tôi muốn.

Vấn đề tiếp theo là làm việc nhóm. Tôi đã nghĩ đến việc có 3 dự án hợp tác cho mỗi ứng dụng. Một dự án dev luôn trỏ vào thân cây, một dự án QA để thử nghiệm xây dựng QA và một dự án sản xuất để xây dựng các thay đổi cho hotfix. Mỗi khi một bản phát hành mới đến với QA, tôi sẽ phải cập nhật dự án nhóm QA để trỏ đến nhánh phát hành mới và cập nhật số bản phát hành trong teamcity. Khi bản phát hành đó vượt qua QA, tôi sẽ phải cập nhật dự án teamcity sản xuất để chỉ ra rằng chi nhánh vừa vượt qua QA và cập nhật số bản dựng cho số bản dựng vừa vượt qua QA.

Chắc chắn có một chiến lược tốt hơn cho điều này.

Câu hỏi

Nơi tôi nên đặt các thư mục này chi nhánh?

Các bản dựng QA có nên là ảnh chụp nhanh cho đến khi bản dựng đi trước khi sản xuất không?

Làm cách nào để bạn định cấu hình teamcity để nhận các nhánh này mà không thay đổi đường dẫn nguồn cho mỗi bản phát hành?

Có nên có POM mẹ cho mỗi ứng dụng mà nhà phát triển sử dụng để đảm bảo tất cả các phụ thuộc của họ được biên soạn và cập nhật không?

Answer 1

Tôi chỉ muốn đặt câu hỏi cho suy nghĩ của bạn rằng các ứng dụng của bạn phải ở trong các chu kỳ phát hành khác nhau. Modularization là một điều tốt cho chất lượng mã, nhưng nếu các mô-đun của bạn đang trong chu kỳ phát hành riêng biệt, bạn giới thiệu rất nhiều chi phí. Đặc biệt, quản lý phiên bản trở thành một gánh nặng và nếu bạn làm sai, bạn có thể giới thiệu các lỗi thời gian chạy.

Các ứng dụng riêng biệt này có liên quan như thế nào với nhau? Có sự phụ thuộc nào giữa chúng (có thể thông qua thư viện được chia sẻ) không? Họ có giao tiếp với nhau không? Chúng có được triển khai cùng nhau không?

Nếu không phải là cần thiết rằng chúng có trong chu kỳ phát hành riêng biệt thì có thể bạn nên giữ chúng lại với nhau.