共计 1855 个字符，预计需要花费 5 分钟才能阅读完成。
为了让继续集成和继续交付（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 的指标。
* 该文为翻译文章，原文链接：https://thenewstack.io/how-to-avoid-pit-stops-on-the-road-to-…
