为什么DevOps美但却难落地？

现在的IT部门是企业能够快速响应市场和得到竞争优势的主要动力。IT专人开始改变自己在行业中管理项目的方式方法，而管理方法本身也在不断改进。试想一下，当下互联网正在颠覆一个个行业，我们试着从高层角度看这件事，作为信息行业的领导者/追随者，IT项目管理方式不强大怎么行？DevOps发起于发达国家，它们的互联网起步比我们早。在此理论的影响下，敏捷性和持续交付成了软件开发和测试领域的新鲜热门话题，因为它描绘了一个有效应对现代工作流程的一些核心原则和流程。

DevOps全貌没有非黑即白立马呈现，想要落地就要接受一个逐步进化的步骤和阶段。换句话说，世上最不会改变的就是改变，DevOps不是老板一拍脑袋就能很快落地的事，在实施过程中的各种具体执行也不存在一劳永逸。翻译成IT术语，DevOps通过简化组织的工作方式，分解组织孤岛（部门墙）来实现，有效促成合作。

本篇聊聊典型组织跟进DevOps要跨越的弯路，以及为什么绝大部分仍旧走不出适合自己的DevOps路子。除了devops内容，我们顺便讨论了不同程度的敏捷性，组织需要克服的障碍。

现代软件交付链涉及许多重要工具和流程，许多组织正在打怪升级，不断进入DevOps下一阶段。一口虽然吃不了胖子，但DevOps内有4个主要的敏捷阶段可以作为一定的参考标准。

瀑布流：瀑布交付是很多企业在用的交付模式，其内涵包括一些手动过程，比如测试。代码按照特定节奏编写，测试和交付。所有的整体团队，包括开发人员，运营和质量保证，都在孤立地运作，很少合作。

初始的敏捷：一般来说，有一定程度敏捷的组织正处于瀑布的快速阶段。但是由于灵活性，重定位或修复bug的机会有限，最终产品说不定……咳咳，我们往下说。实际操作阶段，GitHub上一大堆工具是很有可能为工作流程带来一定程度上的自动化和可扩展性。不过即便在此基础上又有了一些自动化方面的测试，但基础流程决定约束仍然存在，比如一些并行测试。

持续集成：DevOps跑到一定阶段的标志是用了诸如Jenkins，CircleCI和TeamCity等持续整合平台，这些工具对构建自动化大有益处。这里确定交付模式存在的深层次问题，把开发运营角色职能汇聚起来，使得快速诊断和快速解决得到落实，又没有占用额外资源。
持续交付：走到这里，DevOps基本已经落地成型。实现持续交付的组织采用了近乎全自动化的开发流程，甚至于包括高频而精确的自动化测试。此外，开发，运营和QA团队也已形成一股战斗力，不断地相互同步。这个阶段调整业务需求、IT项目、开发团队和IT运营人员等曾经比较头疼的大动作都变得更加顺畅，以便持续提供新的应用程序版本。

通过采用跟开发，交付和产品相关的工具开启DevOps落地的组织很可能会发现自己在敏捷方面受到高效自动化测试流程的限制。我知道说来容易，但破解之道确实就是提高测试效率。先前的DevOps工具和方法提高了部分测试效率，比如自动测试、云测试、并行测试…不过这些使测试更有效率以提高敏捷性的策略迄今没成为DevOps对话的核心部分，但它们构成了简单，低成本的增长更灵活的方法，以便实现全面持续交付的目标。

自动化测试的作用本质在实现持续交付方面与其他DevOps工具区别开来。当目标是实现全面的敏捷性时，自动化测试的重要性就凸显了。在印象里，开发Web应用的企业在过去很多年就充分利用到受DevOps启发的工具和技术了。从GitHub仓库，到Jenkins，它们已经实现了几种方法来构建部分的自动化流程。这些摸爬滚打探索出来的流程很大程度上能确保开发可以轻松加愉快的与QA和运维沟通对话。换个角度，部分这些特定的企业已经很大程度上吸收了DevOps文化。然而熟归熟，该指出的短处还是要指出，它们缺乏自动测试的DevOps资源，还是赤手空拳打天下。虽然测试可以脚本化，但大多数测试都是在临时搭建的基础上进行，而团队还没有在构建过程中把自动化测试囊括进去。

缺乏完整的测试自动化过程意味着产出高频且可靠质量的应用依旧（相对）困难。此外，这很有可能会扰乱组织已经执行的其他新变更，削弱开发和交付的管道价值。虽然这些变化已经优化了开发和部署，但没有实际的自动测试导致连续交付依然困难。因此，即便工作流程更敏捷了，但还是没达到持续交付的效果。

此阶段并非对持续交付就没什么价值，既然缺一环，那就能理解它的价值在铺垫，继续DevOps下一步的铺垫。使自动化测试成为持续集成工作流程的一部分的工具，这对现有流程的敏捷性帮助就大了。

DevOps你也可以看成是一种交付心态，一种人人为我、我为人人的协作心态。团队每个人都肩负业务指标，协作搞定需求，共同思考开发，构建，测试并部署到集成环境。跨团队合作，创造性挑战和勇气，随着越来越多的迭代进步，都包含DevOps概念。DevOps是高效软件交付的核心部分。大多数超出用户预期的公司，他们的IT模式早已不是你我能随便赶超的样子，他们都在做最好的工作，深谙DevOps之道。抛开这种大神级文明，我们为了达到持续交付实质性阶段并尽可能全面敏捷，要做的不单是用几个DevOps工具，也可以用DevOps涉及的语言。组织需要彻底改革在瀑布发展时期建立的做法，让工作流程完全敏捷、完整的DevOps落地，才更贴近你我可能都说不太清楚的DevOps理念。开始工具因公司而异，但有一些东西是岗位上就要有的觉悟：运维方面，想想你想要什么样的自动化；测试人员，请想想你想要什么样的自动化；开发不是不需要考虑，能协助就是最大的幸福，毕竟听说你们玩OT都是玩的最高级。