从责任到优势：与 John Graham-Cumming 和 John Ousterhout 的对话
软件生产已成为许多开发组织中的瓶颈。
问： 欢迎收听本月 Queuecast 节目，本期节目邀请了 Electric Cloud, Inc. 的联合创始人 John Graham-Cumming 和 John Ousterhout 进行对话。Electric Cloud 生产自动化、加速和分析整个软件生产管理流程的解决方案。接下来，我将把话筒交给 John Graham-Cumming。John?
JOHN GRAHAM-CUMMING： 非常感谢。今天我们在这里讨论 Electric Cloud 真正声称拥有的领域，那就是软件生产管理。John，这是一个新名词。它到底是什么？
JOHN OUSTERHOUT： 嗯，我们是这样看待它的，你可以将软件生产或软件开发视为有一个前端和一个后端。前端流程涉及高度创造性、高度人工参与的活动，例如设计、编码和调试等等。如果你回顾过去 20 或 30 年，已经构建了许多高质量的工具来帮助人们进行软件开发的前端工作。然后是后端，例如构建、测试、打包和部署——理想情况下这些流程应该完全没有人为干预。你只需按下按钮，它们就会像钟表一样运行。但在过去 20 或 30 年里，这些流程并没有受到太多关注，而这正是我们公司真正关注的重点。
GRAHAM-CUMMING： 那么，为什么它们没有受到关注呢？我们构建软件已经很长时间了。软件生产管理这件事是新出现的问题吗？发生了什么？
OUSTERHOUT： 是的，这是一个好问题。这绝对不是一个新问题。自从我开始从事软件开发以来，它就一直存在，但在过去 10 或 15 年里，情况变得越来越糟，至少有四个因素在起作用：软件复杂性、敏捷编程、分布式开发和合规性。
软件复杂性只是意味着软件持续变得越来越复杂。人们谈论集成电路的摩尔定律，即 IC 的复杂性每三年增长四倍。软件复杂性的增长速度可能甚至更快。
不仅是单个软件包变得更大，而且软件包的变体也大量涌现，例如嵌入式系统供应商必须编写可在数十种不同芯片组上运行的软件。然后是敏捷编程，人们尝试采用更具迭代性的开发风格，为了做到这一点，你需要一个像钟表一样运行的后端，因为你需要进行更多的构建和测试来支持敏捷编程。
第三，是分布式开发，越来越多的开发工作发生在相距遥远的地点，在许多情况下，实际上不同地点的团队之间没有工作日重叠。例如，美国和印度之间，或欧洲和亚洲之间，正因为如此，你需要依靠更高水平的自动化来组织这些不同团队之间的互动。
最后，是对合规性的日益重视，这意味着你需要能够证明软件的某些属性，为此，你需要非常好的报告，并且你需要非常仔细地跟踪软件及其构建方式。
GRAHAM-CUMMING： 所以，如果你认为人们今天确实面临着这些问题，那么 Electric Cloud 就出现了。如果你暂时把 Electric Cloud 放在一边，人们正在做什么，并试图做什么来解决这些问题？有哪些现成的工具可以下载并开始使用？
OUSTERHOUT： 今天没有很多东西可以下载。有一些开源软件包可以管理部分问题——例如，像 Make 或 Ant 这样的软件包用于构建——还有一些相对较小的软件包用于管理构建和测试，例如 Maven 和 Cruise Control。
但老实说，没有太多现成的工具。大多数情况下，人们倾向于构建自己的工具来处理软件生产。
GRAHAM-CUMMING： 是的。我认为长期以来，构建管理者已经习惯于构建大量的工具和东西……打包式的文件和……脚本。这已经不够好了。我们必须削减这些。
管理者真的……他们习惯于拼凑东西。曾经有一段时间是 Perl 和 Make 的时代。为什么他们不能继续这样做？为什么这已经不够好了？
OUSTERHOUT： 嗯，这是我之前提到的所有因素的结合，这些因素使得自己动手构建变得越来越困难。例如，如果你有数百名开发人员想要能够一键调用构建和测试，你需要机器池来支持，因此你必须为这些池构建资源管理。
如果你的项目变得非常庞大，你的构建需要花费数小时，你需要某种方法来加速这些构建。
如果你进行分布式开发，你需要自动化所有这些不同团队之间的交互。
因此，仅仅是必须添加到此软件中的职责和功能的累积就使得自己动手构建变得越来越困难。因此，人们今天往往会遇到三个问题：性能、可管理性和可见性。
第一个是性能，问题在于事情花费的时间太长。例如，在我们与之交谈的公司中，如果开发人员超过几十人，平均构建时间通常为两到四个小时。这对工程生产力产生了巨大的影响。在可管理性方面，是大量自制脚本来管理构建和测试，这导致系统非常脆弱，很难随着产品的变化进行扩展或演变。然后是第三个领域，可见性，同样主要来自自制工具，很难看到构建和测试流程内部发生了什么。
一方面，你有太多的输出，通常来自 meg 的输出就有兆字节。另一方面，很难获得你需要的关键指标，例如构建成功或失败的百分比，以及是否有经常失败的特定测试，因此我们应该进去弄清楚如何重写这些测试。
所以再次强调三件事：性能、可管理性和可见性。
GRAHAM-CUMMING： 我知道你说的所有事情都让我点头，并回忆起我们创立 Electric Cloud 并讨论其中一些问题的时候。
我们遇到了其他公司。为什么我们不稍微谈谈 Electric Cloud，我在这里把麦克风给你，让你聊聊是什么让我们创立了 Electric Cloud，以及我们今天在做什么？
OUSTERHOUT： 嗯，当然，正如你所知，我们创办这家公司是因为我们厌倦了自己处理各种软件生产问题的痛苦经历。对我来说，关键的经历是当我们的上一家公司被一家更大的公司收购时，我们有机会观察他们的开发团队，以及他们遇到的所有构建问题，构建需要 7 到 10 个小时，并且在一个时期，在一个新产品的主要版本开发的后期，超过一个月没有一次成功的生产构建。当最后一个构建修复后，其他人又签入了更改，破坏了下一个构建，就这样一直持续下去。
因此，我们决定创办这家公司的原因是看看我们是否可以构建工业强度的工具，使解决这些问题成为可能。我们最初主要在速度领域和构建速度方面工作，但随着我们获得更多经验，我们越来越意识到其他问题，因此我们最近扩展了我们的产品线，以涵盖整个软件生产管理领域。
GRAHAM-CUMMING： 是的，我们正在谈论我们所在的那家被另一家公司收购的公司。你让我回想起了那些糟糕的回忆，那些交易持续了多久，以及我们在让事情正常运转方面遇到的所有问题，因为它太脆弱了。让我们稍微谈谈你提到的那三件事，性能、可管理性和可见性，因为我们在之前的公司遇到的一个问题是整体可管理性，构建时间非常长，而且构建数量也很多，以及你如何处理它们。
告诉我们一些我们正在做的事情。让我们稍微谈谈我们现在在可管理性方面正在做的事情。
OUSTERHOUT： 当然。那么让我从问题开始，问题是，通常是大量自制的构建脚本，每个组织都为自己构建这些脚本。
我们彼此之间都有过多次这样的经历，例如，当我们构建我们的第一个产品时，我们实际上在 Electric Cloud 构建了自己的自制构建系统，在公司成立的头两年，我们可能在一个工程师身上投入了一年的时间，结果它变成了一个非常糟糕的系统，由堆积如山的创可贴组成。
问题在于你永远不会将你的构建系统视为你的核心竞争力，因此你倾向于拼凑一些没有良好架构、无法扩展且不提供良好报告设施的东西。
因此，我们的产品 Electric Commander 的目标是通过提供一个强大的基于 Web 的平台来解决这个问题，该平台使你能够轻松地实施和管理分布式流程，例如构建和测试的流程。
GRAHAM-CUMMING： 我认为任何听众都会说，这听起来很棒，但我已经在现有的基础设施中投入了大量的资金。我不可能重写它或使其与 Electric Commander 一起工作。使用 Electric Commander 的新人需要什么？
OUSTERHOUT： 是的，这当然是一个很好的问题，我们已经尝试构建 Electric Commander，以便你可以非常轻松地集成你现有的脚本。你可以将它看作是将你现有的构建脚本整体带入 Electric Commander 系统，然后让它运行并获得一些好处，然后随着时间的推移，逐渐将其分解为更自然地适合 Electric Commander 结构的各个部分。
关于这些夜间构建脚本，有趣的事情之一是，如果你查看它们，似乎每个人的构建脚本都不同，至少表面上是这样。每个团队都构建自己的脚本。我们与拥有 30 个不同构建系统的公司交谈过，但如果你深入了解，实际上，它们往往是由相同的组件构建的。每个人最终都会在他们的构建和测试系统中构建相同的基本基础设施。
例如，在远程机器上运行命令的能力，你知道，在这里进行我的 Solaris 构建，在那里进行我的 Windows 构建。
或者，在构建完成后发送电子邮件报告，或者重启机器，或者在机器在构建过程中崩溃时检测到错误。
因此，即使表面上所有这些构建系统看起来都不同，但实际上，它们往往主要由相同的基础设施组成。具有讽刺意味的是，一家公司内有数十个团队，全世界有数千个团队基本上都在一遍又一遍地重新实施相同的基础设施。
因此，Electric Commander 的想法之一是，我们提供一个非常强大的架构，其中包含每个人都需要的所有通用基础设施，以及一个非常简单的基于 Web 的界面，你可以在其中定义特定于你的环境的东西。通过这样做，我们可以大大减少你构建构建或测试系统所需的工作量。
GRAHAM-CUMMING： 对，而且我们也没有要求人们丢弃他们的 make 文件或任何类似的东西。
OUSTERHOUT： 不，不，事实上，在这个层面上，我们真正谈论的是我们周围的基础设施，所以是运行你的 Makes 的系统，而不是替换 'Make'。
GRAHAM-CUMMING： 那么，John，给我们举一个例子，说明这个东西实际上是如何运作的？在我的日常工作中，我将如何使用它？
OUSTERHOUT： 你使用 Electric Commander 的方式是通过 Web 界面进入，并描述你的流程。流程以我们称之为过程的方式描述，过程是步骤的集合。你说类似“这个编译集需要在该机器上执行，这个测试集需要在另一台机器上执行”等等。
因此，你描述你想要运行的流程，你描述可用于运行这些流程的机器——我们称之为资源——然后你描述一系列计划，这些计划指示何时应该运行特定流程。你可能有每天午夜运行的东西，或者你可能进行持续构建，整天每 20 分钟运行一次，或者你可能在每次有人在源代码控制系统中签入更改时进行构建和测试。
因此，一旦你描述了你的流程、计划和资源，Electric Commander 就会完成剩下的所有工作。我们将这些信息存储在数据库中，我们的服务器会介入并按照你希望的时间运行各种流程，并记录关于它们的大量信息，然后你可以使用这些信息进行报告。
GRAHAM-CUMMING： 好的，我想继续讨论第二个主题，即速度。我注意到速度变得越来越重要，这有两个原因，一个是正在进行的分布式开发，这基本上消除了夜晚。因此，夜间构建的概念在这一点上是自相矛盾的。
另一个是敏捷开发，它倾向于——开发人员正在呼吁非常快速的构建。事实上，他们希望构建速度快到他们在喝咖啡回来后就能得到完整的构建。
那么，让我们稍微谈谈 Electric Cloud 如何处理速度问题。
OUSTERHOUT： 当然。这是我们的第二个产品——实际上，它是我们历史上的第一个产品，名为 Electric Accelerator，它是一个专注于构建问题的产品。因此，想象一下在 Make 或 Ant 或 Visual Studio Build 级别或更低级别发生的事情。因此，Electric Commander 更多的是，将其视为尝试获取构建和测试的所有部分的总体的全局基础设施。Electric Accelerator 专注于这一个点问题，我确信人们想知道这些产品是如何关联的，答案是，你可以一起或单独使用它们。它们解决的是不同但相关的问题。
无论如何，Electric Accelerator 的想法是让这些构建运行得更快得多，理想情况下，例如，快 10 倍、20 倍甚至更多。
Electric Accelerator 实现这一目标的方式是通过使用你为 Make 或 Visual Studio 或任何其他工具提供的信息，以非常细的粒度实现并行性。我们将构建分解为许多小的部分，在要编译的单个文件级别，然后将这些单独的编译传递给机器集群，在集群中并行完成。
因此，简单的总体答案是，你通过并行性获得速度。
GRAHAM-CUMMING： 好的，我认为每个听众都会觉得这听起来很棒。我可以只做 make … 并免费获得并行性吗？它已经存在了，不是吗？有什么不同？我们做了什么不同的事情？
OUSTERHOUT： 对，在过去的几十年里，人们已经进行了大量的尝试，使并行性可用于构建。我在 20 世纪 80 年代后期在伯克利担任教授时做了一些，我们一路上也进行过其他实验。如果你去谷歌搜索分布式 Make 或并行构建，你会看到很多结果。
因此，并行构建的想法很棒，但有一个小小的障碍，那就是它不起作用。它不起作用的原因，至少到现在为止不起作用的原因是，为了知道何时可以或不可以并行运行构建步骤，你必须拥有完美的依赖关系信息。你必须知道构建的哪些部分依赖于哪些其他部分，这样你就不会意外地并行执行应该串行运行的操作。不幸的是，直到现在，获得依赖关系信息的唯一方法是让人类指定它。例如，有一些工具，如 Make depend，可以为你提供一些依赖关系信息，但最终，这归结为工程师在 Make 文件中写下哪些文件依赖于哪些其他文件。
显然，对于具有数千或数万个源文件的商业项目来说，这根本不切实际。
因此，当我们在 Electric Accelerator 成立公司时，我们知道我们必须解决依赖关系问题。我们不能依赖人类来提供这些信息，因此在 Electric Accelerator 中，我们构建了一些非常酷的技术，我们可以在构建运行时通过监视文件访问来推断依赖关系。简单的想法是，如果你读取我写入的文件，你最好在我完成之前不要运行。通过这样做，我们可以获得依赖关系的完美图景，通过这样做，我们可以使并行构建安全。我们可以将 10 个、20 个、30 个或更多 CPU 用于单个构建。
GRAHAM-CUMMING： 你知道，当你开始谈论依赖关系很重要时，你让我想起了我们真正涵盖的第三个主题，即可见性，因为我认为大多数处理构建的人都没有对构建内部的可见性，哪些作业花费很长时间，或者它依赖于什么，这是一件非常困难的事情……
你能谈谈 Electric Insight 工具吗？
OUSTERHOUT： 是的，Electric Insight 最初是一个调试工具，后来发现它非常有用，以至于我们将其变成了一个单独的产品。它的工作方式是，它使用 Electric Accelerator 在运行并行构建时创建的数据库。Electric Accelerator 输出一个 XML 文件，我们称之为注释文件，其中包含关于构建的各种信息，然后在构建完成后，Electric Insight 可以获取该文件并为你提供构建过程中发生的事情的图形显示。例如，当你在运行并行构建时，Electric Insight 将显示参与构建的每个 CPU，以及任何给定时间该 CPU 的工作，这样你就可以看到构建的进度，并且你可以看到，例如，突然之间出现一个时间间隔，在该时间间隔内，集群中只有一台机器在做任何工作，而其他机器都在等待，因此从中你可以推断出，肯定存在某种依赖关系，迫使其他所有机器都在等待，并且使用 Electric Insight，你可以深入探索并找出该依赖关系是什么。
你还可以获得关于失败步骤和发生的事情的许多其他信息。
例如，Make 的问题之一是，人们在他们的 Make 文件中的许多命令前面放一个小 at 符号 (@)，这会导致这些命令在 Make 运行时不回显到 Make 日志。因此，当你返回并查看日志时，很难弄清楚在发生错误时发生了什么，因为通常有趣的命令甚至没有回显。
嗯，使用 Electric Insight，我们将所有这些都保留下来，我们可以准确地向你展示哪些命令正在运行，以及更重要的是，它们来自哪个 Make 文件，以及这些 Make 文件是从哪个 Make 文件调用的，等等。
因此，在许多不同的层面上，Insight 允许你查看构建内部发生了什么。
GRAHAM-CUMMING： 让我们稍微谈谈这些总体——你已经真正谈到了软件生产管理，包括可见性（我们刚刚谈到）、性能（就构建速度而言）和整体可管理性。
你认为组织如果安装一些软件生产管理软件或程序，会获得哪些好处？
OUSTERHOUT： 对。我认为你将在三个领域看到好处。最容易衡量的是开发人员的生产力，我稍后会回到这一点，并给你一个例子，说明如果事情运行得更快，开发人员只需更快地完成工作。第二个领域是质量。这个领域最难衡量，但也可能是最重要的。
软件开发的定律之一是，查找和修复问题的成本急剧上升。数量级。如果直到过程后期才发现错误。例如，如果它出现在现场，修复它的成本非常高。
如果在开发人员的桌面上，在他们检查任何其他内容之前发现它，修复它的成本真的很低。
因此，通过更好的生产工具，你可以更快地找到问题，运行更多测试，通过这样做，你可以以更低的总体成本获得更高质量的产品。
第三个好处是上市时间。我们看到客户通过消除当前由于软件生产管理问题而出现的瓶颈，可以从开发周期中节省数周的时间。例如，如果在开发周期的后期构建中断，并且你的构建需要 8 或 10 个小时，那么这可能对你来说是损失一天。
如果你可以在半小时或一小时内重新启动该构建，那么可能根本不会损失任何时间。
GRAHAM-CUMMING： 听起来很棒。你比我更清楚我们现在在客户方面的情况。你能谈谈一些真正受益并正在使用这些工具的客户吗？
OUSTERHOUT： 让我举一个例子。Qualcom 是一家手机芯片和软件制造公司，已经使用我们的 Electric Accelerator 产品几年了。他们面临的问题是手机软件复杂性正在急剧上升。这场手机战争很可能由谁能推出下一个酷炫功能来赢得，这个功能可以让十几岁的女孩用旧手机换新手机。
因此，他们的复杂性正在急剧上升，他们必须支持各种平台。当他们更改软件时，他们需要重建并在多达 30 或 40 种不同的芯片组上对其进行测试，以确保他们没有破坏任何东西。
因此，他们的构建问题非常巨大，并且随着时间的推移变得越来越糟。
在 Qualcom，我们能够在构建中获得显着的加速，并且在我们安装 Electric Accelerator 后，我们能够衡量开发人员的生产力。使用 Accelerator 附带的软件，我们可以衡量人们进行构建的频率、这些构建花费的时间，然后由于我们知道我们运行构建的速度快了多少，我们可以估计如果没有 Electric Accelerator，构建会花费多长时间，并从中我们能够计算出我们为开发人员节省了多少时间，答案非常酷。
在一个团队中，我们每周为每位开发人员节省约 8 个小时，在其他团队中，每周节省约 5 个小时。
这是一个相当大的生产力提升。没有多少方法可以获得 5%、10%、20% 的开发人员生产力提升。
GRAHAM-CUMMING： 给他们很多咖啡。
OUSTERHOUT： 我们不让他们睡觉。然后第二个例子是 LSI Logic，有趣的是，另一家嵌入式系统公司，同样具有非常庞大、复杂的测试矩阵。在那里，他们最大的问题是管理他们必须运行的所有不同测试集的复杂性，所有不同的芯片组。他们一直在使用我们的 Electric Commander 产品——实际上还有我们的 Accelerator 产品——但最近主要是 Electric Commander 产品，这使他们能够管理他们拥有的庞大数量的测试头以及复杂的测试矩阵，并跟上步伐。此外，借助 Electric Commander 的一些报告工具，他们已经能够提取比以前更多关于他们测试的数据，因此他们对测试内部发生的事情以及软件的稳定性有了更好的了解。
GRAHAM-CUMMING： 这非常有趣。很高兴有机会和你交谈。
OUSTERHOUT： 非常感谢。和你谈话也很有趣。
最初发表于 Queue 第 5 卷，第 2 期—
在 数字图书馆 中评论本文
更多相关文章
- 为你的应用程序武装防弹部署：与 Tom Spalthoff 的对话
应用程序、更新和补丁的部署是任何 IT 部门最常见 - 也是风险最高 - 的职能之一。部署任何未正确配置为分发的应用程序都可能中断或崩溃关键应用程序，并使公司在生产力损失和帮助台费用方面付出高昂的代价 - 而且公司每天都在这样做。事实上，Gartner 报告称，即使经过 10 年的经验，大多数公司也无法以 90% 或更高的成功率自动部署软件。
Martin J. Steinmann - 基于 SIP 的统一通信
基于 SIP（会话发起协议）标准的通信系统在过去几年中取得了长足的进步。SIP 现在基本上已经完成，甚至涵盖了高级电话和多媒体功能以及功能交互。不同供应商的解决方案之间的互操作性在 SIP 论坛组织的 SIPit（互操作性测试）会议等活动中得到了反复证明，并且一些制造商已经证明，对该标准的专有扩展不再受技术需求驱动，而是受商业考虑驱动。
Jason Fischl, Hannes Tschofenig - 让 SIP 更有意义
会话发起协议 (SIP) 用于在基于 IP 的网络中建立实时会话。这些会话可能是用于音频、视频或 IM 通信，或者它们可能用于中继在线状态信息。SIP 服务提供商主要专注于提供一种服务，该服务复制 PSTN（公共交换电话网络）或 PLMN（公共陆地移动网络）提供的服务到基于互联网的环境。
David A. Bryan, Bruce B. Lowekamp - 去中心化 SIP
SIP（会话发起协议）是当今最流行的 VoIP 协议。1 它被企业、消费者甚至运营商在其网络核心中广泛使用。由于 SIP 旨在建立任何类型的媒体会话，因此它还用于 VoIP 之外的各种多媒体应用，包括 IPTV、视频会议，甚至协作视频游戏。
© 保留所有权利。