C++或QT項目如何進行CI（Continuous Integration）?

01-03

個人科研用途，基於QT4項目，主要在Windows平台，使用Git做版本控制，項目需要鏈接很多的第三方庫（如QGIS、GDAL等），有單元測試。詳細問題如下列出：（回答不限於QT，但最好是C++）
1.如何選擇CI工具？
2.如何配置第三方庫？
3.非得需要專門的伺服器嗎？
4.能跨平台嗎？

5.個人開源項目有必要用CI嗎？

持續集成

如果真的是個人項目，我認為沒必要搞CI，自己寫完代碼自己build下，如果有testcase，就再跑一遍，發現問題修復後重複上述過程，純手工操作也花不了多少時間。

如果想自動化一點，寫個bat就搞定。

qmake可以用命令行生產 makefile，nmake可以用命令行build，Qt有自己的Qtest測試框架。

如果項目編譯集成的過程有點複雜，那麼用python寫個腳本就能搞定。

CI系統對個人來說反而降低效率，只有對團隊開發才有意義，而且要比較大點的團隊，我覺得起碼10人以上吧，否則指定個人手工做也不費事。

CI系統我推薦 Jenkins 這是我們一直在用的，當然要配專門的伺服器，它提供web的管理操作界面。

我自己最近的一個項目，開始只有4個人開發，我每天自己手工做build，就是用個簡單的bat。

後來10個人的時候，有個兼職的build manager，他寫了個python腳本，svn觸發器，實現了自動編譯集成。

再後來，我們用jenkins，一直用到現在。

CI是工具是手段不是目的，目的是什麼呢？

1. 儘快發現build break，團隊規模很小的時候，出了build break吼一聲就好了，反正就是這幾個人乾的，或者自己幫忙修復，反正代碼規模也小互相都能看懂。團隊規模大了以後，出現build break就麻煩了，首先定位是誰幹的，然後找這個人，這個人又不一定在，可能他commit後下班跑了，別人幫他改的話還要找個能看懂的，沒改之前幾十號人都只能等著，尤其是開發組是分布在多個地區的，這麼一折騰可能要幾個小時，當天的build就出不來了，於是自動測試也要推遲，然後明天的測試組就拿不到新版本，總之一系列的連鎖反應耽誤了很多人的時間。

而CI系統會在build break的時候自動發email給所有人，上面寫明了是哪個revision的問題，是誰提交的，非常有助於快速發現修復問題。而且工程師也容易養成習慣，在提交代碼後，看到一封build成功通知email後再下班走人。

所有的build事故都有記錄，方便我們發現團隊管理的問題。

2. 用基本的測試用例儘快發現問題，CI系統不僅是編譯，還會做代碼規範檢查，靜態代碼掃描，跑自動測試用例，記錄下崩潰異常，內存泄漏 cpu佔用異常等問題，儘快發現問題儘快修復，保證當天能提供一個基本沒問題的build給測試組。

3. 複雜系統需要編譯生成多個發行版，比如跨平台的軟體要有 Windows Linux MacOS版本，還要有32bit 64bit版本，有個還能跨CPU，生成x86 arm版本。眾多的release只能靠CI自動配置完成，手工做是不可能的。

第三方庫的管理

如果是小型的第三方庫，我建議直接拿源碼過來，把它集成到你的工程里一起編譯。

比如我以前用到protobuf的時候，給protobuf寫了個qmake的pro文件，直接當子工程用了。

目前C++項目沒有統一的包管理，各種庫做法千奇百怪，遠不如java的世界。

Ubuntu下起碼還有個apt-get，windows下就麻煩了。

如果比較大型的庫，我建議自己搞一套簡單的包管理。

我的做法是，每個第三方庫自己編譯好，把生成的 .lib .dll .h，打包成一個zip文件，文件名上寫上版本號，把這些zip放到一個中央伺服器上，架個webserver，讓他們可以通過http下載。

然後在工程里放一個配置文件，寫上依賴的第三份庫的名字和版本號，編譯之前用一個python腳本根據配置去伺服器拉取相應的zip，解壓縮到指定目錄。

qmake的pro里寫好對這些庫的依賴 INCLUDEPATH LIBS 等。

反正這些第三方庫不常更新，這樣一個簡單的包管理也夠用了。

謝邀。

PETER HARTMANN的一片博文：http://www.peter.hartmann.tk/#!Minimal-Continuous-Integration-for-Git-projects-with-Jenkins-and-a-Qt-example/cmzt/557e1b840cf298dc5b98f2a5

關於CI，其實是和的團隊人員多少、應用程序目標平台和配置的不同是有很大關係的。

例如，只有一個人開發，只面向一個平台，每次自己寫了一個commit之後，跑一下自動或者手工測試，基本就可以知道結果了。

手工測試肯定不如寫單元測試，寫了很多單元測試之後，一般都會有一個腳本來批處理一下。這其實就是一個CI的原型，CI無非也就是自動獲取代碼，在目標平台上跑一遍或者幾遍，然後報告結果。

簡單介紹一下Qt Project的CI配置：(詳情見 http://qt-project.org/wiki/CI_Overview )

1. 使用Jenkins(http://jenkins-ci.org/)，以前用過Pulse(http://zutubi.com/products/pulse/)，都是Java的，這樣就可以比較簡單的跑在Qt的各個目標平台了。個人或者小團隊也許可以試試Travis(https://travis-ci.org/)之類的

2. 配置第三方庫好像用得是puppet(http://puppetlabs.com/)，另外很多編譯器升級之類的，也許還是需要手工操作的

3. 台式機也可以呀，配置Jenkins伺服器和節點都很簡單的

4. 可以呀，除了各種桌面平台，例如Symbian、CE、iOS和Android什麼的，只要能寫腳本搞定的，都可以跨呀

5. 看需要和精力了，機器跑單元測試總比自己手工測試要牢靠一些，但肯定不能覆蓋百分之百的情況...

看了其他人的回答，好像還有一個問題，通常小團隊操作，可能是先commit然後再跑CI，而Qt Project則不同，它使用Gerrit(https://code.google.com/p/gerrit/)，每個提交的change只有在通過CI之後才會被commit。這樣自己添加的一個feature，通過單元測試保證以後，基本上別人就不能把你這個feature毀掉了...

有關Qt Project的CI，請參考 Coin - Continuous Integration for Qt - Qt Blog 。

最新動態：COIN已經從VSphere切換到OpenNebula了，Coin on OpenNebula。COIN文檔 Welcome to the Coin - Qt Continuous Integration System documentation!

CMake已經發布3.0，支持Qt5，如果用CMake的話就有CTest和CPack了，很自然就可以用CDash做CI。

還有很多其它Java的CI工具，我推薦試試Jenkins/Hudson。

最近公司在用cruisecontrol做CI，以前做的是C#的項目，現在想把QT也做進去，可能嗎？我在網上找了很多方法都不行。

直接使用bitnami的gitlab和gitci安裝包好了。

可以參考：用gitlabCI快速搭建一個GitServer與CI

我覺得蠻不錯的。