Feature freeze y code freeze en el desarrollo de aplicaciones: esencia, diferencias y papel

¿Qué es un feature freeze?

Feature freeze es una prohibición temporal de añadir nueva funcionalidad a la base de código, introducida antes de un lanzamiento planificado. El equipo deja de fusionar funciones y se dedica a corregir errores, optimizar y pulir el código existente. Los desarrolladores finalizan funciones incompletas solo dentro del alcance de correcciones de errores, sin ampliar el alcance.

El feature freeze resuelve el problema de las funciones en progreso (work-in-progress) que no llegan al lanzamiento pero ya están parcialmente fusionadas en la rama principal. Si se siguen fusionando nuevas funciones, aumenta el riesgo de regresión: cada nueva integración requiere volver a probar los módulos ya terminados. Feature freeze fija el alcance del lanzamiento, convirtiéndolo de un objetivo móvil en un conjunto estable de funcionalidades.

Una aclaración importante: feature freeze ≠ code freeze. Durante un feature freeze, se permiten correcciones de errores, refactorización, actualizaciones de dependencias y documentación. Solo se prohíben las nuevas funciones visibles para el usuario, es decir, cualquier código que cambie el comportamiento de la aplicación desde la perspectiva del usuario. Verificación en code review: si un PR añade una nueva pantalla, botón o método de API, se rechaza hasta que se levante la congelación.

¿Qué es un code freeze y en qué se diferencia del feature freeze?

Code freeze es una práctica más estricta en la que todos los cambios en el código están completamente prohibidos. Incluso las correcciones de errores no están permitidas a menos que sean críticas. El code freeze se introduce por un período corto (generalmente 24-48 horas) y garantiza que la compilación de lanzamiento se ensamble a partir de un conjunto fijo de commits.

La diferencia entre feature freeze y code freeze radica en el nivel de control. El feature freeze gestiona el alcance: qué exactamente se incluirá en el lanzamiento. El code freeze gestiona la calidad: elimina el riesgo de introducir un nuevo error el día antes del lanzamiento. En la práctica, muchos equipos utilizan un modelo de dos etapas: 1-2 semanas antes del lanzamiento — feature freeze, 24-48 horas antes — code freeze. Code freeze es particularmente relevante para aplicaciones móviles, donde la compilación debe subirse a la tienda varios días antes de la fecha de lanzamiento planificada.

La excepción al code freeze son las correcciones de seguridad para vulnerabilidades críticas (CVE con puntuación 9+). Dichos cambios pasan por un proceso de emergencia con revisión de código acelerada obligatoria y notificación al equipo. Todos los demás cambios se posponen hasta el próximo ciclo de lanzamiento.

Feature freeze vs code freeze: comparación

La elección entre feature freeze y code freeze depende de la madurez del equipo y la frecuencia de lanzamientos. Los equipos con CI/CD y feature flags pueden necesitar solo un code freeze de 24 horas, mientras que los equipos con lanzamientos mensuales suelen usar ambas congelaciones de forma secuencial.

Tipos de congelaciones: total, parcial y BAU-freeze

Además del feature freeze total y el code freeze, existen opciones más flexibles. Partial feature freeze (congelación parcial) bloquea la nueva funcionalidad solo en ciertos módulos, por ejemplo, en el módulo de pagos o en el módulo de autorización, dejando el resto de componentes abiertos a cambios.

BAU-freeze (business as usual freeze) es una opción de compromiso en la que solo se prohíben las funciones grandes con un volumen de cambios que supere un cierto umbral (por ejemplo, 500 líneas de código). Las mejoras menores, ajustes de UI y correcciones de errores continúan fusionándose. BAU-freeze es conveniente para proyectos con entrega continua, donde una parada total del desarrollo durante una semana no es económicamente viable.

También existe el concepto de deployment freeze (congelación de despliegue): una parada completa de los despliegues a producción, típica para la temporada navideña (vacaciones de Navidad, Black Friday). Durante este período, incluso los hotfixes se bloquean a menos que estén relacionados con la seguridad. El deployment freeze suele durar 1-2 semanas y se coordina a nivel de empresa.

