About GitHub Actions for enterprises
GitHub Actions 是一种持续集成和持续交付 (CI/CD) 平台，可用于自动执行生成、测试和部署管道。 With GitHub Actions, your enterprise can automate, customize, and execute your software development workflows like testing and deployments. For more information, see "About GitHub Actions for enterprises."
Before you introduce GitHub Actions to a large enterprise, you first need to plan your adoption and make decisions about how your enterprise will use GitHub Actions to best support your unique needs.
Governance and compliance
You should create a plan to govern your enterprise's use of GitHub Actions and meet your compliance obligations.
Determine which actions your developers will be allowed to use. First, decide whether you'll enable access to actions from outside your instance. 如果企业中的用户需要访问来自 GitHub.com 或 GitHub Marketplace 的其他操作，有几个配置选项。 For more information, see "About using actions in your enterprise."
Then, decide whether you'll allow third-party actions that were not created by GitHub. You can configure the actions that are allowed to run at the repository, organization, and enterprise levels and can choose to only allow actions that are created by GitHub. If you do allow third-party actions, you can limit allowed actions to those created by verified creators or a list of specific actions.
For more information, see "管理存储库的 GitHub Actions 设置", "禁用或限制组织的 GitHub Actions", and "Enforcing policies for GitHub Actions in your enterprise."
Consider combining OpenID Connect (OIDC) with reusable workflows to enforce consistent deployments across your repository, organization, or enterprise. You can do this by defining trust conditions on cloud roles based on reusable workflows. For more information, see "将 OpenID Connect 与可重用的工作流程结合使用."
You can access information about activity related to GitHub Actions in the audit logs for your enterprise. If your business needs require retaining this information longer than audit log data is retained, plan how you'll export and store this data outside of GitHub. For more information, see "流式处理企业审核日志" and "日志转发."
Security
You should plan your approach to security hardening for GitHub Actions.
Security hardening individual workflows and repositories
Make a plan to enforce good security practices for people using GitHub Actions features within your enterprise. For more information about these practices, see "GitHub Actions 的安全强化."
You can also encourage reuse of workflows that have already been evaluated for security. For more information, see "Innersourcing."
Securing access to secrets and deployment resources
You should plan where you'll store your secrets. We recommend storing secrets in GitHub, but you might choose to store secrets in a cloud provider.
In GitHub, you can store secrets at the repository or organization level. Secrets at the repository level can be limited to workflows in certain environments, such as production or testing. For more information, see "在 GitHub Actions 中使用机密."
You should consider adding manual approval protection for sensitive environments, so that workflows must be approved before getting access to the environments' secrets. For more information, see "使用环境进行部署."
Security considerations for third-party actions
There is significant risk in sourcing actions from third-party repositories on GitHub. If you do allow any third-party actions, you should create internal guidelines that encourage your team to follow best practices, such as pinning actions to the full commit SHA. For more information, see "GitHub Actions 的安全强化."
Innersourcing
Think about how your enterprise can use features of GitHub Actions to innersource automation. Innersourcing is a way to incorporate the benefits of open source methodologies into your internal software development cycle. For more information, see An introduction to innersource in GitHub Resources.
若要在不公开发布操作的情况下在整个企业中共享操作，可以将操作存储在内部存储库中，然后将存储库配置为允许访问同一组织或企业中任何组织拥有的其他存储库中的 GitHub Actions 工作流。 有关详细信息，请参阅“与企业共享操作和工作流”。
With reusable workflows, your team can call one workflow from another workflow, avoiding exact duplication. Reusable workflows promote best practice by helping your team use workflows that are well designed and have already been tested. For more information, see "重新使用工作流."
To provide a starting place for developers building new workflows, you can use starter workflows. This not only saves time for your developers, but promotes consistency and best practice across your enterprise. For more information, see "为组织创建入门工作流程."
Whenever your workflow developers want to use an action that's stored in a private repository, they must configure the workflow to clone the repository first. To reduce the number of repositories that must be cloned, consider grouping commonly used actions in a single repository. For more information, see "关于自定义操作."
Managing resources
You should plan for how you'll manage the resources required to use GitHub Actions.
Hardware requirements
You may need to upgrade the CPU and memory resources for 你的 GitHub Enterprise Server 实例 to handle the load from GitHub Actions without causing performance loss. For more information, see "Getting started with GitHub Actions for GitHub Enterprise Server."
Runners
GitHub Actions workflows require runners. You will need to host your own runners by installing the GitHub Actions self-hosted runner application on your own machines. For more information, see "关于自托管运行程序."
Decide whether you want to use physical machines, virtual machines, or containers for your self-hosted runners. Physical machines will retain remnants of previous jobs, and so will virtual machines unless you use a fresh image for each job or clean up the machines after each job run. If you choose containers, you should be aware that the runner auto-updating will shut down the container, which can cause workflows to fail. You should come up with a solution for this by preventing auto-updates or skipping the command to kill the container.
You also have to decide where to add each runner. You can add a self-hosted runner to an individual repository, or you can make the runner available to an entire organization or your entire enterprise. Adding runners at the organization or enterprise levels allows sharing of runners, which might reduce the size of your runner infrastructure. You can use policies to limit access to self-hosted runners at the organization and enterprise levels by assigning groups of runners to specific repositories or organizations. For more information, see "添加自托管的运行器" and "使用组管理对自托管运行程序的访问." You can also use policies to prevent people using repository-level self-hosted runners. For more information, see "Enforcing policies for GitHub Actions in your enterprise."
You should consider using autoscaling to automatically increase or decrease the number of available self-hosted runners. For more information, see "使用自托管运行器自动缩放."
Finally, you should consider security hardening for self-hosted runners. For more information, see "GitHub Actions 的安全强化."
Storage
构件允许您在工作流程完成后，分享工作流程中作业之间的数据并存储数据。 For more information, see "将工作流程数据存储为构件."
GitHub Actions also has a caching system that you can use to cache dependencies to speed up workflow runs. For more information, see "缓存依赖项以加快工作流程."
You must configure external blob storage for workflow artifacts, caches, and other workflow logs. Decide which supported storage provider your enterprise will use. For more information, see "Getting started with GitHub Actions for GitHub Enterprise Server."
You can use policy settings for GitHub Actions to customize the storage of workflow artifacts, caches, and log retention. For more information, see "Enforcing policies for GitHub Actions in your enterprise."
Tracking usage
You should consider making a plan to track your enterprise's usage of GitHub Actions, such as how often workflows are running, how many of those runs are passing and failing, and which repositories are using which workflows.
You can use webhooks to subscribe to information about workflow jobs and workflow runs. For more information, see "关于 web 挂钩."
Make a plan for how your enterprise can pass the information from these webhooks into a data archiving system. You can consider using "CEDAR.GitHub.Collector", an open source tool that collects and processes webhook data from GitHub. For more information, see the Microsoft/CEDAR.GitHub.Collector repository.
You should also plan how you'll enable your teams to get the data they need from your archiving system.