Introducción a la entrega continua

Introducción a la entrega continua

En el camino hacia la agilidad es necesario que el despliegue a producción de una actualización del software se produzca de una forma fácil y rápida. Nos referimos a la entrega continua. Definimos entrega continua como la disciplina de desarrollo de software que tiene como objetivo conseguir un despliegue a producción rápido, frecuente y reproducible.

Usando patrones, técnicas y buenas prácticas conseguimos que la construcción del software se realice de tal forma que en cualquier momento se pueda actualizar la versión de producción (deploy). Gracias a la aplicación de la entrega continua reduciremos los riesgos y la incertidumbre del éxito de cualquier subida a producción.

La entrega continua evita que la puesta en producción de una nueva funcionalidad sea un proceso largo y en el que puedan ir apareciendo sorpresas, más o menos agradables. Los que ya llevamos un tiempo en esto, recordamos los tiempos en los que lanzar una actualización requería la ejecución manual de unos procesos, en el mejor de los casos bastantes mecánicos.

Estos momentos, muchas veces bautizados como los momentos de deploy, eran muy tensos. El equipo, sobretodo algunas personas en concreto (las involucradas en la actualización y en los procesos a ejecutar), estaba altamente concentrado hasta comprobar que todo funcionaba correctamente. O no. Luego venían las prisas para resolverlo.

Ante estas situaciones, los equipos, como señal de autodefensa, intentaban minimizar las subidas a producción, puesto que se podían convertir en situaciones traumáticas con posibles errores humanos.

Una prioridad en la entrega continua es que el software pueda ser desplegado a producción en cualquier momento y mientras se está desarrollando una nueva funcionalidad. La entrega continua nos permite hacer un deploy en el momento deseado, gracias a la ejecución de un proceso directo, repetible y rápido.

¿QUÉ RELACIÓN EXISTE ENTRE SCRUM Y LA ENTREGA CONTINUA?

El Mínimo Producto Viable, en el desarrollo de un producto, es un producto con las características suficientes para satisfacer a los clientes iniciales y conseguir su feedback para la evolución futura. Descubre los 7 errores más comunes en la definición del Mínimo Producto Viable.

El Mínimo Producto Viable, en Scrum, se trabaja de forma iterativa, dividiendo el tiempo en sprints. El Product Owner es el encargado de priorizar las historias de usuario con las que se trabajará en los siguientes sprints. Al terminar todo sprint se obtiene un incremento en el producto.

Es muy importante que al final de cada sprint el producto sea usable. En cada una de las iteraciones de nuestro producto, bajo la construcción de Mínimos Productos Viables, aporta un incremento en sus funcionalidades y en su valor. En ningún momento nos podemos permitir el lujo de dejar el producto sin funcionar.

El Mínimo Producto Viable nos aporta el conocimiento sobre nuestros usuarios y clientes que nos determina como irá evolucionando nuestro producto. La entrega continua nos permite dedicarnos a la evolución del producto y no a cómo actualizar la versión de producción.

Scrum no va de procesos para desplegar a producción nuevos desarrollos y la entrega continua casi sólo habla de esto.

La entrega continua se resume en poder hacer un deploy a producción en el momento deseado, de forma automática y sin ningún proceso manual. Scrum consiste en dividir el trabajo en sprints, en los que al final de cada uno se entrega una nueva funcionalidad o alguna evolución en el software.

La construcción del software bajo el concepto de Mínimos Productos Viables y sprints nos llevan al desarrollo iterativo o incremental. La entrega continua entiende cada una de las iteraciones en el producto como un miniproyecto.

Las iteraciones, en Scrum sprints, repiten un proceso de trabajo muy similar. Cada una de las iteraciones tiene como objetivo proporcionar un resultado completo sobre el producto final con el que se trabaja. Los beneficios del desarrollo incremental son:

  • Gestionar las expectativas del cliente y tomar las decisiones pertinentes en cada una de las iteraciones.
  • Priorizar los cambios a corto plazo que el cliente pueda necesitar.
  • Empezar un proyecto con objetivos muy ambiciosos y poco concretos. Sólo debemos definir con detalle el mínimo producto viable.
  • Ofrecer resultados importantes y usables en las primeras iteraciones.

Por experiencia os puedo asegurar que no hay nada más desmotivador que ser el encargado de ejecutar los procesos manuales para subir a producción los cambios desarrollados. Esto ya hace mucho tiempo que son historia! (y sino tienes un problema!)

El equipo que construye el producto debe estar totalmente centrado en la evolución del mismo, para ello necesita que sus entregas, una vez validadas, se vayan publicando a producción de una forma transparente. Puedes leer más sobre el cómo trabajar el Mínimo Producto Viable EN ESTE POST.

