Làm thế nào để bạn giữ các nhị phân phát hành dưới sự kiểm soát phiên bản?

Làm thế nào để bạn giữ các nhị phân phát hành dưới sự kiểm soát phiên bản? Điều này cho phép theo dõi những thứ được thay đổi giữa mỗi lần phát hành. Tôi có nghĩa là để tách các nhị phân được phát hành từ kho lưu trữ nguồn. Các tệp nhị phân được phát hành được xây dựng từ phần mềm Tích hợp liên tục hoặc được biên dịch thủ công.

Hai lựa chọn:

a) Đừng. Chỉ cần đảm bảo rằng bạn có các bản dựng xác định có thể lặp lại, nghĩa là, xây dựng cùng một bản sửa đổi kiểm soát nguồn với cùng cấu hình luôn tạo ra cùng một nhị phân.

b) Chỉ định một thư mục ở đâu đó làm nguồn có thẩm quyền cho các bản dựng được xuất bản. Hãy tải lên các phần nhị phân của quy trình triển khai / vận chuyển và đảm bảo thư mục bản dựng được xuất bản được bao phủ bởi gói sao lưu của bạn. Bạn không cần bất kỳ kiểm soát phiên bản nào ở đây; bản dựng là ghi một lần, nếu bạn cần thay đổi bất cứ thứ gì, bạn tạo bản dựng mới.

Dù bằng cách nào, nhị phân và đầu ra bản dựng khác không thuộc quyền kiểm soát nguồn, vì nhiều lý do.

Sử dụng kho lưu trữ giả cho nhị phân, không phải hệ thống kiểm soát phiên bản. Một phiên bản cụ thể của tệp nhị phân được phát hành không được phép thay đổi theo thời gian, do đó kiểm soát phiên bản không có ý nghĩa vì (các) tệp sẽ không thay đổi.

Xem ví dụ kho lưu trữ Maven dưới dạng kho lưu trữ / xuất bản / cung cấp bản phát hành và các tệp nhị phân khác (ví dụ như tài liệu)

Chỉ cần đặt chúng vào. Không có vấn đề gì với điều đó, trừ khi bạn đang sử dụng git (không hợp nhất các nhị phân, vì vậy bạn sẽ phải tự quản lý chúng) hoặc bạn đã cam kết chúng quá nhiều lần (chỉ cam kết khi nó sẵn sàng để vận chuyển, không phải mọi lúc bạn xây dựng nó).

Hầu hết các nhị phân delta của SCM khá tốt, chúng tôi thường đưa dll tài nguyên 2Mb vào SVN của chúng tôi và nó sẽ delta đến vài kb mỗi lần.

Tôi nghe thấy rất nhiều lập luận rằng SCM là dành cho nguồn, không phải là nhị phân nhưng điều này hoàn toàn sai khi bạn xem xét hầu hết các phần mềm bao gồm hình ảnh, ngay cả khi chúng chỉ là các tệp biểu tượng. Chúng là nhị phân, nhưng chúng là một phần của nguồn, vì vậy hãy đặt chúng vào và đừng quá giáo điều về nó. Tôi cũng nghe nói rằng bạn chỉ có thể xây dựng lại nhị phân khi cần, thường thì đây là trường hợp, nhưng nó có thể là một nỗ lực lãng phí thời gian rất lớn cho các hệ thống cũ không còn được hỗ trợ tích cực. Nếu bạn phải tạo lại một hệ thống chỉ có các gói dịch vụ hoặc bản vá cũ hơn để tương ứng với hệ thống đã được sử dụng để xây dựng nhị phân 3 năm trước, bạn sẽ rất vui khi bạn thêm thùng vào SCM của mình sau đó.

