在 GitHub Actions 中管理和利用可重用组件

9 分钟

在上一单元中，你了解了如何在企业和组织级别构建 GitHub Actions 策略和模板。在本单元中，你将深入了解如何在多个存储库中管理和维护可重用组件（如工作流、自定义作和自动化脚本）。

在 GitHub Actions 中管理和利用可重用组件

GitHub Actions 中的可重用组件是指跨多个存储库使用的 工作流、作和脚本 ，以简化开发和自动化。它们有助于标准化 CI/CD 管道，提高可维护性，并减少冗余配置工作。

可重用组件的类型

可重用工作流
- 被定义一次，并在多个存储库中被引用。
- 示例：企业中所有项目的标准生成和部署工作流。
自定义 GitHub Actions
- 为重复的任务创建（例如设置依赖项、运行安全检查）。
- 示例：用于强制实施代码 linting 的公司范围的操作。
共享脚本
- 用于自动化任务的工作流中使用的 Bash、PowerShell 或 Python 脚本。
- 示例：用于为代码存储库生成符合性报告的脚本。

为可重用组件创建集中式存储库

用于可重用工作流和操作的结构化存储库可确保轻松访问和标准化。请考虑创建以下内容：

存储库类型	目的	命名约定示例
Actions 存储库	存储跨项目使用的自定义 GitHub Actions。	`org-actions-repo`
工作流存储库	包含用于 CI/CD 自动化的可重用工作流。	`org-reusable-workflows`
脚本存储库	维护可重用的自动化脚本。	`org-scripts-library`

动作库的示例结构：

org-actions-repo/
│── setup-node/         # Custom GitHub Action for Node.js setup
│   ├── action.yml
│   ├── Dockerfile
│   ├── README.md
│── security-scan/      # Custom GitHub Action for security scanning
│   ├── action.yml
│   ├── scan.py
│   ├── README.md
│── LICENSE
│── README.md

文件和文件夹的命名约定

若要确保可维护性和易用性，请遵循 一致的命名约定。

存储库命名

对存储库使用 描述性和一致性 名称：
- org-actions-repo
- org-reusable-workflows
- my-random-actions
为了清楚起见，首选 连字符名称 ：
- ci-pipeline
- CIPipeline

工作流和操作命名

遵循结构化格式：
- [scope]-[purpose]
- 例子：
  - ci-test.yml → 用于持续集成测试
  - deploy-app.yml →部署工作流
  - build-container.yml →生成 Docker 容器

使用 版本控制目录 实现长期可维护性：

reusable-workflows/
├── v1/
│   ├── ci-test.yml
│   ├── deploy-app.yml
├── v2/
│   ├── ci-test.yml
│   ├── deploy-app.yml

操作命名

对操作名称使用 PascalCase 或 kebab-case：
- Run-Linter
- run-linter
- Runlinter

在 action.yml 中提供明确的说明：

name: "Run Linter"
description: "A reusable action to run lint checks on JavaScript projects."

计划持续维护可重用组件

1. 版本控制与依赖项管理

使用 GitHub 版本标记版本 (v1.0.0，v2.0.0)。
避免在工作流中使用 latest 标记 来防止意外的重大更改。
使用语义版本控制：
- 修补程序更新：v1.0.1 → 修复漏洞、小幅更新。
- 次要更新：v1.1.0 →新功能，向后兼容。
- 主要更新：v2.0.0 → 重大变更。

在工作流中引用版本

不使用：

uses: org-actions-repo/setup-node@latest

使用稳定版本：

uses: org-actions-repo/setup-node@v1.2.0

2. 自动执行更新和维护

实现 GitHub Action，以在合并之前自动测试工作流和操作。
使用 Dependabot 检测可重用作中的过时依赖项。

3. 记录并提供使用指南

每个存储库应包括：
- README.md 说明：
  - 组件的用途。
  - 如何使用它。
  - 示例工作流。
- CHANGELOG.md 跟踪更新。
- CONTRIBUTING.md 概述修改的最佳做法。

4. 安全性和访问控制

限制对操作存储库的写入访问权限。
需要代码评审和 GitHub CODEOWNERS 来管理更改。
使用 GitHub 机密扫描 防止工作流中的硬编码机密。

5.监视和弃用策略

设置 GitHub 问题和讨论 以获取反馈。
弃用计划：
- 在删除旧版本之前通知用户。
- 提供主要更改的迁移指南。

如何为企业分配任务

GitHub Actions 可实现 工作流自动化，例如测试、部署和安全扫描。在企业中，分发作可以有效地允许多个团队 重复使用常见的自动化任务 ，而不是重新创建相同的工作流。

在企业中分发 GitHub Actions 有三种主要方法：

在 GitHub 市场中发布操作（用于公共分发）。
在 Organization-Owned 存储库中托管操作（用于内部企业分发）。
使用 GitHub Packages 分发容器化操作（以实现更受控的分发）。

在企业中分发行动的最佳实践

最佳做法	建议
标准化	使用清晰的文档维护单个存储库，以便执行可重用操作。
版本控制	使用语义化版本控制（`v1.0.0`，`v2.0.0`），并避免使用`latest`以保持稳定性。
安全评审	在发布动作之前，需要进行代码评审和自动安全扫描。
存取控制	限制谁可以修改和使用内部操作，通过存储库设置。
常规更新	维护变更日志并通知用户更新，以防止重大更改。

分布方法比较

方法	用例	存取控制	安全注意事项
GitHub 市场	公共分发	无限制	可公开访问，必须安全
Organization-Owned 存储库	内部企业使用	团队及存储库角色	需要严格的权限控制
GitHub 软件包（容器化操作）	安全内部使用	需要身份验证	必须保护映像免受篡改

选择正确的方法取决于 业务需求、安全需求和可伸缩性注意事项。企业应实施 结构化方法来 分发 GitHub Actions，确保其 DevOps 工作流 的效率、安全性和合规性 。

在 GitHub Actions 中管理和利用可重用组件