Skip to main content

Introducing GitHub Actions to your enterprise

You can plan how to roll out GitHub Actions in your enterprise.

About GitHub Actions for enterprises

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. With GitHub Actions, your enterprise can automate, customize, and execute your software development workflows like testing and deployments. For more information about the basics of GitHub Actions, see "Understanding GitHub Actions."

Diagram of jobs running on self-hosted runners

Antes de que incluyas las GitHub Actions en una empresa grande, primero necesitas planear tu adopción y tomar las decisiones de cómo tu empresa utilizará GitHub Actions para apoyar de la mejor forma a tus necesidades únicas.

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 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. Para obtener más información, consulta las secciones "Administrar los ajustes de las GitHub Actions para un repositorio", "Inhabilitar o limitar las GitHub Actions para tu organización" y "Requerir políticas para las GitHub Actions en tu empresa".

Screenshot of GitHub Actions policies

Consider combining OpenID Connect (OIDC) with reusable workflows to enforce consistent deployments across your repository, organization, or enterprise. Puedes hacerlo si defines las condiciones de confianza en los roles de la nube con base en los flujos reutilizables. For more information, see "Using OpenID Connect with reusable workflows."

You can access information about activity related to GitHub Actions in the audit logs for your enterprise. If your business needs require retaining audit logs for longer than six months, plan how you'll export and store this data outside of GitHub. Para obtener más información, consulta la sección "Transmitir las bitácoras de auditoría en tu empresa".

Entradas de la bitácora de auditoría

Seguridad

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 "Security hardening for GitHub Actions."

You can also encourage reuse of workflows that have already been evaluated for security. Para obtener más información, consulta la sección de "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. Para obtener más información, consulta la sección "Secretos cifrados".

Screenshot of a list of secrets

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 "Using environments for deployments."

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 "Using third-party 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.

Para compartir las acciones en toda tu empresa sin publicarlas públicamente, puedes almacenarlas en un repositorio interno y luego configurarlo para que acceda a los flujos de trabajo de las GitHub Actions en otros repositorios que le pertenezcan a la misma organización o a cualquier organización de la empresa. For more information, see "Sharing actions and workflows with your enterprise."

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. Para obtener más información, consulta la sección "Reutilizar flujos de trabajo".

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. Para obtener más información, consulta la sección "Crear flujos de trabajo iniciales para tu organización".

Managing resources

You should plan for how you'll manage the resources required to use GitHub Actions.

Ejecutores

GitHub Actions workflows require runners. You can choose to use GitHub-hosted runners or self-hosted runners. GitHub-hosted runners are convenient because they are managed by GitHub, who handles maintenance and upgrades for you. Sin embargo, podrías querer considerar los ejecutores auto-hospedados si necesitas ejecutar un flujo de trabajo que accederá a los recursos tras tu cortafuegos o si quieres tener más control sobre los recursos, configuración o ubicación geográfica de tus máquinas de ejecutores. Para obtener más información, consulta las secciones "Acerca de los ejecutores hospedados en GitHub" y "Acerca de los ejecutores auto-hospedados".

Si estás utilizando ejecutores auto-hospedados, tienes que decidir si quieres utilizar máquinas físicas, virtuales o contenedores. Las máquinas físicas conservarán los restos de los jobs anteriores, así como las máquinas virtuales, a menos de que utilices una imagen nueva para cada job o que limpies las máquinas después de cada ejecución de un job. 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. Para obtener más información, consulta las secciones "Agregar ejecutores auto-hospedados" y "Administrar el acceso a los ejecutores auto-hospedados utilizando grupos".

You should consider using autoscaling to automatically increase or decrease the number of available self-hosted runners. Para obtener más información, consulta la sección "Autoescalar con ejecutores auto-hospedados".

Finally, you should consider security hardening for self-hosted runners. For more information, see "Security hardening for GitHub Actions."

Almacenamiento

Los artefactos te habilitan para compartir datos entre jobs en un flujo de trabajo y para almacenar datos una vez que este flujo se complete. For more information, see "Storing workflow data as artifacts."

Screenshot of artifact

Predeterminadamente, GitHub Enterprise Cloud almacena las bitácoras de compilación y los artefactos durante 90 días y este periodo de retención se puede personalizar. Para obtener más información, consulta la sección "Límites de uso, facturación y administración".

If you want to retain logs and artifacts longer than the upper limit you can configure in GitHub Enterprise Cloud, you'll have to plan how to export and store the data.

Some storage is included in your subscription, but additional storage will affect your bill. You should plan for this cost. Para obtener más información, consulta "Acerca de la facturación para GitHub Actions".

Tracking usage

Debes considerar hacer un plan para rastrear el uso que tu empresa tiene para las GitHub Actions, tal como qué tan a menudo se ejecutan los flujos de trabajo, cuántas de estas ejecuciones están pasando y fallando y qué repositorios están utilizando cuáles flujos de trabajo.

You can see basic details of storage and data transfer usage of GitHub Actions for each organization in your enterprise via your billing settings. Para obtener más información, consulta la sección "Visualizar tu uso de 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 "About webhooks."

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.