作者：齊亮
鏈接：http://www.zhihu.com/question/24314354/answer/27547787
來源：知乎
著作權歸作者所有，轉載請聯系作者獲得授權。
鏈接：http://www.zhihu.com/question/24314354/answer/27547787
來源：知乎
著作權歸作者所有，轉載請聯系作者獲得授權。
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毀掉了...
關於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毀掉了...