问如何在实践中持续交付工作？

EN

我多年的软件开发经验表明，在实践中它不能工作。

你试过吗？戴夫和我写这本书是基于多年的集体经验，无论是我们自己，还是ThoughtWorks的其他高级人员，实际上都在做我们讨论的事情。这本书里没有任何东西是推测的。我们讨论的每一件事都经过了尝试和测试，甚至在大型的分布式项目上也是如此。但我们不建议你相信我的信仰。当然，你应该自己试一试，把你发现的和没有的写下来，包括相关的内容，这样其他人就可以从你的经历中吸取教训。

持续交付非常注重自动化测试。我们花了大约1/3的书来讨论它。我们这样做是因为替代方法--手工测试--昂贵且容易出错，而且实际上并不是构建高质量软件的好方法(正如Deming所说，“停止依赖大规模检查来实现质量。首先改进过程并将质量纳入产品中”)。

全面的测试覆盖是不可能的。你必须投入大量的时间--时间就是金钱--对每件小事都是如此。这是很有价值的，但这些时间可以在其他方面为质量作出贡献。

当然，完全的测试覆盖是不可能的，但是还有什么可供选择的:零测试覆盖率？这是一种权衡。中间的某个地方是您的项目的正确答案。我们发现，一般来说，您应该期望花费大约50%的时间来创建或维护自动化测试。这听起来可能很昂贵，直到您考虑到全面的手动测试和修复泄漏给用户的bug的成本。

有些事情很难自动测试。例如GUI。即使Selenium也不会告诉您GUI是否不稳定。

当然了。看看布莱恩·马里克的测试象限。您仍然需要手动执行探索性测试和可用性测试。但这是你应该使用昂贵和有价值的人类-而不是回归测试。关键是您需要设置一个部署管道，这样您就只需要对通过了一套全面的自动化测试的构建运行昂贵的手动验证。因此，您既减少了手工测试的开销，也减少了曾经用于手工测试或生产的bug的数量(在此之前，它们的修复成本非常高)。正确的自动化测试在产品的生命周期中要便宜得多，但当然，随着时间的推移，这是一项资本支出。

如果没有庞大的固定装置，就很难测试数据库访问，即使这样也不会覆盖数据存储中奇怪的角落情况。同样，安全和其他许多事情。只有业务层代码才是有效的单元测试代码。

数据库访问通过基于端到端场景的功能性验收测试进行隐式测试。安全需要自动化和手工测试相结合--自动渗透测试和静态分析才能找到(例如)缓冲区溢出。

即使在业务层，大多数代码也没有简单的函数，其参数和返回值可以很容易地隔离用于测试目的。您可以花费大量时间构建模拟对象，这些对象可能与实际实现不相对应。

当然，如果您构建的软件和测试都很糟糕，自动化测试是非常昂贵的。我强烈建议阅读“成长中的面向对象的软件，由测试指导”一书，以了解如何正确地完成它，这样您的测试和代码就可以随着时间的推移而得到维护。

集成/功能测试是单元测试的补充，但是这些测试需要很长时间才能运行，因为它们通常涉及在每个测试上重新初始化整个系统。(如果不重新初始化，则测试环境不一致。)

我曾经工作过的产品之一有一套3500个端到端的验收测试，需要18小时才能运行。我们在一个由70个盒子组成的网格上并行运行，在45m内得到反馈。这就是为什么在单元测试几分钟后，我们把它作为第二阶段运行，这样我们就不会把我们的资源浪费在一个我们没有基本信心的构建上。

重构或任何其他更改都会破坏许多测试。你花了很多时间修理它们。如果这是一个验证有意义的规范更改的问题，这很好，但是测试经常会因为没有意义的低级实现细节而中断，而不是真正提供重要信息的东西。通常，调整的重点是重新工作测试的内部，而不是真正地检查正在测试的功能。

如果您的代码和测试封装得很好，并且是松散耦合的，那么重构不会破坏很多测试。我们在书中也描述了如何为功能测试做同样的事情。如果您的验收测试失败，这是一个迹象，表明您缺少一个或多个单元测试，因此CD的一部分涉及不断改进您的测试覆盖率，以便在交付过程中更早地发现错误，在交付过程中，测试粒度更细，修复错误更便宜。

关于bug的现场报告很难与精确的微版本代码相匹配。

如果您更频繁地进行测试和发布(CD的一部分)，那么识别导致错误的更改是相对简单的。CD的全部目的是优化反馈周期，以便在错误被签入到版本控制之后尽快识别它们--实际上，最好是在它们被签入之前(这就是为什么我们在签入之前运行构建和单元测试)。

首先，CD需要一个很大的心理调整--你必须承认，无论你做什么，有时事情都会破裂。到头来，你不能证明是负面的。

一旦克服了这些错误，您就会意识到需要工具和过程来( a)快速捕获这些错误，b)要么回滚，要么非常高效地部署更新。此外，如果你真的喝了CD鸡尾酒，你真的是交付了许多小的，有针对性的变化，很容易回滚，不应该能够引入主要的，应用程序范围的错误。甚至那些真正练习CD的人也在以一种更传统的方式来处理主要的转换。

每个系统都有风险，每个风险都有潜在的成本。如果某些微小风险的成本足够高(心脏起搏器中的软件)，这种风险可能需要几个月或几年才能在大范围的测试和质量保证中找到，那么你就不会在没有长时间的冷冻释放测试的情况下发货。如果失败的代价足够小，也许你会继续提供零测试(你的猫的Facebook页面)。