LA ENTREGA CONTINUA ES LA EVOLUCIÓN DE LA INTEGRACIÓN CONTINUA

Estos últimos años el mundo agile ha introducido en nuestro vocabulario una gran cantidad de palabras nuevas, como si de marketing estuviéramos hablando! Se ha ido bautizando todo y a veces son pequeños matices las diferencias entre una y la otra.

La entrega continua es imprescindible para poder trabajar ágil e iterativamente sobre el Mínimo Producto Viable. Los equipos van actualizando la versión de producción muy frecuentemente, también en función del número de desarrolladores. Bajo el objetivo de actualizar la aplicación de forma incremental, no podemos permitirnos el lujo de perder el tiempo constantemente actualizando de forma manual la versión de producción.

Definimos una integración como la compilación y ejecución de pruebas sobre todo el proyecto. La integración continua es un modelo de desarrollo de software que consiste en hacer integraciones automáticas de un proyecto muy a menudo. Las integraciones nos permiten detectar fallos en etapas muy iniciales.

Los principales objetivos de la integración continua son:

  • Encontrar y arreglar los errores de forma más rápida.
  • Mejorar la calidad del software.
  • Reducir el tiempo de validación de una actualización del software.

La integración continua la situamos en la fase de construcción del software, en el desarrollo vaya. El desarrollo está en manos de personas y estas deben cambiar ciertos comportamientos para poder seguir las pautas de la integración continua.

Años atrás los desarrolladores de un equipo trabajan de forma aislada entre ellos. Lo hacían durante largos periodos de tiempo. A medida que se avanzaban en los distintos desarrollos, empezaban a aparecer espacios compartidos y se empezaba a escuchar en la oficina que la combinación de cambios (merge) sería muy dura.

La integración continua permite que los desarrolladores se actualizen las modificaciones realizadas de forma constante durante su desarrollo. Con esta actualización constante se elimina de forma drástica que los deploys sean procesos largos y complicados.

La integración continua y las metodologías ágiles, como Scrum, han provocado que los equipos de desarrollo hayan pasado a trabajar de una forma mucho más colaborativa. Si trabajas usando la metodología Scrum y no trabajáis en equipo, tenéis un problema como equipo! En este post se explica como mejorar la motivación de un equipo con Scrum.

Resumiendo, la integración continua nos permite la actualización y ejecución de pruebas automáticas de forma fácil y evita así largos procesos de combinación (merge). La entrega continua amplía la integración continua al implementar todos los cambios en el entorno de producción.

CONCLUSIONES

La entrega continua nos permite trabajar en el Mínimo Producto Viable y ponerlo en producción de forma rápida, segura y fácil. Así mismo nos permite acelerar el flujo de trabajo y motivar al equipo para implementar cambios o mejoras sin tener miedo a desplegarlo a producción o a romper alguna otra parte de la aplicación.

La entrega continua nos elimina esta incertidumbre de la puesta en producción de una nueva release y nos da un mayor control sobre todo el proceso. De este modo perdemos el miedo a subir a producción cambios y permite trabajar de una forma mucho más iterativa.

Podemos destacar los siguientes beneficios de la entrega continua:

  • Reduce el riesgo de las despliegues a producción de los nuevos desarrollos al tratarse de procesos automáticos y bajo pruebas test.
  • Permite avanzar en el desarrollo de una forma más confiable, puesto que se trabaja de una forma iterativa y manteniendo siempre el software funcionando.
  • Mejora la productividad del equipo puesto que no ha de destinar tiempo en ejecutar de forma manual procesos mecánicos (y con posibles errores humanos) para subir a producción.
  • Permite detectar los errores lo antes posibles y corregirlos y subirlos a producción con la máxima agilidad.
  • Facilita la entrega de actualizaciones de software con mayor rapidez y actuar o tomar decisiones gracias al feedback del propio usuario.
  • Reduce los gastos generales gracias al ahorro en términos de horas/persona gracias al sistema automatizado para las subidas a producción.

Si estás interesado en mejorar el flujo dentro del equipo puedes LEER ESTE POST en el que se trata como el Scrum Máster debe trabajar para crear flujo y eliminar los impedimentos.

Te ha gustado el post? No olvides en suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!

También te puede interesar...
Pitu Sabadí
Pitu Sabadí
TDD and Agile enthusiast

CEO en Please Networks. Profesor de Agile en el Máster de UIUX en ESDi. Fullstack developer y believer en la vida real. El trabajo en equipo, la mejora continua y las dinámicas de grupo constituyen las motivaciones de este blog.