Debe adoptar la entrega continua

Debe adoptar la entrega continua

 
El escenario más probable es que su equipo de desarrollo genere dos o tres versiones por año del software de su empresa. Si no es el caso, y está en los cientos de paquetes generados anualmente: felicitaciones, ha adoptado con éxito la Entrega Continua. De lo contrario, siga leyendo, porque podríamos convencerlo de que cambie su forma de actuar.

Implementar con más frecuencia y estabilidad, junto con la inclusión de pruebas automáticas en su canalización, permite reducir los riesgos que generalmente acompañan a cualquier versión. La idea es que todos los cambios realizados en su código deben pasar por un conjunto de puertas de calidad, lo que podría crear una promoción completa, o ser rechazados para que se puedan solucionar los problemas encontrados.

Esto también elimina una gran carga de los hombros de sus equipos: para hacer un paquete publicable con todos los empujes de código, esto significa que deben invertir en automatización. Aunque deben gastar mucho capacidad al principio, rápidamente les devuelve beneficios, ya que las tareas tediosas tienden a generar errores humanos (ya sea por excesos de confianza, falta de atención, estrés…). La automatización, en su base, significa que las tareas se repetirán de la manera más exacta cada vez. Entonces, si funciona una vez, lo hará cien o un millón de veces.

El término "Entrega continua" se confunde a menudo con "Implementación continua". La diferencia entre ambas estrategias radica en el detalle de la automatización a nivel de promoción: “Delivery” se trata de crear paquetes, mientras que “Deployment” ejecuta la instalación en cada entorno de forma autónoma. El primero es un requisito absoluto para una estrategia de DevOps adecuada, mientras que el segundo solo facilita la implementación. Puede darse el caso de que la “implementación continua” no sea adecuada para su empresa, pero la “entrega continua” siempre será un beneficio para usted.

Escrito por Álvaro G. Cachón