- 问题
我们目前大概存在的问题：
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
