buildbot vs hudson / jenkins để tích hợp liên tục C ++

Tôi hiện đang sử dụng jenkins / hudson để tích hợp liên tục một dự án lớn chủ yếu là C ++. Chúng tôi có các dự án riêng biệt cho thân cây và mọi chi nhánh. Ngoài ra, có một số dự án liên quan cho mã Java, nhưng thiết lập cho những dự án đó khá cơ bản ngay bây giờ (mặc dù vậy, chúng tôi có thể thực hiện thêm sau). Các dự án C ++ làm như sau:

• Xây dựng mọi thứ với các tùy chọn để định cấu hình lại, xây dựng hoàn chỉnh hoặc sử dụng thanh toán mới
• Tùy chọn xây dựng và chạy tất cả các thử nghiệm
• Tùy chọn chạy tất cả các bài kiểm tra bằng cách sử dụng ghi nhớ của Valgrind
• Chạy cppcheck
• Tạo tài liệu doxygen
• Báo cáo xuất bản: kiểm tra đơn vị, valgrind, cppcheck, cảnh báo trình biên dịch, SLOC, các tác vụ đang mở và phạm vi mã (sử dụng gcov, gcovr và plugin cobertura)
• Triển khai mã hàng đêm hoặc theo yêu cầu vào môi trường thử nghiệm và kho lưu trữ gói

Mọi thứ đều có thể định cấu hình cho các bản dựng tự động và tùy chọn cho các bản dựng theo yêu cầu. Bên dưới, có một tập lệnh bash kiểm soát phần lớn điều này, điều này phụ thuộc nhiều hơn vào hệ thống xây dựng của chúng tôi, sử dụng chế độ tự động hóa và autoconf cùng với các tập lệnh bash tùy chỉnh.

Chúng tôi bắt đầu sử dụng Hudson (vào thời điểm đó) vì đó là thứ mà những người Java đang sử dụng và chúng tôi chỉ muốn các bản dựng hàng đêm. Kể từ đó, chúng tôi đã thêm rất nhiều và tiếp tục thêm nhiều hơn nữa. Về mặt nào đó, Hudson rất tuyệt, nhưng chắc chắn không phải là lý tưởng.

Tôi đã xem xét các giải pháp khác và giải pháp duy nhất có vẻ như nó có thể thay thế là buildbot. Buildbot sẽ tốt hơn cho tình huống này? Khoản đầu tư có xứng đáng không vì chúng tôi đã sử dụng Hudson? Tại sao?

CHỈNH SỬA : Có người hỏi tại sao tôi không thấy Hudson / Jenkins là người lý tưởng. Câu trả lời ngắn gọn là mọi thứ đều có thể được cải thiện. Tôi chỉ đơn giản là tự hỏi liệu Jenkins có phải là giải pháp tốt nhất hiện tại cho trường hợp sử dụng của tôi hay không hay liệu có thứ gì đó tốt hơn (buildbot?) Sẽ dễ bảo trì hơn về lâu dài ngay cả khi các yêu cầu mới xuất hiện.

Cả hai đều là các dự án mã nguồn mở, nhưng bạn không cần phải thay đổi mã buildbot để "mở rộng" nó, thực sự khá dễ dàng để nhập các gói của riêng bạn vào cấu hình của nó, trong đó bạn có thể phân loại hầu hết các tính năng bằng các bổ sung của riêng bạn. Ví dụ: mã biên dịch hoặc kiểm tra của riêng bạn, phân tích cú pháp một số kết quả đầu ra / lỗi sẽ được cung cấp cho các bước tiếp theo, định dạng email cảnh báo của riêng bạn, v.v. có rất nhiều khả năng.

Nói chung, tôi sẽ nói rằng buildbot là công cụ xây dựng tự động "có mục đích chung" nhất. Tuy nhiên, Jenkins có thể là tốt nhất liên quan đến việc chạy thử nghiệm, đặc biệt là để phân tích cú pháp và trình bày kết quả theo những cách tốt đẹp (kết quả, chi tiết, biểu đồ .. cách một vài cú nhấp chuột), những thứ mà buildbot không làm được. Tôi thực sự đang nghĩ đến việc sử dụng cả hai để có các trang kết quả kiểm tra quyến rũ hơn .. :-)

Cũng như một nguyên tắc chung, không khó để tạo cấu hình của một công cụ mới: nếu đặc điểm kỹ thuật của công việc cần làm (cấu hình, xây dựng, kiểm tra) quá khó để chuyển từ công cụ này sang công cụ khác, thì đó là một dấu hiệu (xấu) không đủ các tập lệnh cấu hình được chuyển đến các nguồn. Buildbot (hoặc Jenkins) chỉ nên gọi các lệnh đơn giản. Nếu nó đơn giản để chạy các bài kiểm tra, thì các nhà phát triển cũng sẽ làm điều đó và điều này sẽ cải thiện tỷ lệ thành công, trong khi nếu chỉ có hệ thống tích hợp liên tục chạy các bài kiểm tra, bạn sẽ chạy theo nó để sửa các lỗi mã mới và sẽ mất giá trị không hồi quy của nó, chỉ 0,02 € của tôi :-)

Hy vọng nó sẽ hữu ích.

'Tích hợp kết quả' cũng có trong jenkins / hudson và bạn có thể tương đối dễ dàng nắm bắt các sản phẩm xây dựng mà không cần phải 'sao chép chúng ở nơi khác'.

