¿Qué es una release?

Una release (lanzamiento, en español) es una versión específica de un software que ha sido completada, probada y puesta a disposición para su uso por los usuarios finales. Representa un hito en el ciclo de desarrollo donde un conjunto de funcionalidades, mejoras o correcciones se empaquetan y se hacen accesibles en un entorno de producción.

La release es el punto donde el trabajo del equipo se convierte en valor real para el usuario. Según el informe State of DevOps de DORA (Google Cloud), los equipos de alto rendimiento realizan despliegues bajo demanda o múltiples veces al día, mientras que los de bajo rendimiento hacen releases cada 1-6 meses. Además, los equipos elite logran un lead time inferior a 1 hora desde el commit hasta la producción.

Como afirma Jez Humble, coautor de Continuous Delivery (Addison-Wesley): "Si algo duele, hazlo más frecuentemente y trae el dolor hacia adelante. Las releases frecuentes reducen el riesgo, no lo incrementan."

Estos tres conceptos se confunden frecuentemente, pero tienen diferencias importantes:

Release

Una release es una decisión de negocio. Es la acción de hacer disponible una versión del software para los usuarios. Implica que las funcionalidades están listas, probadas y se ha decidido estratégicamente que es el momento adecuado para lanzarlas.

Versión (Version)

Una versión es una etiqueta técnica que identifica un estado específico del código. Cada commit podría considerarse una versión, pero no todas las versiones son releases. La versión es un concepto técnico, no de negocio.

Despliegue (Deployment)

Un despliegue es una operación técnica de deploy. Es el acto de instalar y configurar el software en un entorno (desarrollo, staging, producción). Un equipo puede desplegar código a producción sin hacer una release (por ejemplo, usando feature flags).

En resumen:

• Release = qué funcionalidades están disponibles para el usuario
• Versión = qué estado del código estamos referenciando
• Despliegue = dónde y cuándo se instala el código

El Semantic Versioning es el estándar más utilizado para nombrar releases de software:

MAJOR.MINOR.PATCH (ejemplo: 2.4.1)

• MAJOR (2.x.x): Cambios que rompen compatibilidad con versiones anteriores (breaking changes)
• MINOR (x.4.x): Nuevas funcionalidades compatibles hacia atrás
• PATCH (x.x.1): Correcciones de bugs compatibles hacia atrás

Ejemplos de versionado

Release	Tipo	Qué incluye
1.0.0	Major	Primera versión estable del producto
1.1.0	Minor	Nueva funcionalidad de exportación a PDF
1.1.1	Patch	Corrección de bug en el login
2.0.0	Major	Rediseño completo de la API (breaking changes)

Pre-release versions

Antes de una release final, se usan sufijos para identificar versiones previas:

• 1.0.0-alpha: Versión temprana, inestable, para pruebas internas
• 1.0.0-beta: Versión más estable, para pruebas con usuarios seleccionados
• 1.0.0-rc.1: Release Candidate, candidata a ser la versión final

El camino de una release desde el código hasta el usuario pasa por varios entornos:

Desarrollo (DEV)

• Donde los desarrolladores trabajan y prueban sus cambios
• Inestable por naturaleza, con cambios frecuentes
• Cada desarrollador puede tener su propio entorno local

Integración (INT / QA)

• Donde se integran los cambios de múltiples desarrolladores
• Se ejecutan tests automatizados y pruebas de integración
• Primer punto de validación del equipo de QA

Pre-producción (PRE / Staging)

• Réplica lo más fiel posible del entorno de producción
• Se realizan pruebas de aceptación (UAT) con datos similares a los reales
• Último punto de validación antes de la release

Producción (PRO / Production)

• El entorno real donde los usuarios acceden al software
• Máxima estabilidad y monitorización
• Donde la release se convierte en realidad

Big Bang Release

Se acumula un gran número de cambios y se lanzan todos a la vez:

• Ventaja: Un solo momento de coordinación
• Riesgo: Si algo falla, hay muchos cambios donde buscar el problema
• Cuándo usarla: Migraciones grandes, lanzamientos iniciales de producto

Release incremental

Se lanzan pequeños conjuntos de cambios con frecuencia:

• Ventaja: Menor riesgo, feedback más rápido
• Riesgo: Requiere automatización y pipeline maduros
• Cuándo usarla: Equipos con CI/CD maduro, productos SaaS

Canary Release

Con un Canary Release, se despliega la nueva versión a un pequeño porcentaje de usuarios y se monitoriza antes de expandir:

• Ventaja: Riesgo mínimo, detección temprana de problemas
• Riesgo: Complejidad en la infraestructura
• Cuándo usarla: Cambios de alto impacto, grandes bases de usuarios

Blue-Green Deployment

Se mantienen dos entornos de producción idénticos (blue y green). La release se despliega en el inactivo y se redirige el tráfico:

