Cómo preparo y pruebo mis lanzamientos
Las publicaciones y la gestión de versiones son una parte esencial de nuestro trabajo. Publicar el producto correcto para los clientes los hará felices. Realizar una publicación sin contratiempos nos hará felices a nosotros, quienes estamos involucrados en la publicación.
¿Cómo podemos lograr una publicación sin contratiempos?
Después de haber participado en un gran número de ellas, puedo decir que hay algunos puntos clave que pueden ayudar a lograr una gestión exitosa de la publicación.
Déjame contarte cuáles son.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Una publicación exitosa comienza durante el desarrollo.
Identificación de casos de prueba
Una buena gestión de publicación comienza mucho antes del día de la publicación, desde el momento en el que la funcionalidad que se va a lanzar está en la fase de desarrollo. Durante este tiempo, la funcionalidad debe contar con la aprobación de QA. Esto significa que necesitamos probar todos los escenarios posibles que podamos imaginar, que tengan sentido para la funcionalidad dada, con el fin de validar que funciona según los requisitos. Algunos de estos escenarios serán probados por pruebas automatizadas, mientras que en otros casos, o bien es demasiado difícil o no vale la pena crear la automatización.
Cuando identificamos el tipo de pruebas que debemos realizar para la funcionalidad en cuestión, debemos considerar lo siguiente: la primera vez que esta funcionalidad se publique en producción, necesitamos probarla completamente. Debemos asegurarnos de que los clientes no encuentren problemas críticos. Debemos validar los requisitos. Y debemos garantizar el buen rendimiento de la funcionalidad.
Los retrasos y problemas en las pruebas pueden afectar gravemente los plazos al prepararse para los lanzamientos de software. Incorporar prácticas efectivas de gestión de lanzamientos ayudará a garantizar que las pruebas y el despliegue sean confiables y predecibles.
Pero una vez que la funcionalidad esté disponible en producción, salvo que se requieran actualizaciones para ella, no es necesario probarla tan minuciosamente con cada futura publicación del mismo código base. El comportamiento de la funcionalidad solo cambiará si se modificó el código subyacente o si ocurrió un cambio externo en alguna de sus dependencias. El resto del tiempo, será suficiente realizar una prueba de sanidad de la funcionalidad, donde la sanidad, por supuesto, debe incluir los casos de prueba más importantes.
Dicho esto, cuando la funcionalidad esté en desarrollo, asegúrate de evaluar: cuántos casos de prueba necesitas ejecutar; cuánto tiempo tienes disponible para probar; cuáles de los casos de prueba son críticos; y cuáles casos de prueba ejecutarás en cada publicación.
Así podrás identificar cuáles son los casos de prueba que vas a automatizar. Céntrate en cubrir con automatización al menos la funcionalidad crítica. Para el resto de las pruebas, deberías crear casos de prueba escritos, ya sea en tu sistema de seguimiento de proyectos (por ejemplo, Jira), o en la herramienta de gestión de pruebas que estés utilizando. De esta manera, no se perderán ni olvidarán, y podrán ejecutarse siempre que una publicación lo requiera.
Ejecución de las pruebas en el CI
Una vez que tengas las pruebas automatizadas, deberías comenzar a ejecutarlas a través del CI, en los entornos de desarrollo, de manera periódica. Mientras se desarrollan otras funcionalidades antes de que ocurra la publicación, es bueno asegurarse de que la funcionalidad que quieres publicar siga funcionando correctamente, especialmente si ya la aprobaste durante el sprint. Ejecutar las pruebas de la funcionalidad que te interesa, por ejemplo de forma diaria, te dará una retroalimentación rápida sobre cualquier corrección que sea necesario aplicar a la funcionalidad debido a errores causados por otros cambios en el sistema.
Detectar de manera temprana los posibles errores de la funcionalidad que se va a publicar dará tiempo suficiente para aplicar las correcciones y volver a probar la funcionalidad, sin tener el estrés de hacerlo en el tiempo limitado de la fase de publicación. Cuanta más cobertura de los requisitos tengas en tus pruebas automatizadas, más probable será que encuentres solo un pequeño número de errores en la fase de publicación.
La preproducción es importante y debe contar con un margen de tiempo.
Plazos de tiempo
La fase de publicación suele consistir en un período dedicado a probar en un entorno de integración de preproducción, aparte del día o período de publicación en producción. Como tester involucrado en la publicación, siempre procuro pedir los intervalos de tiempo adecuados para la publicación, de modo que la fase de preproducción me permita probar correctamente las funcionalidades que se van a publicar.
También siempre considero un margen de tiempo, porque espero que surjan problemas imprevistos dentro del proceso de gestión de publicaciones, ya sean errores en las funcionalidades a publicar o factores externos. Sólo para mencionar uno de estos factores, los entornos de preproducción son entornos de pruebas y son propensos a no ser lo suficientemente confiables. Muchas veces funcionan muy lento o se vuelven inaccesibles por un tiempo, justo cuando se están realizando las pruebas de publicación.
Tener tiempo adicional como margen siempre es una buena idea, y aunque no uses ese tiempo extra, está bien. Puedes dar tu visto bueno antes de que termine el tiempo asignado para pruebas, ya que puedes dedicar el resto del tiempo a trabajar en otra cosa. Es peor no tener un margen de tiempo y necesitarlo, porque en ese caso tendrás que encajar todas las pruebas necesarias en un periodo más reducido. Esto podría provocar que algunos casos de prueba no se ejecuten, lo cual podría llevar a que algunos errores solo se descubran directamente en producción.
Alcance
Otro aspecto importante de la liberación previa a producción, desde mi punto de vista, es contar con un coordinador de gestión de versiones dedicado. Para mí, esto significa alguien que se encargue de ciertos aspectos, siendo el primero de ellos: verificar el alcance de la liberación. Antes de empezar a probar cualquier versión, el tester necesita saber qué debe probar. Eso se reduce al alcance de la liberación.
El equipo de producto, es decir, los PO o BA, esperan que determinadas funcionalidades entren en la versión, y esto se acuerda cuando inicia el desarrollo. Sin embargo, el código que se incorpora en la versión final puede no cubrir exactamente el alcance esperado por el equipo de producto. A veces, alguien olvida subir el código a la rama desde la cual se genera la versión. O peor aún, pueden subir código a esa rama que no debería estar. Esto puede representar funcionalidades que aún no están terminadas ni aprobadas por QA, o funcionalidades que no pertenecen al alcance actual.
Para garantizar que se cumpla el alcance, el coordinador de liberación debería comparar el alcance esperado con el real. Para esto, el alcance esperado debe provenir del equipo de producto y debe estar claramente especificado en algún tipo de documento (y quizás en tu plan de garantía de calidad). Por ejemplo, podrías tener algún tipo de documento de planificación, que muestre los hitos del proyecto y qué se incluye en cada hito.
Para el alcance real, se debe extraer un registro de cambios desde el VCS (Sistema de Control de Versiones, por ejemplo Git) que esté usando el proyecto. El registro de cambios reflejará todos los "commits" hechos durante la fase de desarrollo a la rama que generará la versión de liberación. Esperemos que, si trabajas de forma organizada, cada commit tenga una descripción que apunte a un elemento de Jira al que se refiere el código. De esta manera, puedes ver todos los elementos de Jira que tienen código correspondiente incluido en la versión, y cuáles de estos elementos no deberían haber sido incluidos en este build. Por supuesto, si encuentras que estos commits están relacionados con correcciones de errores necesarias, eso está perfectamente bien. Lo que no quieres es que estos commits representen trabajo de funcionalidades no acabadas o relacionadas con características que no deberían entrar en producción con la liberación actual.
A medida que avanzas en técnicas avanzadas de gestión de versiones, verás que integrar tus procesos con soluciones de gestión de pruebas diseñadas para Jira puede ofrecerte un flujo de trabajo más cohesivo y eficiente.
Cuando se detecta una discrepancia entre el alcance esperado y el real, el coordinador de liberación debe interactuar con el equipo de producto y los managers del equipo de desarrollo para identificar cuál es el mejor enfoque. Si los commits detectados como fuera de alcance representan trabajo de funcionalidades no acabadas, lo mejor es eliminarlos. Esto se debe a que ya estás en la fase de liberación previa a producción, y no quieres arriesgarte a que el código pendiente se escriba y pruebe de prisa solo para que acabe en la versión. Esto es arriesgado, ya que esa prisa puede llevar a que se olviden casos de prueba y se ejecuten incompletamente, permitiendo que errores críticos lleguen a producción. Lo mejor, en este caso, es permitir que el trabajo restante de esas funcionalidades se complete adecuadamente para una liberación futura.
Las pruebas
Una vez que el alcance está claro, debe comenzar la fase de pruebas. Durante la fase de pruebas previa a producción, necesitas volver a validar toda la funcionalidad que vas a lanzar. Debes imaginar que es la primera vez que la ves, y probar cada escenario que ya realizaste durante la fase de desarrollo. Ejecuta las pruebas automatizadas que ya escribiste, pero en el entorno pre-producción, y no olvides los escenarios no automatizados. Realiza una regresión completa sobre la funcionalidad, por el simple motivo de que cuando llegas a esta fase de gestión de versiones, y en el entorno pre-producción, probablemente habrá otros equipos que también deban hacer sus lanzamientos en el mismo periodo de tiempo. Básicamente, es la primera vez en que todas las dependencias se reúnen, con código listo para producción, en el mismo entorno. Y esta, en teoría, es la configuración que ejecutará la producción a partir de la liberación.
A menos, claro, que se descubran problemas durante las pruebas y se requieran correcciones. Si eso ocurre, debes considerar qué necesitas volver a probar. No importa si la corrección está en tu código o en el de alguna dependencia externa, si los cambios afectan de algún modo a tu funcionalidad, tienes que plantearte otra ronda de pruebas. Asegúrate de volver a probar al menos la funcionalidad crítica.
Esto puede parecer aburrido, especialmente si se producen muchas correcciones durante esta fase. Sin embargo, no puedes predecir con exactitud el impacto que pueden tener dichas correcciones en diferentes partes de tu funcionalidad.
Pequeños cambios pueden tener grandes repercusiones, así que es mejor aburrirse, pero estar seguro de que la funcionalidad crítica sigue funcionando correctamente, que lamentar no haber probado lo suficiente.
Y, por supuesto, si se descubre algún error menor durante esta fase de pruebas, no te molestes en corregirlo en este momento. De nuevo, no quieres apresurar ninguna implementación ni prueba en una funcionalidad que, de otro modo, funciona perfectamente, para no introducir el riesgo de que algo se rompa.
Durante la publicación, la comunicación y las pruebas son clave.
Una vez que la funcionalidad ha sido aprobada en el entorno de preproducción, está lista para pasar al entorno de producción.
Comunicación
En lo referente a la publicación en producción, el coordinador de gestión de la publicación tiene algunas tareas que cumplir. Primero que todo, la fecha y la hora de la publicación deben establecerse adecuadamente con antelación y comunicarse a todas las partes involucradas. Me parece que tener la fecha y la hora de la publicación programadas como una reunión en los calendarios de los participantes es muy útil para la gestión, ya que permite que los participantes organicen su día; esta es una tarea que puede realizar el coordinador.
El día de la publicación, el coordinador debe recordar a todos los involucrados los plazos de la liberación. Idealmente, la comunicación debería hacerse en un canal que todos utilicen, por ejemplo, Slack. Contar con un canal específico en Slack donde se comuniquen todos los aspectos importantes asegura que todos los involucrados tengan el mismo entendimiento sobre en qué paso está la publicación, cuál es el alcance, qué problemas se detectan y quién puede ayudar con ellos. Este tipo de comunicación garantiza que cualquier persona que necesite saber ciertos aspectos verá esta información, a diferencia de la comunicación verbal (donde esa persona podría estar ausente, y quien comunica la información podría no percatarse de su ausencia).
El coordinador de gestión de la publicación debe hacer un seguimiento y anunciar los hitos de la publicación en este canal, como cuándo empieza la publicación y cuándo ha sido aprobada. Además, cada parte involucrada debe informar por este canal que está realizando sus pasos asignados para que todos tengan conocimiento del estado y el avance de la publicación. Si alguna parte que se requiere en cierto momento no está disponible, el coordinador debe ponerse en contacto con la(s) persona(s) adecuada(s) para que todo transcurra sin contratiempos.
Las pruebas
Durante la publicación en producción, nuevamente se deben realizar todas las pruebas de la nueva funcionalidad. Esto se debe a que, aunque la funcionalidad fue aprobada en otros entornos de prueba, dichos entornos no son 100% idénticos en configuración y recursos al de producción.
Para prevenir comportamientos imprevistos no deseados de la funcionalidad publicada, es importante ejecutar todas las pruebas automatizadas disponibles, junto con aquellos elementos no automatizados para los cuales se han escrito casos de prueba. Nunca apruebes en producción una funcionalidad sin haberla probado.
Asumir que la funcionalidad funciona en producción no significa que realmente lo haga.
Asegúrate de que funcione, pruébala.
Después de la publicación
Así que la publicación está hecha. Pero, asegurarse de que la funcionalidad funciona correctamente implica más trabajo que solo probarla en la fase de publicación.
Una vez hayas terminado eso, asegúrate de tener tus pruebas automatizadas ejecutándose en el CI, para producción. Esto te permitirá detectar cualquier comportamiento no deseado causado por cambios externos de los que quizá no tengas conocimiento.
Monitorea de forma constante el rendimiento de la funcionalidad para asegurarte de que la carga de producción y el uso por parte de los clientes no esté causando una degradación en el rendimiento. Y asegúrate de estar atento a cualquier reporte de problemas recibido por parte de tus clientes. Estos pueden señalar áreas que no funcionan correctamente y así puedes programar rápidamente una actualización futura si es necesario.
Y, en caso de que la publicación no haya salido como se esperaba, asegúrate de organizar una reunión retrospectiva después de la publicación. Allí puedes abordar todos los problemas que ocurrieron durante el proceso de gestión de la publicación y asignar acciones a las personas relevantes, de modo que cualquier publicación futura se realice de una manera fluida y exitosa.
