访谈Dennis Ehle：DevOps价值链的可见性-InfoQ

本文要点

DevOps 是敏捷文化和思想的扩展。

DevOps 工具集是高度分散的，并很有可能将继续如此。

由于在大型企业中部署节奏的放缓，透彻了解 DevOps 价值链是十分重要的。

在从策略目标直至已部署软件包的全价值流中，具备追踪价值的能力需要贯穿始终的 DevOps 工具集。

在近期的 Agile 2016 大会上，InfoQ 访谈了 VersionOne 的 DevOps 策略副总裁 Dennis Ehle 。访谈内容涉及从思考问题方式和支持实践工具集角度看 DevOps 的演进，以及透彻了解价值是如何在 DevOps 流水线上交付的重要性。

InfoQ：对 DevOps 有多种定义和描述。你们在提及 DevOps 时是如何定义它的？

Dennis： DevOps 的确是一个被很多市场营销组织所攫取的词汇，已被重定义为可指代任何的事情。我倾向于将 DevOps 定义为仅是一种优化的手段，它可以精简开发者与终端用户间的业务价值流。DevOps 借助了工具、技术和文化，采用了敏捷的概念和思想，并将所有这些自始至终应用于软件的交付中。

InfoQ：你们采取了哪些特殊的做法？

Dennis： 我认为 VisionOne 的确具有独到的 DevOps 方法。DevOps 社区在创建各种自动化上做得很出色，这使大多数企业几乎每件事情都可以找到自动化的方法。但是一般来说，DevOps 社区的组织仍然是围绕着分散的工具。举个例子，一个 DevOps 工具链中可能会有 15 种不同的自动化工具，这些工具共同构成了更大规模的流水线。

问题在于，其中没有任何一种工具了解它们所流转的价值。这些工具如此擅长流转，擅长简化少量已提交代码的获取、处理、验证和部署过程。这些工具一起协作以协调地完成交付。但是它们不擅于描述当前正在流转什么价值，以及这些价值是在此过程中是如何一步一步流转的。

一旦我们的想法被转化为代码并编译为可执行的二进制程序，我们就从根本上丧失了对业务价值流的可见性。我们实现 DevOps 的途径是使用已有的工具和技术。而且，跟踪通过这个工具的价值迁移时不会妨碍到 DevOps 工具栈，这为所有的利益干系人提供了可见性，他们可以看到通往产品部署的所有途径。

InfoQ：我们以一个用户故事来讲，为实现它我们在开发中完成所有的事，然后还有哪些事呢？

Dennis： 是这样的。对于把大的想法和主题可视化为价值流，进而将它们分解为各个 epic 或是特征，乃至最终分解为用户故事，我认为 VersionOne 对此已做了非常好的工作。具有有效的敏捷生命周期管理的解决方案，我们可以可视化从策略层到开发的价值流转。

VersionOne 的 DevOps 解决方案称为“ Continuum ™”。它自开发人员检入新代码就开始追踪价值。所以每个提交都能关联回用户故事。现在，我们清楚该提交是关联回该用户故事的。然后我们联通 Jenkins、Travis CI 或 CI Server Maven 等编译自动化工具，监控编译过程，关联编译过程的输出，即一些二进制工件（Artifact）。所以我们现在就可以将这些工件清晰表述（或诠释）成业务价值了。

我们所做的第三件事情是与部署自动化的联动。一旦工件被 Octopus 或 UrbanCode Deploy 等工具发送到某个环境中，我们就可以追踪业务价值。我们知道现在该价值就在这个环境中。这可以回答诸如“我们想要测试这个用户故事，但是它在哪里？”或是“这个用户故事是否已经部署到生产系统中？”这类问题。将所有这些 DevOps 数据关联起来，我们就可以从头到尾全过程地追踪价值流，直至终端用户。

InfoQ：这是否意味着我们可以开始把一些度量部署到位？

Dennis： 当然可以！在这个过程中的确产生了一些有意义的度量。事实证明，它们十分有助于把握交付在各个阶段要停留多长的时间。在测试阶段要花多长时间？达到完成标准要花多长时间？所以从本质上讲，它完成了，测试了并验证了。从此时开始到生产部署需花费多少时间？在一些情况下，可能需要六个星期时间达到完成标准、结束 Sprint 并实际交付到终端用户手上。

