“If Agile Was the Opening Act, Continuous Delivery is the Headliner!”——Kurt Bittner

　　正如Kurt Bittner说的那样，如果敏捷仅仅是个开始的话，那持续交付则是头条!(我则更喜欢理解成高潮)。

　　现代企业要求软件开发过程保持最大的工作效率，传统的瀑布式开发早已跌入历史洪流，甚至敏捷宣言也已超过10年的历史，软件开发在经历了敏捷开发、持续集成后，正逐步迈入到持续交付的时代。

　　持续交付是持续集成的延伸，强调以自动化、可视化的手段更快的将产品交付到客户手中。持续交付的一个重要衡量指标就是从代码提交直到客户能使用这个功能所花费的时间，通过实行持续交付，这个时间往往可以从原先的几天、几周缩短到几分钟。当然，快速交付并不意味着不可靠。

　　那么我们如何实施自己的持续交付?以我们实际项目为例，与大家进行一个探讨，归纳起来，总共经历了以下3个过程：

　　搭建持续集成环境

　　以jenkins为核心搭建持续集成平台，每天定时从代码库中检出最新的代码进行编译、构建。构建结果通知到项目组，开发人员只需要关注每天的集成结果是否是绿的就可以了，同时加入测试环境部署及自动化测试。

　　图1. 自动部署测试环境

　　图2. Selenium自动测试

　　代码规范及单元测试

　　简洁统一风格的代码有利于大家更好的理解及进行走查，而单元测试则是为了前期高质量的交付。

　　图3. 单元测试统计

　　通过Sonarqube+jacoco的引入，可方便的定位到存在问题的代码行及单元测试情况。

　　图4. 问题定位

　　自动化测试流水线

　　持续交付讲究Automate almost everything将一切过程自动化起来，减少人工的干预。这里我们主要加入了以下环节：

　　自动化的接口及集成测试：

　　测试进入的越早，发现问题修复的成本越低，通过引入TestNG等测试框架，对接口以及模块集成进行测试，有效的降低Bug流入后续环节的风险。

　　测试分级：

　　将测试用例拆分成SmokingTest、AllTest等多套用例集，一方面快速反馈代码更新可能引起的风险，同时保证测试的有效覆盖，同时通过分布式集群并发执行等方式，加速执行效率，最终形成以下的流水线。

　　图5. 管道流水线

　　自动化交付及全平台工具整合

　　在传统模式下开发、测试、运维往往比较独立，测试完成后由运维人员进行部署上线，但是由于运维人员能力水平存在高低，复杂环境下的发布往往只有固定的几人才能搞得定，从而导致上线发布周期被拉长。我们通过自建交付自动化工具，同时整合平台让运维对外提供服务，消除开发、测试与运维之间的边界，大大降低了自动化运维的门槛，让运维效率有了很大的提升。

　　图6. 交付自动化

　　通过作业流程的编排，沉淀标准化作业封装，让普通运维人员快速实现相应的自动化脚本，同时通过整合资源/环境，对开发测试提供资源申请、部署等服务，加速自动化发布的验证，避免在正式发布时导致问题。

　　持续的反馈

　　上线发布完成并不意味着交付结束，当今社会是一个以服务取胜的社会，我们交付给用户的不再是简单的产品，更多的应该是服务。通过自动化的监控获取用户的反馈快速做出响应，不断提升我们的服务，才能提高用户的满意度和粘性。

　　————————————————————总结————————————————————

　　持续交付是一套方法论，通用的并不一定适合自己。希望仅以本文做一个引子，让大家寻找到适合自身的持续交付之路!附上一张交付过程中的工具集供大家参考。