2011-06-30 40 views
19

Làm cách nào để bạn xử lý ánh xạ công việc Jenkins cho quá trình xây dựng của mình và bạn có thể xây dựng trong cấu hình tầng trên kế thừa không?Thừa kế công việc trong công việc Jenkins

Đối với bất kỳ công trình nào, tôi sẽ có ít nhất ba công việc (tích hợp liên tục tiêu chuẩn/đêm, quét bảo mật, vùng phủ sóng) và sau đó một số công việc kiểm tra tích hợp hạ lưu. Plugin slicer cấu hình xử lý một số khía cạnh, nhưng mỗi công việc vẫn còn rất nhiều thực thể riêng của nó mà không có mối quan hệ với các công việc khác trong nhóm của nó.

Gần đây tôi đã thấy QuickBuild và nó có thừa kế công việc trong đó công việc cha mẹ có thể xác định nhóm bước chuẩn và con của nó có thể ghi đè và chuyên môn. Với Jenkins, tôi có các bản sao của công việc, điều đó tốt cho đến khi tôi cần thay đổi một thứ gì đó. Với QuickBuild, mối quan hệ giữa các công việc cho phép tôi truyền bá những thay đổi của mình với ít nỗ lực.

Tôi đã cố gắng tìm ra cách xử lý điều này trong Jenkins. Tôi có thể sử dụng plugin kích hoạt trình xây dựng tham số để cho phép công việc gọi cho người khác và ghi đè các khía cạnh. Sau đó tôi sẽ thu thập dữ liệu từ các công việc được gọi đến người gọi của nó. Tôi nghi ngờ tôi sẽ chạy vào một loạt các vấn đề mà có những khía cạnh mà tôi không thể ghi đè mà sẽ buộc tôi để thực hiện chức năng Jenkins trong kịch bản của riêng tôi do đó làm cho Jenkins ít hữu ích.

Làm cách nào để bạn xử lý sự phức tạp trong công việc xây dựng của mình trong Jenkins? Bạn đã từng nghe về bất kỳ vấn đề nghiêm trọng nào với QuickBuild chưa?

+0

Tôi đã nhìn vào những vấn đề hiện nay mặc dù không bất kỳ sự quan tâm nào trong QuickBuild. Cụ thể là tôi muốn các tùy chọn cấu hình khác nhau cho CI và Nightly builds, chẳng hạn như kiểm tra vào không gian làm việc sạch so với bản cập nhật hoàn nguyên, thời gian tạo các tạo phẩm được lưu trữ và cách lưu trữ hoặc triển khai các tạo phẩm - xây dựng hướng dẫn cho từng. The Matrix/multiconfig plugin không cung cấp đủ tùy chọn. Tôi nghĩ rằng chúng ta có thể quản lý nó với một công việc phụ mà chỉ xây dựng chính nó, được gọi với một không gian làm việc được tham số hóa - nhưng nó là một sự phức tạp thêm vào. – CJBrew

+0

Nếu mỗi công việc của bạn thực hiện một khía cạnh của CI của bạn thì không cần sao chép các nhiệm vụ giữa các công việc. Chúng tôi có một công việc xây dựng có một công việc hạ lưu mà các giai đoạn mà sau đó chạy các bài kiểm tra tích hợp. Nếu có mong muốn chạy một số thử nghiệm theo giai đoạn này trong khoảng thời gian định kỳ thông thường, điều này có thể được thiết lập trong các công việc đó dưới dạng trình kích hoạt theo thời gian. Bằng cách này, công việc xây dựng chỉ được xây dựng, công việc kiểm thử chỉ thực hiện kiểm tra và vân vân. Nếu bạn sử dụng tác vụ 'Lưu trữ cho Clone Workspace' thì công việc ở hạ lưu có thể truy cập vào các tạo phẩm xây dựng. Có thể mở rộng trong câu trả lời nếu bạn muốn? – jbjon

+3

Tôi tự hỏi nếu một năm sau, bạn tìm thấy một giải pháp cho vấn đề này. – sorin

Trả lời

2

Tôi có khá nhiều vấn đề tương tự. Chúng tôi có một bộ công việc cần chạy cho thân cây của chúng tôi cũng như ít nhất hai nhánh. Các nhánh đại diện cho các phiên bản của chúng ta, và một nhánh mới được tạo ra sau mỗi vài tháng. Tạo công việc mới bằng tay cho điều này là không có giải pháp, vì vậy tôi đã kiểm tra một số khả năng.

