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 and reusable workflows your developers will be allowed to use. First, decide whether you'll allow third-party actions and reusable workflows that were not created by GitHub. You can configure the actions and reusable workflows 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 and reusable workflows, you can limit allowed actions to those created by verified creators or a list of specific actions and reusable workflows.
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 "엔터프라이즈에 대한 감사 로그 스트리밍."
You can practice the principle of least privilege by administering custom organization roles for access to settings in your GitHub Actions CI/CD pipeline. For more information about custom organization roles, see "사용자 지정 조직 역할 소개."
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에 대한 보안 강화."
Private networking with GitHub-hosted runners
Azure VNET에서 GitHub 호스트형 실행기를 사용할 수 있습니다. 이렇게 하면 실행기 네트워킹 정책의 모든 권한을 제공하면서 CI/CD의 GitHub관리 인프라를 사용할 수 있습니다. Azure VNET에 대한 자세한 내용은 Azure 문서의 Azure Virtual Network란?을 참조하세요. For more information, see "About Azure private networking for GitHub-hosted runners in your enterprise."
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.
Runners
GitHub Actions workflows require runners. You can choose to use GitHub-hosted runners or self-hosted runners. GitHub manages maintenance and upgrades for GitHub-hosted runners. For more information, see "GitHub 호스팅 실행기 사용."
To manage your own resources, configuration, or geographic location of your runner machines, use self hosted runners. For more information, see "자체 호스트형 실행기 정보."
If you want more control over the networking policies for your runners, use self-hosted runners or private networking options for GitHub-hosted runners. For more information about private networking options, see "GitHub 호스팅 실행기를 사용하는 프라이빗 네트워킹 정보."
If you are using self-hosted runners, you have to decide whether you want to use physical machines, virtual machines, or containers. 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
Artifacts를 사용하면 워크플로의 작업 간에 데이터를 공유하고 워크플로가 완료되면 데이터를 저장할 수 있습니다. 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 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."
Some storage is included in your subscription, but additional storage will affect your bill. You should plan for this cost. For more information, see "GitHub Actions 요금 청구 정보."
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 see basic details of storage and data transfer usage of GitHub Actions for each organization in your enterprise via your billing settings. For more information, see "Viewing your GitHub Actions usage(GitHub Actions 사용량 보기)."
For more detailed usage data, you can use webhooks to subscribe to information about workflow jobs and workflow runs. For more information, see "웹후크 정보."
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.