Làm thế nào tôi có thể tạo ra một trường hợp cho quản lý phụ thuộc vào khu vực khác?

Tôi hiện đang cố gắng tạo ra một trường hợp để áp dụng quản lý phụ thuộc cho các bản dựng (ala Maven, Ivy, NuGet) và tạo một kho lưu trữ nội bộ cho các mô-đun chia sẻ, trong đó chúng tôi có hơn một chục doanh nghiệp. Các điểm bán hàng chính của kỹ thuật xây dựng này là gì? Những cái tôi có cho đến nay:

• Bắt đầu quá trình phân phối và nhập các mô-đun chia sẻ, đặc biệt là nâng cấp phiên bản.
• Yêu cầu sự phụ thuộc của các mô-đun chia sẻ phải được ghi lại chính xác.
• Loại bỏ các mô-đun được chia sẻ khỏi kiểm soát nguồn, tăng tốc và đơn giản hóa kiểm tra / kiểm tra _{(khi bạn có ứng dụng với hơn 20 thư viện thì đây là một yếu tố thực sự)} .
• Cho phép kiểm soát nhiều hơn hoặc nhận thức về những gì libs bên thứ ba được sử dụng trong tổ chức của bạn.

Có điểm bán nào mà tôi đang thiếu không? Có bất kỳ nghiên cứu hoặc bài viết đưa ra số liệu cải thiện?

Tôi không chắc chắn 100% về mặt tích cực. Dưới đây là một vài tiêu cực

1. Bạn thường kết thúc việc thêm phụ thuộc vào máy chủ / điểm cuối của bên thứ 3 có thể không ổn định.

   Tôi đã có một điều xảy ra với Bower rằng repo của một số phụ thuộc đã bị xóa hoặc di chuyển. Vì vậy, một nhà phát triển mới xuất hiện, nhân bản repo của tôi, gõ bower installvà gặp lỗi cho các repos không thể truy cập. Nếu thay vào đó tôi đã kiểm tra mã bên thứ 3 vào repo của mình thì vấn đề đó sẽ biến mất.

   Điều này được giải quyết giống như OP gợi ý nếu bạn lấy dep từ các bản sao được giữ trên máy chủ bạn chạy.

2. Khó hơn cho noobs.

   Tôi làm việc với các sinh viên nghệ thuật với rất ít kinh nghiệm dòng lệnh. Họ làm nghệ thuật với Xử lý, arduino, Unity3D và nhận được rất ít kiến ​​thức công nghệ. Họ muốn sử dụng một số HTML5 / JavaScript tôi đã viết. Các bước vì bower

   1. Tải xuống Zip repo từ github (lưu ý rằng bên phải của mỗi repo trên github. Bởi vì họ không biết git)
   2. Tải xuống và cài đặt nút (để chúng tôi có thể chạy npm để cài đặt bower)
   3. Cài đặt git hoặc msysgit (vì Bower yêu cầu và nó không được cài đặt trên nhiều máy của sinh viên)
   4. Cài đặt bower ( npm install -g bower)
   5. bower install (cuối cùng để có được sự phụ thuộc của chúng tôi)

   Tất cả các bước 2-5 có thể bị xóa nếu chúng ta chỉ kiểm tra các tập tin vào repo github của chúng tôi. Những bước đó có vẻ siêu dễ dàng cho bạn và tôi. Đối với các sinh viên, họ rất bối rối và họ muốn biết tất cả các bước ở đâu và những gì họ có thể học tốt có thể nhưng hoàn toàn trực giao với chủ đề của lớp và do đó nhanh chóng bị lãng quên.

3. Nó thêm một bước nữa khi kéo.

   Nó đã xảy ra nhiều lần tôi làm một git pull origin mastervà sau đó kiểm tra mã của tôi và phải mất 5 đến 10 phút để nhớ tôi cần phải nhập bower install để có được các bản mới nhất. Tôi chắc chắn rằng điều đó dễ dàng được giải quyết với một số hook script.

4. Nó làm cho git phân nhánh khó hơn

   Nếu 2 nhánh có các dep khác nhau, bạn sẽ bị loại. Tôi cho rằng bạn có thể gõ bower installsau mỗi git checkout. Quá nhiều cho tốc độ.