Cuándo introducir una congelación y cuánto dura

El momento óptimo para introducir un feature freeze es después de completar el código, cuando todas las funciones planificadas están fusionadas y pasando QA. El momento exacto depende del ciclo de lanzamiento: para un sprint de dos semanas, el feature freeze se introduce 3-4 días antes de la fecha de lanzamiento; para un lanzamiento mensual, 7-10 días antes. Code freeze se introduce 24-48 horas antes de la hora planificada de compilación del lanzamiento.

La duración de la congelación debe ser la mínima suficiente para estabilizar el código. Una congelación demasiado larga (más de 2 semanas) desmotiva al equipo y crea una acumulación de funciones sin fusionar, cada una de las cuales aumenta el riesgo de conflictos después de levantar la congelación. Una congelación demasiado corta (menos de 24 horas para un feature freeze) no permite tiempo suficiente para pruebas y correcciones exhaustivas.

La práctica recomendada es establecer la congelación no por fecha de calendario sino por el estado de la base de código. El feature freeze se introduce cuando el número de errores abiertos para el lanzamiento supera un umbral (por ejemplo, 10 errores críticos). Code freeze — cuando la compilación pasa correctamente las pruebas de humo y la suite de regresión. Time-based freeze (fecha fija) sigue siendo el estándar para industrias reguladas (fintech, medtech) donde la fecha de lanzamiento está aprobada por un regulador.

Automatización de congelaciones mediante CI/CD y Git

El control manual de congelaciones es una fuente de errores: un desarrollador podría fusionar accidentalmente un PR que debería esperar hasta que se levante la congelación. La automatización resuelve esto mediante reglas de protección de ramas de Git y pipelines de CI/CD. En el proveedor de Git (GitHub, GitLab, Bitbucket), se configuran reglas que bloquean las fusiones en la rama de lanzamiento sin una etiqueta especial o aprobación del release manager.

Pipeline de CI/CD verifica el estado de la congelación antes de compilar la build. En Jenkins, GitLab CI o GitHub Actions, se añade un paso que lee un archivo de configuración con el calendario de congelaciones y rechaza las compilaciones si la fecha actual cae dentro del período de congelación. Una alternativa es un feature flag en el panel de administración que bloquea el despliegue a producción.

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze is active. PR blocked." && exit 1

El script de ejemplo freeze-check.js lee un JSON con el calendario de congelaciones desde la raíz del repositorio. Si la fecha actual cae dentro del intervalo entre start_date y end_date para la rama especificada, el pipeline falla con un mensaje de estado de congelación. Git branch protection añade una segunda barrera: incluso si el pipeline no se activó, la regla no permite fusionar el PR sin aprobación.

Errores comunes al implementar congelaciones

El primer error es una congelación sin criterios claros de levantamiento. El equipo congela el código pero no define qué condiciones deben cumplirse para descongelar: cero errores críticos, suite de regresión superada, aprobación del product manager. Sin criterios, la congelación puede prolongarse durante semanas. La definición de completado para la congelación debe estar documentada y ser conocida por todos los desarrolladores.

El segundo error es demasiadas excepciones a la congelación. Cada excepción (“este PR no es una función, es deuda técnica”) desdibuja el límite de la congelación. Si las excepciones superan el 20% del flujo normal de PR, la congelación no funciona. El equipo simplemente renombra funciones como correcciones de errores para evitar el bloqueo.

El tercer error es ignorar los release candidates. Si el equipo no construye compilaciones candidatas de lanzamiento y despliega directamente a producción después del code freeze, el propósito de la congelación se pierde: los errores son descubiertos por los usuarios. El release candidate debe construirse antes del code freeze, probarse por QA y en staging, y solo después de la confirmación de calidad se introduce el code freeze.

El cuarto error es el factor humano en el control manual. Un desarrollador podría olvidar verificar el estado de la congelación antes de fusionar, un release manager podría perder una notificación. La única solución fiable es el bloqueo automático a nivel del proveedor de Git o CI/CD, eliminando el error humano.