Desplegar consiste en poner una versión del software en un entorno, como producción. Lanzar una funcionalidad consiste en hacerla disponible para los usuarios a los que va dirigida. Ambas cosas pueden ocurrir a la vez, pero un equipo también puede desplegar el código y activar la funcionalidad más tarde. Esa separación permite comprobar el sistema antes de ampliar el acceso, siempre que la arquitectura lo admita.
Para un Product Manager, «ya está en producción» puede dejar una pregunta pendiente: ¿quién puede utilizarlo? Una mejora del checkout puede estar ejecutándose en los servidores y seguir sin estar disponible para los clientes. Si una campaña se organiza alrededor de la fecha de despliegue sin comprobar el plan de lanzamiento, puede dirigir a los usuarios hacia una funcionalidad a la que todavía no tienen acceso.
Desplegar y lanzar describen cambios distintos
Un despliegue cambia lo que se ejecuta en un entorno. Puede introducir código de la aplicación, configuración o cambios de infraestructura, y su destino puede ser un entorno de pruebas. Las comprobaciones del despliegue permiten saber si el cambio se ha aplicado y si el sistema se comporta como se esperaba.
En este artículo, lanzamiento significa poner una capacidad a disposición de una audiencia definida. Algunos equipos también utilizan «release» para referirse a una versión empaquetada o a un hito, por lo que conviene acordar el vocabulario dentro de la organización. Para planificar, la distinción útil está entre instalar un cambio y permitir que los usuarios utilicen su comportamiento.
| Pregunta | Despliegue | Lanzamiento |
|---|---|---|
| ¿Qué cambia? | La versión o la configuración que se ejecuta en un entorno. | Quién puede utilizar una capacidad y en qué condiciones. |
| ¿Cómo se comprueba? | Verificando el despliegue y el funcionamiento del sistema. | Comprobando que los usuarios elegibles acceden al comportamiento previsto. |
| ¿Puede hacerse gradualmente? | Sí, por ejemplo sustituyendo las instancias por etapas. | Sí, por ejemplo activando la funcionalidad para determinadas cuentas. |
| ¿Qué puede fallar? | La nueva versión no arranca, ralentiza servicios compartidos o rompe la compatibilidad. | La funcionalidad falla para quienes tienen acceso o produce un resultado de negocio inesperado. |
Un despliegue correcto aporta información sobre el sistema en ejecución, pero no permite confirmar todos los resultados de negocio. Los controles de salud pueden pasar mientras una promoción calcula mal el descuento de una cesta concreta. Una funcionalidad oculta también puede provocar una incidencia si su despliegue modifica código compartido o la base de datos.
Una promoción de checkout, desde el despliegue hasta su disponibilidad
En un lanzamiento hipotético de Mercato, una plataforma de comercio electrónico, Producto quiere introducir un descuento en los gastos de envío para determinados clientes. Ingeniería implementa el cálculo y coloca el nuevo comportamiento detrás de una feature flag: una decisión dentro del código, controlada mediante configuración, que selecciona qué comportamiento se ejecuta. El backend comprueba los requisitos y aplica el descuento; ocultar un botón en el navegador no bastaría.
El equipo despliega la nueva versión el martes con el acceso de los clientes desactivado. Los clientes existentes siguen utilizando el recorrido anterior del checkout. Ingeniería comprueba el estado de la versión y prueba el nuevo recorrido mediante una configuración interna controlada. Esto exige preparar ambos comportamientos; añadir una flag no garantiza que el código inactivo sea inocuo.
El miércoles se activa la promoción para un grupo pequeño y definido de cuentas que cumplen los requisitos. Ese es el primer lanzamiento de la funcionalidad a clientes. Una selección estable por cuenta mantiene la experiencia entre visitas, mientras el backend conserva el tratamiento acordado para un checkout que ya esté en marcha. El tamaño del grupo se decide para este ejemplo; no existe un porcentaje universal que haga seguro un lanzamiento.
- Desplegar la nueva versión con el acceso de clientes desactivado y comprobar el checkout existente.
- Validar el nuevo recorrido en condiciones controladas, incluidos los requisitos y el importe final del pedido.
- Activar el acceso para el grupo inicial y observar las señales técnicas y de negocio.
- Ampliar el acceso cuando las comprobaciones acordadas lo permitan; detener la ampliación o iniciar la recuperación si fallan.
El anuncio público de la promoción debe coordinarse con ese plan de disponibilidad. Si solo puede utilizarla el grupo inicial, marketing y soporte necesitan conocer la limitación. También conviene registrar qué versión de la oferta vio cada cliente, para que soporte pueda explicar un gasto de envío inesperado sin tener que deducirlo.
La apertura gradual necesita evidencias y un responsable
El equipo de Mercato observa los errores del checkout y los fallos de pago, pero también comprueba que el descuento llegue a los pedidos elegibles y que los márgenes se mantengan dentro de los límites acordados. Un aumento de los pedidos completados sería difícil de interpretar sin revisar los cambios de tráfico y qué clientes recibieron la oferta. Un lanzamiento gradual controla la exposición; no constituye automáticamente un experimento A/B bien diseñado.
Antes de ampliar el acceso, el equipo necesita observar comportamientos relevantes, como las visitas de clientes que vuelven o los pedidos que se completan con retraso. No hay un tiempo de espera fijo que sirva para todos los productos. Un checkout con mucho tráfico y un proceso empresarial que se utiliza una vez al mes ofrecen información a ritmos distintos.
El plan debe identificar quién puede ampliar o detener el acceso, qué señales obligan a revisar la decisión y quién responde fuera del horario habitual. Un cambio de flag puede afectar a producción inmediatamente o tras un tiempo de propagación, según la implementación. Antes del lanzamiento hay que conocer ese comportamiento y qué ocurre si la configuración de las flags no está disponible.
Desactivar una funcionalidad y hacer rollback de un despliegue
Si la promoción calcula descuentos incorrectos, desactivar su flag puede detener el comportamiento protegido para las siguientes peticiones cuando se propaga la configuración. La versión desplegada sigue en producción. El equipo todavía tiene que atender los checkouts en curso, los descuentos concedidos y los pedidos pagados. Cambiar la flag no deshace esos eventos de negocio.
Un rollback del despliegue devuelve el componente correspondiente a una versión o configuración anterior. Puede ser necesario si la nueva versión rompe una parte compartida del checkout, incluso con la promoción desactivada. También tiene límites: restaurar código no revierte automáticamente una migración de base de datos, cancela trabajo encolado ni recupera datos escritos con un formato nuevo. La compatibilidad determina si la versión anterior puede ejecutarse con seguridad.
En Mercato, un plan de recuperación podría detener nuevos checkouts promocionales, conservar las condiciones ya aceptadas por los clientes e investigar los pedidos afectados. Ingeniería podría entonces restaurar una versión compatible o publicar una corrección. Producto y soporte necesitan acordar cómo tratar los cobros incorrectos de forma independiente de la recuperación técnica.
Qué acordar antes de anunciar una fecha
La conversación sobre el lanzamiento puede tomar como referencia el recorrido del cliente. Así resulta más fácil distinguir la versión que se ejecuta en un servidor del comportamiento que una persona puede utilizar. Estas preguntas ayudan a convertir la distinción en requisitos de lanzamiento:
- ¿La fecha corresponde al despliegue, al primer acceso de clientes o a la disponibilidad para toda la audiencia prevista?
- ¿Qué cuentas cumplen los requisitos y recibirá el mismo cliente una experiencia consistente?
- ¿Qué comprobaciones deben pasar antes de ampliar el acceso y quién toma la decisión?
- ¿Qué sigue ejecutándose al desactivar la flag, incluidos los procesos en segundo plano y las transacciones en curso?
- ¿La versión anterior sigue siendo compatible con los datos actuales y qué necesita una acción de recuperación independiente?
- ¿Quién retirará las flags temporales y el código que deje de utilizarse cuando termine el lanzamiento?
Las aplicaciones móviles añaden otra dependencia: desplegar un cambio en el backend no instala una nueva versión de la aplicación en todos los dispositivos. La aprobación de la tienda, la instalación y la compatibilidad con versiones anteriores pueden condicionar la disponibilidad. El plan debe explicar esas limitaciones cuando la funcionalidad necesita un cliente actualizado.
La guía de CI/CD y lanzamientos explica el pipeline, los entornos y las comprobaciones automáticas. El libro CI/CD y releases para Product Managers desarrolla estas decisiones de entrega con más detalle. Para entender las consecuencias de las dependencias entre componentes, puede consultarse la guía de arquitectura de software.
Referencias técnicas
- LaunchDarkly: estrategias de despliegue y diferencia entre deployment y release.
- Unleash: estrategias de activación y ciclo de vida de las feature flags.
- Kubernetes: revisiones de un despliegue y rollback.
- Microsoft: despliegues seguros, exposición gradual y planificación de la recuperación.
