你能跳下飞机然后检查一下你的降落伞索具吗？在你检查你的空气被打开之前，你会开始潜水吗？你能在起飞前检查一下吗？我不知道有谁能回答这些问题中的任何一个，但我们大多数人仍然从事与这些风险实践相当的软件开发：我们签入代码，然后在其上进行产品构建。我们甚至给这个实践起了个名字：持续集成。它应该被称为连续构建破损。一个持续集成的主要目标之一是为开发人员提供快速反馈；他们需要技术基础设施，使他们能够尽早、经常地进行构建和测试。多年来，这推动了市场的持续整合，其目标显然是为客户打造高质量的软件，无论是一个实施财务报告内部应用程序的小团队，还是一家价值数百万美元的游戏公司，即将推出其最新的跨平台大片击中。到打造最好的软件，开发团队必须达到他们的重要里程碑，以允许足够的质量保证，当他们的代码崩溃时，他们会挣扎。为什么？因为许多人仍然在自己的机器上进行验证和测试，而不是在生产类系统上。开发团队在早期和经常遵循持续集成和敏捷测试方法，但是当他们的代码被集成时，构建就中断了。他们回答说，"它在我的机器上起作用了！"所以生产环境中的某些东西与开发人员的机器上的不同，结果失败了。也许他们有一些不同的工具，或者不同版本的工具，再加上一个10到100名开发人员的团队，他们很快就会得到不听话的在这种常见场景中，持续集成的意外后果有三个。首先，开发人员害怕在一天中的晚些时候报到，他们不想成为破坏构建的人，必须通宵把事情弄清楚，所以生产力是第一个牺牲品。第二，延迟的代码提交会导致计划的延误。或者第三，好的三角洲会被贴上一个糟糕的构建标签，因为它们加入了一个被破坏的变更。不是一个激励人心的结果。士气进入俯冲。还有我们没有考虑到全球开发团队的额外挑战。由于美国和海外的开发团队正在努力克服时区和语言方面的挑战，生产率下降的影响可能会持续数小时到数天。我们都知道，失去生产力就失去了收入。以及士气的损失不可低估。我亲眼目睹过客户因为这个问题失去了优秀的开发人员。非常好的公司一直无法留住他们最好的开发人员，因为构建会因为基础设施问题而不断中断，这不是坏事代码。所以解决办法是什么？开发团队不应该只在生产类环境中验证他们的构建。在正确的操作系统、数据库版本和工具链上进行早期、频繁的测试，以及跨平台测试的能力，是有效敏捷战略的关键。飞行前构建和测试——在签入前进行构建和测试，包括生产级环境中的单元测试和系统测试子集，消除了上述示例中所遭受的巨大生产力损失和士气下降。开发人员得到快速反馈。代码是否干净？如果答案是yes，它将自动签入并准备好进行QA。如果失败了，它会被退回给开发人员，但是问题会在测试过程中更早地被发现，团队的其他成员继续保持高效，不用等待就签入代码。所以，在飞机起飞前，一个可能在起飞前才被发现的错误现在被发现了。原本延误数小时的情况，现在可以隔离和修复，而不会影响所有乘客以及其他等待乘坐的飞机-关了。所以它的实际效果如何？我们在electricommander3.0中引入了飞行前构建功能。有几个客户每天都在实践飞行前的构建。我们有一个客户发现，在短短几个月内，损坏的构建减少了90%。值得注意的是，剩下10%的失败构建是由于开发人员没有使用飞行前构建和持续集成方法论早期和经常的测试结果是，与"半空中"相比，您在飞行前阶段发现了问题，并且得到了更快的反馈，最终得到了更干净的代码库。一架飞机返回航站楼，但另外20架飞机同时起飞。在敏捷开发中，你得到了可以工作的软件，并且可以随时发布，因为你正在达到你的里程碑。你的演示已经准备好了；QA正在测试正确的版本，可以运行干净的测试。我们宁愿早一点抓到几百只虫子，而不是花上几千美元顾客。持续整合很好，但它只会告诉你，在阻止问题的下游损害为时已晚之后，问题就出现了——高性能的开发团队已经将飞行前的构建和测试结合起来，以获得灵活性，并专注于代码，而不是基础设施。