持续集成作为一种很好的软件工程实践被很多团队所采用，和其他一些先进的实践一样，它终的目的一定是服务于产品的。产品的价值终体现在用户体验的提升，而这个的前提是产品的每一次更新能够及时地传递给用户，对于运维团队来说是更快地在生产环境中部署新的产品，对于研发团队来说是更频繁地发布可以工作的软件。
　　暂且抛开业界非常流行的DevOps理念，单纯地从研发团队来看，如何快速的发布对用户有价值的软件是重中之重。
　　那结合持续集成，我们又可以做些什么呢？
　　先来看看我们持续集成的现状
　　独立的环境：持续集成往往有一套独立的测试环境，而团队还会在其他测试环境中进行测试，两者似乎从来没有交集
　　独立的构建：持续集成往往是对当前新的代码做一些自动化的测试，而完全忽略了软件版本的管理，甚至不能很好的保证各种测试是否是基于同一份代码
　　辅助手段：持续集成往往作为一种测试的辅助手段，更多的是用于快速发现代码提交阶段的错误
　　以上这些在持续集成初期完全没有问题，而且这种方式也的确带来了不少的价值，能够帮助团队更透明地了解产品的质量，并且快速的定位和解决问题。只是，我们可以做的更多
　　再来展望下持续发布的流程
　　整体的思路是以持续集成流水线作为核心，把软件发布的各个环节透明地展示给团队，并且通过流水线来管理版本的发布流程

　　测试环境整合：打通持续集成环境/手工测试环境/线上模拟环境，保证一条流水线上使用同一份代码，同一份构建物
　　测试流程整合：一键式的环境部署和一键式的版本管理（打TAG，拉分支，构建物的存储等），发布前对产品质量有清晰的了解
　　重要和主要手段：以持续发布流水线为基准，并积极拓展其他类型的测试
　　把持续集成融入到产品开发和发布阶段，而不是简单地搭建一套“自动化运行任务”，并充分利用构建流水线实现流程和质量的双重把控
　　后来看下某个产品初步定义的持续发布的流程
　　产品现状
　　三套环境：持续集成环境（云主机），手工测试环境（云主机），线上模拟环境（物理机）
　　持续集成状态
　　自动化的编译，打包，部署，冒烟测试和快速性能测试已经实现自动化并实时通过代码提交触发，全程20分钟左右
　　单元测试和静态代码检查还在完善中，也实时通过代码提交触发，不过没有列入关键点，也是成功与失败并不直接影响构建流程
　　每日的功能测试（1000+个测试用例）在晚间运行，全程3个小时左右
　　新功能测试在手工测试环境下进行
　　上线前需要在线上模拟环境进行性能测试和稳定性测试