持续集成方案

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

方案优势

一、解决了没有实施分支策略时，代码不能常常签入的问题。

二、主干代码始终处于稳定的状态随时能够发布，下降了风险。

三、能够基于一个完整的测试分支进行测试及发布，而不是以口口相传的方式增量更新。

四、最大限度了减小分支的数量，并能知足现有的要求。减小组长和开发人员维护分支

的成本。

方案缺点

创建分支、合并分支增长了工做量，须要有专人负责。考虑实际状况，以及版本控制工具的辅助，增长的工做量应该能够接受。各组应该有专人（组长）在开发结束后进行代码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