- 问题
我们目前大概存在的问题:
1.发布更新较为频繁
2.频发发布。(每周两次的发布)
3.存在比较多的bug-fix(各组情况不一样)
4.修改的任务通常比较小,开发周期比较短
5.各项目或功能有不同的小组负责
6.没有采用分支策略,开发人员本地打包,编译,进行手动的增量更新。出现错误的几率比较高。
7.各组没有专人负责对上线前的代码版本进行检查,导致代码经常会被覆盖。
- 原则和要素
根据目前的问题,制定如下的原则和要素:
1).原则
(1)所有的开发人员需要在本地机器上做本地构建,然后再提交的版本控制库中,从而确保他们的变更不会导致持续集成失败。
(2)开发人员每天至少向版本控制库中提交一次代码。(是否需要,有待探讨)
(3)开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
(4)需要有专门的集成服务器来执行集成构建,每天要执行多次构建。
(5)每次构建都要100%通过。
2).要素
版本控制,统一的代码库,分支策略
自动构建
自动化的部署
自动化测试
每个人每天都要向代码库提交代码
每次代码递交后都会在持续集成服务器上触发一次构建
保证快速构建
模拟生产环境的自动测试
每个人都可以很容易的获取最新可执行的应用程序
每个人都清楚正在发生的状况
3.实施方案:
1):制定分支策略
代码版本控制采用分支的形式。分支的策略主要有三种:不稳定主干,稳定主干和敏捷发布。
不稳定主干策略
主干作为开发主线,分支用过发布。
Bug修改要在各分支上进行合并。
优点:不需要分支合并,减少工作量,比较简单。
缺点:分支比较多,需要有专人建立分支,随着分支的逐步增多,对分支的管理开销比较大。
稳定主干策略
使用主干作为稳定版的发布。
bug的修改和新功能的增加,全部在分支上进行。
不同的修改或新功能开发以分支隔离。
分支上的开发和测试完毕以后才合并到主干。
主干上的每一次发布都做一个标签而不是分支。
优点:每次发布的内容调整起来比较容易。
缺点:分支合并所增加的成本,需要有专人来合并分支。
敏捷发布策略
敏捷发布策略比较复杂,对开发人员的要求很高,个人认为按照目前的状况不适合我们。
根据我们的实际情况,采用稳定主干的策略。具体实施方案如下:
- 发布周期固定,每周三,四为发布日。建立主干和日常开发分支。
主干时刻处于稳定状态,随时可以发布。设专门人员对主干代码进行管理,普通开发人员只读。
日常开发分支是不稳定状态,用于日常开发人员开发使用。开发结束并本地测试通过后,提交给测试人员测试。
日常开发分支由专人在每周从主干上打下两个个发布周期的分支。
当日常开发分支经测试稳定后,由专人合并到主干。
当日常开发分支合并到主干并发布后,在服务器删除。
日常开发分支命名规则 : 项目名称_部署日期。如:Infrastructure_20130306
- 如果有的需求跨越多个部署周期,应建立单独功能分支。由各组长发送邮件给相关
领导,经批准后,由专人建立相应的分支并通知组长和开发人员。各组长发送邮件内容应包括项目名称,需求编号,投产日期。专人根据需求编号和投产日期建立功能分支。
功能分支命名规则为 : 项目名称+需求编号+投产日期。
如 :XXXXXXX_CR0001_20130828
注:功能性分支需要各组长定期从主干合并最新代码,保证和主干的一致性。
- bug修复。对于生产上出现的bug,由组长临时从主干建立bug-fix分支,开发人员bug-fix分支上进行bug修复,修复完成,经测试人员验证通过无误后合并到主干。
如不是紧急需要修复的Bug,可以不建立bug-fix分支。由组长安排相关开发人员在日常分支上进行修复,并提交测试。验证通过后在下一个投产日期投产。
Bug-fix分支命名规则 : 项目名称+’bugfix’+投产日期。
如:XXXXXXX _bugfix_20130828
方案优点
1、解决了没有实施分支策略时,代码不能经常签入的问题。
2、主干代码始终处于稳定的状态随时可以发布,降低了风险。
3、可以基于一个完整的测试分支进行测试及发布,而不是以口口相传的方式增量更新。
4、最大限度了减少分支的数量,并能满足现有的要求。减少组长和开发人员维护分支
的成本。
方案缺点
建立分支、合并分支增加了工作量,需要有专人负责。考虑实际情况,以及版本控制工具的辅助,增加的工作量应该可以接受。各组应该有专人(组长)在开发结束后进行代码review的工作。
2):版本管理工具
1、使用现有的SVN。
优点:学习成本低,开发人员都比较熟悉。对windows支持好,图形化工具多。
有权限管理。可以设置目录级的权限。
缺点:分支不够轻量。基于文件复制的形式打分支。分支的切换,合并比较麻烦。
只能在公司才能提交代码。
2、SVN+Git形式。SVN作为中央仓库。GIT作为本地客户端。
优点:Git的主要优点在于分支是真正意义的分支,各分支
并行,分支的合并,各分支间的切换非常方便,快速。
Git可以随时随地提交代码,不受网络限制。
缺点:Git学习曲线陡峭。需要开发人员对Linux有一定的了解。
对windows支持不如SVN。图形化工具功能不完善,很
多操作需要命令行才可以。
没有目录级的权限控制。
需要对所有开发人员做培训,不能快速的实施下去。
综上所诉,考虑到时间和人员的学习成本以及风险,可以暂时先使用SVN,先保证了版本的稳定和风险的降低。不过考虑到Git的灵活和方便,可以以后逐步的从SVN切换到Git。
3):自动构建和自动化部署
1,构建工具:
构建工具使用Gradle。Gradle是使用Groovy来书写构建脚本的构建系统,类似Maven,比Maven简单,灵活。
优点:
1:使用Groovy语言编写脚本。比XML的可读性更好,更灵活,强大。
2:支持自定义Task,比Maven灵活(Maven需要写Maven插件)。
maven的依赖管理死板,只能依赖于标准的maven artifact,不能依赖本地的某个jar文件或者其它的源码。而gradle则可以混合地同时支 持这些依赖方法,这样可以让旧项目的迁移容易。
缺点: 需要从头学习。
2, 持续集成引擎:
Jenkins(前身是Hudson)。目前使用最广的持续集成工具。暂时没有第二选择。
厂商 | Java.net |
支持的编程语言 | Java |
是否开源 | 是 |
价格 | 免费 |
主流 SCM 支持程度 | Clear Case , VSS, CVS, Subversion , PVCS 等, SCM 支持最为完善 |
构建管理 | 并行构建,分布式构建,增量构建,人工强制构建, SCM 触发构建等都有支持 |
消息通知机制 | Email , Run executable , FTP , IRC , Jabber , Lotus Sametime , RSS,SCP,Windows System Tray,Formatted Logging
|
构建工具支持 | Shell 脚本与命令行, Ant, Groovy, OpenMake Meister, Maven, Maven2 , MSbuild , NAnt , Rake (Ruby) |
项目管理工具集成 | 无 |
测试工具集成 | CppUnit result rendering , JUnit result rendering , NUnit result rendering , Selenium result rendering , PHPUnit result rendering , MSTest result rendering , SilkCentral , Clover result rendering , PMD result rendering |
安装与配置 | 有 windows 安装程序, Self contained distribution (except SCM clients) , N 无需修改构建脚本,支持多个项目,自动配置构建脚本 |
IDE 集成 | Eclipse Plug-in , IntelliJ Plugin |
4):自动化测试
自动化测试方案还未考虑。。。
4.实施计划:
版本管理工具 :SVN
持续集成工具 :Jenkins
构建工具 :首选Gradle, 备选 MAVEN,ANT