做到在价值流的各个阶段中跟踪度量变化情况，在团队层获得价值流转不畅的确切位置，这会让做出确定投资方向的战略决策不再是难事。我们现在知道了机会与瓶颈所在。各种度量最终会使组织得以达成敏捷，进而简化交付的过程。

InfoQ：如果我们审视这些看上去十分零散的工具和生态系统，会发现每个人都在做着自己的实现，并且看上去显然没有适合所有人的工具。这不危险吗？我们会丢失价值的洞察力吗？

Dennis： 这是一个很好的问题。我认为如果回顾 DevOps 的起始点，就会发现该问题存在于这样的一些组织中，它们从最初构建到终端用户部署之间用时较短。鉴于在这种情况下，价值存在于交付阶段中的时间较短，等待时间并未造成过多的风险，团队可以很快地实现部署。而当我们逐渐步入到企业层级，首次提交至终端用户部署间的时间会显著增长，DevOps 的等待时间也会相应增加。

在我们最初构建 DevOps 工具时，并没有必要去追踪业务价值，因为价值流转太快。而现在在企业中经常发生的是团队在每次产品部署中会都做上千次的构建，这意味着生成了非常多的工件。每个构建都是独特的，其中组合了不同的用户故事和价值。有能力在那么多工件和复杂的企业交付价值流中追踪业务价值，是向降低 DevOps 等待时间所迈出的关键的第一步。

InfoQ：为什么这些工具会是分散的?

Dennis：在我看来，这是由于七到十年前的 DevOps 社区文化是非常倾向于开源的。从本质上看，开源工具几乎都是单点解决方案。我认为很多的自动化解决方案，甚至包含商业的自动化解决方案，都是设计用于解决一个非常特定的或狭隘的问题。由此产生了解决部署问题的工具，解决配置问题的工具，解决测试问题的工具，等等。但就是没有标准的 DevOps 工具链。这就像是没有两片雪花会是一样的。开发人员会倾向于采用他们所选定的某种工具，而 DevOps 文化也鼓励通过实验进行验证。在企业还没有完全成长为可自行开发各种工具的巨人之前，会选取特定的单点解决方案并将多个解决方案拼凑在一起，在所有价值流之上形成效率。

我认为这个方法在过去是十分高效的，它可在价值流中任何一点上获得最佳效率。其不好的一面在于，其中并没有任何一种工具能对过程的整体有所了解，即在价值流中上一步曾发生了什么，下一步将会发生什么。最为重要的是，这些工具很少甚至是完全不知道它们刚刚处理的价值是什么。

InfoQ：那么所有这些工具是会变得更加统一，还是会继续维持现状？

Dennis：在我看来，一些特大型的软件厂商可能正致力于实现端到端的解决方案，但我认为社区依然倾向于提供工具链中各步的单点最佳解决方案。我看不到未来会发展成统一工具的可能。考虑到每个部署团队的异构本质和各种各样的需求，在 DevOps 中近期不太可能会出现大规模的统一。另一方面，我们已经适应了将这些零散工具所生成的数据应用于整个价值流中。

InfoQ：您已经为我们介绍了 VersionOne 的一些做法，涉及如何看穿整个价值流，如何审视各种工具，以及如何将这些可见性向上提供给用户。你们的产品未来将会如何发展？

Dennis： 为理解对新的业务价值是如何构建、验证并部署的，我们将继续关联整个价值流中的数据。在其中我最感兴趣的事情是，如何利用这些数据去生成一些十分智能的和客观的部署风险衡量指标。

如果我们知道每次部署的确切内容，就可以开始客观地评估风险了。举个例子，使用分析方法可以识别某处代码是否尤为脆弱。一旦鉴别出是最为脆弱的代码片段，我们就可以对每次部署的脆弱性做定量分析，扩充问题报告的内容。为提高精确度，还可以整合由其它的 DevOps 工具所采集的循环复杂度数据。将所有这些重要的 DevOps 数据整合在一起，有助于测定整体部署、特性和 epic 中的测试覆盖度、代码复杂度和技术债务。

关于被访者

Dennis Ehle是 VersionOne 的 DevOps 战略副总裁。他是持续交付自动化和敏捷交付方法论的先行者和思想引领者。Dennis 在技术自动化领域具有超过 14 年的工作经验，他一直在倡导简化 DevOps 和软件交付的创新方法。他的 Twitter 为 @DennisEhle。