挖掘企业工具链的基本真相（掘宝科技有限公司）

挖掘企业工具链的基本真相（掘宝科技有限公司）

要了解有关在大型DevOps和敏捷部署中哪些有效和哪些无效的更多信息，我们需要数据。 问题是，众所周知难以获得数据，因为大部分数据隐藏在众多私有存储库中。

诸如 DevOps状态报告之类的 努力 通过使用调查数据回答有关诸如团队或组织中部署频率等实践的问题，帮助我们获得了一些了解。 然而，调查数据有其局限性，正如Nicole Forsgren和我在“DevOps Metrics”中所描述的那样，我们写这篇文章是为了澄清系统和调查数据收集的权衡。 1 今天，我们对DevOps实践的理解主要基于这一调查数据和轶事证据。 有没有办法扩展我们对DevOps的看法，包括研究DevOps的系统数据？

一种方法是检查公共可用的存储库，例如由GitHub或Eclipse和Apache基础托管的存储库。 但是，这项研究的结论仅限于开源项目的工作方式。 在规模，范围和工作类型方面，大规模和企业软件交付与开源交付有很大不同。

在我的博士研究中，我最初研究开源开发人员。 2 我的主管Gail Murphy推动我将我的学习扩展到企业环境中的专业开发人员。 我的职业生涯大部分时间都在进行开源开发，但我对这项工作的不同感到震惊。 我学到的最有趣的事情是专业开发人员每天工作的额外复杂性。 应用程序，系统，进程和要求的数量使我在更优雅的开源世界中遇到的任何事情都相形见绌。

在我的文章“  生产线类比的终结  ”中，我讨论了先进汽车制造与软件生产的关系。 3 汽车制造业的一个令人惊奇的事情是，工厂车间可以看到生产的“基本事实”。 走装配线可以即时查看工作流程。 我们在哪里可以找到企业软件交付的基本事实？ 这个基本事实如何改变我们对大规模软件交付失败的理解？

利用寒武纪工具爆炸

在我的上 一篇 文章中 ，我总结了“寒武纪爆炸”如何导致数百个DevOps工具的激增。 4 这次爆炸的一个关键原因是这些工具对于各种利益相关者的需求有多专业化。 例如，大型企业可能有十几个不同的专家参与软件交付，例如Java专家，AWS（亚马逊网络服务）专家，设计专家或支持人员。 现在每个角色都有一个专门的工具。

这提供了一个有趣的机会。 使用这些工具的次数越多，特定从业者的工作就越多。 如果我们只能获得这些数据，我们将有一个独特的机会更好地了解DevOps和软件交付在一般情况下如何在实践中发挥作用。

挑战在于这种端到端系统数据是不可访问的。 它隐藏在组织的防火墙后面或锁定在私有存储库中。 有时，供应商可以访问切片 - 例如，软件即服务支持台工具供应商可能拥有关于支持服务单的跨公司信息。 但是，这只是价值流的一个切片;  它错过了所有开发和其他上游数据，并没有提供端到端的视图。

在我对开源和专业开发人员的研究中，诀窍是使用开发人员对工具存储库的访问作为这些存储库中发生的事件的代理。 但是，再一次，这只是价值流的一部分。 但是，通过该实验，我意识到我可以访问那些能够看到端到端存储库集的人：企业IT工具管理员。

价值流整合图

我的公司Tasktop与负责敏捷和DevOps工具链的许多企业IT工具管理员密切合作。 我们的解决方案架构师进行的每次参与都会导致创建 价值流集成图 。 我第一次看到这些图表时，我意识到我的数据集与我在博士研究期间收集的Gail一样有趣。 这些图描绘了值流中的每个工具存储库，存储在这些存储库中的每个工件类型，最重要的是，工件类型如何相关。 这些图表不是通过学术研究收集的，而是通过与企业IT工具管理员及其工具合作的数据收集流程收集的。 这些数据偏向于Tasktop的客户和潜在客户，他们往往是500家企业IT组织，他们希望通过一个或多个工具进行集成。

Tasktop收集了308个这样的图表。 图1显示了其中一些。 它们是企业工具链的基本事实的迷人窗口。 因此，他们可能会以有趣的方式告知未来收集软件交付数据的努力。 在这里，我提供了我们从中学到的内容的高级概述。 更详细的分析将出现在我即将出版的 Project to Product中 。

这些图提供了价值流中每个工具的时刻总结，以及每个工具中捕获的关键工件的信息，以及它们应该或应该如何连接的信息。 这些图表并未详尽地列出组织中的所有工具存储库或所有工件类型。 它们也不提供有关这些工具中数据的信息 - 例如，缺陷的数量和类型。 但它们确实提供了有关这些组织的企业IT工具链组成的基本事实。

数据揭示了什么

在这一组之外可能有相关的工具。 例如，这些组织最近才报告漏洞跟踪工具是其DevOps工具链的一部分。 工具缺少结果并不意味着它不存在，只是因为当时没有考虑将其包含在组织对连接值流的视图中。

这些图来自Tasktop客户和潜在客户，他们定义了他们想要连接的工具和工件。 大多数图表来自财富1000强中的企业IT组织。表1显示了行业细分。

表2列出了所使用的工具类型。 正如预期的那样，敏捷规划和应用程序生命周期管理（ALM）工具占主导地位，但IT服务管理，项目组合管理和需求管理也构成了工具链的关键部分。 即使在敏捷和DevOps时代，需求管理工具仍然显着使用。 相比之下，连接客户关系管理（CRM）和安全工具的举措仍然很少。 总而言之，该数据集包括使用55个工具。

更有趣的是在工具中跟踪了哪些信息。 表3提供了对创建的工件以及工作类型的深入了解。 在较高的层次上，想象一下这些工件对应于流经执行软件交付的各种工具的小部件。 在接下来的文章中，我将讨论这些不同类型的工件的相关性。

结合表2和表3中的数据，我们观察到工件跨越了多个工具。 例如，通过敏捷，ALM，需求管理以及有时IT服务管理工具跟踪功能。 我们将此解释为另一个迹象，表明大型敏捷和DevOps环境中的工具数量及其专业化正在增长。 但是，存储在这些工具中的工件类型（参见表3）要小得多，并且工件往往跨越多个工具。 例如，单个缺陷可以跨越敏捷，ALM，需求管理和IT服务管理工具。

表4中列出了一些最有趣的发现。我们发现只有1.3％的组织使用过单一工具。 更有趣的是，69.3％的组织将工件连接到三个或更多工具上。 更令人惊讶的发现是，超过42％的组织需要集成四个或更多工具，这表明开发大型企业软件所涉及的复杂性。 它还支持这样一种观点，即软件开发中角色的专业化很常见。