咱们正在路上—从持续集成到持续发布
持续集成做为一种很好的软件工程实践被不少团队所采用，和其余一些先进的实践同样，它最终的目的必定是服务于产品的。产品的价值最终体如今用户体验的提高，而这个的前提就是产品的每一次更新可以及时地传递给用户，对于运维团队来讲就是更快地在生产环境中部署最新的产品，对于研发团队来讲就是更频繁地发布能够
工做的软件。
暂且抛开业界很是流行的DevOps理念，单纯地从研发团队来看，如何快速的发布对用户有价值的软件是重中之重。
那结合持续集成，咱们又能够作些什么呢？
先来看看咱们持续集成的现状
独立的环境：持续集成每每有一套独立的
测试环境，而团队还会在其余测试环境中进行测试，二者彷佛历来没有交集
独立的构建：持续集成每每就是对当前最新的代码作一些自动化的测试，而彻底忽略了软件版本的管理，甚至不能很好的保证各类测试是不是基于同一份代码
辅助手段：持续集成每每做为一种测试的辅助手段，更多的是用于快速发现代码提交阶段的错误
以上这些在持续集成初期彻底没有问题，并且这种方式也的确带来了很多的价值，可以帮助团队更透明地了解产品的质量，而且快速的定位和解决问题。只是，咱们能够作的更多
再来展望下持续发布的流程
总体的思路就是以持续集成流水线做为核心，把软件发布的各个环节透明地展现给团队，而且经过流水线来管理版本的发布流程
测试环境整合：打通持续集成环境/手工测试环境/线上模拟环境，保证一条流水线上使用同一份代码，同一份构建物
测试流程整合：一键式的环境部署和一键式的版本管理（打TAG，拉分支，构建物的存储等），发布前对产品质量有清晰的了解
重要和主要手段：以持续发布流水线为基准，并积极拓展其余类型的测试
把持续集成融入到产品开发和发布阶段，而不是简单地搭建一套“自动化运行任务”，并充分利用构建流水线实现流程和质量的双重把控
最后来看下某个产品初步定义的持续发布的流程
产品现状
三套环境：持续集成环境（云主机），
手工测试环境（云主机），线上模拟环境（物理机）
持续集成状态
自动化的编译，打包，部署，冒烟测试和快速
性能测试已经实现自动化并实时经过代码提交触发，全程20分钟左右
单元测试和静态代码检查还在完善中，也实时经过代码提交触发，不过没有列入关键点，也就是成功与失败并不直接影响构建流程
新功能测试在手工测试环境下进行
上线前须要在线上模拟环境进行性能测试和稳定性测试
持续发布流水线
持续集成环境实时保证当前的提交没有破坏基本功能
经过手工触发（QA人员控制），一键部署产品到手工测试环境并能在流水线上展现手工测试结果（经过简单的设置一个变量达到效果）；同时能够选择触发功能测试，达到同步的执行
若是QA人员认为当前测试版本能够达到内部发布要求，能够一键打TAG，并生成和存储dist包
经过手工触发（QA人员控制），一键部署dist包到模拟线上环境，然后自动化进行性能测试和稳定性测试
理想状态这步应该是自动触发，因为目前机器的不可独占性，暂时只能手工触发
自动化的性能测试和稳定性测试仍是实施中
最终版本的对外发布也是经过手工触发（QA人员控制）
以上的流程是根据项目/产品的需求和现状制定的，只是一些思路能够借鉴，具体的实施必定要结合实际状况，因地制宜的开展
Jenkins持续发布流水线
几个Jenkins持续发布流水线配置小Tips
经过BuildNameSetterPlugin显示当次流水线构建的版本（SVN revision或是Git revision）
经过ParameterizedTriggerPlugin自动触发下游任务，并把构建版本信息传递下去
经过CopyArtifactPlugin用于构建物的部署
经过BuildPipelinePlugin手工触发某些任务，用于须要人工介入的阶段