CI/CD部署管道可以帮助开发软件和组织架构来促进快速流动，从而提高业务敏捷性。
任何软件交付工作的核心都应该是部署管道，Jez Humble和Dave Farley在其开创性的 2010 年著作《 持续交付：通过构建、测试和部署自动化实现可靠的软件发布》中广为推广。
部署管道通过确保所有软件更改使用相同的“生存路径”来帮助创建快速的更改流程。但是，许多组织将部署管道以及更普遍的持续集成/持续交付 (CI/CD) 视为一组自动化脚本。
但是限制你的观点会错过 CI/CD 的显着优势，包括自主性、松散耦合的架构、有限的认知负载、减少的依赖关系以及使用管道作为可视化价值流的一种方式。
1. CD 部署管道是价值流
CD 中的一个关键概念是部署管道，因此这里是 Humble 和 Farley 的书《持续交付》中对部署管道的定义：
部署管道是您将软件从版本控制交付到用户手中的过程的自动化表现
因此，至关重要的是，部署管道不仅仅是构建或测试软件。部署管道应该是 软件进入生产的唯一途径。不应有幕后活动；所有软件和配置更改都应通过部署管道进行。
如今，大多数组织应该使用供应商提供的 CI/CD 工具，而不是在内部构建一个。自从 CD 书于 2010 年出版以来，CD 工具有了巨大的改进，因此，如果您选择了一个好的工具，它将帮助您的组织利用良好的实践，例如价值流管理(VSM)。
从价值流的角度来处理组织的各个方面确实有助于使业务决策和软件与变化的自然流保持一致，这反过来又有助于加快快速和安全地交付变化。
事实上，一个 好的部署工具将有助于强调管道是组织该部分价值流的一部分。一些部署管道工具甚至提供价值流图视图，显示端到端的变化流，包括执行和等待时间，这对于价值流分析至关重要。
2. 好的部署管道突出依赖关系
一个典型的高绩效组织将有许多单独的部署管道——一个用于可以部署的每个单独的“事物”：服务、应用程序、支持基础设施等。每个部署管道还应该有助于突出该价值流中的依赖关系。
依赖项是现代软件交付的必要组成部分，因为单个团队不能期望自己构建所有东西；团队及其软件总是依赖于其他资源。
但是，区分不同类型的依赖关系很重要。依赖关系有两个不同的关键维度：
（1）软件依赖与团队依赖
- 直接的软件依赖关系——诸如库、API 和平台之类的东西，可通过锁定文件或包规范进行跟踪
- 团队依赖——一个团队依赖另一个团队完成一些工作，然后第一个团队才能取得进展
如今，直接的软件依赖关系管理起来相对简单，尤其是当依赖关系使用版本控制方案（例如 SemVer或语义版本控制）时，该方案提供了关于适用性的明确信号。这些依赖关系通常由存储在版本控制中的版本配置文件跟踪，因此很容易通过部署管道浮出水面。
团队依赖关系目前需要更多的手动工作来跟踪，但幸运的是有一些简单的方法可以很好地工作。
（2）依赖的性质
要区分的第二个重要事项是阻塞依赖与非阻塞依赖。阻塞依赖是第一个团队必须等待另一个团队完成一些工作，然后第一个团队才能取得进展。这显然会减慢进度并损害快速流程。
与非阻塞依赖相比，第一个团队只是从第二个团队消费“作为服务”的东西。在这种情况下，第一个团队根本不需要等待第二个团队，因为依赖项（可能是代码库、服务、API、一些数据、一些内容等）已经准备好在自己的项目中使用。服务方式。
3.快速部署反馈避免上下文切换
使用良好的部署管道的一个非常有价值的结果是工程师可以快速获得有关代码更改的反馈。一旦代码更改提交给版本控制，部署管道就会被触发并运行一些快速测试。这创建了一个良性循环反馈循环，工程师通过针对测试套件证明其有效性来获得对更改的信心，鼓励他们更频繁地提交更改并鼓励更小、更易理解的更改。
实际上，如果部署管道能够实现快速构建和测试，团队可以依靠工具来提高工作流程的效率。工程师们熟悉逐步产生许多小的更改，使用部署管道工具来完成围绕测试和困难更改的繁重工作。
在其出色的 2020 年软件交付状态报告中，管道部署工具供应商 CircleCI 发现，在其衡量的 1100 万个工作流中，有一半在 4 分钟内完成，75% 的工作流在 11 分钟内完成。这些持续时间足够短，可以每天多次运行工作流，鼓励工程师专注于一系列小的更改，而不是将所有更改分批处理到更少的大块中。
不仅较小的更改更容易诊断和调试，而且由于更改更小，测试套件也可以更小；只有更改的代码和即时集成需要重新测试。这有助于避免工程团队中的“上下文切换”：他们将注意力集中在手头的任务上，而不是在（非常缓慢的）构建和测试过程运行时跳到另一个任务。
与定期切换上下文等待慢速测试套件完成的团队相比，专注于业务领域的工程团队可能会产生更少的编码错误。
保持专注也限制了认知负荷，从而进一步提高了代码质量。快速部署管道产生更好、更有界的软件。
4. CI/CD 有助于重新构建软件
实现快速的业务变更流程需要对齐的软件架构和系统架构。但是什么样的架构能够与快速的变化兼容，组织如何才能实现这一点？
Accelerate 书中的研究表明，松散耦合架构允许扩展。转向松散耦合架构的一种方法是使用来自部署管道的洞察力和信号来推动团队和软件职责边界的变化。
使用部署管道来识别不同类型的依赖项（见上文）。一旦确定了不同类型的依赖关系，就这些依赖关系进行定向对话非常重要。
目的是识别影响快速变化的依赖关系。要使用Team Topologies中的术语，请在依赖关系两侧的两个团队之间发起一段时间的协作，以发现依赖关系周围的更好边界。
诸如独立服务启发式 和领域驱动设计之类的技术 可以真正帮助发现与变化流相一致的更好边界。这反过来又有助于发展业务和软件架构，使其变得更加灵活和快速流动。
来自 CI/CD 部署管道的快速反馈有助于在低级别进行代码重构过程，也有助于保持生成的软件解耦。这是通过为可单独部署的事物（服务、应用程序、数据等）提供单独的部署管道来实现的。所有这些对于快速的变化都是必不可少的。
5. 良好的 CI/CD 会增加团队所有权
良好的 CI/CD 还有助于提高工程团队的主人翁意识。正确使用 CI/CD 时，团队会感到被授权；实施良好的部署管道可帮助团队拥有软件，从开发一直到生产，在需要时实现快速更改。
例如，如果在软件服务中发现零日漏洞，良好的部署管道使团队能够在几分钟内发布针对零日漏洞的修复程序。团队成员更好地了解零日漏洞的性质，因此可以更轻松地避免将来出现类似问题。
将 CI/CD 视为关键的组织能力
CI/CD 不仅仅是现代软件交付的工具集或次要细节。相反，CI/CD 是一种将领导者与追随者区分开来的软件交付的基本方法。通过投资于良好的 CI/CD 工具和实践，组织可以发现并维持鼓励快速变化的工作方式和软件设计。
特别是，通过聆听来自良好部署管道的信号，组织可以检测未对齐的软件和团队边界，从而开始采用团队拓扑和加速中经过验证的实践，重新调整团队和软件。