Administrar entornos para la implementación

Acerca de los ambientes

Los entornos se usan para describir un destino de implementación general como production, staging o development. Cuando se despliega un flujo de trabajo de GitHub Actions en un ambiente, dicho ambiente se desplegará en la página principal del repositorio. Para obtener más información sobre cómo ver las implementaciones en los entornos, consulta Visualización del historial de implementación.

Puedes configurr ambientes con reglas de protección y secretos. Cuando un job de un flujo de trabajo referencia un ambiente, el job no comenzará hasta que todas las reglas de protección del ambiente pasen. Un trabajo tampoco puede acceder a los secretos que se definen en un ambiente hasta que se superen todas las reglas de protección de implementación.

Opcionalmente, puedes omitir las reglas de protección de un entorno y forzar que todos los trabajos pendientes hagan referencia al entorno para continuar. Para más información, consulta Revisar los despliegues.

Reglas de protección de implementación

Las reglas de protección de implementación requieren que se superen condiciones específicas antes de que un trabajo que hace referencia al entorno pueda continuar. Puedes usar reglas de protección de implementación para requerir una aprobación manual, retrasar un trabajo o restringir el entorno a determinadas ramas. También puedes crear e implementar reglas de protección personalizadas con tecnología de GitHub Apps para usar sistemas de terceros para controlar las implementaciones que hacen referencia a los entornos configurados en GitHub.

Los sistemas de terceros pueden ser sistemas de observabilidad, sistemas de administración de cambios, sistemas de calidad del código u otras configuraciones manuales que utilice para evaluar la preparación antes de que las implementaciones se implementen de forma segura en los entornos.

Revisores requeridos

Utiliza los revisores requeridos para requerir que una persona o equipo específicos aprueben los jobs del flujo de trabajo que referencian el ambiente. Puedes listar hasta seis usuarios o equipos como revisores. Los revisores deben tener acceso de lectura en el repositorio como mínimo. Solo uno de los revisores requeridos necesita aprobar el job para que éste pueda proceder.

También tienes la opción de evitar revisiones automáticas de implementaciones en ambientes protegidos. Si habilitas esta configuración, los usuarios que inician una implementación no pueden aprobar el trabajo de implementación, incluso si son un revisor necesario. Esto garantiza que más de una persona revise siempre las implementaciones en ambientes protegidos.

Para obtener más información sobre cómo revisar los trabajos que hacen referencia a un entorno con los revisores necesarios, consulta Revisar los despliegues.

Temporizador de espera

Utiliza un temporizador de espera para retrasar un job durante una cantidad de tiempo específica después de que el job se active inicialmente. El tiempo (en minutos) debe ser un número entero entre 1 y 43.200 (30 días).

Ramas de implementación y etiquetas

Use ramas de implementación y etiquetas para restringir qué ramas y etiquetas pueden implementarse en el entorno. A continuación, se muestran las opciones para las ramas de implementación y tags para un entorno:

• Sin restricción: no hay ninguna restricción en la rama o etiqueta que se puede implementar en el entorno.

• **Solo ramas protegidas **: solo las ramas con reglas de protección de rama habilitadas pueden implementarse en el entorno. Si no se han definido reglas de protección de ramas en ninguna de las ramas del repositorio, entonces todas las ramas podrán hacer despliegues. Para obtener más información sobre las reglas de protección de ramas, consulta Acerca de las ramas protegidas.

  Note

  El flujo de trabajo de implementación se ejecuta desencadenado por etiquetas con el mismo nombre que una rama protegida y bifurcaciones con ramas que coinciden con el nombre de la rama protegida no pueden implementarse en el entorno.

• Ramas seleccionadas y etiquetas: solo las ramas y etiquetas que se correspondan con sus patrones de nombre especificados pueden implementarse en el entorno.

  Si especifica releases/* como una rama de implementación o regla de etiqueta, solo una rama o etiqueta cuyo nombre comienza por releases/ puede implementarse en el entorno. (Los caracteres comodín no coincidirán con /. Para buscar coincidencias con ramas or etiqutas que comienzan por release/ y contienen una barra diagonal única adicional, use release/*/*). Si agrega main como una regla de rama, una rama denominada main también se podrá implementar en el entorno. Para obtener más información sobre las opciones de sintaxis para las ramas de implementación, consulte la documentación File.fnmatch Ruby .

  Note

  Los patrones de nombre deben configurarse para ramas o etiquetas de forma individual.

