DevOps，不是一个传说！

摘要: 如何有效提升 开发 、 运维 、 质量保证 之间的工作效率，降低沟通成本，DevOps 是不错的方案之一。

"DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。"这恰好体现了精益管理中的客户价值原则，即：以客户的观点来确定企业从设计到生产交付的全部过程，实现客户需求的最大满足。我们也可以把DevOps看作是一种能力，在缺乏这种能力的组织中，开发与运维之间存在着信息"鸿沟"。

　　如何获得这种能力呢？关键有两点：一是全局观：要从软件交付的全局出发，加强各角色之前的合作；二是自动化：人机交互就意味着手工操作，应选择那些支持脚本化、无需人机交互界面的强大管理工具，比如各种受版本控制的script，以及类似于Nagios这样的基础设施监控工具，类似于Puppet、Chef这样的基础设施配置管理工具。



　　有人评论说："针对目前国内情况，DevOps还是很遥远。也许只有行业顶尖的公司，或者新成立的公司会有这样的尝试。大多数的企业还未开始进行敏捷的推进，传统的重重阻碍会使敏捷的推进进程遥遥无期。" DevOps真的离我们有那么远吗？DevOps应该从哪里开始呢？

一. 应对措施

　　1. 无人工干预方式的脚本自动化

自动化提测——由于已做到了每日集成，所以每天都有可测试的版本，开发人员不再需要为提测进行专门的准备工作，只要从成功构建的列表中选择一个给测试人员就可以了。使用Hudson平台后，通过插件即可调用自动化脚本，完成提测版本的标识。

统一配置信息源——将所有的配置项全部放在Subversion库中进行版本控制；并根据应用环境的不同，分别保存在Dev，Test和Online三个目录中。


常规流程脚本化——经过各角色的共同讨论和可行性分析，最后配置上线部署的实施方案是：由开发人员将产品二进制包与配置项进行剥离，这样仅做策略调整时，测试人员只要对已修改的配置项进行相关测试即可。运维人员用一系列的脚本代替了内部运维平台的手工上线操作，再通过Hudson平台的插件，以 "Click Button"的方式达到了一键式部署。

　　2. 尽早发现问题，解决问题

"需求细分，及时开发，及时验证"——将需求拆分成端到端可测试的需求（即"用户故事"），这些需求一般可在3天内完成。在实现每个需求之前，开发人员与测试人员进行充分沟通，对需求与验收条件达成共识。每开发完成一个用户故事，就进行测试，并用自动化测试进行覆盖。

"主干开发，分支提测"——将原来的多个分支进行合并，统一在主干上开发，每周结束时拉出一个分支，进行提测，一旦发现问题，就在主干上修复。

"持续集成"——为了确保每次提交质量，对主干开发建立持续集成环境，开发人员和自动化测试人员都严格遵守持续集成纪律"Check-in Dance"。

　　新的开发流程如下图所示。



　　分支开发策略变更为Single Branch模式。

二. 小结

　　通过以上改进措施，让团队的合作方式发生了重大变化，从"碉堡防御"走向了"战线统一"。

　　原来，各角色仅关注于自己本身的工作，虽然大家都同处于一个项目中，但各自划分了"领地"，产品经理就应该将MRD写得清清楚楚，如果开发人员认为不清楚，那就回去再改。开发人员只管按照MRD上的内容进行开发，很少考虑可测性和易测性问题。测试人员只管按照MRD中内容来测试，有问题通过内部工作流平台提交问题单。运维人员只管根据开发人员提交的上线操作单进行操作。似乎各角色之间的沟通介质只有各自的"交付物"。

　　现在，各角色都能够共同合作，以项目的最终交付为目标，积极讨论需求，优化实现。因为角色之间的这种紧密合作让所有人对不同角色都有了深入的了解。开发人员耐心为产品经理解释技术实现，说明计划安排，测试人员与开发人员共同讨论验收条件，避免遗漏需求。开发人员让运维人员了解架构设计， 细心听取运维人员的建议，进行技术改造，使部署工作更快捷有效。



　　通过这些活动，大家都认识到原有内部管理平台仅是个公文流转的支撑平台，要想提高工作效率，就要将这种"办公自动化工具"进一步提升为"全面自动化工具"，使所有人更关注于端到端的价值，而非各角色之间的分界点。

三. 结束语

　　百度刚刚开始敏捷之旅，还没人谈及"DevOps"运动，虽然还没有什么强大的工具支撑，但基于"提高效率"的朴素思想进行的过程改进也带来了"DevOps"效果。可见，DevOps听上去很神秘，但其实并不难。只要本着精益思想，聚焦于快速交付价值，不断发现并消除浪费，你也一定会有很大收获。