Cuando se trata de la entrega de scrum, las personas generalmente esperan una ejecución de lanzamiento después del final de un sprint. Esto significa directamente después de una exitosa presentación de demostración al cliente.
Pero siempre me pregunté cómo esto podría ser una expectativa tan automática. Especialmente si considera las siguientes actividades posibles que deben ocurrir antes o al lado.
- Desarrollar y completar todas las historias dentro del sprint. Algunas pueden completarse antes, pero la mayoría de las veces, las historias se completan justo antes del final del sprint. Tal vez incluso después de la presentación de demostración, estar abierto aquí.
- Realice todas las pruebas programadas sobre el contenido del sprint para asegurarse de que el código que se lanzará esté listo para la producción.
- Póngase al día con los errores descubiertos y corríjalos a tiempo antes de que se produzca el lanzamiento.
- Asegúrese de que la canalización de implementación esté actualizada con el contenido más reciente y que la canalización en sí sea confiable para ejecutarse.
- Ejecute la canalización en todos los entornos relevantes para llevarlos al estado más reciente desde la perspectiva del código y de los datos.
- Prepare notas de lanzamiento y comuníquele al cliente el impacto del lanzamiento y qué cambiará exactamente después.
- Si es relevante, sincronice con otros equipos de scrum paralelos para garantizar que el contenido dependiente se publique simultáneamente. No debe faltar nada para garantizar que el contenido de su lanzamiento funcione como se espera.
- Además de todo esto, realice todas las ceremonias de scrum. No solo relacionados con el sprint actual, sino también con los objetivos del próximo sprint (por ejemplo, sesiones de refinamiento de historias).
Ahora imagina que el sprint tiene dos semanas.
Las actividades de liberación por sí solas toman tiempo y personas para completarlas. Pero no puede tomar demasiado. Justo después del último día del sprint llega directamente el día uno del próximo sprint, y el círculo comenzará de nuevo.
¿La expectativa de lanzamiento después de cada sprint todavía parece tan automática?
Tabla de contenido
Procesamiento del contenido de la versió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 había experimentado un estado tan perfecto del equipo scrum.
Si es realmente el caso en algunas empresas privadas de pequeña escala, realmente las envidio. Pero la realidad en el mundo empresarial es que un equipo Scrum no alcanzará ese nivel de madurez. Por el contrario, los procesos de lanzamiento generalmente están conectados con actividades que consumen mucho tiempo y alcanzan la mayor parte del siguiente sprint, lo que afecta ese sprint desde el contenido y todas las perspectivas de métricas. El lanzamiento es solo un acto estresante por el que nadie en el equipo está feliz de pasar.
Así que estaba después de descubrir el siguiente mejor escenario para lidiar con los lanzamientos.
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 formas de abordar un mismo problema, y todas ellas pueden tener éxito. Pero para el propósito de este artículo, voy a simplificar las cosas para demostrar el enfoque y su impacto.
Para tener el menor impacto posible en las actividades de desarrollo en curso, es importante separar el contenido de la próxima versión en una rama separada. Llamémoslo Release Branch. Con ello se resolverá lo siguiente:
- El equipo de desarrollo puede continuar con las actividades y fusionarse con las nuevas historias de la rama principal sin interrupciones.
- No hay riesgo de que el contenido del lanzamiento se vea afectado por modificaciones de código inesperadas por parte del equipo Scrum.
- Las actividades de prueba se pueden ejecutar en un espacio aislado. Aquí, solo se introducirán los cambios necesarios para resolver la prueba.
- Dado que la canalización de lanzamiento implementará en producción solo el contenido de la rama de lanzamiento, tenemos un proceso claro y un control total sobre el contenido que se lanzará. No puede suceder que algún compromiso inesperado en la rama de Git rompa el código ya probado.
Así que mantenga a un lado el contenido del próximo lanzamiento y deje que concluya en un estado estable, listo para su lanzamiento.
Programe los lanzamientos para que funcionen repetidamente
Renuncié a la ambición de hacer el lanzamiento después de completar cada sprint. Estaba muy claro que esto no tendría ninguna posibilidad de funcionar. Al menos no con efectos secundarios como:
- impactando el siguiente contenido de desarrollo de sprint,
- no poder estabilizar el contenido del lanzamiento,
- ponerse al día con todas las actividades de prueba requeridas, etc.
Entonces, el objetivo era ejecutar el lanzamiento al final de cada segundo sprint. Eso implicaría lo siguiente:
- Un lanzamiento siempre contendrá historias de los dos últimos sprints ya finalizados. Dado que el lanzamiento se realiza dentro del actual (sprint activo), este contenido del sprint aún no está incluido en el lanzamiento.
- Hay un tiempo completo 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 información relevante para la versión (casos de prueba, notas de la versión, etc.) con el sprint sin versión. De esta manera, pueden operar básicamente de forma independiente y mantener al resto del equipo de desarrollo trabajando en nuevas historias.
- En caso de que se descubran errores, el propietario de la versión puede conectarse rápidamente con el desarrollador concreto para solucionar el problema y volver al contenido del sprint actual. Por lo tanto, siempre debe haber un porcentaje de tiempo asignado de la capacidad del equipo para respaldar la corrección de este error. Cuánto se puede descubrir exactamente con el tiempo.
Está claro que los usuarios no obtendrán el último contenido de sprint dentro de la última versión. Pero con el tiempo, esto se volverá irrelevante. Obtendrán dos sprints de contenido con cada próximo lanzamiento de todos modos, después de cada segundo sprint.
Esto parece un buen compromiso entre la satisfacción de la entrega rápida y mantenerse al día con las actividades de scrum sin perturbaciones significativas.
Ejecutar la implementación de lanzamiento
Cuando las actividades de prueba, corrección de errores y preparación de la canalización se completan con éxito, es un proceso bastante sencillo ejecutar la canalización de producción y completar el lanzamiento a producción.
Dado que se implementa desde una sucursal independiente, esto puede ser básicamente una actividad invisible e inadvertida. Nadie necesita saber. Si ese es el caso, es la mejor implementación posible de la implementación de la versión.
Un requisito previo para eso es haber creado una canalización de DevOps sólida y automatizada. No solo se utiliza para implementar en el entorno de producción, sino también en todos los demás entornos de nivel inferior. Esto puede incluir desarrollo, sandbox, prueba, garantía de calidad, entorno de rendimiento, etc. Esto será un solo clic para implementar todas las soluciones para cada entorno.
La liberación no debe ser un punto de dolor o estrés. O una pesadilla que todos temen y se preparan para ese día durante una semana. No, en cambio, si nadie se da cuenta de esto nunca, esta es la mejor señal de un lanzamiento exitoso.
Vuelva a fusionar la rama de lanzamiento en la rama de desarrollo
La Rama de lanzamiento ahora contiene contenido especial que no existe en la rama de desarrollo regular en curso. Está relacionado con todas las correcciones que se implementaron durante el período de prueba. Este contenido debe volver a fusionarse con la rama de desarrollo para garantizar que las correcciones permanezcan allí incluso después de la próxima versión.
En ese momento, la rama de versión más reciente sirve como un código de producción de emergencia listo para volver a implementar. Si es necesario resolver un problema urgente de alta prioridad poco después de la implementación de producción, puede usar esta rama. Es simple tomar este código e implementar la solución en su interior. Esta sigue siendo la copia exacta del código de producción actual sin ningún contenido nuevo inédito.
Finalmente, una vez que comienza el nuevo período de prueba, la rama de lanzamiento anterior se puede eliminar y reemplazar por una nueva. El nuevo se crea nuevamente como una copia de la rama de desarrollo actual.
Establecer lanzamientos regulares
Y ahora lo tenemos 😀: un proceso sólido para abordar el lanzamiento. Lo único que falta es hacer un compromiso para 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 lograr, principalmente porque:
- Si el lanzamiento es después de un tiempo no demasiado largo, no hay tanto contenido nuevo para instalar en producción. El incremento es pequeño y se considera estable.
- Ahora, tanto contenido nuevo significa que no hay demasiadas actividades de prueba y creación de casos de prueba. Menos comunicaciones, llamadas de acuerdo y colaboración con las partes interesadas sobre qué necesita todo para ser revalidado. También estarán de acuerdo en que no ha pasado tanto tiempo desde el último lanzamiento. Así que se le 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 prueba a menudo actualizan los datos. De todos modos, eso es necesario para cada nuevo ciclo de prueba. Así que no será una actividad más programada para 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 creería eso.
Conclusión
Este capítulo concluye mis publicaciones anteriores sobre el tema del ciclo de vida de scrum. Además, se trata de lo que resultó funcionar en la vida real.
A menudo, los equipos comienzan de manera ágil y hacen muchas cosas mal. Luego evolucionan, eventualmente, y comienzan a hacer las cosas de manera diferente. Esta serie podría ayudar a algunos de ellos a hacer este cambio más rápido.
Este enfoque de lanzamiento no es el único viable, ni está exento de problemas. Esos seguirán existiendo, y los equipos tienen que lidiar con ellos. Entonces mejora lo que es posible y olvida lo que no tiene sentido.
Pero por lo que sé, este enfoque, aunque simple, demostró que el cambio es posible. Desde sprints caóticos e impredecibles hasta entregas más estables con lanzamientos regulares en los que uno puede confiar y planificar. Y no requiere una metodología especial y muy complicada, solo reglas simples y voluntad de seguir el plan.