连续交付在实践中如何工作？
连续交付听起来不错，但是我多年的软件开发经验表明，在实践中它是行不通的。 （编辑：为了明确起见，我总是有很多测试会自动运行。我的问题是关于如何使每次签入都充满信心，我知道这是CD的完整格式。替代方法不是一年周期每周两次（如果正确完成，有些人可能会认为它仍然是CD），两周或一个月的迭代；在每个迭代的末尾都包含老式的质量检查，以补充自动化测试。 无法全面覆盖测试。对于每件事，您都必须投入大量时间-时间就是金钱。这是有价值的，但是可以花费时间以其他方式为质量做出贡献。 有些事情很难自动测试。例如GUI。甚至Selenium也不会告诉您您的GUI是否不稳定。没有笨拙的固定装置，很难测试数据库访问，甚至无法覆盖数据存储中的奇怪情况。同样的安全性和许多其他事情。只有业务层代码才可以有效地进行单元测试。 即使在业务层中，大多数代码也不是简单函数，其参数和返回值可以很容易地隔离以进行测试。您可能会花费大量时间来构建模拟对象，这可能与实际实现不符。 集成/功能测试是对单元测试的补充，但是它们需要大量时间才能运行，因为它们通常涉及在每个测试中重新初始化整个系统。（如果不重新初始化，则测试环境会不一致。） 重构或任何其他更改都会破坏很多测试。您花费大量时间修复它们。如果只需要验证有意义的规范更改，那很好，但是测试常常由于无意义的低级实现细节而失败，而不是真正提供重要信息的东西。通常，调整主要集中在重新测试内部，而不是真正地检查正在测试的功能。 错误的现场报告无法轻松地与代码的精确微版本相匹配。