Despliegue continuo

La implementación continua puede ser considerada como una extensión de la integración continua, con el objetivo de minimizar el tiempo de entrega, el tiempo transcurrido entre la escritura de desarrollo de una nueva línea de código y el uso de este nuevo código por parte de los usuarios en vivo, en producción.

Para lograr una implementación continua, el equipo se apoya en una infraestructura que automatiza e instrumenta los distintos pasos que conducen a la implementación, de modo que después de cada integración que cumple con éxito estos criterios de lanzamiento, la aplicación en vivo se actualiza con nuevo código.

La instrumentación es necesaria para asegurar que cualquier sugerencia de menor calidad resulte en abortar el proceso de despliegue, o hacer retroceder las nuevas características, y desencadene la intervención humana.

Beneficios esperados

Los principales beneficios que se reclaman para el despliegue continuo surgen como resultado de la reducción del tiempo de entrega, con dos efectos principales:

  • Retorno de la inversión más temprano para cada característica después de su desarrollo, lo que reduce la necesidad de grandes inversiones de capital.
  • Retroalimentación previa de los usuarios sobre cada nueva característica a medida que se libera para la producción, lo que permite técnicas tales como pruebas paralelas (o A/B) para determinar cuál de las dos posibles implementaciones es la preferida por los usuarios.

Obstáculos comunes

En la medida en que la implementación continua se considera una estrategia para la calidad, es fácil (en particular para los desarrolladores enamorados de la novedad y los aspectos técnicos de la misma) elegir el objetivo equivocado y optimizarlo para una “frecuencia máxima de implementaciones”, lo que por sí solo no resultará en un aumento de la calidad.

Costes potenciales

  • La implementación continua se basa en una amplia instrumentación para garantizar que la funcionalidad que se pone a disposición de los usuarios no provoque incidentes, lo que reduce la calidad percibida externamente.
  • Por la misma razón, el despliegue continuo se basa en una infraestructura que permite recuperar fácilmente nuevas características cuando un defecto no ha sido detectado por pruebas automatizadas.

Orígenes

  • 2002: En las primeras discusiones (no publicadas) sobre la aplicación de las ideas Lean al software, viendo las características no desplegadas como “inventario”, Kent Beck menciona el despliegue continuo en LifeWare y “varios otros”; sin embargo, la idea tardará varios años en ser refinada y codificada.
  • 2006: El primer artículo de la conferencia que describe el núcleo del despliegue continuo, “The Deployment Production Line” de Jez Humble, Chris Read y Dan North, se publica en las actas de Agile2006, una codificación de las prácticas de varios equipos de Thoughtworks UK.
  • 2009: La práctica del despliegue continuo se ha vuelto bien establecida, aunque todavía un tanto controversial como lo atestigua un artículo muy comentado, “Continuous Deployment at IMVU” por Timothy Fitz; se ha vuelto importante no sólo en Agile sino también como un elemento central de estrategias más especializadas y recientes como Lean Startup o Devops.

Deja un comentario

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar