2012-01-19 44 views
20

Tôi có một kho lưu trữ Git chứa một loạt các dự án maven cấp cao nhất (mỗi thư mục nằm trong thư mục con của riêng chúng với một tệp pom.xml). Cấp cao nhất ở đây có nghĩa là các dự án này nằm trong thư mục con trực tiếp bên dưới gốc kho. Tất cả các dự án này nên duy trì trong cùng một kho lưu trữ Git.Jenkins: Cách xây dựng nhiều dự án cấp cao nhất từ ​​kho lưu trữ git?

repo 
+--- projectA 
    +--- pom.xml 

+--- projectB 
    +--- pom.xml 

Chúng có thể/nên được tạo bởi công việc độc lập jenkins. Vì vậy, chúng tôi có một công việc cho projectA và một cho projectB.

Trước đây với Subversion tôi đã có thể thiết lập công việc Jenkins (cho mỗi dự án) sẽ chỉ kiểm xuất nguồn dự án và chạy xây dựng Maven từ tệp pom.xml.

Với mô hình Git (có thể giống với tất cả DVCS) thay đổi này và tôi không chắc thực hành tốt nhất là gì. Có một vài lựa chọn mà tôi nhìn thấy và từ đó không có tôi thực sự thích:

  1. Mỗi công việc Jenkins là configured sao chép/kéo Git repo đầy đủ và đề cập đến /pom.xml cho Maven xây dựng. Vì vậy, công việc có tất cả các mã nhưng chỉ xây dựng một phần của nó.
  2. Git cung cấp submodules (http://book.git-scm.com/5_submodules.html) mà dường như thể là một chút khó khăn để xử lý (và có thể phá vỡ một cách dễ dàng)
  3. Tạo mẹ maven (aggregator có chứa tất cả các dự án) dự án mà gây nên mỗi dự án xây dựng (có một công việc jenkins duy nhất). Tệp pom.xml này chứa các phần tử cho projectA và projectB.

Bạn có thấy cách tiếp cận hữu ích hơn cho thiết lập này (thiết lập rất điển hình) không. Kinh nghiệm của bạn là gì? Bất kỳ phương pháp hay nhất nào?

+0

Tôi rất đồng ý với martin.ahrer rằng, khi so sánh với Subversion, Git không có khả năng thanh toán một tiểu dự án của repo, là một yếu tố hạn chế. Tôi trả lời tốt đẹp cho câu hỏi này sẽ là tuyệt vời. – djangofan

Trả lời

4

Tôi nghĩ bạn đang làm việc chống lại hạt ở đây. Nếu các dự án này được phát hành như một đơn vị được phiên bản, bạn thực sự nên tạo một POM cha mẹ. Nhưng bạn có lẽ chỉ nên có một công việc CI duy nhất. Nếu bạn muốn xây dựng đó đi nhanh, bạn có thể cấu hình nó để chỉ xây dựng các mô-đun đã thay đổi kể từ lần xây dựng cuối cùng (nút nâng cao trong phần Xây dựng - "Xây dựng gia tăng - chỉ xây dựng các mô-đun đã thay đổi"). Bạn cũng có thể yêu cầu Jenkins "Thực thi các bản dựng đồng thời nếu cần thiết" để kiểm tra nhiều lần commit cùng một lúc.

Nhưng tôi tò mò tại sao bạn nghĩ bạn muốn nhiều công việc CI? Nếu bạn nhận thấy rằng hai dự án này có vòng đời khác nhau, có lẽ chúng nên được phiên bản riêng biệt và do đó nên có trong kho lưu trữ git riêng biệt. Không bảo tồn kho git, chúng rẻ. Trong thực tế, càng nhiều càng tốt trong hầu hết các trường hợp.

Thông thường, bạn muốn có một pom nhất định để tạo ra một tạo phẩm duy nhất. Aggregator poms rất hữu ích cho việc chia nhỏ các phần của một tạo tác lớn hơn thành các mô-đun con, nhưng chỉ khi các mô-đun con đó không được tự giải phóng.

0

Vâng, thực hành tốt nhất là không lặp lại chính bạn. Vì vậy, có một siêu POM sẽ là tốt từ điểm đứng đó.

Id có thể đi kèm với tùy chọn 1. Dung lượng ổ đĩa thường rẻ.

Nhưng 3 sẽ giúp triển khai các hệ thống mới dễ dàng hơn, mà không cần thiết lập lại Jenkins.

1

@recampbell, tôi có cùng một vấn đề. Chúng tôi có một số dự án liên quan đến nhau trong một kho lưu trữ Hg.

Bằng cách đó, chúng tôi biết chính xác theo phiên bản nào (số phiên bản hg), mỗi biên dịch khác. Khi tôi nói chính xác, tôi có nghĩa là tôi có thể xác minh nó là nhị phân giống hệt nhau.

Sử dụng số bản phát hành quá thô. Ví dụ hôm nay tôi tìm thấy một lỗi được tái sản xuất chỉ dưới phiên bản hg 3367 nhưng không có trong phiên bản hg 3368. Sử dụng nhiều repo hg có thể không tái sản xuất, vì có một số cam kết trong mỗi dự án mỗi ngày, và do đó nó là không thể xác định chính xác phiên bản của từng dự án riêng lẻ đã được sử dụng, chỉ có phiên bản hg là phiên bản đúng để sử dụng (sử dụng bisect để tìm lỗi).

Hóa ra chúng tôi đã thay đổi phiên bản trình điều khiển cơ sở dữ liệu máy khách ở một trong các tiểu dự án và điều đó khiến cho việc tạo dao tự động của chúng tôi thất bại với NPE. Trình điều khiển tất nhiên nếu một phiên bản phát hành mà chúng tôi không viết, chúng tôi chỉ đơn giản sử dụng một phiên bản được cung cấp bởi nhà cung cấp. Chúng tôi đã mất vài ngày để gỡ lỗi này, nhưng vì chúng tôi sử dụng Jenkins để xây dựng mỗi giờ, chúng tôi biết có từ 10 đến 20 cam kết tìm kiếm, và chỉ có 3 hoặc 4 lần chạm vào máy phát dao, nên đó là một nhiệm vụ dễ dàng.

Có phiên bản hỗn hợp của mọi dự án sẽ là một cơn đau ở lưng sau, vì chúng tôi sẽ có một số máy phát-dao-3.1.2.jar khác nhau sẽ khác một chút so với phiên bản khác (trừ khi bạn mong đợi chúng ta thay đổi các số phiên bản sau mỗi lần commit, hoặc nếu có một số cấu hình trong Jenkins/maven/bất cứ điều gì thực hiện điều này tự động thì điều đó sẽ tuyệt vời ...).

Các vấn đề liên quan