2024 年，随着团队努力在日益复杂的环境中平衡速度和可靠性，软件交付的格局将继续发展。根据 Google 的 2024 年 DORA 报告 ，持续集成 （CI） 和持续交付 （CD） 巩固了它们在现代软件开发中作为基本实践的地位。通过将自动化集成到部署管道中，团队不仅可以加快交付周期，还可以提高发布的稳定性和质量。
随着应用程序复杂性的增加，CI/CD 管道已经扩展到部署之外，在自动化测试、监控和安全流程方面发挥着关键作用，从而使团队能够在快节奏的行业中保持竞争优势。这些自动化工作流程加快了软件开发生命周期，减少了错误，并最大限度地减少了对人工干预的需求。但是，管理 CI/CD 管道可能会变得复杂，尤其是在拥有多个存储库的大型组织中。
这就是可复用工作流（尤其是 GitHub Actions）可以帮助 CI/CD 优化的地方。开发人员可以使用 GitHub Actions 直接在 GitHub 存储库中自动化他们的流程。它使 CI/CD 管道创建和管理变得更加容易，使团队能够更多地专注于编码，而不是流程配置。GitHub Actions 建立可复用工作流的能力使团队能够指定一次流程并将其应用于各种存储库、项目甚至整个公司。
本文旨在为 DevOps 从业者和开发人员提供使用 GitHub Actions 创建可复用工作流的全面“作方法”。我们将介绍 DevOps 最佳实践、典型陷阱和开发模块化自适应工作流的尖端技术。我们还将研究整合 Incredibuild 等工具如何进一步提高性能，尤其是对于资源密集型或大规模构建。
当您读完本文时，您将确切地知道如何实施可复用的工作流来优化您的 CI/CD 管道并提高团队产出。
GitHub Actions 中的可复用工作流程简介
GitHub Actions 是一个自动化平台，可让开发人员自动执行测试、代码部署等任务。通过在 YAML 配置文件中定义一系列作，特定事件可以触发工作流程，例如代码推送、拉取请求或计划任务。
虽然 GitHub Actions 很有价值，但它的全部潜力在于可复用的工作流程。这些允许团队一次性定义任务并在多个项目中重复使用它们，从而减少冗余并确保一致性。
在存储库中定义工作流可确保您的 CI/CD 管道保持一致和最新。此外，其可自定义特性允许您控制工作流中的触发器和作。
可复用工作流有三个主要组件：
- 工作流程定义一系列自动化任务，并存储在仓库的 GitHub/workflows 目录中。
- 作业是在特定环境中执行的每个工作流程中的一组连续步骤。
- 作是作业中的单个任务，例如，安装依赖项、运行测试或部署应用程序。
对于设计灵活、可维护和可复用的工作流程以适应团队不断变化的需求，必须牢牢掌握这些组件。
可复用工作流程的概念和优势
可复用工作流是存储在单个位置的预定义工作流，可由存储库中的其他工作流调用。这种方法集中了逻辑，减少了重复，并确保测试、部署和 linting 等流程的一致实施。
例如，具有标准化部署流程的公司可以将其定义为可复用的工作流程，并从多个存储库中调用它。对此工作流程的任何更新都会自动应用于所有依赖存储库。
这样做的主要好处包括：
- 效率： 每次启动新项目时，您都不必重做常规步骤，例如构建项目、运行测试和部署到云，从而节省时间和金钱。
- 减少重复： 由于可复用的工作流程，不再需要跨存储库进行代码复制;这保证了所有项目的一致性并降低了出错的机会。
- 集中管理： 当您使用可复用的工作流来集中构建映像、部署代码和运行单元测试等任务时，可以更轻松地跟踪更改。
- 自动更新： 对可复用工作流程所做的任何更新/更改都会自动使使用它的所有存储库受益;无需人工干预，从而更容易维护。
创建可复用工作流的最佳实践
以下建议将帮助公司实施可复用的工作流程，使他们能够在其存储库生态系统中建立标准化、有效且易于维护的 CI/CD 管道。
模块化设计原则
模块化是可复用工作流最重要的设计概念之一。通过使用模块化方法，您可以将工作流划分为更易于管理的目标部分，以满足特定任务的需求。这对于可扩展性至关重要，因为每个模块都可以独立更改和重复使用，而不会影响整个管道。
例如，考虑将构建、测试和部署流程划分为不同的工作流，您可以在必要时将其组合起来。这有助于更改过程的任何一个步骤，而不会影响整个管道。
- 单一责任原则 ：每个工作流都应专注于特定任务，例如测试、构建或部署，以确保清晰度和可复用性。
- 灵活的组合 ：模块化工作流可以组合形成复杂的管道，从而允许独立更新各个工作流。
参数化技术
使用输入和输出参数化工作流程可增加灵活性。输入允许您根据特定使用案例定制工作流程，例如部署到不同的环境。输出允许工作流程共享数据。
例如，您可以指定是应部署到生产环境还是暂存环境，并定义可复用的部署工作流程。
例：
on: workflow_call
inputs:
environment:
description: 'Deployment environment'
required: true
default: 'staging'
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploy to ${{ inputs.environment }}
run: ./deploy.sh --env ${{ inputs.environment }}版本控制策略
为了有效地管理可复用的工作流程，必须维护版本控制。这确保了各种存储库之间的兼容性，并有助于清晰地传达更改。结构化的版本控制计划是必不可少的。
语义版本控制
这种流行的技术对可复用的工作流（例如，v1.0.0、v1.1.0、v2.0.0）进行版本控制。语义版本控制有助于传达工作流修改的类型和范围：
- 主要版本更新： 在引入重大功能更改或破坏向后兼容性时，增加主要版本号（例如，从x.x 到 v2.0.0）。
- 次要更新和补丁： 使用次要版本更新（例如，0.0 到 v1.1.0）或补丁更新（例如，v1.0.0 到 v1.0.1）进行向后兼容的更改，例如，添加功能或修复错误。
错误处理和日志记录
易于调试和监控的工作流需要实施强大的错误处理和日志记录。
每个工作流阶段都应该产生清晰易懂的日志 ，例如警告、错误和成功消息。这有助于开发人员更快地发现问题。实施强大的错误处理机制也是必不可少的，尤其是在关键情况下。这些可以防止单个错误中断整个工作流。
对于非关键步骤，即使某些步骤失败，工作流也可以使用 continue-on-error 等功能继续运行。这可确保更顺畅的执行，并最大限度地减少小问题的影响。
适当的错误处理可确保工作流程正常失败，而详尽的日志可以帮助在工作流程出现问题时及时识别问题。
创建可复用工作流的分步指南
请按照以下步骤在每个类别中作，以获得有效的可复用工作流程。
语法和结构
在 GitHub Actions 中，您首先必须定义具有适当语法和结构的 YAML 文件，以创建可复用的工作流程 。您可以将此文件存储在仓库的 .github/workflows/ 目录中。
让我们回顾一下可复用流程的基本框架。基本的 GitHub Actions 工作流程包括：
- 名字： 工作流的可选但建议的名称
- 触发器： 启动工作流程的事件，例如，自定义事件推送请求或拉取请求的
- 工作： 完成工作流所需的任务列表
- 步骤： 每个作业中使用的一组过程
您通常会以模块化方式定义可复用工作流，以便不同存储库中的其他工作流可以调用它。以下是可复用工作流文件的示例：
name: Reusable Workflow Example on: workflow_call: # Triggers the workflow when called by another workflow jobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v2 - name: Set up Node.js uses: actions/setup-node@v2 with: node-version: '14' - name: Install dependencies run: npm install - name: Run tests run: npm test
安装依赖项和执行测试的工作流由此结构定义。通过引用其位置，您可以在不同的存储库中重用此工作流。此工作流旨在由另一个工作流调用，而不是由 theon： workflow_call 触发器指示的推送或拉取请求等事件调用。
输入和输出管理
可复用工作流的一个主要优势是它们能够接受输入并返回输出。这使它们变得动态且易于适应各种用例。
定义输入
Inputs 是可在调用可复用工作流时传递到可复用工作流的值。您可以定义必需和可选输入，每个输入都带有描述和默认值（如果需要）。
例：
on:
workflow_call:
inputs:
environment:
description: 'The environment to deploy to'
required: true
default: 'staging'此处，输入指定要部署到的环境。此输入是必需的，如果未传递，则使用 staging 的默认值。
捕获输出
可复用工作流可以返回输出，然后调用它们的工作流可以使用这些输出。当您希望将数据从一个工作流传递到另一个工作流时，输出非常有用。
例：
jobs: build: runs-on: ubuntu-latest steps: - name: Run tests run: ./run_tests.sh id: test_results outputs: result: ${{ steps.test_results.outputs.result }}
在此示例中，构建作业运行测试并输出结果，然后其他工作流可以访问该结果。
调用可复用工作流
要调用可复用工作流程，您需要按路径以及存储库和版本（分支、标签或提交）引用工作流程文件。
例：
on: push: branches: - main jobs: deploy: uses: my-org/my-repo/.github/workflows/reusable_workflow.yml@v1.0 with: environment: 'production'
在上面，部署作业引用了存储在 my-org/my-repo 存储库中的可复用工作流程。它将输入环境作为 production 传递。
通过以这种方式调用可复用工作流，团队可以集中其 CI/CD 逻辑，无需在每个存储库中重新定义常见任务。
先进的技术
以下技术用于优化复杂的工作流程并采用最佳实践，例如正确管理敏感信息。
嵌套的可复用工作流
复杂流程通常需要多个工作流。在这些情况下，嵌套的可复用工作流是一个不错的选择，因为它们支持从其他工作流中调用工作流。它们本质上允许您将复杂的任务划分为可以更轻松地管理的较小部分。
例如，您可以有一个用于测试的可复用工作流和另一个用于构建应用程序的工作流，其中测试工作流由构建工作流调用。
嵌套可复用工作流的示例：
on: workflow_call: jobs: build: uses: my-org/my-repo/.github/workflows/build.yml@v1.0 test: uses: my-org/my-repo/.github/workflows/test.yml@v1.0
在这种情况下，构建作业调用 build.yml 工作流，而测试作业调用 test.yml 工作流。通过以这种模块化、嵌套的方式构建工作流，它们将易于更新、扩展和维护。
条件执行
在某些工作流程中，您可能希望仅在特定条件下运行特定作业或步骤。GitHub Actions 提供了多种基于预定义变量、输入或输出处理条件执行的方法。
条件执行示例：
jobs: test: runs-on: ubuntu-latest if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }} steps: - name: Checkout code uses: actions/checkout@v2 - name: Run tests run: npm test
在这种情况下，仅当触发工作流的事件是推送到主分支时，测试作业才会运行。您可以根据事件类型、分支名称甚至其他作业的输出使用条件来决定是否执行工作流的某些部分。
密钥管理
安全地处理敏感信息在任何 CI/CD 管道中都至关重要。GitHub Actions 支持使用机密，即可在工作流程中使用的加密环境变量，而无需在存储库中公开它们。
要在工作流程中引用密钥，请使用 ${{ secrets.<secret_name> }} 语法：
jobs: deploy: runs-on: ubuntu-latest steps: - name: Deploy to production run: ./deploy.sh env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
在此示例中，AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY 作为机密存储在 GitHub 中，确保它们永远不会暴露在工作流程文件中。这样可以确保敏感信息的安全，保证它仅供需要它的工作流程使用。
与其他 DevOps 工具集成
尽管 GitHub Actions 非常适合自动化，但当与其他 DevOps 工具结合使用时，其功能会得到进一步增强。团队可以通过与 CI/CD 监控和通知解决方案集成来提高可观测性、自动化反馈循环并简化工作流程。考虑将 GitHub Actions 与以下内容集成：
- Terraform：自动配置基础设施。
- Docker：构建和部署容器作为 CI/CD 管道的一部分。
- Sentry：监控应用程序中的错误和异常。
- Slack 或 Microsoft Teams：发送工作流事件（如构建成功或失败）的通知。
- JIRA： 根据工作流状态自动创建问题或更新工单。
包含这些工具将使您的工作流成为更大的自动化 DevOps 生态系统的一部分。
真实示例和用例
让我们看一下可复用工作流特别有益的几个场景。
用例 1：多存储库测试
在大型组织中，多个存储库可能具有类似的测试需求。您可以创建可复用的测试工作流程并在每个存储库中引用它，而不是在每个存储库中维护单独的测试工作流程：
on: push: branches: - main jobs: test: uses: my-org/my-repo/.github/workflows/test.yml@v1.0 This approach reduces redundancy, makes updates easier, and ensures consistency across repositories.
用例 2：标准化部署管道
另一个示例是使用可复用的工作流来标准化不同环境中的部署。例如，相同的部署过程可用于暂存和生产，输入确定目标环境：
jobs: deploy: uses: my-org/my-repo/.github/workflows/deploy.yml@v1.0 with: environment: 'production'
这种标准化有助于减少错误，并保证每个环境都使用相同的流程进行部署。
维护和更新可复用工作流的最佳实践
工作流重用可以节省时间和金钱，但需要仔细管理和维护。以下是一些基本策略：
- 定期审查和更新工作流程 ：随着您的技术堆栈发生变化或出现新要求，需要更新工作流程;版本控制允许您管理更新，而不会影响依赖先前迭代的存储库。
- 模块化工作流程 ：工作流程应模块化，以保持其重点、小尺寸和易于更新;这降低了进行修改时出错的可能性。
- 自动化工作流程测试 ：定期测试可复用的工作流程，以了解它们继续按预期运行;创建特定存储库以测试可复用工作流程，然后再在多个存储库中实施它们。
- 维护信息同步文档： 为可复用的工作流程提供清晰的文档和更改日志对于开发人员了解它们的工作原理和所需的输入/输出至关重要。
集成 Incredibuild 以实现性能优化
Incredibuild 通过分布式计算加速计算任务来增强 GitHub Actions。这对于消耗大量资源的项目（如企业软件或游戏开发）来说是理想的选择。通过集成 Incredibuild，团队可以显著提高性能，确保在不影响质量的情况下实现更快的 CI/CD 管道。
CI/CD 自动化的结论和未来趋势
GitHub Actions 中的可复用工作流通过提高效率、可维护性和可扩展性来彻底改变 CI/CD 管道。通过遵循模块化设计、参数化和版本控制等最佳实践，团队可以构建适应其不断变化的需求的工作流。
展望未来，集成 Incredibuild 等尖端技术并探索先进的自动化技术将是 DevOps 团队在不断发展的软件开发领域中保持竞争力的关键。本文既可以作为伴侣，也可以作为参考，为那些喜欢按照自己的节奏探索的人提供关键的收获和细节。我们将通过一个真实示例，并提供可行的策略来减少缓存未命中并提高整体效率。无论您是构建缓存的新手，还是希望改进当前的工作流程，本指南都能满足您的需求。
