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