Utilizar ambientes para el despliegue

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 más información sobre cómo ver las implementaciones en los entornos, vea "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 job tampoco puede acceder a los secretos que se definen en un ambiente sino hasta que todas las reglas de protección de dicho ambiente pasen.

Reglas de protección del entorno

Las reglas de protección de ambiente requieren que pasen condiciones específicas antes de que un job que referencia al ambiente pueda proceder. Puedes utilizar reglas de protección de ambiente para requerir una aprobación manual, retrasar un job o restringir el ambiente a ramas específicas.

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.

Para obtener más información sobre cómo revisar los trabajos que hacen referencia a un entorno con los revisores necesarios, consulte "Revisión de implementaciones".

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 0 y 43,200 (30 días).

Ramas de despliegue

Utiliza ramas de despliegue para restringir las ramas que pueden hacer despliegues en el ambiente. A continuación encnotrarás las opciones para las ramas de despliegue de un ambiente:

• All branches: todas las ramas del repositorio pueden implementarse en el entorno.

• Protected branches: 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, consulte "Acerca de las ramas protegidas".

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

  Por ejemplo, si especifica releases/* como una regla de rama de implementación, solo las ramas cuyo nombre comience por releases/ podrán implementarse en el entorno. (Los caracteres comodín no coincidirán con /. Para buscar coincidencias con ramas que comienzan por release/ y contienen una barra diagonal única adicional, use release/*/*). Si agrega main como regla de rama de implementación, 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 de Ruby File.fnmatch.

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 los secretos, consulte "Secretos cifrados".

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 your GitHub Enterprise Server instance, vaya a la página principal del repositorio. 1. Debajo del nombre del repositorio, haz clic en Configuración. 1. En la barra lateral de la izquierda, haz clic en Entornos. 1. Haga clic en New environment (Nuevo entorno). 1. 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.
2. Opcionalmente, personas o equipos específicos deben aprobar los jobs de flujo de trabajo que utilicen este ambiente.
   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. Haga clic en Save protection rules.
3. Opcionalmente, especifica la cantidad de tiempo a esperar antes de permitir los jobs de flujo de trabajo que utilizan este ambiente para proceder.
   1. Seleccione Wait timer.
   2. Ingresa la cantidad de minutos a esperar.
   3. Haga clic en Save protection rules.
4. Opcionalmente, especifica qué ramas pueden desplegarse en este ambiente. Para obtener más información sobre los posibles valores, consulte "Ramas de implementación".
   1. Seleccione la opción deseada en la lista desplegable Deployment branches.
   2. Si eligió Selected branches, escriba los patrones de nombre de rama que desea permitir.
5. 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 obtener más información sobre los secretos, consulte "Secretos cifrados".
   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.

También puedes crear y configurar ambientes a través de la API de REST. Para obtener más información, consulta «Entornos de implementación», «Secretos de Acciones de GitHub» y «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. El ambiente 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.

Utilizar un ambiente

Cad job en un flujo de trabajo puede referenciar un solo ambiente. Cualquier regla de protección que se configure para el ambiente debe pasar antes de que un job que referencia al ambiente se envíe a un ejecutor. El job puede acceder a los secretos de ambiente únicamente después de que se envía a un ejecutor.

Cuando un flujo de trabajo referencia un ambiente, éste aparecerá en los despliegues del repositorio. Para obtener más información sobre cómo ver las implementaciones actuales y anteriores, consulte "Visualización del historial de implementación".

Puedes especificar un ambiente para cada job de tu flujo de trabajo. Para ello, agregue una clave jobs.<job_id>.environment seguida del nombre del entorno.

Por ejemplo, en este flujo de trabajo se utilizará un entorno llamado production.

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

Cuando se ejecute el flujo de trabajo anterior, el trabajo deployment estará sujeto a las reglas configuradas para el entorno production. Por ejemplo, si el ambiente requiere revisores, el job se pausará hasta que uno de ellos lo apruebe.

También puedes especificar una URL para el ambiente. La URL especificada aparecerá en la página de implementaciones del repositorio (a la que se accede al hacer clic en Environments (Entornos) en la página principal del repositorio) y en el gráfico de visualización de la ejecución del flujo de trabajo. Si una solicitud de incorporación de cambios ha desencadenado el flujo de trabajo, la URL también se muestra como un botón View deployment (Ver implementación) en la escala de tiempo de la solicitud de incorporación de cambios.

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: 
      name: production
      url: https://github.com
    steps:
      - name: deploy
        # ...deployment-specific steps

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 your GitHub Enterprise Server instance, vaya a la página principal del repositorio. 1. Debajo del nombre del repositorio, haz clic en Configuración. 1. En la barra lateral de la izquierda, haz clic en Entornos.
2. Junto al ambiente que quieres borrar, haz clic en .
3. 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 la sección sobre los "Entornos".

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, consulte "Repositorios" (API de REST), "Objetos" (GraphQL API) o "Eventos y cargas de webhook".

Pasos siguientes

GitHub Actions proporciona varias características para administrar tus despliegues. Para obtener más información, consulte "Implementación con Acciones de GitHub".