buildbot VS持續集成的大型大多是C++項目哈德森/ C++的持續集成

Question

詹金斯我目前使用詹金斯/哈德森。我們爲主幹和每個分支分別開發項目。此外，還有一些與Java代碼相關的項目，但現在對於這些項目的設置相當基本（儘管我們可能會做更多的事情）。在C++項目執行以下操作：

• 構建與是否要重新配置，做一個乾淨的構建，或使用新的結賬
• 可選構建選項的一切，運行所有測試
• 可選擇使用運行所有測試Valgrind的的MEMCHECK
• 奔跑cppcheck
• 生成Doxygen文檔
• 時間表發佈報告：單元測試，Valgrind的，cppcheck，編譯器警告，SLOC，在打開的任務和代碼覆蓋（使用gcov的，GCO VR，和的Cobertura插件）
• 部署代碼夜間或按需到測試環境和一個包庫

一切可配置爲自動構建和可選點播構建。在下面，有一個bash腳本來控制這個，這更多的取決於我們的構建系統，它使用automake和autoconf以及自定義的bash腳本。

我們開始使用哈德森（當時），因爲這是Java的傢伙們使用的是什麼，我們只是想每晚構建。從那以後，我們增加了更多，並繼續增加更多。在某些方面哈德森是偉大的，但肯定不是理想的。

我看其他的解決方案和看起來像它可能是一個更換buildbot唯一的一個。這種情況會更好嗎？自從我們已經使用Hudson以來，投資是否值得？爲什麼？

編輯：有人問我爲什麼沒有發現哈德森/詹金斯是理想的。簡而言之，一切都可以改善。我只是想知道，如果詹金斯是我用例的最佳解決方案，或者是否有更好的東西（buildbot？），那麼即使出現新的需求，從長遠來看也會更容易維護。

Answer 1

兩者都是開源項目，但你並不需要改變buildbot代碼爲「擴展」，它實際上是很容易導入自己的包在其配置中，你可以子類的大部分功能與你自己的補充。例如：你自己編譯或測試代碼，輸出/錯誤的一些分析必須考慮到下一步，自己的警報電子郵件等格式化有很多的可能性。

一般來說，我會說，buildbot是最「通用」自動構建工具。然而Jenkins可能與運行測試最爲相關，特別是以很好的方式解析和呈現結果（結果，細節，圖表......一些點擊消失），這些buildbot不會「開箱即用」。我實際上正在考慮使用兩者來使性能更好的測試結果頁.. :-)

另外作爲一個經驗法則，創建一個新的工具的配置應該不難：如果指定要做什麼（配置，構建，測試）很難從一個工具切換到另一個工具，這是一個（壞）信號，沒有足夠的配置腳本移動到源。 Buildbot（或Jenkins）只應該調用簡單的命令。如果運行測試很簡單，那麼開發人員也會這樣做，這會提高成功率，而如果只有持續集成系統運行測試，那麼您將在運行之後運行它來修復新的代碼故障，並且會丟失它的非迴歸價值，只是我的0.02€:-)

希望它會有所幫助。

Answer 2

'結果整合'也在jenkins/hudson中，您可以相對容易地捕獲構建產品而無需'複製他處'。

對於我們的例子，java代碼的覆蓋率報告和單元測試指標以及javadoc都是集成的。對於我們的C++代碼，插件有點缺乏，但您仍然可以獲得大部分插件。

我們在0.7之前就運行了buildbot，現在運行了0.8，現在只能看到切換的真正原因，因爲buildbot 0.8在很長一段時間內忘記了Windows從站，並且支持很差。

Answer 3

還有許多其他的解決方案在那裏，除了詹金斯/哈德森/ BuildBot：

• 的TeamCity通過Jetbrains的
• 由Atlassian的
竹
• 轉到由ThoughtWorks的
• 巡航控制
• OpenMake梅斯特

有關細節事實上，只要您正在執行的代理（又名節點）支持這些任務，您所做的事情並不那麼重要。

當構建更改爲觸發新構建（和測試），發佈構件和發佈測試結果時，CI服務器的美妙之處在於注意到這一點。當你比較我們提到的CI工具時，考慮諸如它的接口的可用性，分支有多容易（和自動合併可能提供的功能），通知（如XMPP/jabber）或基於信息的通知散熱器（如連接顯示器始終顯示狀態）。產品支持是另一個需要考慮的事情 - 詹金斯的支持只有在您有問題時誰回答社區問題。

我個人最喜歡的是Bamboo，但它收取了許可費。