¿Qué es la entrega continua?

La piedra angular de DevOps es un cambio de mentalidad. En lugar de ver el proceso de desarrollo de software como una cinta transportadora de una sola dirección, en la que los requisitos, el código o los informes se pasan de un equipo al siguiente de manera lineal, en DevOps predomina la colaboración y el feedback rápido en ciclos breves y reiterados.

Cambiar la definición de "Terminado" puede ayudarle a adoptar esta mentalidad: en lugar de considerar que su parte está completa en cuanto entrega el código al siguiente equipo de la cadena, piense que su nueva funcionalidad o cambio en el código está terminado una vez se lanza al público. Si se detecta alguna incidencia en algún momento del proceso, comunicar ese feedback con rapidez y colaborar para solucionarlo logra una resolución más ágil que los extensos informes que deben pasar por un panel de cambios para su aprobación. De eso se trata la entrega continua.

Ver el ciclo de desarrollo de software como un todo, en lugar de solo una parte del mismo, le ayuda a comprender mejor lo que se necesita para hacer llegar el software a los usuarios, y le da la oportunidad de abrir más líneas de comunicación con otros equipos implicados.

La entrega continua significa identificar puntos conflictivos que ralentizan este proceso de entrega y crear un proceso automatizado para que el lanzamiento sea más rápido y fiable, de modo que usted siempre esté listo para lanzar. Una vez creado su proceso, debería poder lanzar un buen build al público con un solo comando.

La integración continua es el cimiento de este proceso, gracias a la confirmación de los cambios en el código al menos una vez al día seguida de una compilación automatizada y un proceso de prueba para dar un feedback rápido a los desarrolladores. Si un build o una prueba fallan, solucionarlo es prioritario para todos.

Al detectar los errores al inicio, puede solucionarlos mientras todavía tiene el código reciente en la memoria, y evita que se creen otras funcionalidades basadas en un código erróneo que haya que eliminar posteriormente. Con la entrega continua, el build que contiene los últimos cambios del proceso de integración continua avanza automáticamente a través de una serie de entornos de preproducción. Aunque el avance final hacia la producción se desencadena manualmente, sigue un proceso con script, lo cual facilita su repetición para que pueda lanzar tan a menudo como lo necesite.

Crear su proceso de CI/CD es una oportunidad de colaborar con los diversos implicados en su secuencia de lanzamiento, para que pueda tener en cuenta sus necesidades durante el diseño del proceso. Con un poco de suerte, ya habrá conectado con sus compañeros de control de calidad al diseñar las pruebas automatizadas.

Añadir una etapa para las pruebas exploratorias manuales en un entorno de pruebas adecuado (lo más similar posible al de la producción) identificará fallos que no había previsto (y que podrán abordarse con pruebas automatizadas). Se trata de un plato importante para la entrega continua.

El equipo de infosec o ciberseguridad suele considerarse una barrera frente a los lanzamientos frecuentes a causa del tiempo que conlleva efectuar una auditoria de seguridad y los interminables informes que le siguen. Asumir el enfoque de DevSecOps (Desarrollo, seguridad y operaciones) le ayudará a navegar entre los requisitos de seguridad de su proceso.

Los pasos de compilación, entornos y pruebas exactos que necesita dependen de la arquitectura de su software y de sus prioridades organizativas. Si está creando un sistema basado en microservicios, puede aprovechar la arquitectura para ejecutar pruebas en servicios individuales en paralelo antes de combinarlos para una integración más compleja y para pruebas de extremo a extremo.

Las pruebas exploratorias manuales pueden parecer excesivas para cada resolución de error que llegue a través del proceso, y disponer de pasos opcionales o procesos alternativos basados en el tipo de cambio puede resultar más eficiente para la entrega continua.

Una vez que haya decidido las etapas de su proceso, incluidas las pruebas que se ejecutarán en cada una de ellas, es hora de elaborar el script del proceso para asegurarse de que es fiable y repetible. Para evitar la introducción de incoherencias, debería implementarse el mismo artefacto de compilación de la etapa de integración continua en cada entorno de preproducción y en la propia producción.

Lo ideal sería que los entornos de prueba se actualizasen para cada nueva compilación, y el uso de contenedores con un enfoque de "infraestructura como código" significa que puede elaborar un script con estos pasos, para así deshacer y reactivar nuevos entornos según sea necesario.

Si su proceso incluye representar entornos de pruebas para que los equipos de asistencia, ventas o marketing se familiaricen con las nuevas funcionalidades, puede que prefiera controlar manualmente cuándo se actualizan con una nueva compilación para evitar alterar las tareas que están en curso. Como sucede con el lanzamiento final al público, se puede elaborar un script de la implementación para mantener el proceso rápido y coherente.

La entrega continua promete lanzamientos más rápidos sin poner en entredicho la calidad, pero para lograrlos es necesaria la cooperación de varias partes de una organización.

Desglosar silos es tanto un desafío a corto plazo como una ventaja a largo plazo, puesto que esa colaboración le ayudará a trabajar de forma más eficiente.

Implementar la entrega continua requiere cierta inversión de tiempo, y puede parecer algo abrumador. Adoptar un enfoque iterativo e ir perfeccionando su proceso a lo largo del tiempo lo hace más fácil de gestionar y le permite demostrar sus ventajas a los grupos de interés senior. Recopilar datos acerca de los tiempos de compilación y pruebas y compararlos con los procedimientos manuales es un modo sencillo de mostrar el retorno sobre la inversión, así como las tasas de defectos.

Cuantificar el valor de la entrega continua puede resultar útil al planificar sus requisitos de infraestructura. A medida que avanza en el proceso de lanzamiento, probablemente desee comenzar a ejecutar múltiples compilaciones y pruebas en paralelo, y las máquinas disponibles pueden ser un factor limitador. Una vez que haya optimizado el rendimiento de su proceso, quizá desee plantearse pasar a una infraestructura alojada en la nube, para poder crecer según lo necesite.

Crear un proceso de CI/CD puede parecer una tarea desalentadora que requiere mucha aportación inicial por parte del equipo. Sin embargo, cuando se hace bien, la CI/CD puede permitir a su equipo establecer el proceso de entrega de software en una décima parte del tiempo. No obstante, es importante seguir algunas buenas prácticas de CD para que el proceso sea correcto.

La entrega continua es el proceso de automatización de los distintos pasos necesarios para enviar software a producción. Sin embargo, no implica automatizar por completo el lanzamiento del software: ahí es donde entra en juego la implementación continua. Podemos pensar en la entrega continua y la implementación continua como partes diferentes del mismo proceso de CI/CD.

Más información sobre la comparación entre la implementación y la entrega continua

La entrega continua facilita y agiliza el lanzamiento de software, de modo que pueda implementar a producción con mucha más frecuencia. En lugar de un gran lanzamiento anual o trimestral, se lanzan pequeñas actualizaciones con frecuencia. Esto no solo significa que los usuarios obtienen las nuevas funciones y reparación de errores mucho antes, sino también que usted puede ver cómo se utiliza su software en la vida real y adaptar sus planes en consecuencia.

Aunque algunas organizaciones prefieren mantener el control del último paso del proceso de lanzamiento, para otras, la conclusión lógica de un proceso de CI/CD es automatizar el lanzamiento al público, utilizando una práctica denominada implementación continua.