Implementaciones y entornos

Reglas de protección de despliegue

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 una tarea o restringir el entorno a ciertas 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 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 necesarios para requerir la aprobación de una persona o equipo específico sobre los trabajos del flujo de trabajo que hacen referencia al entorno. 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 trabajo para que continúe.

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 una tarea durante una cantidad de tiempo específica después de que la tarea 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 y etiquetas de implementación para limitar qué ramas y etiquetas pueden hacer implementaciones en el entorno. A continuación se presentan opciones para las ramas y etiquetas de implementación de 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 [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches).
  

  Nota:

  Los flujos de trabajo de implementación desencadenados por etiquetas con el mismo nombre que una rama protegida, así como las 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.
  

  La rama de implementación o norma de etiqueta se compara con la GITHUB_REF de la ejecución del flujo de trabajo. Para conocer los valores de GITHUB_REF para cada disparador de flujo de trabajo, consulte Eventos que desencadenan flujos de trabajo. Si especifica releases/* como una rama de implementación o una regla de etiqueta, solo un GITHUB_REF cuyo nombre comienza por releases/ puede implementarse en el entorno. Agregar otra regla de rama para refs/pull/*/merge también permitiría que los flujos de trabajo desencadenados por pull_request eventos se implementaran en el entorno. Los caracteres comodín no coincidirán con /. Para que coincidan con ramas o etiquetas que comiencen por release/ y contengan una barra diagonal única adicional, use release/*/*. 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 impedir que se omitan las reglas de protección en todas las implementaciones de cualquier entorno.

Reglas personalizadas de protección de implementación

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 entorno solo están disponibles para los trabajos que referencian el entorno. Si el entorno requiere aprobación, una tarea no puede acceder a secretos del entorno hasta que uno de los revisores requeridos lo apruebe. Para obtener más información sobre secretos, consulta Secretos.

Variables de entorno

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