使用 GitHub Actions 重构和优化发布流程的实用技巧( 二 ) _GitHub

文章插图
能够在首次尝试时就成功执行 GitHub Actions 的人非常罕见。我们在重构过程的开始阶段，应该首先注重可维护性优于性能（构建速度）。发布的流水线将随项目的增长不断演化，因此可维护性至关重要。如果忽视了可维护性，可能会逐渐陷入困境，最终导致研发效率的降低。只有保障了可维护性，我们才能着手提高性能。在编译/构建场景中，合理利用各种缓存机制和优质的构建机器通常能够提升性能。
重构计划重构 YAML 文件不同于常规编程项目，它更多地是一次对配置流程的全面审查，虽然这听起来并不完全符合逻辑，却存在较高的偶发复杂性。在此过程中容易陷入难以察觉的问题，进而可能面临解决的艰难挑战。以下总结了针对正在经历此类重构的一些实用建议。

采用 Dockerfile 实现构建标准化：虽然基于 Dockerfile 的构建可能影响性能，但这样的方式增强了可维护性，统一了跨平台构建流程，确保了构建的可重复性。
统一构建命令接口：基于上述考虑，需将各类构建命令精简为单一 make 命令。将编译的复杂性限制在 yaml 文件之外，避免发布阶段隐藏过多细节，且在开发阶段的 Makefile 或脚本中展现出来。通过 Makefile ，用户可以体验到与发布阶段一致的构建过程，从而提升开发效率。
采用 AWS EC2：鉴于 GitHub Actions 目前缺乏 ARM64 VM 实例，需要采用交叉编译。使用 AWS EC2 ARM64 实例来构建 ARM64 平台的软件，以实现所有平台构建过程的标准化。
模块化解耦合：将 release.yml 拆分，使其成为一组明了的任务集合。每个位于 actions 目录下的 action.yml 文件都应保持简洁明了，以便根据相同操作自定义各种流程，提高整个过程的灵活性和效率。由于 GitHub Actions 内无组任务机制，此法是最佳方案。
简化任务执行：每个任务需专注于单一、特定的任务，增强其幂等性。这样在出错时，重试工作将更容易。此外，有助于更有效地提取顶层控制变量，允许更精确的手动触发控制。
避免在 Actions 中过度加载 Shell 命令：不要在单个 GitHub Actions 步骤中打包过多 Shell 命令，以利于维护。如果命令较多，可考虑转换为外部脚本并精简输入参数，确保脚本的独立执行和验证。
引入 Pre Job 分配 Runners：Allocate Runners 是首要任务，用于为后续工作分配 Runners 并创建全局版本标签。例如，使用 EC2 时， Allocate Runners 将通过 EC2 API（由 ec2-github-runner Action 实现）分配相应平台的 EC2 实例。未来计划引入更精确的选择算法以优化 Runner 分配成本。
实现全球统一流程：避免创建功能相似的 GitHub Actions 分支，以减少维护负担。为促进透明的开源开发，所有内部使用的构建流程已合并至主要的 GreptimeDB 存储库。代码若为开源，则软件产品和构建过程也应同样开放。
在 GitHub 存储库中合理使用变量和秘密：不应把大部分外部参数当作机密处理。一些非机密的外部参数应配置为 GitHub 变量，以便未来可以方便修改。应避免在 YAML 中硬编码将需要频繁修改的变量。

展望GreptimeDB 对发布流水线的重构只是其走向成熟旅程中的一个环节。我们正朝着构建更高质量、更强大的 CI 努力发展：