咱们目前大概存在的问题:编程
1.发布更新较为频繁windows
2.频发发布。(每周两次的发布)服务器
3.存在比较多的bug-fix(各组状况不同)网络
4.修改的任务一般比较小,开发周期比较短并发
5.各项目或功能有不一样的小组负责maven
6.没有采用分支策略,开发人员本地打包,编译,进行手动的增量更新。出现错误的概率比较高。编程语言
7.各组没有专人负责对上线前的代码版本进行检查,致使代码常常会被覆盖。分布式
根据目前的问题,制定以下的原则和要素:工具
1).原则学习
(1)全部的开发人员须要在本地机器上作本地构建,而后再提交的版本控制库中,从而确保他们的变动不会致使持续集成失败。
(2)开发人员天天至少向版本控制库中提交一次代码。(是否须要,有待探讨)
(3)开发人员天天至少须要从版本控制库中更新一次代码到本地机器。
(4)须要有专门的集成服务器来执行集成构建,天天要执行屡次构建。
(5)每次构建都要100%经过。
2).要素
版本控制,统一的代码库,分支策略
自动构建
自动化的部署
自动化测试
每一个人天天都要向代码库提交代码
每次代码递交后都会在持续集成服务器上触发一次构建
保证快速构建
模拟生产环境的自动测试
每一个人均可以很容易的获取最新可执行的应用程序
每一个人都清楚正在发生的情况
3.实施方案:
1):制定分支策略
代码版本控制采用分支的形式。分支的策略主要有三种:不稳定主干,稳定主干和敏捷发布。
不稳定主干策略
主干做为开发主线,分支用过发布。
Bug修改要在各分支上进行合并。
优势:不须要分支合并,减小工做量,比较简单。
缺点:分支比较多,须要有专人创建分支,随着分支的逐步增多,对分支的管理开销比较大。
稳定主干策略
使用主干做为稳定版的发布。
bug的修改和新功能的增长,所有在分支上进行。
不一样的修改或新功能开发以分支隔离。
分支上的开发和测试完毕之后才合并到主干。
主干上的每一次发布都作一个标签而不是分支。
优势:每次发布的内容调整起来比较容易。
缺点:分支合并所增长的成本,须要有专人来合并分支。
敏捷发布策略
敏捷发布策略比较复杂,对开发人员的要求很高,我的认为按照目前的情况不适合咱们。
根据咱们的实际状况,采用稳定主干的策略。具体实施方案以下:
主干时刻处于稳定状态,随时能够发布。设专门人员对主干代码进行管理,普通开发人员只读。
平常开发分支是不稳定状态,用于平常开发人员开发使用。开发结束并本地测试经过后,提交给测试人员测试。
平常开发分支由专人在每周从主干上打下两个个发布周期的分支。
当平常开发分支经测试稳定后,由专人合并到主干。
当平常开发分支合并到主干并发布后,在服务器删除。
平常开发分支命名规则 : 项目名称_部署日期。如:Infrastructure_20130306
领导,经批准后,由专人创建相应的分支并通知组长和开发人员。各组长发送邮件内容应包括项目名称,需求编号,投产日期。专人根据需求编号和投产日期创建功能分支。
功能分支命名规则为 : 项目名称+需求编号+投产日期。
如 :XXXXXXX_CR0001_20130828
注:功能性分支须要各组长按期从主干合并最新代码,保证和主干的一致性。
如不是紧急须要修复的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