Flujo HotFix

Un HotFix es un parche urgente sobre un bug crítico en producción. No debe saltarse testing; sigue el flujo estándar de validación pero con prioridad máxima.

fix/202-crash-pagos testing Validación QA Urgente
fix/202-crash-pagos main MR formal (Squash)

Pasos del Hotfix

1️⃣Crear la rama fix/{id}-{slug} desde main actualizado.
2️⃣Aplicar el fix, hacer commit con referencia al issue y subir la rama.
3️⃣Integrar a testing mediante merge directo para validación QA inmediata.
4️⃣Abrir Merge Request hacia main solicitando revisión urgente.
5️⃣Una vez QA valida y el revisor aprueba, mergear a main con squash commit.
# Flujo rápido de comandos
git checkout main && git pull origin main
git checkout -b fix/202-crash-pago-tarjeta

# ... aplicar fix ...
git commit -m "fix: corrige crash al procesar pago con tarjeta" -m "Closes #202"
git push origin fix/202-crash-pago-tarjeta

# Integrar a testing
git checkout testing && git pull origin testing
git merge fix/202-crash-pago-tarjeta
git push origin testing

Excepción: Producción completamente caído

Solo en caso de que la instancia de producción se encuentre completamente caída o inoperativa. Una funcionalidad rota o un error en parte del flujo no califica como excepción.

El hotfix puede mergearse a main con aprobación del Team Leader.
🔄Inmediatamente después del merge, integrar a testing para validación retroactiva.
📄Documentar el incidente y realizar una retrospectiva obligatoria.
👤El Team Leader asume la responsabilidad de esta decisión.
La urgencia no elimina el code review. Incluso en la excepción, se requiere aprobación del Team Leader antes del merge.

Anexo: Diagrama del Flujo HotFix

Flujo urgente desde la detección del bug en producción hasta el merge. Pasa por testing para validación QA incluso en contexto de urgencia.

main fix/202 testing QA urgente (merge directo) MR urgente → main squash + approval TL ① crear rama desde main ② fix + commits ③ listo ④ integrar QA ⑤ merge ⚠ No omitir testing salvo que producción esté completamente caída — en ese caso: merge directo a main con approval del TL, luego retroactivo a testing