• Ventaja: Rollback instantáneo cambiando el tráfico de vuelta
• Riesgo: Coste de mantener dos entornos
• Cuándo usarla: Servicios con alta disponibilidad requerida

Feature Flags

Se despliega el código a producción pero se controla qué funcionalidades están activas:

• Ventaja: Separar el despliegue de la release
• Riesgo: Acumulación de flags sin limpiar
• Cuándo usarla: Releases graduales, testing A/B, dark launches

Release Planning

En Scrum, el Release Planning es una actividad donde el Product Owner y el equipo definen:

• Qué features incluir en la próxima release
• Cuántos sprints se necesitan para completarlas
• Criterios de calidad y Definition of Done para la release
• Fecha objetivo de la release

Sprint vs. Release

Es importante distinguir:

• Un sprint es un período fijo de trabajo (1-4 semanas)
• Una release puede incluir uno o más sprints
• No todo sprint termina en una release a producción
• Lo ideal en Agile es que cada sprint produzca un incremento potencialmente liberable

Continuous Delivery y Release

En organizaciones con alta madurez DevOps, la distinción entre sprint y release se difumina. Con Continuous Delivery:

• Cada commit que pasa los tests puede ser desplegado a producción
• La decisión de release es puramente de negocio (cuándo activar una feature)
• Los despliegues pueden ocurrir varias veces al día

Según datos publicados por las propias compañías: Amazon realiza un deploy cada 11,7 segundos, Netflix hace miles de deploys al día, y Google gestiona más de 2.000 millones de líneas de código con releases continuas (Forsgren, Humble & Kim, Accelerate, 2018).

Las release notes (notas de la versión) son un documento que acompaña a cada release, informando a los usuarios sobre:

Qué incluir

• Nuevas funcionalidades: Qué puede hacer el usuario que antes no podía
• Mejoras: Qué funcionalidades existentes se han mejorado
• Correcciones de bugs: Qué problemas se han resuelto
• Breaking changes: Qué cambios requieren acción del usuario
• Deprecaciones: Qué funcionalidades se eliminarán en futuras releases
• Problemas conocidos: Qué limitaciones tiene esta release

Buenas prácticas para release notes

1. Escribe para el usuario, no para el desarrollador: Evita jerga técnica innecesaria
2. Agrupa por categoría: Nuevas features, mejoras, bugfixes, breaking changes
3. Incluye ejemplos o capturas: Especialmente para cambios visuales o de UX
4. Enlaza a documentación detallada: Para cambios complejos
5. Sé honesto con los bugs conocidos: La transparencia genera confianza

El Release Management es la disciplina que gestiona el proceso completo de la release:

Roles involucrados

• Release Manager: Coordina el proceso y toma decisiones de go/no-go
• Product Owner: Decide qué features incluir y cuándo lanzar
• QA Lead: Valida la calidad y da el visto bueno
• DevOps/SRE: Ejecuta el despliegue y monitoriza la estabilidad
• Soporte: Se prepara para posibles incidencias post-release

Checklist de release

1. Todos los tests automatizados pasan
2. Las pruebas de aceptación (UAT) están completadas
3. Las release notes están redactadas
4. El plan de rollback está documentado
5. El equipo de soporte está informado
6. Los stakeholders están notificados
7. La monitorización está configurada
8. Se ha hecho dry-run en staging

¿Con qué frecuencia debería hacer releases?

Depende del producto y la madurez del equipo. Según el informe DORA 2023, los equipos de alto rendimiento hacen releases múltiples veces al día, con una tasa de fallos inferior al 5%. Lo recomendable es empezar con releases cada 2-4 semanas y aumentar la frecuencia gradualmente. El estudio Accelerate de Forsgren, Humble y Kim demostró que las empresas con releases frecuentes tienen un 46x mayor frecuencia de deploys y un 440x menor lead time que las de bajo rendimiento.

¿Qué es un Release Candidate (RC)?

Un Release Candidate es una versión del software que se considera potencialmente lista para producción. Se somete a pruebas finales antes de ser promovida a release oficial. Si se encuentran bugs críticos, se crea un nuevo RC (rc.2, rc.3...).

¿Qué es un rollback?

Un rollback es la acción de revertir una release problemática a la versión anterior. Es el "plan B" cuando una release causa problemas en producción. Tener un proceso de rollback probado y documentado es fundamental para cualquier equipo.

¿Qué es un hotfix?

Un hotfix es una release de emergencia que corrige un bug crítico en producción. Se hace fuera del ciclo normal de releases y suele contener solo la corrección necesaria, sin funcionalidades nuevas. En SemVer, un hotfix incrementa el número de PATCH.

¿Release y deploy son lo mismo?

No. Un deploy es poner código en un entorno. Una release es hacer funcionalidades disponibles para el usuario. Puedes desplegar código a producción sin que el usuario lo vea (dark launch con feature flags), y puedes hacer una release activando funcionalidades ya desplegadas.