Permitir que los administradores omitan las reglas de protección configuradas

De manera predeterminada, los administradores pueden omitir las reglas de protección y forzar implementaciones en entornos específicos. Para más información, consulta Revisar los despliegues.

Como alternativa, puede configurar los entornos para no permitir omitir las reglas de protección de todas las implementaciones en el entorno.

Reglas de protección de implementación personalizadas

Puede habilitar sus propias reglas de protección personalizadas para controlar las implementaciones con servicios de terceros. Por ejemplo, puede usar servicios como Datadog, Honeycomb y ServiceNow para proporcionar aprobaciones automatizadas para implementaciones en GitHub. Para obtener más información, consulta Creación de reglas de protección de implementación personalizadas.

Una vez creadas e instaladas las reglas de protección de implementación personalizadas en un repositorio, puede habilitar la regla de protección de implementación personalizada para cualquier entorno del repositorio. Para obtener más información sobre cómo configurar y habilitar las reglas de protección de implementación personalizadas, consulta Configuración de reglas de protección de implementación personalizadas.

Secretos de entorno

Los secretos que se almacenan en un ambiente sólo se encuentran disponibles para los jobs de flujo de trabajo que referencien el ambiente. Si el ambiente requiere aprobación, un job no puede acceder a secretos de ambiente hasta que uno de los revisores requeridos lo apruebe. Para obtener más información sobre secretos, consulta Uso de secretos en Acciones de GitHub.

Variables de entorno

Las variables que se almacenan en un entorno solo se encuentran disponibles para los trabajos de flujo de trabajo que hacen referencia a dicho entrono. Estas variables solo son accesibles mediante el contexto vars. Para más información, consulta Almacenamiento de información en variables.

Creación de un entorno

Para configurar un entorno en un repositorio de cuenta personal, debes ser el propietario del repositorio. Para configurar un entorno en el repositorio de una organización, debe tener acceso admin.

1. En GitHub, navegue hasta la página principal del repositorio.

2. En el nombre del repositorio, haz clic en Configuración. Si no puedes ver la pestaña "Configuración", selecciona el menú desplegable y, a continuación, haz clic en Configuración.

   

3. En la barra lateral de la izquierda, haz clic en Entornos.

4. Haga clic en New environment (Nuevo entorno).

5. Escriba un nombre para el entorno y, después, haga clic en Configurar entorno. Los nombres de ambiente no distinguen entre mayúsculas y minúsculas. Un nombre de ambiente no deberá exceder los 255 caracteres y deberá ser único dentro del repositorio.

6. Opcionalmente, personas o equipos específicos deben aprobar los jobs de flujo de trabajo que utilicen este ambiente. Para más información, consulta Revisores obligatorios.

   1. Seleccione Revisores obligatorios.
   2. Ingresa hasta 6 personas o equipos. Solo uno de los revisores requeridos necesita aprobar el job para que éste pueda proceder.
   3. Opcionalmente, para evitar que los usuarios aprueben las ejecuciones de flujos de trabajo que desencadenaron, selecciona Impedir revisión automática.
   4. Haga clic en Save protection rules.

7. Opcionalmente, especifica la cantidad de tiempo a esperar antes de permitir los jobs de flujo de trabajo que utilizan este ambiente para proceder. Para más información, consulta Temporizador de espera.

   1. Seleccione Wait timer.
   2. Ingresa la cantidad de minutos a esperar.
   3. Haga clic en Save protection rules.

8. Opcionalmente, no permita omitir las reglas de protección configuradas. Para más información, consulta Permitir que los administradores omitan las reglas de protección configuradas.

   1. Anule la selección de la opción Allow administrators to bypass configured protection rules.
   2. Haga clic en Save protection rules.

9. Opcionalmente, habilite las reglas de protección de implementación personalizadas que se hayan creado con GitHub Apps. Para más información, consulta Reglas de protección de implementación personalizadas.

   1. Seleccione la regla de protección personalizada que quiere habilitar.
   2. Haga clic en Save protection rules.

