Qt Project的持续集成方案

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

Tony Ho ,嵌入式(Linux/Android) 物联网(BLE)

直接使用bitnami的gitlab和gitci安装包好了。
可以参考:用gitlabCI快速搭建一个GitServer与CI
我觉得蛮不错的。

CMake已经发布3.0,支持Qt5,如果用CMake的话就有CTest和CPack了,很自然就可以用CDash做CI。
还有很多其它Java的CI工具,我推荐试试Jenkins/Hudson。

时间: 2024-10-07 05:12:46

Qt Project的持续集成方案的相关文章

功能自动化接入持续集成方案

功能自动化接入持续集成方案 功能自动化一般用于项目集中测试.回归测试.dailybuild等,我们不可能通过IDE手动来运行case,一般可借助于jenkins或平台化的方式来批量执行case.下面介绍如何将功能自动化接入jenkins. 接入jenkins主要用到了其定时和轮询的功能,我们只要准备好构建jar(build.sh)和执行case(execCase.sh)的脚本,放入jenkins的Excute shell模块,然后配置定时或轮询的时间即可.build.sh和execCase.sh

小程序的持续集成方案

半年前,有机会开始接触微信小程序开发.却因为只是接触而并没投入开发小程序的过程中,因此对很多小程序的细节并未有充分的理解,仅仅停留在了解类似的理论层面,比如mpvue修改了 Vue.js 的 runtime 和 compiler 实现了编译及运行在原生小程序能力,比如原生小程序不支持npm包的使用及管理等,当然那时候的技术细节难点都是由非常给力的好同事解决消化了,所以也没多去细究. 最近,我开始投入到完成的小程序开发迭代里,却发现一个头痛的问题,如何准确并快速的的把小程序上传去后台,并让测试人员

持续集成方案

大纲 构建 版本控制 部署 单元测试 架构文档化 命名约定 数据库伸缩性 自动化 反馈 实践 引言: 持续集成的前身: 在使用持续集成之前,很多开发团队都是用每日构建(nightly build).当时,微软使用这个实践很多年了.谁破坏了构建,就要负责监视后续的构建构成,直至发现下一个破坏了构建的人. 为什么要使用持续集成? 对于大多数项目来说,采纳持续集成实践是向高效率和高质量迈进的一大步.它保证那些创建大型复杂系统的团队具有高度的自信心和控制力.一旦代码提交引入了问题,持续集成就能为我们提供

手机APP自动化持续集成方案

自动化测试流程 自动化测试框架 版权声明:本文为博主原创文章,未经博主允许不得转载.

[分享] 自动化测试与持续集成方案-- UI 检查

对于自动化测试中,UI 自动化测试估计是最有争议的,让人又爱又恨. UI 自动化做回归测试,可以省下很多人力.如果版本一直不稳定,投入跟产出不成比例的. 时机 一般是要版本稳定,界面改动不大.如果迭代版本一个接一个,界面改动大,这样就无法大规模投入 UI 自动化.因为你的维护成本大.也许你脚本还没改好,下一个版本又来了. 有些测试会说,还没有我手动快,没我手动发现的 bug 多.做 UI 自动化就是图个放心,测试的时候只测增量,原有的功能,用 UI 自动化去检测,看是否有改动,原有功能是否是好的

Jenkins Gitlab持续集成打包平台搭建

相关概念 Jenkins Jenkins,一个用Java编写的开源的持续集成工具,提供了软件开发的持续集成服务,可监控并触发持续重复的工作,具有开源,支持多平台和插件扩展,安装简单,界面化管理等特点.更多介绍参考[维基](https://en.wikipedia.org/wiki/Jenkins_(software)介绍. Gitlab GitLab是一个利用Ruby on Rails开发的开源应用程序,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目,更多介绍参考维基

【iOS】Jenkins Gitlab持续集成打包平台搭建

Jenkins Gitlab持续集成打包平台搭建 SkySeraph July. 18th 2016 Email:[email protected] 更多精彩请直接访问SkySeraph个人站点:www.skyseraph.com 1. 相关概念 Jenkins Jenkins,一个用Java编写的开源的持续集成工具,提供了软件开发的持续集成服务,可监控并触发持续重复的工作,具有开源,支持多平台和插件扩展,安装简单,界面化管理等特点.更多介绍参考维基介绍. Gitlab GitLab是一个利用R

持续集成之“分支策略”(续)

在前文中,咱们谈到生命周期长短不同的两种分支策略.对于不超过二十人的小团队来说,推荐使用短生命周期的分支策略.Joe的团队在首次发布之前,也一直使用这种方式.然而,首次发布之后,因市场反响非常好,公司决定加大开发投入,希望更快地推出升级平台,以及更多基于平台的游戏. 一.按特性分支的持续集成策略 现在,Joe的团队中,开发人员快速增加,已接近30人了.由于首次发布后的市场压力,大家一直在赶进度,持续集成的失败频率越来越高,修复构建的时间也越来越长,排队等待提交的代码也越积越多."这种状况不能再持

2、Jenkins持续集成之前期准备

2.Jenkins持续集成之前期准备.md 持续集成 互联网软件的开发和发布,已经形成了一套标准流程,最重要的组成部分就是持续集成(Continuous integration,简称CI). 持续集成指的是,频繁地(一天多次)将代码集成到主干,它的好处主要有两个. (1)快速发现错误.每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易.     (2)防止分支大幅偏离主干.如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成 持续集成的目的,就是让产品可以快