Hotfix en el desarrollo de aplicaciones: esencia, mecanismo y cómo aplicarlo

¿Qué es un hotfix y cuándo se necesita?

Un hotfix (corrección en caliente) es un parche para la versión de producción de una aplicación lanzado fuera de cola para solucionar un problema crítico. Un hotfix se entrega a los usuarios en horas, no en días, y está destinado únicamente a situaciones en las que la aplicación no está disponible, pierde datos o compromete la seguridad del usuario.

Escenarios típicos para un hotfix: un fallo al iniciar en ciertos dispositivos (regresión tras el último lanzamiento), fuga de datos personales debido a una autorización incorrecta, una integración de pago rota (pérdida de ingresos), violaciones de cumplimiento GDPR/CCPA. Todas estas situaciones tienen severidad P0 o P1 en la clasificación de incidentes. Las tareas planificadas — optimización, refactorización, nuevas pantallas — nunca se realizan mediante un hotfix.

Una regla importante: un hotfix contiene un número mínimo de cambios (1–2 archivos, 10–20 líneas de código). Cuanto menor sea el diff, menor será el riesgo de introducir un nuevo error. Si para solucionar el problema se requiere cambiar la arquitectura o añadir un nuevo módulo — esto no es un hotfix, sino un lanzamiento de emergencia que requiere una revisión de código y QA completos.

En qué se diferencia un hotfix de un lanzamiento normal

Las principales diferencias entre un hotfix y un lanzamiento planificado son la velocidad, el alcance de los cambios y el nivel de pruebas. Un lanzamiento planificado puede incluir docenas de funciones, pasar por un ciclo completo de QA (pruebas de regresión + integración + UI) y tardar de 1 a 2 semanas desde el congelamiento del código hasta el despliegue. Un hotfix incluye una o dos correcciones, pasa por una revisión acelerada (2 aprobaciones en lugar de 3) y pruebas smoke mínimas.

Desde la perspectiva del proceso Git, un hotfix se crea a partir de un tag de lanzamiento, no de la rama develop. Esto garantiza que solo los cambios necesarios para solucionar el problema se incluyan en el hotfix, sin incorporar accidentalmente funciones incompletas de develop. Tras el despliegue, el hotfix se fusiona de nuevo en main y develop (mediante cherry-pick o merge).

Comparación entre lanzamiento planificado y hotfix

Importante: no todas las tareas urgentes son un hotfix. Si un gerente dice “necesitamos añadir un botón urgentemente” — eso no es un hotfix, es un cambio de prioridad. Un hotfix real se determina por la severidad para el usuario, no por la urgencia para el negocio. El criterio: si la aplicación no falla y los datos no se filtran — la tarea espera a un lanzamiento planificado.

Proceso de hotfix: desde la detección hasta el despliegue

El primer paso al descubrir un problema crítico es el triage — una evaluación rápida de la severidad. El ingeniero de guardia confirma el error, revisa los registros y los informes de fallos, y determina si el problema es una regresión del último lanzamiento o un error de larga data. Si la severidad es P0 — se activa el pipeline de hotfix. La etapa de triage no debe durar más de 15 minutos.

El segundo paso es crear una rama a partir del último tag de lanzamiento (v2.5.0 → hotfix/v2.5.1). El desarrollador realiza la corrección mínima, hace commit con el prefijo HOTFIX, hace push y abre un PR etiquetado como [HOTFIX]. Revisión de código fast-track: dos revisores se asignan automáticamente mediante CODEOWNERS, el tiempo de revisión no supera los 30 minutos. Si no hay revisión en 20 minutos, el revisor se omite y se asigna el siguiente.

El tercer paso es la compilación y el despliegue mediante CI/CD. El pipeline de hotfix difiere del normal: se omiten las pruebas de integración largas (que toman horas), solo se ejecuta la suite smoke (10–15 escenarios críticos, 5–10 minutos). Después del despliegue: monitorización de la tasa de fallos, tasa de errores, latencia de API — durante 30 minutos. Métricas DORA para hotfixes: el tiempo medio de recuperación (MTTR) debe ser inferior a 1 hora.

