Skip to main content

为企业引入 GitHub Actions

您可以计划如何在企业中推出 GitHub Actions。

关于企业的 GitHub Actions

GitHub Actions 是一种持续集成和持续交付 (CI/CD) 平台,可用于自动执行生成、测试和部署管道。 借助 GitHub Actions,您的企业可以自动化、自定义和执行软件开发工作流程,如测试和部署。 有关详细信息,请参阅“关于企业的 GitHub Actions”。

在自托管运行器上运行的作业的示意图

在为大型企业引入 GitHub Actions 之前,首先需要规划采用情况,并决定企业将如何使用 GitHub Actions 来最好地支持您的独特需求。

管理和符合性

您应制定一个计划来管理企业对 GitHub Actions 的使用,并履行合规性义务。

确定允许开发人员使用的操作 和可重用工作流 。 首先确定是否允许第三方操作 和并非由 GitHub 创建的可重用工作流。 可以配置允许在存储库、组织和企业级别运行的操作 和可重用工作流 ,并且可以选择仅允许由 GitHub 创建的操作。 如果确实允许第三方操作 和可重用工作流,则可以将允许的操作限制为由经过验证的创建者创建的操作,或者某个列表中的特定操作 和可重用工作流。 有关详细信息,请参阅“管理存储库的 GitHub Actions 设置”、“为组织禁用或限制 GitHub Actions”和“在企业中强制实施 GitHub Actions”。

GitHub Actions 策略

考虑将 OpenID Connect (OIDC) 与可重用的工作流相结合,以在存储库、组织或企业中实施一致的部署。 为此,可以基于可重用工作流程在云角色上定义信任条件。 有关详细信息,请参阅“将 OpenID Connect 与可重用工作流结合使用”。

您可以在企业的审核日志中访问与 GitHub Actions 相关的活动信息。 如果业务需要保留此信息的时间超过保留审核日志数据的时间,请规划如何导出此数据并存储在 GitHub 之外。 有关详细信息,请参阅“为企业导出审核日志活动”和“为企业流式传输审核日志”。

审核日志条目

安全性

您应该规划 GitHub Actions 的安全强化方法。

加强单个工作流程和存储库的安全性

制定计划,为在企业中使用 GitHub Actions 功能的用户强制实施良好的安全实践。 有关这些做法的详细信息,请参阅“GitHub Actions 的安全强化”。

您还可以鼓励重用已评估过安全性的工作流程。 有关详细信息,请参阅“内包”。

保护对机密和部署资源的访问

您应该计划将要存储机密的位置。 我们建议将机密存储在 GitHub 中,但您可以选择将机密存储在云提供商中。

在 GitHub 中,您可以在存储库或组织级别存储机密。 存储库级别的机密可限于某些环境中的工作流程,例如生产或测试。 有关详细信息,请参阅“加密机密”。

机密列表的屏幕截图 你应该考虑为敏感环境添加手动批准保护,以便必须先批准工作流,然后才能访问环境的机密。 有关详细信息,请参阅“使用环境进行部署”。

第三方操作的安全注意事项

从 GitHub 上的第三方存储库获取操作存在重大风险。 如果允许任何第三方操作,则应创建内部准则,鼓励团队遵循最佳做法,例如将操作固定到完整提交 SHA。 有关详细信息,请参阅“使用第三方操作”。

内包

想一想您的企业如何使用 GitHub Actions 的功能来实现内包自动化。 内包是一种将开源方法的优势融入内部软件开发周期的方法。 有关详细信息,请参阅 GitHub 资源中的内部资源简介

若要在不公开发布操作的情况下在整个企业中共享操作,可以将操作存储在内部存储库中,然后将存储库配置为允许访问同一组织或企业中任何组织拥有的其他存储库中的 GitHub Actions 工作流。 有关详细信息,请参阅“与企业共享操作和工作流”。

通过使用可重用工作流,团队可以从一个工作流调用另一个工作流,避免重复。 可重用的工作流程通过帮助团队使用设计良好且经过测试的工作流程来促进最佳实践。 有关详细信息,请参阅“重用工作流”。