Lần duy nhất bạn cần lo lắng về việc thêm các bản dựng vào SCM của mình là nếu bạn thực hiện nó một cách tự động như một phần của quy trình máy chủ xây dựng - đừng làm điều này. Bạn sẽ lấp đầy SCM của mình bằng các bản dựng không có lợi cho bạn. Thay vào đó chỉ thêm chúng khi chúng được phát hành. Bằng cách này, bạn biết chính xác những gì khách hàng của bạn có và bạn có thể tái tạo bất kỳ sự cố nào do khách hàng báo cáo với các tệp nhị phân họ đang sử dụng và không phải là những vấn đề bạn đã xây dựng lại (sử dụng, giả sử, cập nhật mới nhất cho trình biên dịch hoặc HĐH).

Tôi không giữ bản phát hành nhị phân dưới sự kiểm soát phiên bản. Thay vào đó tôi xuất bản chúng đến một vị trí được xác định rõ để các công cụ khác kiểm tra và sử dụng chúng. Tôi làm rất nhiều công việc trong Java, vì vậy điều đó có nghĩa là tôi xuất bản Jars lên kho lưu trữ Maven cục bộ. Tuy nhiên, tôi không sử dụng các công cụ này để theo dõi những gì đã thay đổi trên mỗi bản phát hành. Rốt cuộc, chúng là nhị phân và thực sự không có nhiều thứ để theo dõi ngoài số lượng tệp.

Để theo dõi các thay đổi giữa các bản phát hành, tôi sẽ gắn thẻ hoặc gắn nhãn các bản phát hành trong hệ thống kiểm soát phiên bản của tôi với số phiên bản của bản phát hành. Nhưng điều này thực sự chỉ để theo dõi các tập tin nguồn, không phải là nhị phân. Các tệp nhị phân là các tạo phẩm của bản dựng và không cần phải được kiểm soát phiên bản.

Giải pháp tốt nhất là sử dụng độc quyền hệ thống CI của bạn cho tất cả các bản dựng có ý nghĩa tổ chức (phát hành, phát hành ứng viên, v.v.).

Điều này có hệ thống liên kết các nhị phân được phát hành với nội dung kho lưu trữ mà không phải thực sự lưu trữ các nhị phân trong kho lưu trữ.

Ví dụ: nếu bạn đang sử dụng SVN, hãy sử dụng sơ đồ tổ chức chính của chi nhánh; thực hiện tất cả sự phát triển hàng ngày trong / thân cây và tạo thẻ / cho mỗi bản phát hành khi nó sẵn sàng.

Định cấu hình hệ thống CI của bạn để xây dựng từ các thẻ cũng như từ thân cây và lấy nó để ghi đầu ra vào thư mục mạng có cấu trúc phản ánh cấu trúc cấp cao nhất của repo:

• / builds / trunk / [rev] [date] [build_id] /
• / bản dựng / thẻ / phát hành_0_1_3beta4 / [rev] [ngày] [build_id] /

Hệ thống xây dựng sẽ cần xử lý / builds / trunk / như bộ đệm tròn, lưu trữ các bản dựng n cuối cùng, xóa các bản dựng cũ khi nó đi.

Mặt khác, thư mục / builds / tags / là một cửa hàng cố định. Bản thân các tạo phẩm xây dựng được lưu trữ trong các thư mục với các tên được tạo theo sơ đồ sau:

• [rev] [ngày] [build_id]

trong đó [rev] là ID sửa đổi SVN, [ngày] là ngày ở định dạng YYYYMMDD và [build_id] là một bộ đếm duy nhất gồm 3 chữ số, tăng dần từ bản dựng đầu tiên trở đi, làm cho mỗi thư mục bản dựng trở thành duy nhất.

Quá trình chi tiết ở trên cung cấp cho bạn những lợi ích sau:

1. Các tạo phẩm xây dựng được gắn một cách có hệ thống với nguồn đã tạo ra chúng, vì vậy bạn có thể tìm thấy nguồn cho một tạo phẩm xây dựng cụ thể rất dễ dàng, (và ngược lại).

2. Điều này tạo cơ sở cho việc tự động hóa phát hành hơn nữa. Ví dụ: tự động tạo tài liệu phát hành, v.v ...