# .github/workflows/hotfix-deploy.yml
name: Hotfix Deploy Pipeline
on:
  pull_request:
    types: [labeled]
    branches: [hotfix/*]

jobs:
  hotfix-checks:
    runs-on: ubuntu-latest
    if: contains(github.event.label.name, 'hotfix-critical')
    steps:
      - uses: actions/checkout@v4
      - name: Validate diff size
        run: bash .github/scripts/diff-check.sh 30
      - name: Build
        run: ./gradlew assembleRelease
      - name: Smoke test
        run: ./gradlew smokeTest
      - name: Deploy to staging
        run: fastlane deploy_staging
      - name: Approve & deploy to production
        if: success()
        run: fastlane deploy_production
        env:
          HOTFIX_MODE: true

Optimizaciones clave en este pipeline: comprobación del diff (no más de 30 líneas), omisión de pruebas de integración, despliegue automático en staging y production si la prueba smoke es exitosa. HOTFIX_MODE variable de entorno que activa comprobaciones adicionales en tiempo de ejecución — por ejemplo, registro extendido para un diagnóstico rápido de problemas.

Ramificaciones hotfix en Git: la estrategia correcta

La estrategia para trabajar con ramas hotfix se describe en Gitflow Workflow. La regla principal: una rama hotfix se crea a partir del último tag de lanzamiento (git checkout -b hotfix/v2.5.1 tags/v2.5.0), no de develop ni main. Esto garantiza que el hotfix se base en el mismo estado del código actualmente en producción y no incorpore cambios incompletos de develop.

Una vez completada la corrección, la rama hotfix se fusiona en main (o master) y develop. En main — un commit de fusión normal con un nuevo tag de parche (v2.5.1). En develop — una fusión o cherry-pick, según la política del equipo. Si develop contiene más cambios que main, se recomienda hacer cherry-pick del commit específico del hotfix para evitar conflictos. GitFlow recomienda fusionar primero el hotfix en main y luego fusionar main en develop.

# Crear rama hotfix desde el último tag de lanzamiento
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# Aplicar la corrección
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# Fusionar en main y etiquetar el lanzamiento
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# Fusionar también en develop
git checkout develop
git merge --no-ff hotfix/v2.5.1

# Limpiar la rama temporal
git branch -d hotfix/v2.5.1

Importante: si el hotfix corrige un error que existe en la rama develop actual (el error se introdujo hace varios sprints), entonces después de fusionar el hotfix en main y develop, develop ya contiene la corrección. Si el error solo se introdujo en la rama de lanzamiento (se acumuló un error mediante cherry-pick), es posible que no se necesite la corrección en develop. El análisis de causa raíz ayuda a determinar si es necesario hacer cherry-pick en develop.

Riesgos de los hotfix y cómo minimizarlos

El principal riesgo de un hotfix es introducir un error nuevo y más grave debido a las prisas. Según un estudio de Stripe (2021), el 15% de los hotfix provocan una regresión y requieren un segundo hotfix. Es una ley de la ironía: cuanto más rápido corregimos, mayor es la probabilidad de equivocarnos. La minimización del riesgo se logra limitando estrictamente el tamaño del diff (no más de 30 líneas) y mediante pruebas smoke automáticas obligatorias.

El segundo riesgo es la acumulación de deuda técnica. Si un equipo utiliza regularmente hotfix en lugar de lanzamientos planificados, la base de código se degrada: los commits de hotfix no pasan por refactorización, las soluciones temporales no se reemplazan por las adecuadas, la documentación no se actualiza. Indicador de salud: si los hotfix se lanzan más de una vez al mes — el proceso de lanzamiento necesita revisión.

El tercer riesgo es psicológico. Los hotfix regulares agotan al equipo: los desarrolladores de guardia están bajo estrés constante, la revisión de código se convierte en una formalidad (todos quieren ir más rápido) y la cultura de calidad disminuye. Una frecuencia normal de hotfix para un equipo maduro es de 1–2 por trimestre. Si es mayor — el problema no son los hotfix, sino la calidad de los lanzamientos planificados.

Qué hacer después de un hotfix

Después de desplegar un hotfix y estabilizar las métricas, se realiza una retrospectiva post-mortem sin culpas. El equipo responde a cuatro preguntas: qué ocurrió, por qué las comprobaciones no detectaron el error, qué se hizo para corregirlo y cómo evitar que se repita. El post-mortem se realiza dentro de las 24–48 horas posteriores al hotfix, mientras los detalles están frescos. La cultura sin culpas es un principio clave: se discuten los procesos, no las personas.

El resultado del post-mortem son elementos de acción concretos con responsables y plazos. Elementos de acción típicos: agregar una prueba unitaria para el caso omitido, ampliar la suite de pruebas smoke, mejorar la monitorización (agregar una alerta sobre la métrica), actualizar el runbook para incidentes similares. Los elementos de acción deben completarse antes del próximo lanzamiento planificado.