持续集成方案

1. 问题

  我们目前大概存在的问题：

1.发布更新较为频繁

2.频发发布。（每周两次的发布）

3.存在比较多的bug-fix（各组情况不一样）

4.修改的任务通常比较小，开发周期比较短

5.各项目或功能有不同的小组负责

6.没有采用分支策略，开发人员本地打包，编译，进行手动的增量更新。出现错误的几率比较高。

7.各组没有专人负责对上线前的代码版本进行检查，导致代码经常会被覆盖。

 

1. 原则和要素

根据目前的问题，制定如下的原则和要素：

 1）.原则

(1)所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。

(2)开发人员每天至少向版本控制库中提交一次代码。（是否需要，有待探讨）

(3)开发人员每天至少需要从版本控制库中更新一次代码到本地机器。

(4)需要有专门的集成服务器来执行集成构建,每天要执行多次构建。

(5)每次构建都要100%通过。

2）.要素

版本控制，统一的代码库，分支策略

自动构建

自动化的部署

自动化测试

每个人每天都要向代码库提交代码

每次代码递交后都会在持续集成服务器上触发一次构建

保证快速构建

模拟生产环境的自动测试

每个人都可以很容易的获取最新可执行的应用程序

每个人都清楚正在发生的状况

 

3．实施方案：

1）：制定分支策略

代码版本控制采用分支的形式。分支的策略主要有三种：不稳定主干，稳定主干和敏捷发布。

 

不稳定主干策略

 

  

 

主干作为开发主线，分支用过发布。

Bug修改要在各分支上进行合并。

 

优点：不需要分支合并，减少工作量，比较简单。

缺点：分支比较多，需要有专人建立分支，随着分支的逐步增多，对分支的管理开销比较大。

 

稳定主干策略

 

使用主干作为稳定版的发布。

bug的修改和新功能的增加，全部在分支上进行。

不同的修改或新功能开发以分支隔离。

分支上的开发和测试完毕以后才合并到主干。

主干上的每一次发布都做一个标签而不是分支。

优点：每次发布的内容调整起来比较容易。

缺点：分支合并所增加的成本，需要有专人来合并分支。

 

敏捷发布策略

敏捷发布策略比较复杂，对开发人员的要求很高，个人认为按照目前的状况不适合我们。

根据我们的实际情况，采用稳定主干的策略。具体实施方案如下：

1. 发布周期固定，每周三，四为发布日。建立主干和日常开发分支。

主干时刻处于稳定状态，随时可以发布。设专门人员对主干代码进行管理，普通开发人员只读。

日常开发分支是不稳定状态，用于日常开发人员开发使用。开发结束并本地测试通过后，提交给测试人员测试。

日常开发分支由专人在每周从主干上打下两个个发布周期的分支。

 

当日常开发分支经测试稳定后，由专人合并到主干。

当日常开发分支合并到主干并发布后，在服务器删除。

日常开发分支命名规则 ： 项目名称_部署日期。如：Infrastructure_20130306

1. 如果有的需求跨越多个部署周期，应建立单独功能分支。由各组长发送邮件给相关

领导，经批准后，由专人建立相应的分支并通知组长和开发人员。各组长发送邮件内容应包括项目名称，需求编号，投产日期。专人根据需求编号和投产日期建立功能分支。

功能分支命名规则为 ： 项目名称+需求编号+投产日期。

如 ：XXXXXXX_CR0001_20130828

注：功能性分支需要各组长定期从主干合并最新代码，保证和主干的一致性。

1. 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插件）。

        3：依赖管理灵活。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