Using environments for deployment

Puedes configurr ambientes con reglas de protección y secretos. A workflow job that references an environment must follow any protection rules for the environment before running or accessing the environment's secrets.

Los ambientes, las reglas de protección de ambiente y los secretos de ambiente se encuentran disponibles en los repositorios públicos para todos los productos. Para tener acceso a los ambientes en los repositorios privados, debes utilizar GitHub Enterprise.

Acerca de los ambientes

Los ambientes se utilizan para describir un objetivo de despliegue 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 visualizar los despliegues hacia los ambientes, consulta la sección "Ver el historial de despliegue".

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 de ambiente

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 las 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 jobs que referencian un ambiente con revisores requeridos, consulta la sección "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 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:

  • Todas las ramas: Todas las ramas del repositorio pueden hacer despliegues en el ambiente.

  • Ramas protegidas: Solo las ramas que tengan reglas de protección de rama habilitadas podrán hacer despliegues en el ambiente. 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 iformación acerca de las reglas de protección de rama, consulta la sección "Acerca de las ramas protegidas".

  • Ramas selectas: Solo las ramas que coincidan con tus patrones específicos de nombre podrán hacer despliegues en el ambiente.

    Por ejemplo, si especificas releases/* como una regla de rama de despliegue, solo aquellas ramas cuyo nombre inicie con releases/ podrán hacer despliegues en el ambiente. (Los caracteres de comodín no coincidirán con /. Para hacer coincidir las ramas que inicien con release/ y contengan una diagonal sencilla adicional utiliza release/*/*.) Si agregas main como regla de rama de despliegue, la rama que se llame main también podrá hacer despliegues en el ambiente. Para obtener más información sobre las opciones de sintaxis para las ramas de despliegue, consulta la documentación de File.fnmatch de Ruby.

Secretos de ambiente

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, consulta la sección "Secretos cifrados".

Nota: Los flujos de trabajo que se ejecutan en ejecutores auto-hospedados no se ejecutan en un contenedor aislado, incluso si utilizan ambientes. Environment secrets should be treated with the same level of security as repository and organization secrets. Para obtener más información, consulta la sección "Fortalecimiento de la seguridad para las GitHub Actions".

Crear un ambiente

Para configurar un ambiente en un repositorio de cuenta de usuario, debes ser el propietario de éste. Para configurar un ambiente en un repositorio de organización, debes tener acceso de admin.

  1. En your GitHub Enterprise Server instance, visita la página principal del repositorio.
  2. Debajo de tu nombre de repositorio, da clic en Configuración. Botón de configuración del repositorio
  3. En la barra lateral izquierda, da clic en Ambientes.
  4. Da clic en Ambiente nuevo.
  5. Ingresa un nombre para el ambiente y luego da clic en Configurar ambiente. 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. Optionally, specify people or teams that must approve workflow jobs that use this environment.
    1. Select Required reviewers.
    2. Enter up to 6 people or teams. Solo uno de los revisores requeridos necesita aprobar el job para que éste pueda proceder.
    3. Click Save protection rules.
  7. Optionally, specify the amount of time to wait before allowing workflow jobs that use this environment to proceed.
    1. Select Wait timer.
    2. Enter the number of minutes to wait.
    3. Click Save protection rules.
  8. Optionally, specify what branches can deploy to this environment. For more information about the possible values, see "Deployment branches."
    1. Select the desired option in the Deployment branches dropdown.
    2. If you chose Selected branches, enter the branch name patterns that you want to allow.
  9. Optionally, add environment secrets. These secrets are only available to workflow jobs that use the environment. Additionally, workflow jobs that use this environment can only access these secrets after any configured rules (for example, required reviewers) pass. Para obtener más información sobre los secretos, consulta la sección "Secretos cifrados".
    1. Under Environment secrets, click Add Secret.
    2. Enter the secret name.
    3. Enter the secret value.
    4. Haz clic en Agregar secreto (Agregar secreto).

También puedes crear y configurar ambientes a través de la API de REST. Para obtener más información, consulta las secciones de "Ambientes" y "Secretos".

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.

Using an environment

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. The job can access the environment's secrets only after the job is sent to a runner.

Cuando un flujo de trabajo referencia un ambiente, éste aparecerá en los despliegues del repositorio. Para obtener más información acerca de visualizar los despliegues actuales y previos, consulta la sección "Visualizar el historial de despliegues".

You can specify an environment for each job in your workflow. To do so, add a jobs.<job_id>.environment key followed by the name of the environment.

For example, this workflow will use an environment called production.

name: Deployment

on:
  push:
    branches:
      - main

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

When the above workflow runs, the deployment job will be subject to any rules configured for the production environment. For example, if the environment requires reviewers, the job will pause until one of the reviewers approves the job.

You can also specify a URL for the environment. La URL especificada aparecerá en la página de despliegues del repositorio (a la cual se puede acceder haciendo clic en Ambientes en la página principal de tu repositorio) y en la gráfica de visualización de la ejecución del flujo de trabajo. Si una solicitud de cambios activó el flujo de trabajo, la URL también se muestra como un botón de Ver despliegue en la línea de tiempo de esta.

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

Gráfica de flujo de trabajo con URL

Borrar un ambiente

Para configurar un ambiente en un repositorio de cuenta de usuario, debes ser el propietario de éste. Para configurar un ambiente en un repositorio de organización, debes tener acceso de 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, visita la página principal del repositorio.
  2. Debajo de tu nombre de repositorio, da clic en Configuración. Botón de configuración del repositorio
  3. En la barra lateral izquierda, da clic en Ambientes.
  4. Junto al ambiente que quieres borrar, haz clic en .
  5. Da clic en Entiendo, borra este ambiente.

También puedes borrar los ambientes a través de la API de REST Para obtener más información, consulta la sección "Ambientes".

How environments relate to deployments

When a workflow job that references an environment runs, it creates a deployment object with the environment property set to the name of your environment. As the workflow progresses, it also creates deployment status objects with the environment property set to the name of your environment, the environment_url property set to the URL for environment (if specified in the workflow), and the state property set to the status of the job.

You can access these objects through the REST API or GraphQL API. You can also subscribe to these webhook events. For more information, see "Repositories" (REST API), "Objects" (GraphQL API), or "Webhook events and payloads."

Pasos siguientes

GitHub Actions provides several features for managing your deployments. For more information, see "Deploying with GitHub Actions."

¿Te ayudó este documento?

Política de privacidad

¡Ayúdanos a hacer geniales estos documentos!

Todos los documentos de GitHub son de código abierto. ¿Notas algo que esté mal o que no sea claro? Emite una solicitud de cambios.

Haz una contribución

O, aprende cómo contribuir.