Ramas protegidas y revisión obligatoria

Una rama protegida pone condiciones a lo que entra: que haya una propuesta de fusión, que la apruebe alguien distinto del autor, que pasen las pruebas y que nadie empuje directamente. Una regla pensada así convierte cada cambio en una decisión de dos personas. Pero las reglas tienen puertas laterales: el empuje directo si está permitido, las excepciones para administradores, o ramas que despliegan igual y no tienen regla.

El punto de partida de la revisión es siempre la tabla de reglas: qué ramas despliegan y cuáles de ellas están protegidas.

Es frecuente que la rama principal esté bien protegida y que exista otra, de entrega o de arreglos urgentes, que despliega igual y no tiene ninguna regla. Para quien quiera meter un cambio sin que lo vea nadie, esa rama es el camino corto, y para el pipeline es indistinguible de la principal. Un control solo protege lo que cubre.

Busca en las reglas la rama que despliega a producción sin revisión obligatoria.

Las reglas de rama a veces permiten que un administrador las salte «en una urgencia». Esa puerta existe y se usa, y cada uso debería ser un acontecimiento: con motivo escrito y revisión posterior. La tabla de fusiones guarda cómo entró cada cambio. Una fusión sin aprobador, y que tocó la carpeta del pipeline, es el tipo de cambio que más hay que mirar.

Un archivo de propietarios del código (CODEOWNERS en los CI habituales) dice quién debe revisar cada carpeta. Para la carpeta de los flujos, el dueño debería ser el equipo de plataforma o seguridad: un cambio ahí puede alterar permisos y accesos de todo el pipeline. Una revisión de otra persona del mismo equipo de la aplicación cumple la regla de «una aprobación» pero no la de que revise quien entiende el pipeline.

Cuenta las fusiones que cambiaron algo de la carpeta del pipeline sin que revisaran sus propietarios.

Cerrar las puertas es parte de la corrección: activar la revisión obligatoria en la rama de liberación, exigir la revisión de propietarios para .ci y quitar a los administradores la posibilidad de saltarse la regla, o al menos dejar constancia visible de cada uso. Bloquear el empuje directo cierra el camino corto. Nada de esto sustituye al análisis del flujo; lo completa, porque garantiza que el flujo que se analizó es el que se ejecuta.