Ramas, entornos y aprobaciones en el CI

5 tareas · 40 min · Principiante

El último freno antes de producción no es el escáner: es una persona distinta de quien lanzó el cambio que dice que sí. En GitHub se configura con entornos y revisores; en GitLab, con ramas protegidas y entornos protegidos; en los dos, con propietarios de código sobre el propio flujo. Con las configuraciones y el registro de despliegues de Mirto Pagos lees si esos frenos frenan de verdad. Todo es lectura de archivos de ejemplo en la consola del navegador.

0 de 5 · 0%

Objetivo de la sala

En GitHub un entorno agrupa reglas de despliegue: quién debe aprobar, desde qué ramas se puede desplegar, cuánto esperar. Mientras un revisor no apruebe, el trabajo no arranca y no puede leer los secretos del entorno. La opción de evitar la autoaprobación impide que quien lanzó el despliegue lo apruebe él mismo.

En GitLab, los entornos protegidos limitan quién puede desplegar y cuántas aprobaciones hacen falta.

Responde para continuar

¿Para qué sirve activar la opción de evitar la autoaprobación en un entorno de producción?

Para que ninguna rama pueda desplegar a producción salvo la principal, que está protegida Para que quien lanzó el despliegue no pueda ser también quien lo apruebe Para que quien lanza un despliegue pueda aprobarlo siempre que pertenezca al equipo de operaciones

Ver pista de ayuda

Es el principio de dos personas: una propone y otra autoriza.

La configuración de producción de GitHub tiene un revisor requerido, pero el registro de despliegues muestra quién disparó y quién aprobó cada uno. Cruza las dos columnas del registro y encuentra el que se aprobó sin segunda persona.

Responde para continuar

Escribe el identificador del despliegue a producción que aprobó la misma persona que lo disparó.

Ver pista de ayuda

Abre registro/despliegues.txt y compara disparado_por con aprobado_por en las filas de produccion.

Una rama protegida solo protege si las reglas de quién empuja y quién fusiona son estrictas. En GitLab, el rol Developer puede empujar a lo que la regla permita. Lee las reglas de ramas protegidas y la condición con la que el trabajo de despliegue decide cuándo corre.

Responde para continuar

Escribe el patrón de rama protegida que despliega a producción y en el que los Developers pueden empujar directamente.

Ver pista de ayuda

Compara la tabla de ramas protegidas con la regla (rules) del trabajo desplegar.

Quien puede modificar un archivo de flujo puede cambiar lo que corre con los secretos. Por eso el directorio de flujos debería tener propietarios específicos en CODEOWNERS, y la rama debería exigir la revisión del propietario del código para que cuente. Lee el archivo de propietarios.

Responde para continuar

Escribe el nombre del equipo propietario de .github/workflows/ en el archivo CODEOWNERS, sin el arroba ni la organización.

Ver pista de ayuda

Abre github/CODEOWNERS y busca la línea del directorio de flujos.

El entorno de producción de GitHub permite que quien dispara se apruebe a sí mismo, y la rama de lanzamiento de GitLab abre el despliegue a cualquiera con rol de desarrollador. Ninguna de las dos cosas se arregla con un aviso en el chat.

Responde para continuar

¿Cuál es la corrección que cierra los dos fallos?

Activar la prohibición de autoaprobación en el entorno y restringir en la rama de lanzamiento quién empuja y fusiona Subir el tiempo de espera del entorno a una hora para que haya margen de revisar cada despliegue antes de que arranque el trabajo Pedir al equipo por el chat que nadie apruebe sus propios despliegues y revisar el registro cada mes

Ver pista de ayuda

Una norma que depende de que todos se acuerden no es un control.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Qué aporta un entorno con revisores Lab

2 La aprobación que no fue de otra persona Lab

3 La rama que se empuja con rol de desarrollador Lab

4 Quién revisa el propio flujo Lab

5 La corrección Lab

Whoami-Labs Pro utiliza cookies