为什么单元测试不是持续交付的唯一答案

为了让持续集成和持续交付（CI/CD）成为现实，企业必须审查其内部流程，并重新思考如何处理软件交付生命周期。过去的清单和评论根本不是前进的方向。残酷的事实是，大多数企业在持续交付的道路上相当落后。对软件交付过程本身进行根本性的改变与从货架上取下一些工具这样的半个步骤是完全不一样的。

如果目标是对客户和用户做出更好的响应，软件团队需要专注于软件交付周期的更快迭代，并围绕快速响应用户反馈进行组织。虽然可能有如每月发布数量这种代理指标，但采用持续交付的最佳衡量标准是跟踪从反馈到更新软件的时间。

但是如果只是拼凑性地进行持续交付，将无法达成目标。

人们很容易从渐进的角度来看待一个组织如何从现状发展到它想驻足的位置。虽然渐进永远是正确的方法，但目前仅仅迈出第一步的企业不应自欺欺人地认为自己已经走得足够远。

不要依赖于CI/CD工具

通常，团队实行持续交付都是从一些自动化的单元测试来自动化构建过程开始。这是一个很好的开端，但是不要花太多的时间去关注单元测试覆盖的代码行数。相反，企业应该将自动化测试的注意力集中在验证核心业务流程、用户事务和用户交互上，以确保它们仍然按照预期和业务有效运行所需的方式运行。

CI/CD战略的下一个复杂层次是倾向于将计划每季度进行的大量变化打包在一起（如果企业在这一步停留也是一种错误）。实际上，CI成为了企业暂停努力的一个点。另一方面，CD则是尽可能频繁地通过管道和生产进行更改。一旦企业了解了代码更改对用户的影响以及自动实现这些更改的实现方式，它就需要鼓起勇气和付出财力来推动这些更改。

一般来说，即使是正在追求CI/CD的组织，也会存在着将变革视为风险的心态。这就不可避免地导致了这样一种信念：更改的频率应该降低。这与持续交付正好相反，它会对企业完全接受CI/CD造成阻碍。

较小的变更本质上会带来更小的风险，这意味着高生产率的软件组织应能够更快地迁移。 持续交付的概念和前景取决于企业不断部署微小变更的能力。有必要期望进行频繁的发布。

范围软件相应更改

那些单纯使用传统思维方式（CI工具、单元测试和验收测试）进行这项工作的企业仍然没有获得任何真正的好处。企业正在部署的变更范围应该作为它在软件开发生命周期中可以承受的质量问题级别的指导方针。

另一个常见的问题是，当一个组织决定将事情分解为一些小的变更，但是仍然需要开一系列的会议，变更控制委员会或者开发团队必须经过的严格的安全检查。如果您的组织的目标是通过部署较小的变更堆栈来加快进度，那么在全面重新考虑内部正式的发布周期方法之前，它不会有任何进展。

在政府机构等严格监管部门工作的组织，必须通过对其发布的产品进行修改和必要的文档化来克服这些挑战。政府部门以外的组织可以效仿他们的例子，通过对软件进行更改并描述这些更改将如何影响标记版本内的用户来克服文档需求。一个很好的例子就是美国政府的cloud.gov团队如何通过编程生成文档，比如他们的系统图。

想要在CI/CD领域取得成功的企业必须找到一种方法，将这种意见编入某种可以快速完成的自动化测试中，而不是从任何人那里获取关于软件是否应该发布的意见。否则，这条道路上的每一个手动步骤只会进一步造成交付的延迟。

组织如何解决这个问题

许多企业陷入推行CI/CD至一半的境地——他们有各种各样的工具来允许一些这样的实践，但是内部流程、检查表或管理权限下的决定阻止了组织以正常的节奏发布更新。

大量的开发人员被困在传统的软件开发周期中，他们甚至不尝试CI/CD，或者通过专注于工具、测试和自动化来接受CI/CD的人工版本。

有两种方法可以解决这个问题。一种方法是首先使用CI/CD工具，并授权各种开发团队开始在公司范围内使用公共构建服务。另一种方法是确定将从较高的开发速度、较小的变更集中获益最多的开发团队，并允许从该实践中获得的经验渗透到整个业务中。

后一种模型在大多数情况下会工作得更好，因为所涉及的人员数量被保持在最低限度，而IT组织中更关心遵从性和审计的部分将有更大的灵活性来理解单个应用程序范围内发生的事情。企业应该更愿意在单个应用程序和团队中推行试验，而不是试图推动整个公司一起进行转变。

CI/CD的目标始终是不断变化的，这是有意设计的。但是请放心，当所有能够从更快交付中获益的团队都实现了这些结果时，组织将清楚自身已经开始实现CI/CD的目标。