Về mặt tích cực của bạn, tôi nghĩ rằng có những ví dụ ngược lại với từng người

Bắt đầu quá trình phân phối và nhập các mô-đun chia sẻ, đặc biệt là nâng cấp phiên bản.

vs cái gì Nó chắc chắn không dễ dàng hơn để phân phối. Kéo một repo thay vì 20 không dễ dàng hơn và có nhiều khả năng thất bại. Xem # 1 ở trên

Loại bỏ các mô-đun được chia sẻ khỏi kiểm soát nguồn, tăng tốc và đơn giản hóa kiểm tra / kiểm tra (khi bạn có ứng dụng với hơn 20 thư viện thì đây là một yếu tố thực sự).

Ngược lại, nó có nghĩa là bạn phụ thuộc vào người khác để sửa lỗi. Có nghĩa là nếu deps của bạn được lấy từ nguồn của bên thứ 3 và bạn cần sửa lỗi, bạn phải đợi họ áp dụng bản vá của bạn. Tồi tệ hơn, có lẽ bạn không thể chỉ lấy phiên bản bạn muốn cộng với bản vá của bạn, bạn phải lấy phiên bản mới nhất có thể không tương thích ngược với dự án của bạn.

Bạn có thể giải quyết điều đó bằng cách nhân bản các repos của họ một cách riêng biệt và sau đó bạn trỏ dự án của bạn vào các bản sao của bạn. Sau đó, bạn áp dụng bất kỳ sửa chữa cho bản sao của bạn. Tất nhiên bạn cũng có thể làm điều đó nếu bạn chỉ sao chép nguồn vào repo của bạn

Cho phép kiểm soát nhiều hơn hoặc nhận thức về những gì libs bên thứ ba được sử dụng trong tổ chức của bạn.

Điều đó có vẻ như tranh cãi. Chỉ cần yêu cầu nhà phát triển đặt thư viện bên thứ 3 vào thư mục riêng của họ bên dưới <ProjectRoot>/3rdparty/<nameOfDep>. Thật dễ dàng để xem libs của bên thứ 3 được sử dụng.

Tôi không nói là không có tích cực. Đội cuối cùng tôi tham gia có> 100 người thứ 3. Tôi chỉ chỉ ra rằng nó không phải là tất cả hoa hồng. Tôi đang đánh giá xem tôi có nên loại bỏ bower cho nhu cầu của mình không.

Hãy xem ứng dụng Mười hai nhân tố

Đặc biệt đọc về những gì họ phải nói về sự phụ thuộc . Bạn sẽ nhận thấy rằng thiết kế tốt cung cấp một cơ chế khai báo để định vị các phụ thuộc, trong Java điều này thường được nhận ra thông qua Maven. Ivy và NuGet hoạt động tốt, nhưng Maven hiện đang là người dẫn đầu trong lĩnh vực này và Ivy quyết định làm việc chăm chỉ.

Nếu bạn tuân thủ quy trình phát hành Maven (phát triển ảnh chụp nhanh cho đến khi bản phát hành chính thức sẵn sàng, đừng bao giờ ghi đè lên bản phát hành trước đó, hãy sử dụng trình quản lý kho lưu trữ thích hợp như Nexus hoặc Artifactory), sau đó bạn nên có một quy trình xây dựng phù hợp.

Khi bạn đã có quy trình xây dựng khai báo vững chắc, nó sẽ mở ra cơ hội cho các hoạt động tốt khác như Tích hợp liên tục với Jenkins , Phân tích mã liên tục với Sonar và bạn sẽ thấy mình đang tìm kiếm một chiến lược phân nhánh kiểm soát phiên bản tốt hơn bằng git .

Mỗi trong số trên xây dựng trên cốt lõi đó là Maven. Ngày nay, đó là một quyết định không có trí tuệ.

Và mục số 1 trong danh sách top 10 của chúng tôi là ...

(trống cuộn)

Mỗi nhà phát triển xây dựng với các phiên bản chính xác giống nhau của tất cả các phụ thuộc, vì vậy bạn không bao giờ phải tự hỏi nên triển khai gì vào sản xuất.