Để phụ thuộc vào mã nguồn hoặc vào nhị phân?

Chúng tôi có hai dự án nội bộ là A và B, được phát triển bởi các nhóm khác nhau với B phụ thuộc vào A. Vì mã nguồn của cả hai dự án được lưu trữ trong git, tôi đã đưa dự án A làm mô hình con vào dự án B và định cấu hình hệ thống xây dựng để xây dựng cả hai theo đúng thứ tự. Một giải pháp thay thế sẽ là tiêu thụ A thông qua trình quản lý kho lưu trữ nhị phân như Artifactory hoặc Nexus.

Tôi tự hỏi về ưu và nhược điểm của tùy thuộc vào mã nguồn so với tùy thuộc vào tạo tác nhị phân. Khi nào thì tốt hơn cái kia? Cho đến nay tôi đã xoay sở để đưa ra các yếu tố sau, nhưng tôi thực sự muốn nghe ý kiến ​​khác.

Tùy thuộc vào mã nguồn là tốt hơn

• nếu bạn không có trình quản lý kho lưu trữ nhị phân
• nếu bạn cần phụ thuộc vào phiên bản tiền phát hành của dự án khác
• nếu bạn cần vá một dự án khác
• bởi vì nó dễ dàng hơn để duyệt mã nguồn phụ thuộc trong IDE

Tùy thuộc vào nhị phân là tốt hơn

• để giảm thiểu thời gian xây dựng
• để tránh những rắc rối khi thiết lập môi trường xây dựng của dự án khác

Tôi luôn luôn đề nghị các phụ thuộc nhị phân trên các phụ thuộc nguồn. Hầu hết các ưu điểm bạn liệt kê cho mã nguồn cũng có thể dễ dàng kết hợp vào các phụ thuộc nhị phân.

Đầu tiên, rất nhanh chóng để thiết lập repo Nexus trên một số máy chủ cục bộ. Lợi ích của việc có một repo nhị phân vượt xa nỗ lực / chi phí thiết lập. Đây gần như là một điều kiện tiên quyết cho phần còn lại của câu trả lời của tôi :)

Đối với các phiên bản tiền phát hành, các dự án của bạn nên triển khai các phiên bản -SNAPSHOT vào bản tạo. Có thể có một sự khác biệt tốt đẹp và rõ ràng giữa các phiên bản, chẳng hạn như:

• projectA-3.2.0-SNAPSHOT : Phát triển tích cực, có thể thay đổi bất cứ lúc nào
• projectA-3.2.0-RC1 : Ứng cử viên phát hành
• projectA-3.2.0 : Phát hành sản xuất

Tất cả các phiên bản này có thể được lưu trữ cùng nhau trong artifactory của bạn. Các dự án của bạn sẽ biết chính xác những gì họ đang biên dịch chống lại.

Đối với các bản vá, gitlà bạn của bạn. Ngã ba repo và đặt một số phiên bản vá, chẳng hạn như projectA-3.2.1-FOR_PROJ_B. Lưu ý .1 hiển thị bản phát hành bản vá và mô tả. Điều này cũng sẽ giúp dự án dễ dàng kéo các thay đổi đó trở lại bản gốc sau này.

Đối với mã nguồn, bạn có thể định cấu hình công cụ xây dựng của mình để tạo "bình nguồn" và triển khai nó cùng với tệp nhị phân trong phần tử. Hầu hết các IDE có thể tra cứu tên jar nguồn và tự động tải xuống nguồn cho bạn.

Một lý do lớn khác để tránh xa mã nguồn là bạn bị ràng buộc với hệ thống xây dựng, chuỗi công cụ và phụ thuộc thời gian biên dịch của Dự án A. Nếu bạn thấy lỗi xây dựng trong Dự án B, trước tiên bạn phải điều tra xem Dự án A hay Dự án B gây ra lỗi. Nếu đó là Dự án A, bạn đã theo dõi những người từ dự án đó để sửa lỗi bản dựng của họ. Điều này thêm rất nhiều chi phí cho chu kỳ xây dựng của bạn.

Tôi sẽ phụ thuộc vào nhị phân, bởi vì hầu như không có sự cân nhắc nào của bạn ủng hộ tôi là không có sự chỉ trích:

• nếu bạn không có trình quản lý kho lưu trữ nhị phân: không sao, nhưng tôi không nghĩ rằng việc đó khó thực hiện. Ở cấp độ cơ bản nhất, một thư mục dùng chung, nơi chỉ những người phụ trách quyết định sử dụng phiên bản nào mới có thể viết.

• nếu bạn cần phụ thuộc vào phiên bản tiền phát hành của dự án khác: metacubed đã được bảo hiểm. Hoặc với mã nguồn hoặc phụ thuộc nhị phân, bạn nên giữ một phiên bản được thiết lập tốt, ngay cả khi nó được phát hành trước. Tất nhiên, khi phát triển dựa trên bản phát hành trước, tỷ lệ cược là bạn sẽ cần chuyển sang phiên bản cập nhật thường xuyên do giải quyết lỗi.

• nếu bạn cần vá một dự án khác: bạn có nghĩa là nhóm của bạn sẽ vá dự án được thực hiện từ một nhóm khác trong cùng một nhà không? Tôi muốn nói rằng chiến lược lành mạnh nhất là nói với nhóm khác những vấn đề bạn gặp phải với dự án của họ.

• bởi vì việc duyệt mã nguồn phụ thuộc trong IDE dễ dàng hơn: Bạn không cần phải rình mò vào hoạt động bên trong của các phụ thuộc của mình, bởi vì điều đó có nghĩa là:

  • dự án A là tài liệu kém
  • lập trình viên của bạn sẽ kết thúc bằng cách sử dụng "các tính năng không có giấy tờ" của dự án A có thể biến mất mà không có cảnh báo trước tại bất kỳ bản cập nhật nào.