Elige dónde espera Taiga una decisión

Distingue cuatro decisiones

El servicio ficticio de equipamiento tiene cuatro decisiones diferentes: aceptar el plan, ejecutar la implementación, hacer merge del cambio y desplegarlo. No trates un solo interruptor como autorización para las cuatro.

Antes de cambiar la autonomía, examina qué hace el pipeline del repositorio después del merge. Si el merge a la rama de trabajo activa un despliegue, un merge automatizado también puede activar ese flujo existente.

Decide si un plan debe esperar

El ajuste de producto Build on its own by default controla si un plan terminado pasa a implementación o espera aprobación. Desactívalo cuando los planes necesiten primero una decisión humana.

El ajuste Build on its own de una iniciativa puede cambiar ese comportamiento para esa iniciativa concreta. Examina tanto el valor predeterminado como cualquier elección específica antes de poner trabajo en cola.

Approve inicia la implementación como la persona que aprueba, con sus permisos actuales. Un plan fallido no inicia ninguna implementación. La automatización de la implementación no autoriza por sí sola el merge de la pull request resultante.

Entiende la jerarquía del merge

El merge autónomo se controla por separado y está desactivado hasta que se activa. La integración documentada admite GitHub, incluido GitHub Enterprise.

Un límite desactivado en la organización o factory no puede anularse desde un nivel inferior. Un valor predeterminado de producto desactivado es diferente: una iniciativa puede activar su propio merge si los límites superiores lo permiten.

Para el servicio de equipamiento, mantén explícito el alcance inicial. Una iniciativa de consecuencias limitadas puede tener una elección diferente de un cambio en los controles de acceso de empleados, dentro de los límites permitidos.

Haz exigibles las revisiones obligatorias

Taiga pregunta al proveedor de control de versiones si la pull request puede completar el merge. La protección de rama determina las comprobaciones, revisiones y demás condiciones obligatorias. El merge autónomo no elude esas reglas.

Si una revisión automatizada debe bloquear el merge, convierte su resultado en una comprobación de estado obligatoria mediante la configuración admitida por el repositorio. Un resultado informativo no pasa a ser obligatorio porque esperes que lo sea.

Comprueba también las aprobaciones humanas obligatorias. Una comprobación en verde no sustituye una aprobación exigida por tu política. Confirma las reglas de la rama de destino real.

Interpreta un merge detenido

Lee el motivo en la iniciativa. Una comprobación pendiente, una aprobación ausente, un conflicto y un plan incompleto necesitan respuestas diferentes. Taiga también detiene el merge autónomo cuando las correcciones cambian los criterios que hicieron pasar las comprobaciones fallidas. Revisa ese cambio directamente.

No elimines una comprobación obligatoria solo porque bloquee el avance. Si la comprobación nunca informa de su resultado, corrige su configuración o usa el proceso autorizado para cambiar la política. Examina el commit actual después de cualquier corrección.

Mantén separada la autorización de despliegue

La GitHub App de Taiga realiza el merge autónomo y queda registrada como su autora. El pipeline del repositorio conserva su comportamiento de despliegue existente.

En este escenario, el merge despliega a staging. Producción sigue necesitando la decisión y las pruebas de producción de la organización. Confirma que el pipeline aplique esta separación. Continúa con la revisión de la entrega.