关于企业的 GitHub Actions
GitHub Actions 是一种持续集成和持续交付 (CI/CD) 平台，可用于自动执行生成、测试和部署管道。 借助 GitHub Actions，您的企业可以自动化、自定义和执行软件开发工作流程，如测试和部署。 有关详细信息，请参阅“About GitHub Actions for enterprises”。
在为大型企业引入 GitHub Actions 之前，首先需要规划采用情况，并决定企业将如何使用 GitHub Actions 来最好地支持您的独特需求。
管理和符合性
您应制定一个计划来管理企业对 GitHub Actions 的使用，并履行合规性义务。
确定允许开发人员使用的操作 。 首先，确定是否允许从实例外部访问操作。 如果企业中的用户需要访问来自 GitHub.com 或 GitHub Marketplace 的其他操作，有几个配置选项。 有关详细信息，请参阅“关于在企业中使用操作”。
然后，确定是否允许第三方操作 。 可以配置允许在存储库、组织和企业级别运行的操作 ，并且可以选择仅允许由 GitHub 创建的操作。 如果确实允许第三方操作 ，则可以将允许的操作限制为由经过验证的创建者创建的操作，或者某个列表中的特定操作。
有关详细信息，请参阅“管理存储库的 GitHub Actions 设置”、“禁用或限制组织的 GitHub Actions”和“在企业中为 GitHub Actions 实施策略”。
考虑将 OpenID Connect (OIDC) 与可重用的工作流相结合，在存储库、组织或企业中实施一致的部署。 为此，可以基于可重用工作流程在云角色上定义信任条件。 有关详细信息，请参阅“将 OpenID Connect 与可重用的工作流程结合使用”。
您可以在企业的审核日志中访问与 GitHub Actions 相关的活动信息。 如果业务需要保留此信息的时间超过保留审核日志数据的时间，请规划如何导出此数据并存储在 GitHub 之外。 有关详细信息，请参阅“流式处理企业审核日志”和“日志转发”。
安全性
您应该规划 GitHub Actions 的安全强化方法。
加强单个工作流程和存储库的安全性
制定计划，为在企业中使用 GitHub Actions 功能的用户强制实施良好的安全实践。 有关这些最佳方法的详细信息，请参阅“GitHub Actions 的安全强化”。
您还可以鼓励重用已评估过安全性的工作流程。 有关详细信息，请参阅“内包”。
保护对机密和部署资源的访问
您应该计划将要存储机密的位置。 我们建议将机密存储在 GitHub 中，但您可以选择将机密存储在云提供商中。
在 GitHub 中，您可以在存储库或组织级别存储机密。 存储库级别的机密可限于某些环境中的工作流程，例如生产或测试。 有关详细信息，请参阅“在 GitHub Actions 中使用机密”。
应考虑为敏感环境添加手动审批保护，以便必须先批准工作流，然后才可访问环境的机密。 有关详细信息，请参阅“管理部署环境”。
第三方操作的安全注意事项
从 GitHub 上的第三方存储库获取操作存在重大风险。 如果允许任何第三方操作，则应创建内部准则，鼓励团队遵循最佳做法，例如将操作固定到完整提交 SHA。 有关详细信息，请参阅“GitHub Actions 的安全强化”。
内包
想一想您的企业如何使用 GitHub Actions 的功能来实现内包自动化。 内包是一种将开源方法的优势融入内部软件开发周期的方法。 有关详细信息，请参阅 GitHub 资源中的内部资源简介。
若要在不公开发布操作的情况下在整个企业中共享操作，可以将操作存储在内部存储库中，然后将存储库配置为允许访问同一组织或企业中任何组织拥有的其他存储库中的 GitHub Actions 工作流。 有关详细信息，请参阅“与企业共享操作和工作流”。
借助可重用的工作流程，团队可以从另一个工作流程调用工作流程，从而避免完全重复。 可重用的工作流程通过帮助团队使用设计良好且经过测试的工作流程来促进最佳实践。 有关详细信息，请参阅“重新使用工作流”。
若要为开发人员构建新工作流提供起点，可以使用工作流模板。 这不仅为开发人员节省了时间，而且促进了整个企业的一致性和最佳实践。 有关详细信息，请参阅“为组织创建工作流模板”。
每当工作流开发人员想要使用存储在私有存储库中的操作时，他们必须将工作流配置为先克隆存储库。 要减少必须克隆的存储库的数量，请考虑将常用操作分组到单个存储库中。 有关详细信息，请参阅“关于自定义操作”。
管理资源
您应规划如何管理使用 GitHub Actions 所需的资源。
硬件要求
你可能需要升级 CPU 和内存资源，以便 你的 GitHub Enterprise Server 实例处理来自 GitHub Actions 的负载，而不会造成性能损失。 有关详细信息，请参阅“GitHub Actions for GitHub Enterprise Server 使用入门”。
运行程序
GitHub Actions 工作流程需要运行器。需要在自己的计算机上安装 GitHub Actions 自托管运行器应用程序来托管自己的运行器。 有关详细信息，请参阅“关于自托管运行程序”。
决定是要将物理机、虚拟机还是容器用于自托管运行器。 物理机将保留以前作业的残余部分，虚拟机也会保留，除非您为每个作业使用新映像或在每次作业运行后清理计算机。 如果选择容器，则应注意，运行器自动更新将关闭容器，这可能会导致工作流程失败。 您应该通过阻止自动更新或跳过命令来终止容器来为此提出解决方案。
您还必须决定在何处添加每个运行器。 您可以将自托管运行器添加到单个存储库，也可以使运行器可供整个组织或整个企业使用。 在组织或企业级别添加运行器允许共享运行器，这可能会减小运行器基础结构的大小。 您可以使用策略，通过将运行者组分配给特定存储库或组织，在组织和企业级别限制对自托管运行器的访问。 有关详细信息，请参阅“添加自托管的运行器”和“使用组管理对自托管运行程序的访问”。 还可以使用策略来阻止人员使用存储库级别的自托管运行器。 有关详细信息，请参阅“在企业中为 GitHub Actions 实施策略”。
应考虑使用自动缩放来自动增加或减少可用的自托管运行器的数量。 有关详细信息，请参阅“使用自托管运行器自动缩放”。
最后，您应该考虑对自托管运行器进行安全强化。 有关详细信息，请参阅“GitHub Actions 的安全强化”。
存储
构件允许您在工作流程完成后，分享工作流程中作业之间的数据并存储数据。 有关详细信息，请参阅“从工作流存储和共享数据”。
GitHub Actions 还有一个缓存系统，可用于缓存依赖项来加快工作流运行速度。 有关详细信息，请参阅“缓存依赖项以加快工作流程”。
必须为工作流工作缓存和其他工作流日志配置外部 Blob 存储。 确定您的企业将使用哪个受支持的存储提供商。 有关详细信息，请参阅“GitHub Actions for GitHub Enterprise Server 使用入门”。
可以使用 GitHub Actions 的策略设置来自定义工作流工作、缓存和日志保留的存储。 有关详细信息，请参阅“在企业中为 GitHub Actions 实施策略”。
跟踪用法
您应考虑制定计划来跟踪企业对 GitHub Actions 的使用，例如工作流程的运行频率、这些运行中有多少次通过和失败，以及哪些存储库正在使用哪些工作流程。
您 可以使用 web 挂钩订阅有关工作流程作业和工作流程运行的信息。 有关详细信息，请参阅“关于 web 挂钩”。
制定一个计划，说明您的企业如何将信息从这些 web 挂钩传递到数据归档系统中。 您可以考虑使用开源工具“CEDAR.GitHub.Collector”来收集和处理来自 GitHub 的 web 挂钩数据。 有关详细信息，请参阅Microsoft/CEDAR.GitHub.Collector存储库。
您还应该规划如何让您的团队从存档系统获取所需的数据。