Una implementación terminada puede seguir pendiente de revisión, pruebas o despliegue. Planificar un lanzamiento exige saber qué pasos faltan y cuándo podrán utilizar el cambio los clientes.
Entre un ingeniero que escribe código y un cliente que utiliza la nueva funcionalidad, normalmente deben suceder varias cosas: el código se combina, se prueba, se construye, se implementa y finalmente se lanza. Los equipos de software modernos automatizan gran parte de este proceso utilizando CI/CD canalizaciones.
Para Producto, estas etapas afectan a las fechas, la exposición del lanzamiento y las opciones de recuperación. La planificación puede separar el despliegue del código de la decisión de poner una funcionalidad a disposición de los clientes. Esta guía cubre CI/CD y los conceptos de lanzamiento que son más útiles desde la perspectiva de un Product Manager.
¿Qué es CI/CD?
CI/CD generalmente se refiere a Integración continua (CI) y Entrega continua o Implementación continua (CD). En conjunto, estas prácticas ayudan a los equipos a integrar, probar y entregar cambios de software con mayor frecuencia y confiabilidad.
El viaje desde escribir código hasta poner una función en manos de los usuarios implica varios pasos. Un desarrollador escribe un cambio, ese código se integra con el resto de la aplicación, las pruebas automatizadas verifican que todo siga funcionando y se crea una nueva versión de la aplicación. A partir de ahí, se puede implementar el software y, eventualmente, la función se puede lanzar a los usuarios.
Una versión simplificada de ese viaje se ve así:
Código → Integración → Pruebas automatizadas → Compilación → Implementación → Lanzamiento
Hacer todo esto manualmente cada vez que un equipo realiza un cambio sería lento y propenso a errores. Las canalizaciones CI/CD automatizan muchos de estos pasos, creando un proceso repetible para mover el software del desarrollo a la producción.
¿Por qué los Product Managers deberían comprender CI/CD?
La entrega es parte de la gestión de productos porque una característica que se está "realizando" puede significar cosas muy diferentes según quién esté hablando. Cuando Ingeniería le informa que una función está finalizada, es posible que el código se haya escrito pero aún esté esperando revisión o prueba. Es posible que haya pasado todas las pruebas pero que solo exista en un entorno de prueba, o que ya se haya implementado en producción sin estar disponible para los usuarios todavía.
Conviene describir el estado de la entrega con términos concretos: código revisado, comprobaciones superadas, despliegue en un entorno determinado o funcionalidad habilitada para un grupo de clientes. En cada estado queda un trabajo distinto.
Una decisión de lanzamiento con el pipeline en verde
Escenario ilustrativo: un motor nuevo de promociones supera las comprobaciones automáticas. Ingeniería puede desplegarlo detrás de una feature flag. Eso indica que el cambio puede avanzar por el pipeline; no demuestra que se hayan evaluado todas las reglas de promoción ni todos los riesgos comerciales.
Prepara un acuerdo breve de lanzamiento con Ingeniería y QA:
- Audiencia inicial: ¿quién recibe primero la funcionalidad y qué casos importantes cubrirá ese grupo?
- Evidencia: ¿qué escenarios de descuento, pago y devolución se han comprobado y qué defectos conocidos siguen pendientes?
- Señales: ¿quién vigila los fallos de pago, los importes incorrectos y los avisos a soporte tras la activación?
- Respuesta: ¿quién puede detener el despliegue progresivo y qué ocurre con los pedidos ya creados?
Acuerda los umbrales con el equipo a partir del comportamiento habitual y el riesgo de tu producto. Un porcentaje universal escondería ese contexto. Comprueba también que desactivar la flag detiene el comportamiento afectado: puede que no deshaga un cobro, revierta datos guardados o cancele trabajos que ya están en cola.
Decisión que te llevas: distingue el despliegue, la exposición a usuarios y la recuperación. Un pipeline en verde es una evidencia más. La decisión de lanzamiento también necesita audiencia, comprobaciones, monitorización y una respuesta que el equipo pueda ejecutar.
La documentación de feature flags de GitLab explica cómo separar la entrega del lanzamiento a clientes. Para conectar testing y releases, consulta nuestra guía de libros técnicos.
¿Qué es la integración continua?
Los productos de software generalmente los crean varios ingenieros que trabajan en diferentes cambios al mismo tiempo. Esos cambios eventualmente deben unirse, y cuanto más tiempo permanezcan separados, mayor será la posibilidad de que algo no funcione como se espera cuando se combinen.
Integración continua (CI) aborda este problema animando a los equipos a integrar cambios de código con frecuencia y comprobar automáticamente que funcionan con el resto de la aplicación. Un proceso típico podría verse así:
Cambio de código → Confirmar → Comprobaciones automatizadas → Pruebas → La compilación tiene éxito o falla
Ejecutar estas comprobaciones cada vez que se integra código nuevo permite a los equipos identificar los problemas mucho antes, en lugar de descubrirlos después de que se hayan acumulado varios cambios. Una ejecución de CI satisfactoria aporta evidencias sobre las comprobaciones incluidas en el pipeline. No demuestra comportamientos que esas comprobaciones no cubran, de modo que pueden seguir siendo necesarias otras pruebas y una revisión del lanzamiento.
¿Por qué son importantes las pruebas automatizadas?
Cada cambio de software introduce cierto grado de riesgo porque modificar una parte de un producto puede tener efectos inesperados en otra parte. Las pruebas automatizadas ayudan a reducir ese riesgo al verificar repetidamente que la funcionalidad existente aún se comporta como se espera después de introducir el nuevo código.
Imagine, por ejemplo, que el equipo realiza un cambio en el proceso de pago. Las pruebas automatizadas podrían verificar que los usuarios aún pueden completar el recorrido principal:
Agregar un artículo → Iniciar pago → Enviar pago → Crear un pedido
Las pruebas automatizadas pueden detectar regresiones cuando cambia el checkout. Su utilidad depende de los comportamientos cubiertos y de la fiabilidad con la que detecten fallos; un porcentaje alto de cobertura no demuestra por sí solo que el lanzamiento sea seguro.
¿Qué es una compilación?
Antes de que se pueda implementar o distribuir el software, el código fuente a menudo necesita pasar por un proceso de compilación que lo transforma en una versión que el sistema realmente pueda ejecutar. En términos simples, el viaje se ve así:
Código fuente → Proceso de compilación → Aplicación implementable
Es por eso que es posible que escuche a los ingenieros hablar sobre "la última versión" o decir que "la compilación falló". Si la compilación no se puede completar exitosamente, el cambio generalmente no puede continuar a través del proceso de entrega hasta que se solucione el problema.
Para los Product Managers, la distinción útil es que escribir el código y tener una versión funcional de la aplicación lista para implementar no son necesariamente lo mismo. Una característica puede estar completa desde una perspectiva de desarrollo, pero aun así fallar en un paso posterior antes de que pueda pasar a producción.
¿Qué es una canalización CI/CD?
Una canalización es una secuencia automatizada de pasos por los que pasa el software a medida que pasa del código a la producción. Aunque el proceso exacto varía entre organizaciones, un proceso simplificado podría verse así:
CÓDIGO → CONSTRUIR → PRUEBA → IMPLEMENTAR → LANZAR
En la práctica, una canalización puede incluir muchos más pasos. Los equipos pueden verificar automáticamente la calidad del código, ejecutar diferentes tipos de pruebas, realizar controles de seguridad, crear la aplicación, implementarla en un entorno de prueba y verificar que todo esté funcionando correctamente antes de permitir que el cambio llegue a producción.
La configuración de los pipelines varía según la aplicación y los controles del equipo. Para planificar el lanzamiento hay que identificar qué comprobaciones, entornos y aprobaciones separan una implementación terminada del acceso de los clientes.
Entornos: DEV, QA, staging y producción
Los equipos de software suelen trabajar con varios entornos, lo que permite crear y probar cambios sin afectar inmediatamente a los clientes reales. Es posible que encuentre nombres ligeramente diferentes según la empresa, pero una configuración común incluye DEV, donde se desarrolla activamente el software; QA o TEST, donde los equipos verifican que se comporta como se espera; STAGING o PREPRODUCCIÓN, que está diseñada para parecerse lo más posible al entorno de producción; y por último PRODUCCIÓN, el entorno utilizado por los clientes reales.
Por lo tanto, un recorrido simplificado a través de estos entornos podría verse así:
DEV → QA → STAGING → PRODUCCIÓN
No todas las empresas utilizan exactamente esta estructura y algunas organizaciones tienen entornos adicionales o nombres diferentes para ellos. Para un Product Manager, recordar la terminología es menos importante que saber en qué entorno se encuentra actualmente una función. Por ejemplo, que algo funcione perfectamente en control de calidad no significa que los clientes puedan usarlo todavía.
Implementación frente a lanzamiento
Una de las distinciones más útiles para los Product Managers es la diferencia entre una implementación y una versión. A menudo se habla de ellos como si fueran la misma cosa, pero no necesariamente ocurren al mismo tiempo.
Una implementación significa colocar una versión del software en un entorno. Una versión, por otro lado, significa poner la funcionalidad a disposición de los usuarios. Esto significa que un equipo puede implementar código nuevo en producción mientras mantiene oculta la característica correspondiente.
Por ejemplo:
Versión B implementada en producción → La función permanece desactivada → Pruebas y verificación → Función activada
En este escenario, el software ya se estaba ejecutando en producción antes de que los usuarios pudieran acceder a la nueva funcionalidad. Separar la implementación del lanzamiento brinda a los equipos mucho más control sobre cuándo y cómo una característica llega a los clientes, y uno de los mecanismos que lo hace posible es la marca de característica.
¿Qué son las marcas de características?
Una marca de función permite activar o desactivar la funcionalidad sin necesariamente implementar otra versión del software. Imagine que el equipo ha desarrollado un nuevo pago y el código ya se está ejecutando en producción, pero la función está configurada como:
Nuevo pago: DESACTIVADO
Cuando el equipo esté listo para ponerlo a disposición, la configuración puede cambiar a:
Nuevo pago: activado
El punto importante es que el código no llegó repentinamente a producción cuando se activó la bandera; ya estaba allí. La bandera simplemente controlaba si los usuarios podían acceder a ella.
Los indicadores de funciones también pueden proporcionar un control mucho más granular que un simple interruptor de ENCENDIDO/APAGADO. Un equipo podría habilitar una función primero para los empleados, luego para los usuarios beta, luego para el 10% de los clientes y, finalmente, para todos. Dependiendo del sistema, el acceso también podría controlarse por mercado, plataforma, tipo de cliente u otros criterios.
Esto hace posible separar dos decisiones que de otro modo estarían estrechamente relacionadas: cuándo se implementa el código y cuándo se expone la función a los usuarios.
¿Por qué las marcas de funciones son útiles para los Product Managers?
Esa separación crea varias opciones útiles desde la perspectiva de la gestión de productos. Una función se puede probar internamente antes del lanzamiento, exponerse a un grupo beta, implementarse gradualmente para los clientes, usarse como parte de un experimento o lanzarse solo en mercados seleccionados. Un equipo también puede desactivar rápidamente funciones problemáticas sin implementar otra versión.
Por lo tanto, los indicadores de características no son simplemente un mecanismo de ingeniería. Pueden formar parte de la estrategia de lanzamiento del producto, lo que brinda a los equipos de Producto e Ingeniería más flexibilidad sobre quién recibe una función, cuándo la recibe y con qué rapidez aumenta la exposición.
¿Qué es una reversión?
A veces, una implementación introduce un problema grave. Si el problema es lo suficientemente importante, una posible respuesta es una reversión, lo que significa devolver el software a una versión anterior.
Conceptualmente, el proceso podría verse así:
Versión A → Implementar la versión B → Aparecen problemas → Revertir → Volver a la versión A
Revertir puede ser una forma efectiva de recuperarse de una implementación problemática, pero no siempre es la única opción. Si el problema se limita a la funcionalidad controlada por una marca de función, es posible que el equipo pueda mantener la versión actual del software y simplemente desactivar esa función.
Por ejemplo:
Versión B + Nuevo pago activado → Problema detectado → Versión B + Nuevo pago desactivado
En este caso, la versión B permanece implementada. Sólo se ha desactivado la funcionalidad problemática.
Revertir frente a indicador de función
Por lo tanto, la reversión y los indicadores de funciones pueden ayudar a los equipos a recuperarse de los problemas, pero lo hacen de diferentes maneras. Una reversión devuelve el software a una versión anterior, mientras que un indicador de función permite que la versión actual permanezca en su lugar mientras una funcionalidad específica está deshabilitada.
La distinción se vuelve particularmente importante cuando una implementación contiene varios cambios. Revertir toda la versión podría eliminar la funcionalidad que funciona correctamente junto con el cambio problemático. Si ese cambio se controla de forma independiente mediante un indicador de función, desactivarlo puede proporcionar una respuesta mucho más específica.
No existe una opción universalmente correcta. La respuesta adecuada depende de qué falló, cómo está diseñado el software y qué mecanismos de recuperación tiene disponible el equipo.
¿Qué es un lanzamiento por fases?
Lanzar una función no significa necesariamente que esté disponible para todos los usuarios al mismo tiempo. Los equipos pueden utilizar una implementación por fases para aumentar gradualmente el porcentaje de usuarios que reciben un cambio.
Por ejemplo:
1% → 5% → 20% → 50% → 100%
En cada etapa, el equipo tiene la oportunidad de observar cómo se comporta la nueva versión antes de ampliar su exposición. Podrían buscar aumentos en los errores, cambios en el rendimiento o movimientos inesperados en las métricas del producto. Si algo empieza a salir mal, es posible que el lanzamiento se detenga antes de que todos los clientes se vean afectados.
Esto ofrece a los equipos otra forma de gestionar el riesgo de lanzamiento: en lugar de intentar eliminar todos los problemas posibles antes del lanzamiento, también pueden limitar el impacto de un problema desconocido controlando la exposición inicial.
¿Qué es una versión canary?
Una versión canary sigue un principio similar. En lugar de enviar una nueva versión a todo el tráfico de inmediato, el equipo la expone primero a un pequeño subconjunto de usuarios o tráfico y observa lo que sucede.
Si el sistema continúa comportándose normalmente, se puede aumentar la exposición. Si aparecen problemas, el equipo puede detener o revertir la implementación antes de que el problema afecte a una población mucho mayor.
Un canary necesita criterios de observación, un periodo de seguimiento y una decisión sobre cuándo ampliar o detener la exposición. Un público reducido limita el impacto, pero puede no representar a todos los clientes ni revelar fallos poco frecuentes.
¿Qué es la implementación azul-verde?
Laimplementación azul-verde es otra estrategia diseñada para hacer que los cambios de software sean más seguros. En lugar de reemplazar directamente la versión de producción existente, el equipo mantiene dos entornos de producción. Imagine que BLUE actualmente ofrece a los usuarios la Versión A, mientras que GREEN contiene la nueva Versión B que se está preparando:
AZUL → Versión A → actualmente sirviendo a los usuarios
VERDE → Versión B → en preparación
Una vez validada la Versión B, el tráfico se puede redirigir de AZUL a VERDE. Si aparece un problema grave después del cambio, el sistema puede permitir que el tráfico se redirija nuevamente a AZUL.
El tráfico puede volver al entorno anterior si este sigue siendo compatible con los datos y las dependencias compartidos. Los cambios en bases de datos necesitan, en particular, un plan de recuperación que vaya más allá de cambiar el tráfico.
Los lanzamientos no siempre son de todo o nada
Los lanzamientos de productos a menudo se analizan como si solo tuvieran dos estados posibles: no lanzado y lanzado. La entrega de software moderna permite mucha más flexibilidad. Una característica ya podría estar implementada pero deshabilitada, disponible solo para empleados o usuarios beta, lanzada en un país, expuesta al 10% de los clientes, limitada a nuevos usuarios o habilitada en todas partes excepto en una plataforma en particular. Por lo tanto, puede haber muchos estados intermedios entre “no disponible” y “disponible para todos”.
Para los Product Managers, esto crea oportunidades más allá de la gestión de riesgos técnicos. La forma en que se lanza una función puede respaldar las pruebas, la experimentación, la secuenciación del mercado y la comunicación con el cliente. La estrategia de lanzamiento en sí misma puede convertirse en una herramienta de gestión de productos.
Lanzamientos web frente a lanzamientos de aplicaciones móviles
Los productos web y las aplicaciones móviles difieren de manera importante cuando se trata de entrega de software. En muchos productos web, la empresa controla el software que se ejecuta en sus propios servidores. Por lo tanto, a menudo se puede implementar una nueva versión web o backend de forma centralizada y los usuarios interactúan automáticamente con la nueva versión la próxima vez que usan el producto.
Las aplicaciones móviles introducen otro paso:
Nueva versión de la aplicación → App Store / Google Play → Dispositivo del usuario → Actualizaciones del usuario
Una vez que una aplicación se ha distribuido a través de una tienda de aplicaciones, la empresa no controla completamente cuándo cada usuario instala la nueva versión. Algunos usuarios actualizan inmediatamente, otros esperan y algunos pueden seguir usando una versión anterior durante mucho tiempo.
Como resultado, varias versiones de la misma aplicación pueden estar activas simultáneamente:
4.6 ← versión más reciente
4.5
4.4
4.3 ← algunos usuarios todavía aquí
Esa fragmentación crea una complejidad adicional de ingeniería y productos que no existe de la misma manera con las aplicaciones web controladas centralmente.
Fragmentación de versiones
Cuando los clientes ejecutan diferentes versiones de una aplicación móvil, es posible que los sistemas backend deban admitir varias versiones al mismo tiempo. Por ejemplo:
Aplicación 4.4 ─┐
Aplicación 4.5 ─┼──→ Backend
Aplicación 4.6 ─┘
Es posible que un cambio de backend que funcione perfectamente con la aplicación más nueva deba seguir siendo compatible con los clientes que ejecutan una versión anterior. Quitar o cambiar algo en el backend sin tener en cuenta a esos usuarios podría afectar la funcionalidad de las personas que aún no han actualizado su aplicación.
Esta es una de las razones por las que los lanzamientos móviles a menudo requieren una coordinación cuidadosa entre los equipos de frontend y backend. El equipo no necesariamente admite una única versión del producto en un momento dado.
Por qué las reversiones móviles son diferentes
Esto también cambia lo que sucede cuando una versión sale mal. Con una aplicación del lado del servidor, un equipo puede revertir una implementación problemática con relativa rapidez porque controla el software que se ejecuta en sus servidores.
Con una aplicación móvil, es posible que los usuarios ya tengan instalada la versión problemática en sus dispositivos. No puedes simplemente eliminar esa versión de cada teléfono y restaurar la anterior. En cambio, la recuperación podría parecerse más a esto:
Error descubierto en 4.6 → Corrección creada → Nueva compilación → Validación → Distribución en tienda → Actualización de usuarios
Ese proceso puede llevar mucho más tiempo e incluso después de que la versión corregida esté disponible, los usuarios aún deben instalarla. Comprender esta diferencia ayuda a los Product Managers a pensar en el riesgo de lanzamiento antes de distribuir una versión móvil, particularmente cuando un cambio afecta una funcionalidad crítica.
Riesgo de liberación
No todas las versiones merecen el mismo nivel de precaución. Cambiar el color de un botón secundario no tiene el mismo impacto potencial que modificar el procesamiento de pagos, la autenticación u otro proceso crítico.
Al evaluar el riesgo de liberación, las preguntas útiles incluyen:
- ¿Cuántos usuarios podrían verse afectados?
- ¿Qué viajes críticos están involucrados?
- ¿Se puede desactivar el cambio de forma independiente?
- ¿Podemos retroceder?
- ¿Podemos publicar gradualmente?
- ¿Con qué rapidez detectaríamos un problema?
- ¿Qué tan rápido podríamos recuperarnos?
- ¿Están involucrados sistemas externos?
La estrategia de lanzamiento puede entonces reflejar el impacto potencial de la falla. Es posible que un cambio de bajo riesgo no necesite controles elaborados, mientras que un cambio que afecte a los pagos u otra capacidad crítica podría justificar una exposición gradual, un seguimiento adicional o un plan de recuperación claro.
Observabilidad y lanzamientos
Una versión segura no finaliza cuando el proceso de implementación informa que fue exitoso. Una vez que un cambio llega a producción, los equipos aún necesitan comprender cómo se comportan el sistema y el producto posteriormente. Señales técnicas como tasa de error, tiempo de respuesta y tasa de fallos pueden revelar si el software en sí está en buen estado. Al mismo tiempo, las señales del producto, como errores de pago, conversión, activación o contactos de soporte, pueden mostrar si el cambio está afectando a los usuarios de maneras inesperadas.
Esta distinción es importante porque una implementación puede ser técnicamente exitosa mientras que el resultado del producto empeora. Imagine que la canalización se completa sin errores y la nueva versión llega a producción exitosamente, pero la conversión de pago cae un 12%.
Implementación exitosa ✓ → Conversión de pago ↓ 12%
Nada necesariamente salió mal con la implementación en sí. El software llegó a producción exactamente según lo previsto. El problema es que los usuarios ahora se comportan de manera diferente o encuentran un problema para el cual la canalización no fue diseñada para detectar.
Aquí es donde la entrega de software se conecta directamente con la observabilidad y métricas del producto. Saber que una versión llegó a producción es sólo el comienzo; Los equipos también necesitan saber qué sucedió una vez que los clientes comenzaron a usarlo.
¿Qué sucede cuando una versión sale mal?
Imagine que se acaba de implementar una nueva versión. Poco después, el equipo nota que la tasa de error aumenta, la conversión de pago disminuye y los contactos de soporte comienzan a aumentar.
La respuesta puede implicar varios pasos:
Detectar el problema → Investigar → Detener el lanzamiento → Desactivar la función o revertir → Recuperar → Entender lo que sucedió
Exactamente lo que suceda dependerá del sistema y del problema. Es posible que simplemente se detenga una implementación gradual. Un indicador de función podría permitir al equipo desactivar la funcionalidad afectada, mientras que un problema más amplio podría requerir revertir la implementación por completo.
Una vez que se haya resuelto el problema inmediato, el equipo puede investigar lo que sucedió y decidir si se necesitan cambios en el software, las pruebas, el monitoreo o el proceso de lanzamiento. Este es uno de los puntos donde se unen CI/CD, la observabilidad, la arquitectura de software y la gestión de productos.
Preguntas que los Product Managers deben hacer antes de un lanzamiento
Antes del lanzamiento conviene establecer quién puede detener la exposición, qué evidencias activarían esa decisión y cómo se informará a los usuarios afectados. Esas responsabilidades deben estar claras mientras el sistema funciona correctamente.
Antes de un lanzamiento importante, algunas preguntas útiles incluyen:
- Alcance: ¿Qué se publica exactamente?
- Usuarios: ¿Quién lo recibirá?
- Tiempo: ¿Cuándo estará disponible?
- Dependencias: ¿Es necesario implementar algo más primero?
- Control: ¿Se puede habilitar o deshabilitar la función de forma independiente?
- Lanzamiento: ¿Podemos lanzarlo gradualmente?
- Riesgo: ¿Qué podría salir mal?
- Detección: ¿Cómo sabremos si algo sale mal?
- Recuperación: ¿Podemos revertir o desactivar la función?
- Métricas: ¿Qué supervisaremos después del lanzamiento?
- Propiedad: ¿Quién es responsable si es necesaria una intervención?
Estas no son preguntas diseñadas para convertir a un Product Manager en la persona responsable de DevOps. Ayudan a convertir una implementación técnica en un plan de lanzamiento de producto, conectando lo que Ingeniería está haciendo con los usuarios, el tiempo, el riesgo y los resultados esperados.
“Listo” tiene varios significados
Una de las razones por las que las conversaciones de entrega pueden volverse confusas es que la palabra “hecho” puede referirse a varios estados diferentes. Es posible que una función tenga el código completo pero aún no se haya probado. Es posible que haya pasado las pruebas, pero aún esté esperando su implementación. Podría ya implementarse en producción pero permanecer oculto detrás de una marca de característica, o podría haberse lanzado solo para el 10% de los usuarios. Incluso después de que esté disponible para todos, aún queda otra pregunta: ¿está realmente dando el resultado que esperábamos?
Conviene registrar con precisión el estado de la funcionalidad para que el plan de lanzamiento refleje el trabajo pendiente. Código terminado, desplegado y habilitado para clientes describen hitos distintos. Esa pregunta le brinda mucha más información sobre lo que ya sucedió, lo que aún debe suceder y si la función está realmente en manos de los usuarios.
¿Los Product Managers deben comprender CI/CD?
Las conversaciones sobre un lanzamiento necesitan una visión compartida del estado del cambio, su exposición y las acciones de recuperación disponibles. El equipo puede documentarlas junto con el resultado esperado para el cliente. Los conceptos de esta guía permiten concretar el plan: qué entorno contiene el cambio, qué comprobaciones ha superado, quién puede habilitarlo y qué ocurriría si empeoran las métricas de producto.
Profundice: CI/CD y releases para Product Managers
El libro CI/CD y Releases para Product Managers recorre el camino desde la integración del código hasta la distribución y el acceso de los clientes.
Cubre canalizaciones, entornos, pruebas automatizadas, implementaciones, indicadores de funciones, reversiones, lanzamientos por fases y distribución móvil, con un enfoque particular en cómo esos conceptos afectan la planificación de productos, el riesgo de lanzamiento y la colaboración con equipos de ingeniería.
Explore el libro → CI/CD y releases para Product Managers
Continuar aprendiendo Gestión Técnica de Productos
El centro de aprendizaje de Gestión técnica de productos también cubre API, arquitectura de software, SQL y datos, métricas de productos, registros y observabilidad, y seguridad.
Explore el Centro de aprendizaje sobre gestión técnica de productos
Para ver un caso de checkout, consulta Desplegar y lanzar una funcionalidad: qué cambia para un Product Manager, con acceso gradual, feature flags y recuperación.