Cuando se trata de la entrega scrum, la gente suele esperar una ejecución del lanzamiento tras el final de un sprint. Esto significa directamente después de una exitosa presentación de demostración al cliente.
Pero siempre me he preguntado cómo puede ser ésta una expectativa tan automática. Sobre todo si se tienen en cuenta las siguientes actividades posibles que deben suceder antes o al mismo tiempo.
- Desarrollar y completar todas las historias dentro del sprint. Algunas podrían completarse antes, pero la mayoría de las veces, las historias se completan justo antes del final del sprint. Puede que incluso después de la presentación de la demo, para ser abiertos aquí.
- Realice todas las pruebas programadas sobre el contenido del sprint para asegurarse de que el código que se va a liberar está listo para la producción.
- Póngase al día con los errores descubiertos y arréglelos a tiempo antes de que se produzca el lanzamiento.
- Asegúrese de que la canalización de despliegue se actualiza con el contenido más reciente y de que la propia canalización se ejecuta de forma fiable.
- Ejecute la canalización en todos los entornos pertinentes para ponerlos en el estado más reciente tanto desde el punto de vista del código como de los datos.
- Prepare notas de lanzamiento y comunique al cliente el impacto del lanzamiento y qué cambiará exactamente después.
- Si procede, sincronice con otros equipos scrum paralelos para asegurarse de que el contenido dependiente se lanzará simultáneamente. No debe faltar nada para garantizar que el contenido de su lanzamiento funcionará como se espera.
- Además de todo esto, repase todas las ceremonias scrum. No sólo las relacionadas con el sprint actual, sino también las previstas para el siguiente sprint (por ejemplo, las sesiones de refinamiento de historias).
Ahora imagine que el sprint tiene dos semanas.
Las actividades de lanzamiento por sí mismas requieren tiempo y personas para completarse. Pero no puede llevar demasiado. Justo después del último día del sprint llega directamente el primer día del siguiente sprint, y el círculo comenzará de nuevo.
¿Sigue pareciendo tan automática la expectativa de liberación después de cada sprint?
Procesamiento del contenido de liberación
Si todos los procesos dentro del sprint están automatizados, existe la posibilidad de simplemente «apretar el gatillo» e instalar la última versión del código en producción al final de cada sprint. El problema es que nunca he experimentado un estado tan perfecto del equipo scrum.
Si realmente es así en algunas pequeñas empresas privadas, realmente las envidio. Pero la realidad en el mundo corporativo es que un equipo scrum no alcanzará ese nivel de madurez. Al contrario, los procesos de release suelen estar relacionados con actividades que consumen mucho tiempo y que alcanzan la mayor parte del sprint siguiente, afectando a ese sprint desde el punto de vista del contenido y de todas las métricas. La liberación no es más que un acto estresante por el que nadie del equipo está contento de pasar.
Así que yo estaba tras descubrir el siguiente mejor escenario para lidiar con los releases.
La conclusión fue hacer de cada segundo sprint el Release Sprint. Esto es lo que significa
Versión de código separada para la próxima versión
Se trata de manejar ramas separadas en el repositorio GIT. Hay muchas maneras de enfocar el mismo problema, y todas ellas pueden tener éxito. Pero para el propósito de este artículo, voy a mantener las cosas simples para demostrar el enfoque y su impacto.
Para que las actividades de desarrollo en curso tengan el menor impacto posible, es importante separar el contenido de la próxima versión en una rama independiente. Llamémosla Release Branch. Con esto, se resolverá lo siguiente
- El equipo de desarrollo puede continuar en las actividades y fusionarse con las nuevas historias de la rama principal sin interrupciones.
- No hay riesgo de que el contenido de la versión se vea afectado por modificaciones inesperadas del código por parte del equipo scrum.
- Las actividades de prueba pueden ejecutarse en un espacio aislado. Aquí sólo se introducirán los cambios necesarios para resolver las pruebas.
- Dado que la cadena de liberación desplegará en producción únicamente el contenido de la rama de liberación, tenemos un proceso claro y un control total sobre el contenido que se va a liberar. No puede ocurrir que algún commit inesperado en la rama Git rompa código ya probado.
Así que simplemente mantenga el contenido de la próxima versión a un lado y deje que concluya a un estado estable, listo para su liberación.
Cronometre las versiones para que funcionen repetidamente
Abandoné la ambición de hacer la liberación después de que se completara cada sprint. Estaba súper claro que esto no tendría ninguna posibilidad de funcionar. Al menos no con efectos secundarios como
- impactar en el contenido de desarrollo del siguiente sprint,
- ser incapaces de estabilizar el contenido de la liberación,
- ponerse al día con todas las actividades de prueba necesarias, etc.
Así que el objetivo era ejecutar el lanzamiento al final de cada segundo sprint. Eso implicaría lo siguiente:
- Una release siempre contendrá historias de los dos últimos sprints ya finalizados. Dado que la liberación se realiza dentro del sprint en curso (activo), el contenido de este sprint no se incluye aún en la liberación.
- Hay todo un tiempo de un sprint para que se completen las actividades de prueba necesarias y las correcciones de errores.
- El propietario de la versión tiene tiempo suficiente para recopilar la información relevante para la versión (casos de prueba, notas de la versión, etc.) con el sprint de no liberación. De este modo, puede operar básicamente de forma autónoma y mantener al resto del equipo de desarrollo trabajando en nuevas historias.
- En caso de que se descubra un error, el propietario de la versión puede conectar rápidamente con el desarrollador concreto para solucionar el problema y volver al contenido del sprint en curso. Por lo tanto, siempre debe haber algún porcentaje de tiempo asignado de la capacidad del equipo para apoyar esta corrección de errores. Cuánto exactamente puede descubrirse con el tiempo.
Está claro que los usuarios no obtendrán el último contenido del sprint dentro de la última versión. Pero con el tiempo, esto será irrelevante. De todos modos, obtendrán dos sprints de contenido con cada próxima versión, después de cada segundo sprint.
Esto parece un buen compromiso entre la satisfacción de una entrega rápida y el mantenimiento de las actividades de scrum sin perturbaciones significativas.
Ejecutar el despliegue de la versión
Cuando las pruebas, la corrección de errores y las actividades de preparación de la canalización se hayan completado con éxito, es un proceso bastante sencillo ejecutar la canalización de producción y completar la liberación a producción.
Dado que se despliega desde una rama independiente, esta puede ser básicamente una actividad desapercibida e invisible. Nadie tiene por qué saberlo. Si ese es el caso, es la mejor implementación posible del despliegue de la liberación.
Un requisito previo para ello es haber creado una sólida canalización automatizada de DevOps. No sólo se utiliza para desplegar en el entorno de producción, sino también en todos los demás entornos de nivel inferior. Esto podría incluir dev, sandbox, prueba, control de calidad, entorno de rendimiento, etc. Con un solo clic se desplegarán todas las soluciones para cada uno de los entornos.
El lanzamiento no debe ser un punto de dolor o estrés. O una pesadilla que todo el mundo teme y sigue preparando para ese día durante una semana. No – en cambio, si nadie se da cuenta de esto en absoluto, este es el mejor signo de una liberación exitosa.
Fusione de nuevo la rama de lanzamiento con la rama de desarrollo
La rama de lanzamiento contiene ahora un contenido especial que no existe en la rama de desarrollo regular en curso. Está relacionado con todas las correcciones que se implementaron durante el periodo de pruebas. Este contenido debe fusionarse de nuevo en la rama de desarrollo para garantizar que las correcciones permanezcan allí incluso después de la próxima versión.
En ese momento, la última rama de lanzamiento sirve como código de producción de emergencia listo para volver a desplegarse. Si es necesario resolver un problema urgente de alta prioridad poco después del despliegue en producción, puede utilizar esta rama. Es sencillo tomar este código e implementar la corrección en su interior. Sigue siendo la copia exacta del código de producción actual, sin ningún contenido nuevo sin liberar.
Por último, una vez que comienza el nuevo periodo de pruebas, la rama de lanzamiento anterior puede eliminarse y sustituirse por una nueva. La nueva se crea de nuevo como una copia a partir de la rama de desarrollo actual.
Establecer versiones regulares
Y ahora ya lo tenemos 😀 -un proceso sólido para abordar la liberación. Lo único que falta es comprometerse a mantenerlo regular. En este caso, después de cada segundo sprint.
Al mantenerlo regular, en realidad sentamos las bases para que sea más fácil de cumplir, principalmente porque:
- Si el lanzamiento se produce después de un tiempo no demasiado largo, no hay tanto contenido nuevo que instalar en producción. El incremento es pequeño y se considera estable.
- Ya no hay tanto contenido nuevo, lo que significa que no hay una gran cantidad de actividades de prueba y creación de casos de prueba. Menos comunicaciones, llamadas de acuerdo y colaboración con las partes interesadas sobre qué es lo que hay que volver a validar. También estarán de acuerdo en que no ha pasado tanto tiempo desde la última versión. Así que se da menos importancia a esta acción.
- El equipo se acostumbrará a este ciclo; con el tiempo, será una parte natural del equipo.
- Como efecto secundario, los entornos de desarrollo y pruebas suelen recibir una actualización de datos. De todos modos, esto es necesario para cada nuevo ciclo de pruebas. Así que no será simplemente otra actividad programada que hacer. Más bien, una acción que ya forma parte del proceso establecido. Este cambio de perspectiva influye mucho en el ambiente del equipo. Uno no se lo creería.
Conclusión
Este capítulo concluye mis anteriores entradas sobre el tema del ciclo de vida de scrum. También trata de lo que ha demostrado funcionar en la vida real.
A menudo, los equipos comienzan el camino ágil y hacen muchas cosas mal. Luego evolucionan, con el tiempo, y empiezan a hacer las cosas de otra manera. Esta serie podría ayudar a algunos de ellos a realizar este cambio más rápidamente.
Este enfoque de lanzamiento tampoco es el único viable, ni está exento de problemas. Éstos seguirán existiendo y los equipos tendrán que enfrentarse a ellos. Después, mejorar lo que sea posible y olvidar lo que no tenga sentido.
Pero por lo que sé, este enfoque, aunque sencillo, ha demostrado que el cambio es posible. De sprints caóticos e impredecibles a entregas más estables con lanzamientos regulares en los que se puede confiar y con los que se puede planificar. Y no requiere una metodología especial y muy complicada, sólo reglas sencillas y voluntad de seguir el plan.