要为开发人员构建新工作流程提供起点,可以使用入门工作流程。 这不仅为开发人员节省了时间,而且促进了整个企业的一致性和最佳实践。 有关详细信息,请参阅“为组织创建入门工作流”。

每当工作流开发人员想要使用存储在私有存储库中的操作时,他们必须将工作流配置为先克隆存储库。 要减少必须克隆的存储库的数量,请考虑将常用操作分组到单个存储库中。 有关详细信息,请参阅“关于自定义操作”。

管理资源

您应规划如何管理使用 GitHub Actions 所需的资源。

运行程序

GitHub Actions 工作流程需要运行器。 您可以选择使用 GitHub 托管的运行器或自托管的运行器。 GitHub 托管的运行器很方便,因为它们由 GitHub 管理,后者为您处理维护和升级。 但是,如果需要运行将访问防火墙后面的资源的工作流程,或者希望更好地控制运行器计算机的资源、配置或地理位置,则可能需要考虑自托管运行器。 有关详细信息,请参阅“关于 GitHub 托管的运行器”和“关于自托管运行器”。

如果您使用的是自托管运行器,则必须决定是要使用物理机、虚拟机还是容器。 物理机将保留以前作业的残余部分,虚拟机也会保留,除非您为每个作业使用新映像或在每次作业运行后清理计算机。 如果选择容器,则应注意,运行器自动更新将关闭容器,这可能会导致工作流程失败。 您应该通过阻止自动更新或跳过命令来终止容器来为此提出解决方案。

您还必须决定在何处添加每个运行器。 您可以将自托管运行器添加到单个存储库,也可以使运行器可供整个组织或整个企业使用。 在组织或企业级别添加运行器允许共享运行器,这可能会减小运行器基础结构的大小。 您可以使用策略,通过将运行者组分配给特定存储库或组织,在组织和企业级别限制对自托管运行器的访问。 有关详细信息,请参阅“添加自托管运行器”和“使用组管理对自托管运行器的访问权限”。

应考虑使用自动缩放来自动增加或减少可用的自托管运行器的数量。 有关详细信息,请参阅“使用自托管运行器进行自动缩放。”

最后,您应该考虑对自托管运行器进行安全强化。 有关详细信息,请参阅“GitHub Actions 的安全强化”。

存储

构件允许您在工作流程完成后,分享工作流程中作业之间的数据并存储数据。 有关详细信息,请参阅“将工作流数据存储为工件”。

GitHub Actions 还有一个缓存系统,可用于缓存依赖项来加快工作流运行速度。 有关详细信息,请参阅“缓存依赖项以加快工作流”。

可以使用 GitHub Actions 的策略设置来自定义工作流工件的存储、缓存、 和日志保留。 有关详细信息,请参阅“在企业中强制实施 GitHub Actions 的策略”。

某些存储包含在订阅中,但额外的存储将影响计费。 您应该为此费用做好计划。 有关详细信息,请参阅“关于 GitHub Actions 的计费”。

跟踪用法

您应考虑制定计划来跟踪企业对 GitHub Actions 的使用,例如工作流程的运行频率、这些运行中有多少次通过和失败,以及哪些存储库正在使用哪些工作流程。

可以通过计费设置查看企业中每个组织的 GitHub Actions 的存储和数据传输使用情况的基本详细信息。 有关详细信息,请参阅“查看 GitHub Actions 使用情况”。

有关更详细的使用数据, 可以使用 web 挂钩订阅有关工作流程作业和工作流程运行的信息。 有关详细信息,请参阅“关于 Webhook”。

制定一个计划,说明您的企业如何将信息从这些 web 挂钩传递到数据归档系统中。 您可以考虑使用开源工具“CEDAR.GitHub.Collector”来收集和处理来自 GitHub 的 web 挂钩数据。 有关详细信息,请参阅Microsoft/CEDAR.GitHub.Collector存储库

您还应该规划如何让您的团队从存档系统获取所需的数据。