CI/CD管道的优化与管理

### CI/CD 管道的优化与管理 在 CI/CD（持续集成/持续交付）流程中，管道的顺畅运行对于软件开发和部署至关重要。然而，资源限制、可管理性、操作、质量保证和指标等方面的问题可能会影响管道的性能和效率。本文将详细探讨这些方面的要求和最佳实践。 #### 1. 资源限制 资源限制会对管道产生负面影响，导致排队、执行时间过长，甚至整个 ALM 平台或集成服务器完全停止。常见的原因包括计算（CPU）资源不足、磁盘空间不足和网络拥塞。为了避免这些问题，在设计和开发管道时，就应该对应用程序的数量、管道的数量以及预期的管道运行次数有一定的了解。以下是一些优化建议： - **并行化代码分析扫描**：如果代码分析包含多种扫描类型，按顺序执行所有任务可能需要很长时间。可以将这些任务并行化，因为不同类型的代码分析扫描之间没有关联。 - **并行化测试**：测试运行也容易耗时较长。可以并行执行多种类型的测试，或者将同一类型的测试分组并行执行。还可以根据历史计时数据对测试进行分组，使每个组的测试时间大致相同。 - **卸载构建、源代码分析和测试执行**：不建议在同一服务器上运行构建、源代码分析（SCA）任务和执行测试，因为服务器可能会达到其极限，导致管道运行排队。可以将构建任务卸载（例如，向 Jenkins 主节点添加节点），在专用服务器上运行 SCA 任务，并将测试运行从构建服务器卸载到测试服务器。 #### 2. 可管理性 可管理性意味着以一种易于应用更改且代码不冗余、不分散的方式组织管道。以下是一些可管理性要求： - **保持管道代码可管理**：管道开发可能会变得复杂，使用技术标准、命名约定和开发指南是保持管道开发可管理的唯一方法。 - **一次构建，随处运行**：应用程序工件必须始终使用管道进行一次构建，并在所有目标环境（包括测试和生产环境）中安装相同的工件。特定于环境的属性作为应用程序部署的一部分进行部署。 - **将二进制文件（工件和依赖项）存储在工件存储库中**：除了将代码（包括管道代码）存储在源代码管理系统（SCM）中，还应将所有工件和依赖项存储在不可变的二进制存储库中。 - **不直接从 Internet 位置检索库或外部资源**：应将库本地存储（本地或在云账户中），管道使用本地存储库，以避免安全问题和对外部 Internet 位置可用性的依赖。 - **将管道代码视为软件**：管道代码、自动化和编排代码、脚本和管道设计都应存储在源代码管理系统（如 Git）中，以便进行版本控制。 - **修复变量**：在特定情况下，可能需要在 CI/CD 管道中使用常量变量，或防止它们在管道运行开始或期间被更改，以确保管道的可靠性和一致性。 - **使用一个部署脚本用于所有环境**：不仅要在所有目标环境中使用相同的工件，核心部署脚本也必须相同，不同目标环境之间的差异通过参数化来处理。 - **使用一个配置脚本用于所有环境**：用于创建目标环境的基础结构代码对于所有目标环境都应相同，不同目标环境之间的差异通过参数化来处理。 - **使用有意义的发布版本控制方案**：版本控制方案应满足可沟通、可生成和有顺序的标准。常见的版本控制方案包括语义版本控制（major.minor.patch）和基于日期的版本控制（yyyyMMdd.<seq>）。 - **使用适当的工具编排管道阶段和任务**：ALM 平台或集成服务器是执行特定任务的编排工具，但在某些情况下可能需要特定的工具。确保工具的安装位置合适，例如部署工具可以安装在 ALM 平台/集成服务器本身、目标环境或单独的服务器上。 以下是一个简单的表格总结可管理性要求： | 要求 | 描述 | | --- | --- | | 保持管道代码可管理 | 使用标准和指南 | | 一次构建，随处运行 | 相同工件用于所有环境 | | 存储二进制文件 | 在工件存储库中 | | 不直接从 Internet 检索资源 | 使用本地存储库 | | 将管道代码视为软件 | 存储在 SCM 中 | | 修复变量 | 确保可靠性和一致性 | | 使用一个部署脚本 | 用于所有环境 | | 使用一个配置