10. Opcionalmente, especifique qué ramas y etiquetas pueden implementarse en este entorno. Para obtener más información, consulte "Ramas de implementación y etiquetas".

    1. Seleccione la opción deseada en la lista desplegable Deployment branches.

    2. Si eligió Ramas seleccionadas y etiquetas, para agregar una nueva regla, haga clic en Agregar rama de implementación o regla de etiqueta 1. En el menú desplegable "Ref type", haz clic en Branch o Tag en función de la regla que quieras aplicar.

    3. Escriba el patrón de nombre de la rama o etiqueta que desea permitir.

       Note

       Los patrones de nombre deben configurarse para ramas o etiquetas de forma individual.

    4. Haga clic en Agregar regla.

11. Opcionalmente, agrega secretos de ambiente. Estos secretos solo están disponibles para los jobs de flujos de trabajo que utilicen el ambiente. Adicionalmente, los jobs de flujo de trabajo que utilicen este ambiente solo pueden acceder a estos secretos después de que pase cualquier regla configurada (por ejemplo, los revisores requeridos). Para más información, consulta Secretos de entorno.

    1. En Environment secrets, haga clic en Add Secret.
    2. Ingresa el nombre del secreto.
    3. Ingresa el valor del secreto.
    4. Haga clic en Add Secret.

12. Opcionalmente, agrega variables de entorno. Estas variables solo están disponibles para los trabajos de flujo de trabajo que usan el entorno y solo son accesibles mediante el contexto vars. Para más información, consulte Variables de entorno.

    1. En Variables de entorno, haz clic en Agregar variable.
    2. Establece el nombre de la variable.
    3. Establece el valor de la variable.
    4. Haz clic en Agregar variable.

También puedes crear y configurar ambientes a través de la API de REST. Para más información, consulta Puntos de conexión de la API de REST para entornos de implementación, Puntos de conexión de API de REST para secretos de Acciones de GitHub, Puntos de conexión de API de REST para las variables de las Acciones de GitHub y Puntos de conexión de la API de REST para directivas de rama de implementación.

El ejecutar un flujo de trabajo que referencie un ambiente que no existe creará un ambiente con el nombre referenciado. Si el entorno se crea a partir de la ejecución de compilaciones de página implícitas (por ejemplo, desde una rama u origen de carpeta), la rama de origen se agregará como regla de protección al entorno. De lo contrario, el entorno recién creado no tendrá configurada ninguna regla de protección o secreto. Cualquiera que pueda editar flujos de trabajo en el repositorio podrá crear ambientes a través de un archivo de flujo de trabajo, pero solo los administradoresd e repositorio pueden configurar el ambiente.

Borrar un ambiente

Para configurar un entorno en un repositorio de cuenta personal, debes ser el propietario del repositorio. Para configurar un entorno en el repositorio de una organización, debe tener acceso admin.

El borrar un ambiente borrará todos los secretos y reglas de protección asociadas con éste. Cualquier job que esté actualmente en espera porque depende de las reglas de protección del ambiente que se borró, fallará automáticamente.

1. En GitHub, navegue hasta la página principal del repositorio.

2. En el nombre del repositorio, haz clic en Configuración. Si no puedes ver la pestaña "Configuración", selecciona el menú desplegable y, a continuación, haz clic en Configuración.

   

3. En la barra lateral de la izquierda, haz clic en Entornos.

4. Junto al entorno que quieras borrar, haz clic en .

5. Haga clic en I understand, delete this environment.

También puyedes borrar ambientes a través de la API de REST. Para más información, consulta Puntos de conexión de la API de REST para repositorios.

Cómo se relacionan los ambientes con los desplilegues

Cuando se ejecuta un trabajo de flujo de trabajo que hace referencia a un entorno, crea un objeto de implementación con la propiedad environment establecida en el nombre del entorno. A medida que avanza el flujo de trabajo, también crea objetos de estado de implementación con la propiedad environment establecida en el nombre del entorno, la propiedad environment_url establecida en la URL del entorno (si se ha especificado en el flujo de trabajo) y la propiedad state establecida en el estado del trabajo.

Puedes acceder a estos objetos a través de la API de REST o la API de GraphQL. También puedes suscribirte a estos eventos de webhook. Para obtener más información, consulta Puntos de conexión de la API de REST para repositorios, Objetos (GraphQL API) o Eventos y cargas de webhook.

Pasos siguientes

GitHub Actions proporciona varias características para administrar tus despliegues. Para más información, consulta Desplegar con GitHub Actions.