Si tu empresa tarda semanas en pasar a producción un pequeño cambio en el software seguramente tienes un proceso demasiado burocrático, y/o poco automatizado, y/o negocio, sistemas y desarrollo están poco compenetrados.
Si esto pasa estás perdiendo competitividad (ya lo comentábamos en el post de que lo más determinante es la velocidad de desarrollo), tardarás mucho en validar versiones del producto con el usuario real, tardarás en adaptar futuras versiones a las necesidades reales del usuario.
La entrega continua o continuous delivery es el proceso de poder liberar software (con la seguridad de que no va a explotar en producción) rápidamente, lo cual se basa, obviamente, en tener todo automatizado al máximo, y que desarrollo, sistemas y negocio trabajen como uno.
El movimiento aparece con fuerza en 2010, cuando apareció el libro Continuous Delivery (entrega continua), de Jez Humble and David Farley
(premiado con un Jolt), y que trata las técnicas para poder crear un flujo continuo de versiones software listas para pasar al entorno de producción de manera segura, sin defectos ni sustos. Las herramientas, tecnologías y organización necesaria para lograr el ideal de poder desplegar software de forma segura en producción inmediatamente después de haberlo programado.
La entrega continua, el “continuous delivery”, es la evolución natural de la “integración continua”
La integración continua, popularizada Fowler, se basa en integrar el software (compilarlo y probarlo) automáticamente lo más frecuentemente posible, y así poder detectar fallos cuanto antes.
La integración continua (continuous integration), es una de las bases de la entrega continua: Integración continua -> Entrega continua (continuous delivery)
El proceso de integración continua se basa en obtener las fuentes desde el gestor de versiones (Subversion, Git, Plastic u otros) compilarlo y lanzar las pruebas. Todo este proceso suele automatizarse con herramientas como Jenkins, que, a su vez, se basan en que la secuencia de compilación, despliegue, etc., esté “escrita” y se lance con Maven (u otros, Ant, Msbuild, Mkfile).
La entrega continua, el “continuous delivery”, no implica necesariamente que tengas que hacer muchos pasos a producción. “Continuous Delivery” no es “Continuous Deployment”
La entrega continua no implica exactamente que pongas con mucha frecuencia software en producción… el “continuous delivery” pretende que podamos poner en producción cuando queramos, rápidamente, que cuando decidamos pasar a producción sea en poco tiempo.
El momento y frecuencia en pasar a producción lo decide negocio, pero cuando se decide… la puesta es lo mas rápida posible.
La entrega continua consiste en olvidar que el software se construye como una actividad separada de explotación, producción, paso a producción, sistemas, o como cada uno lo llaméis, y que el software esté siempre listo para el lanzamiento.
Terminando…
Titulaba este post con una frase de Mary Poppendieck en Implementing Lean Software Development: «How long would it take your organization to deploy a change that involves just one single line of code?» Pregúntate si ese tiempo es razonable y si te está haciendo ser cada vez menos competitivo.
Como siempre, compartelo, tuitealo, y me ayudas a difundir el conocimiento.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Pingback: Bitacoras.com
Hola, buenas:
Si hay alguien interesado en estos temas, en durante el mes de diciembre se celebran dos cursos: «Integración continua» e «Inspección continua».
Para más información: https://klicap.stagehq.com
Un saludo
Hola Javier, después de haber leído tu post y de haberlo ampliado con los dos que cito abajo sigo sin ver clara la diferencia entre integración continua y entrega continua.
Si la entrega contínua no implica publicar inmediatamente.. ¿en qué se diferencia de la integración contínua?
Un saludo!
http://www.itwriting.com/blog/4797-continuous-integration-vs-continuous-delivery-vs-continuous-deployment-what-is-the-difference.html
http://continuousdelivery.com/2010/08/continuous-delivery-vs-continuous-deployment/
Hola Carlos,
Para mi la primera y maor diferencia viene de los entornos. Integración Continua trabaja en el entrono de desarrollo y entrega continua ya entra en el entorno de producción, lo que implica, que IC afecta al equipo de desarrollo y EC implica a la gente de sistemas.
Saludos!
Que risa me ha dado esta entrada. Es como mi vida misma…es tan real.
Aqui se ha llegado a tardar hasta 4 dias en copiar una p…IMAGEN una imagen como lo oyes un simple jpg a production por el magnifico sistema burocratico.
Cabreo del cliente incluido.
Yo he intentado «acelerar» el sistema y resulta que descubro que hay hasta cuatro tios que tienes que aprovar el cambio, ver riesgos…Si esto se automatiza y se hace acorde a la logica humana… estos tios van a la calle y eso no mola.
Eso en teoria esta muy bien….pero en la practica… ya sabes! 🙂
En mi empresa estamos intentando aplicar esta metodología desde hace un tiempo y la verdad es que nos está yendo mejor de lo que podía pensarse pero el cambio es bastante duro. Hace un año hacíamos 2 releases a la semana y cada una era una pequeña aventura con muchos equipos involucrados, mucho tiempo para prepararlo y muchos esfuerzos por parte de todos. Ahora mismo hacemos entre 2 y 3 releases al día (sin contar hotfixes) con muy poco esfuerzo por parte de la gente involucrada y lo mejor es que la calidad del producto no ha disminuido si no que empieza a aumentar… pero nos ha costado Dios y ayuda, hemos tenido que involucrar a toda la empresa y cambiar muchas mentalidades.
Creo que este tema puede ser un buen tema para próximas reuniones de MADQA 😀
Pues ya es un logro! Si ser ágil ya es duro, esto es lo siguiente…
Si que sería buen tema de un MAD QA