介绍服务器
持续集成是一种软件开发实践。开发人员频繁地集成各自的工做,通常至少一天一次。eclipse
每次的集成都被自动构建,测试,发现其中的问题。这样,能够迅速的解决开发过程当中的不少问题,而不是等到软件开发完成以后。而软件的质量,能够在很大程度上由一次次的自动化测试获得保障。maven
下面介绍如下本人团队中目前的持续集成实现。svn
持续集成,首要的就是选择持续集成服务器。测试
目前比较成熟的持续集成服务器不少,例如CruiseControl,Continuum,Luntbuild… ui
我这边采用的是Jenkins(An extendable open source continuous integration server)spa
除了CI Server 外,咱们还用到了svn,maven,ant,jira,fisheye。插件
下面详细介绍一下咱们项目的实施状况。code
大体状况:server
源码管理方式
主干
分支1
测试分支
开发分支
分支2
测试分支
开发分支
项目有个主干。新需求开分支进行开发。允许并行需求开发。(多分枝状况)
开发分支须要创建持续集成任务,按天集成;
测试分支在完成总体开发,或者大里程碑开发后集成测试。
分支测试完成后,须要同步回主干。同步回主干前又须要先同步主干的更新
项目状况:1)须要出基础包+增量包。且增量包的文件须要核对。
2)须要出先后台包,先后台包文件有所不一样
3) 须要处理升级脚本
故决定采用ant 来控制打包流程,调用maven执行项目的编译,测试工做。
开发
Jira 与 eclipse 集成。每次开发任务都关联Jira任务(bug/改进/…)。
开发人员发起code review 请求。 Review人员每次均可以在jira上找到任务对应的文件内容修改。
自动化测试
Jenkins天天跑构造任务,自动测试,生成测试报告。分发问题给各开发人员。(email/jira)
开发分支天天打包编译/发布/自动化测试,checkstyle
测试分支阶段性打包
部署环境/配置文件
部署环境涉及 SIT,UAT,生成. 软硬件部署形式都有点不一样。Ant部署脚本+项目配置文件
具体流程:
1. 任务创建阶段
2. 开发阶段
2.1 开发环境:
采用Eclipse集成Jira 插件的形式,把开发与Jira任务更紧密结合起来。
(Mylyn + atlassianConnector 本文不作具体介绍)
当开发人员开始某个任务时,首先激活该任务。以后所作的全部修改,都会自动关联到该任务。
当开发完成时,提交代码,在Svn message 中加入Jira 任务ID(其实插件会自动加入该信息,开发人员不删除便可).
这样,当在Jira 上查看问题时,就能够查看到svn log(Jira须要安装svn plugin)。
任务及对应的代码自动关联。若有须要, reviewer 能够很方便的查看代码。
2.2 持续集成:
2.2.1 配置自动集成全部资源 (Jenkins 源码管理)
每次新的任务下来都会创建对应的开发分支。
1.2.2 按照国际惯例,开发最少1天集成1次。设定天天6点自动打包
1.2.3 执行具体的构建工做
构建工做很简单。
因为项目文件目录遵循了maven规范,跑check style,unit test 等只须要执行 maven site 任务就好了。
Maven 测试结束后,跑了个后续的部署脚本,把测试报告文件发布到内部的应用服务器。
其实一开始还有计划是把测试报告的内容按咱们自定的负责人规则自动发布的jira上,但后来却不了了之。
感受这个想法,,,仍是不错的。
其实Jenkins的配置仍是很简单,清晰的。
大多数任务都仅需配置个一下资源,Jenkins要跑的任务(例如maven脚本,或者ant脚本…),任务之间的先后关系。
3. 测试(SIT,UAT,…)
测试环节因部署环境的不一样,涉及到增量包,升级脚本及配置文件修改。
这些都主要是在ant脚本中完成。所以实现效果就是先执行maven编译,以后ant在maven编译结果的基础上,处理各类具体需求。在遇到这种特别需求时,ant仍是很给力的。不过ant脚本写复杂以后,因为整个脚本是流程化的,测试起来仍是很麻烦的。所以ant脚本的传参,变量定义,调用方式都是值得慢慢斟酌的。
抛开ant脚本,总体Jenkins任务倒是依旧简单,清晰。
4. 交付