Một khả năng là sử dụng template plugin. Điều này cho phép bạn tạo một hệ thống phân cấp các công việc của một loại. Nó cung cấp thừa kế cho các nhà xây dựng, nhà xuất bản và cài đặt SCM. Có thể làm việc cho một số, đối với tôi nó là không đủ.

Điều thứ hai tôi đã kiểm tra là Ant Script để nhân bản công việc và anh chị em của mình là Bash Script. Đây là những điều thực sự tuyệt vời. Ý tưởng là để làm cho kịch bản tạo một công việc mới cho, sao chép tất cả các thiết lập từ một công việc mẫu, thực hiện thay đổi khi bạn cần chúng. Vì đây là một kịch bản rất linh hoạt và bạn có thể làm được rất nhiều điều đó. Hạn chế duy nhất là, điều này sẽ không dẫn đến một hệ thống phân cấp thực sự, vì vậy những thay đổi trong công việc mẫu sẽ không phản ánh về công việc đã nhân bản, chỉ trên các công việc sẽ được tạo ra trong tương lai.

Nhìn vào những mặt hạn chế và nhân đức của hai giải pháp đó, sự kết hợp cả hai có thể hoạt động tốt nhất. Bạn tạo một dự án mẫu với một số cài đặt cơ bản sẽ đúng đối với tất cả các công việc, và sau đó sử dụng tập lệnh bash hoặc ant để tạo các công việc tùy thuộc vào mẫu đó.

Hy vọng điều đó sẽ hữu ích.

+0

Plugin mẫu là cách để đi. Chúng tôi đã sử dụng nó và nó được thực hiện tất cả chúng tôi thực sự muốn ra khỏi một plugin templating! – Mark

1

Tôi được hỏi giải pháp cuối cùng của chúng tôi cho vấn đề là gì ... Sau nhiều tháng chiến đấu với hệ thống mua hàng của chúng tôi, chúng tôi đã chi khoảng 4000 đô la Mỹ cho Quickbuild. Trong khoảng 2-3 tháng, chúng tôi đã có một hệ thống xây dựng theo khuôn mẫu tại chỗ và rất hài lòng với nó. Trước khi rời công ty, chúng tôi đã có một vài nhóm sản phẩm trong hệ thống và đang tự động hóa quá trình phát hành.

Quickbuild là một sản phẩm tuyệt vời. Nó phải ở trong lớp $ 40k nhưng nó có giá thấp hơn nhiều. Trong khi tôi chắc chắn Jenkins có thể làm điều này, nó sẽ là một chút của một kludge trong khi Quickbuild đã có chức năng này nướng. Tôi đã thực hiện hành vi phức tạp trên đầu trang của sản phẩm trước (ví dụ như hợp nhất theo dõi trong SVN 1.0) và hối tiếc nó. Quickbuild có giá hợp lý và cung cấp một nền tảng vững chắc cho các hệ thống xây dựng và thử nghiệm của chúng tôi.

Hiện nay, tôi đang ở một công ty sử dụng tre và hy vọng tính năng chi nhánh tính năng mới của nó sẽ cung cấp phần lớn những gì có thể làm Quickbuild

0

Chúng tôi sử dụng quickbuild và có vẻ như để làm việc tuyệt vời cho hầu hết mọi thứ. Tôi thậm chí có thể sử dụng API của mình để viết các plugin tùy chỉnh. Một lĩnh vực mà quickbuild thiếu là tích hợp sonar. Nhóm sonar có một plugin Jenkins và không phải là một cho quickbuild.

13

Tôi muốn chỉ ra cho bạn bản phát hành plugin mà nhóm của tôi đã phát triển và chỉ mới xuất bản gần đây theo nguồn mở. Nó thực hiện đầy đủ "Thừa kế giữa các công việc".

đây cho các liên kết hơn nữa có thể giúp bạn:

+0

Có kế hoạch tiếp tục phát triển không? Đặc biệt là sửa chữa các không tương thích được liệt kê với 'Lịch sử cấu hình công việc' và' Artifactory'. Cam kết cuối cùng trên GitHub là từ tháng 2 năm 2015. –

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