Implementaciones y entornos

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

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.