Đối với ví dụ của chúng tôi, tất cả các báo cáo phạm vi và số liệu kiểm tra đơn vị và javadoc cho mã java đều được tích hợp. Đối với mã C ++ của chúng tôi, các plugin còn thiếu một chút, nhưng bạn vẫn có thể sử dụng hầu hết.

chúng tôi đã chạy buildbot kể từ trước 0.7 và hiện đang chạy 0.8 và hiện chỉ thấy bất kỳ lý do thực sự nào để chuyển đổi, vì buildbot 0.8 quên mất các cửa sổ nô lệ trong một khoảng thời gian dài và hỗ trợ khá kém.

Có nhiều giải pháp khác ngoài Jenkins / Hudson / BuildBot:

• TeamCity của Jetbrains
• Bamboo của Atlassian
• Đi theo Thoughtworks
• Kiểm soát hành trình
• OpenMake Meister

Trên thực tế, chi tiết cụ thể về những gì bạn đang làm không quá quan trọng, miễn là các tác nhân (hay còn gọi là các nút) mà bạn đang thực hiện hỗ trợ những nhiệm vụ đó.

Vẻ đẹp của máy chủ CI là nhận thấy khi bản dựng thay đổi để kích hoạt bản dựng mới (và thử nghiệm), xuất bản các tạo tác và công bố kết quả thử nghiệm.

Khi bạn so sánh các công cụ CI như những công cụ chúng tôi đã đề cập, hãy xem xét các tính năng như khả năng sử dụng của giao diện, mức độ dễ dàng phân nhánh (và các tính năng mà nó có thể cung cấp như hợp nhất tự động), thông báo (như XMPP / jabber) hoặc bộ tản nhiệt thông tin (như nối lên màn hình để luôn hiển thị trạng thái). Hỗ trợ sản phẩm là một điều khác cần xem xét - hỗ trợ của Jenkins chỉ tốt khi người đang trả lời các câu hỏi của cộng đồng tại thời điểm bạn có câu hỏi.

Yêu thích cá nhân của tôi là Bamboo, nhưng nó đi kèm với phí bản quyền.

Tôi là người dùng Jenkins lâu năm đang trong quá trình đánh giá Buildbot và muốn cung cấp một số mặt hàng cho những người đang cân nhắc sử dụng Buildbot cho các giải pháp đa mô-đun:

*) Buildbot không có bất kỳ khái niệm ngoại lệ nào về tệp artifactsliên quan đến mỗi bản dựng. Nó không có trong giao diện người dùng và nó không nằm trong bất kỳ mô-đun "bước" nào trong nội dung theo như tôi có thể thấy:

http://docs.buildbot.net/current/manual/configuration/buildsteps.html

... và tôi không thấy plugin của bên thứ ba nào:

https://github.com/buildbot/buildbot/wiki/PluginList#steps

Buildbot thu thập tất cả đầu ra của bảng điều khiển từ một bản dựng nhất định, nhưng quan trọng là bạn không thể thu thập các tệp liên quan đến nó.

*) Do hiện vật không được hỗ trợ, thật không dễ dàng để tạo các dự án "bộ sưu tập" đưa nhiều mô-đun vào, một trình cài đặt duy nhất. Jenkins có một tính năng tuyệt vời cho phép bạn tham số hóa một bản dựng với các bản dựng từ các mô-đun khác (kiểu tham số là a run).

*) Thiết lập sự phụ thuộc giữa các mô-đun phức tạp hơn trong Buildbot. Giả sử bạn có một thư viện mà ba tệp nhị phân phụ thuộc vào và bạn muốn các tệp nhị phân đó xây dựng lại mỗi khi thư viện thay đổi. Jenkins đã tích triggershợp vào giao diện người dùng. Nếu bạn muốn thực hiện kích hoạt trong Buildbot, bạn phải viết kịch bản cho chúng bằng cách sử dụng schedulers.Dependentvà nó gây ra rất nhiều tắc nghẽn mục trong Schedulersgiao diện người dùng.

*) Khi bạn đang làm việc trong Buildbot, có vẻ như hầu hết tất cả cấu hình đều được thực hiện master.cfgtrong mã. Điều này thật tuyệt vời và khó chịu.

*) Buildbot buộc bạn phải tạo workerthêm một mastermáy chủ. Điều này gây khó chịu cho người mới bắt đầu và các hệ thống mà chỉ cần một máy chủ xây dựng là đủ.

Ấn tượng của tôi sau hai ngày đánh giá Buildbot là chúng tôi sẽ gắn bó với Jenkins, chủ yếu là do nó có artifacts. Buildbot là một công cụ chúng tôi chỉ sử dụng nếu chúng tôi có nhu cầu tùy chỉnh rộng rãi hơn và có thời gian để thực hiện điều đó.

Về chủ đề buildbot và tạo tác - tôi không có đủ điểm của người dùng để đưa ra nhận xét - bạn có thể lấy hiện vật từ dòng buildbot 2.x khá dễ dàng với các hành động tải lên tệp / thư mục được tích hợp sẵn. Tuy nhiên, bạn hiếm khi muốn chỉ di chuyển tệp. Thông thường, bạn thực hiện một bước xây dựng được kích hoạt để triển khai trực tiếp từ nhân viên để có kết quả tốt nhất. ví dụ: đẩy lên lưu trữ đám mây, vùng chứa, bên thứ ba (tải lên steam), v.v.

Bằng cách này, bạn có thể nhận được các chỉ số về video tải lên và có điều kiện kiểm soát chúng tốt hơn (hoặc thậm chí trộn và kết hợp các phần mềm tạo tác giữa các máy công nhân).