Implementando CI/CD de manera eficaz con clientes

Por: Natalia Romero, Vicky De Palma, Magda Sbant & Laura Bassani

En los últimos años, Continuous Integration (integración continua) / Continuous Deployment (despliegue continuo) o, por sus siglas, CI/CD, se ha convertido en la forma más popular de desarrollar software.

La integración continua es un método de desarrollo en el que los miembros de un equipo integran su trabajo de forma frecuente dando lugar, normalmente, a varias integraciones al día. El despliegue continuo, es una técnica en la que cada cambio pasa por la pipeline y automáticamente llega a producción, lo que da lugar a varios despliegues a producción al día.

Estas técnicas aportan valor al cliente casi desde el principio, aseguran una buena calidad del código, una buena cobertura de tests y un proceso de release más eficaz y rápido. El sueño de cualquier developer ¿no?

La realidad es que, implementarlo desde cero en un cliente que está empezando a familiarizarse con CI/CD puede tener sus desafíos, ya que es probable que tenga dudas y que presente cierta resistencia al cambio. En este artículo, queremos compartir cómo es trabajar con un cliente que está empezando a utilizar CI/CD, desde nuestra propia experiencia.

CI/CD ¿Por dónde empezamos?

Como no hay Continuous Deployment sin Continuous Delivery (entrega continua — forma de trabajo en la que se construye software de tal forma que este puede ser desplegado a producción en cualquier momento), el primer paso es llevar a cabo el desarrollo de manera que el código de todo el equipo sea puesto en común, de manera frecuente.

Con el uso de Test Driven Development (TDD) sentamos los fundamentos de una entrega de código con la seguridad de que nuestros cambios no rompen el funcionamiento previo. TDD nos obliga a desarrollar de manera incremental, esto facilita poder subir el código a una misma rama de desarrollo, haciendo una integración lo más frecuente posible y agilizando la identificación de errores o conflictos.

Empezar la automatización del deployment

Una vez que el equipo trabaja con CI, el código es testeado y desplegado de manera automática en entornos de desarrollo. El siguiente paso es desplegar frecuentemente en el resto de entornos. En este punto, nos encontramos con que los procesos manuales para aprobar esos despliegues son pura burocracia, a menudo repetitiva y que no aportan mucho valor. Este es el momento en el que debemos empezar a trabajar con Continuous Delivery.

Es importante destacar que como todo nuevo proceso, tendrá cierta curva de aprendizaje, sobre todo si el equipo no posee conocimientos de infraestructura. Por ello, se recomienda priorizar la implementación del mismo, y no intentar realizar nuevos desarrollos de manera paralela, así, además de garantizar que se comparta el contexto con todo el equipo, también evitamos los bloqueos que generarían intentar mantener el antiguo proceso de despliegue y el nuevo enfoque a implementar.

Una vez que se empiecen a migrar los primeros servicios, se hará muy evidente cualquier problema de rendimiento pues, al existir un solo pipeline, los tiempos de espera para cada entorno son más visibles. Al fallar un despliegue muy avanzado, se debe volver a empezar desde el principio. Es por esto que se recomienda optimizar cada fase, desde la construcción de la imagen hasta garantizar que la batería de pruebas sea robusta y no falle intermitentemente.

Es importante mantener la cercanía del cliente, sobre todo a las personas de negocio, para que prioricen correctamente cualquier optimización necesaria para que la implementación del Continuous Deployment sea un éxito. De lo contrario, es posible que se le atribuya al CD la culpa de estos problemas de rendimiento y se aumente la resistencia a implementar este enfoque.

Por último, es recomendable tener un proceso transitorio para desplegar a producción. Por ejemplo, un paso temporal de aprobación en producción, en el cual el cliente aún tiene la última palabra de lo que será desplegado, mientras gane la suficiente confianza en el proceso como para dejar que cada commit vaya directamente a producción.

Entregas Seguras

¿Cómo se pueden probar funcionalidades nuevas sin que estén disponibles todavía al usuario en producción? La respuesta es usando feature toggles o feature flags. Los feature toggles permiten esconder nuevas funcionalidades detrás de unas simples variables booleanas, que se pueden gestionar de diferentes maneras.

Usando esta técnica, se pueden realizar tests en producción sin afectar a todos los usuarios. Así mismo, se pueden realizar tests más avanzados como mostrar a un número reducido de usuarios las nuevas implementaciones (Canary Release) o hacer cambios para que el usuario se comunique con un nuevo backend, pero que se ignoren las respuestas del mismo, permitiendo a los developers monitorear las respuestas antes de mostrarlas al usuario (Dark Launches). Algo a tener en cuenta en estos casos es la retrocompatibilidad, ya que vamos a tener dos versiones de nuestra aplicación, es importante que las dependencias de la misma sean compatibles en las ambas versiones.

De esta manera, el cliente se queda más tranquilo cuando le hablamos de “subir cambios directamente a producción”, ya que podemos tener todo el código desplegado en producción, pero “escondido” detrás de un toggle. En el momento en el queremos que esa nueva funcionalidad esté disponible, solo necesitamos cambiar el toggle.

Como vemos, para el uso de CI/CD es necesario implementar prácticas que mejoran la calidad del proceso desarrollo y el cliente puede ir recibiendo iterativamente entregas de valor, incluso cuando el producto todavía no está terminado. Sin embargo, convencer al cliente para adoptar esta práctica puede ser un proceso de negociación lento, para el cual es vital una relación con el mismo, basada en la confianza y la transparencia.

Disclaimer: las declaraciones y opiniones expresadas en este artículo son las de l@s autor@s y no reflejan necesariamente las posturas de Thoughtworks.

¿Quieres formar parte de Thoughtworks España? Aplica a nuestras vacantes en nuestra página web https://thght.works/3F3T4JA