Chúng tôi là một công ty nhỏ với nhiều đội quản lý kho git của riêng họ. Đây là một nền tảng web và các đồ tạo tác của mỗi đội được triển khai vào cuối ngày để kiểm tra hàng đêm. Chúng tôi đang cố gắng chính thức hóa quy trình xung quanh phiên bản và bao bì.
Mỗi đội có một nhánh chính nơi họ phát triển hàng ngày. Các thành viên đảm bảo chất lượng của mỗi đội muốn các vật phẩm từ các thay đổi của đội của họ được triển khai thành giường thử nghiệm, nơi tất cả các thành phần được kết hợp bởi đầu bếp. Hiện vật là tarball nhưng tôi muốn chuyển đổi chúng thành RPM để chúng ta có thể suy nghĩ và suy luận về các phiên bản một cách chính xác.
Quá trình phát hành bao gồm việc cắt một nhánh phát hành khỏi nhánh phát triển (chủ trong hầu hết các trường hợp) của mỗi kho git. Điều này sau đó được trao cho đảm bảo chất lượng, những người chạy thử nghiệm và đăng xuất trên một bộ cổ vật.
Ví dụ: đây là kho lưu trữ git điển hình với các nhánh phát hành được liên kết:
0-0-0-0-0-0-0-0-0-0 (master)
| |
0 0
(rel-1) |
0
(rel-2)
Tôi bị mắc kẹt khi cố gắng tìm ra một kế hoạch để thực hiện phiên bản các gói đến từ các nhánh phát triển. Chúng tôi không muốn gắn thẻ quá mức cho nhánh chính của mỗi repo và hạn chế các thẻ chỉ phát hành các nhánh. Nhưng chúng ta sẽ có thể truy vấn các gói được triển khai trong các máy kiểm tra bằng cách sử dụng ngữ nghĩa yum / vòng / phút tiêu chuẩn. Các phiên bản phát triển sẽ trông như thế nào khi nhánh chính không có thẻ? Tôi hiểu rằng git describecó thể cung cấp cho tôi một đại diện hữu ích của phiên bản xây dựng nhưng hoạt động tốt khi các điểm phát hành khác nhau trên nhánh được gắn thẻ.
EDIT1: Đáp lại câu trả lời của @ Urban48
Tôi hình dung tôi nên giải thích quá trình phát hành của chúng tôi nhiều hơn một chút. Đối với mục đích của cuộc thảo luận này, giả sử chúng ta có chi nhánh mastertrong tất cả các kho lưu trữ. Các masterchi nhánh được coi là chi nhánh phát triển và được triển khai đến một tự động CI-CD kích hoạt môi trường QA. Đây là nơi một tập hợp các bài kiểm tra hàng đêm chạy để đảm bảo sự ổn định của chủ. Chúng tôi xem xét đường ống công việc này trước khi cắt một chi nhánh phát hành. Chi nhánh phát hành của chúng tôi là ngắn ngủi. Giả sử, sau khi cắt một nhánh phát hành (từ một bản gốc ổn định), một hồi quy đầy đủ được chạy, các bản sửa lỗi được thực hiện và triển khai để sản xuất. Điều này mất khoảng một tuần để làm. Chúng tôi phát hành gần như hai tuần một lần để sản xuất.
Các nhánh tính năng của chúng tôi luôn được cắt từ chủ và trải qua một số lượng thử nghiệm của nhà phát triển trước khi hợp nhất với chủ mà họ trải qua kiểm tra độ ổn định CI-CD.
Hotfix được thực hiện trên các nhánh hotfix (được cắt từ các nhánh phát hành) và được triển khai với thử nghiệm tác động tối thiểu vào sản xuất.
Chiến lược phiên bản của chúng tôi để phát hành và các nhánh hotfix theo sau semver. Thả chi nhánh trong QA chu kỳ đi qua các phiên bản như v2.0.0-rc1, v2.0.0-rc2và cuối cùng sau khi QA dấu-off trở thành v2.0.0.
Đôi khi chúng tôi thực hiện các bản phát hành chấm cho các tính năng nhỏ được hợp nhất để phát hành các nhánh (và sau đó thành chủ) nơi các phiên bản trở thành v2.1.0. Và hotfix giả định v2.1.1mô hình.
Tuy nhiên, câu hỏi không phải là về phiên bản các nhánh này. Tôi không muốn thay đổi hoàn toàn sơ đồ phiên bản này. Sự thay đổi duy nhất đến về nhánh phát triển tức là. bậc thầy. Làm thế nào tôi có thể chỉ ra một cách đáng tin cậy trong môi trường CI-CD phiên bản nào tồn tại trong bản phát hành trước đó vào sản xuất. Điều này lý tưởng sẽ được thực hiện thông qua gắn thẻ git thông minh nhưng một cái gì đó không gắn thẻ quá mức chi nhánh chính được ưa thích.
rchậu tố? Điều đó sẽ ra lệnh cho major.minorphiên bản phát triển. rcvà số lượng xây dựng có thể được lấy chỉ dựa trên đó. Ngoài ra rctrên chủ không có ý nghĩa bởi vì chúng tôi không bao giờ phát hành từ chủ. Chúng tôi gắn thẻ các ứng cử viên phát hành của chúng tôi ngày hôm nay trên các nhánh phát hành như một phần của chu kỳ phát hành
rchậu tố.
