作者：齐亮
链接：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毁掉了...