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 utilizar reglas de protección de implementación para requerir una aprobación manual, retrasar un job o restringir el ambiente a ramas específicas. 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 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 entornos 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 entornos 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). El tiempo de espera no contará para el tiempo facturable.

Ramas y etiquetas de implementación

Utiliza ramas de implementación para restringir las ramas que pueden hacer implementaciones en el entorno. A continuación encontrarás opciones para las ramas de implementación para un entorno:

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

• Protected branches only: solo las ramas con reglas de protección de rama habilitadas se pueden implementar 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 más información sobre las reglas de protección de rama, consulta Acerca de las ramas protegidas.

  Nota:

  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.

• Selected branches and tags: solo las ramas y etiquetas que coinciden con los patrones de nombre especificados se pueden implementar en el entorno.

  Si especificas releases/* como una regla de rama o etiqueta de implementación, solo una rama o etiqueta cuyo nombre comience por releases/ se podrá implementar en el entorno. (Los caracteres comodín no coincidirán con /. Para hacer coincidir las ramas o etiquetas que comiencen por release/ y contengan una barra diagonal sencilla adicional, utiliza release/*/*. Si agregas main como regla de rama, una rama denominada main también se puede 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 .

  Nota:

  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 Secrets.

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 han desencadenado, selecciona Prevent self-review.
   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, especifica qué ramas se pueden implementar en este entorno. Para más información, consulta Ramas y etiquetas de implementación.

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

    2. Si has elegido Selected branches and tags, para agregar una nueva regla, haz clic en Add deployment branch or tag rule.

    3. En el menú desplegable "Ref type", haz clic en Branch o Tag en función de la regla que quieras aplicar.

    4. Escribe el patrón de nombre de la rama o etiqueta que quieres permitir.

       Nota:

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

    5. 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 Deploying with GitHub Actions.