Buenas prácticas de CI/CD

Asegurarse de que todo su código fuente, archivos de configuración, scripts, bibliotecas y ejecutables se encuentran en el control de fuentes es un primer paso esencial para implementar la integración continua, que le permite efectuar un seguimiento de cada cambio.

No obstante, no basta con tener la herramienta: lo importante es cómo la utiliza. La integración continua busca facilitar el proceso de integrar cambios de múltiples contribuidores compartiendo actualizaciones menores con más frecuencia.

Cada confirmación desencadena una serie de pruebas automatizadas para darle un feedback rápido acerca del cambio. Confirmar con regularidad garantiza que su equipo trabaje sobre la misma base, y facilita así la colaboración, a la vez que reduce la probabilidad de tediosos conflictos de combinación al integrar cambios grandes y complejos.

Para disfrutar de las ventajas de la integración continua, es esencial que todos compartan sus cambios con el resto del equipo haciendo push al principal (master) y que actualicen la versión en la que están trabajando para recibir los cambios de los demás. Por regla general, trate de confirmar a principal (master) al menos una vez al día.

Confirmar los cambios a la rama principal suele resultarles incómodo a los equipos acostumbrados a trabajar en ramas prologadas. Esto puede deberse al miedo a la mirada crítica de los demás o quizá a que la tarea es demasiado grande para completarla en un día.

Crear una cultura de equipo de colaboración en lugar de crítica es esencial y, como cualquier cambio en la rutina de trabajo, vale la pena debatir acerca del modo de trabajo con su equipo. Trabajar como equipo para desglosar tareas en fragmentos más reducidos y discretos puede ayudar a cada individuo a adoptar esta práctica.

Allí donde se utilizan ramas prolongadas para alojar nuevas funcionalidades que todavía no están listas para el lanzamiento, una alternativa es utilizar feature flags. Esto le permitirá controlar la visibilidad de una funcionalidad en particular en diferentes entornos, para que los cambios en el código puedan fusionarse e incluirse en la compilación para un control de la calidad sin estar disponibles para los usuarios finales.

Compilando la solución y ejecutando una serie de pruebas automatizadas cada vez que se confirma un cambio, un proceso de CI/CD proporciona un feedback rápido a los desarrolladores acerca de sus cambios.

El objetivo es evitar seguir construyendo sobre unos cimientos erróneos y mantener el código en un estado constante en el que pueda lanzarse cuando se desee. No solo es mucho más eficiente abordar las incidencias tan pronto como surjan, sino que posibilita poner en marcha una solución rápidamente si algo va mal durante la producción.

Si una compilación falla por cualquier motivo, debería ser una prioridad del equipo hacer que funcione de nuevo. Puede que resulte tentador culpar a quien hizo el último cambio y dejarle la tarea de resolver el problema. Pero centrarse en buscar culpables entre su equipo no crea una cultura de equipo constructiva, y es menos probable que le ayude a descubrir la causa subyacente del problema. Al hacer que abordar una compilación fallida sea responsabilidad de todo el equipo, y comprender qué ha dado lugar al fallo, puede mejorar todo el flujo de trabajo de CI/CD. Por supuesto, es más fácil decirlo que hacerlo cuando la presión y las tensiones aprietan; desarrollar una cultura de DevOps también es un ejercicio de mejora continua.

Sin duda puede resultar frustrante tener que dejarlo todo y ponerse a arreglar una compilación fallida, para descubrir que ha sido causada por algo trivial, como un error de sintaxis o una dependencia olvidada. Para evitar esto, una buena idea es que los miembros del equipo creen una compilación y ejecuten una serie inicial de pruebas localmente antes de compartir sus cambios. Lo ideal es que todos puedan usar los mismos scripts que el sistema de CI/CD para evitar duplicar el esfuerzo. Asímismo, plantéese implementar una herramienta de CI/CD en su organización.

Un error común es crear una nueva compilación para cada etapa.

Volver a compilar el código para diferentes entornos supone un riesgo de introducir incoherencias, y significa que no puede confiar en que se hayan superado todas las pruebas anteriores. En su lugar, el mismo artefacto de compilación debería ir avanzando por cada etapa del proceso de compilación para, finalmente, lanzarse al usuario.

Poner en práctica esta secuencia requiere que la compilación sea independiente del sistema. El script de implementación debería llamar a las variables, parámetros de autenticación, scripts o archivos de configuración, en lugar de incorporar todos ellos en la propia compilación. Esto permite que la misma compilación se pruebe en todos los entornos, y en cada etapa aumenta la confianza del equipo en ese artefacto de compilación en particular.

Aunque es una buena práctica mantenerlo todo, incluyendo el script de compilación, los archivos de configuración y los scripts de implementación en el mismo sistema de control de fuentes que el código de la aplicación, esto no es aplicable al propio artefacto de compilación. Como producto de estas entradas, la compilación no corresponde al control de fuentes. En su lugar, debería versionarse y almacenarse en un repositorio central de artefactos, como Nexus, desde donde se puede extraer e implementar en cada instancia.

Aunque la CI/CD depende en gran medida de que las pruebas automatizadas ofrezcan confianza en la calidad de su software, eso no significa que su objetivo sea testear cualquier eventualidad.

Después de todo, el objetivo de la integración continua es lograr un feedback ágil y entregar productos de valor a los usuarios más rápido de lo que lo haría con métodos tradicionales. Eso significa que tiene que encontrar un equilibro entre la cobertura de pruebas y el rendimiento. Si tarda mucho en obtener resultados, la gente buscará motivos y modos de puentear el proceso.

Ejecute primero las pruebas que se completan más rápidamente para obtener feedback lo antes posible, y dedique tiempo a pruebas más prolongadas solo cuando ya tenga cierta confianza en la compilación. Dado el tiempo que cuesta el control de calidad manual, y que todo depende de que su equipo esté disponible para realizar esas comprobaciones, lo mejor es limitar esta fase hasta después de que todas las pruebas automatizadas se hayan completado con éxito.

La primera capa de pruebas automatizadas normalmente son las pruebas de unidades, que puede utilizar para obtener una amplia cobertura y alertarle de cualquier incidencia obvia introducida con el último cambio. Después de las pruebas de unidades puede que tenga una capa de integración automatizada o pruebas de componentes, que testeen las interacciones entre las diferentes partes de su código.

Aparte de esto, puede invertir en pruebas automatizadas más complejas, como pruebas de GUI, pruebas de rendimiento y de carga, o pruebas de seguridad, antes de tomarse su tiempo para las pruebas de aceptación o las pruebas exploratorias manuales. Para que estas pruebas más prolongadas (ya sean automáticas o manuales) resulten más eficientes, céntrese en las áreas que suponen mayor riesgo para su producto y usuarios en particular.

Para sacar el máximo partido al equipo de control de calidad, vale la pena tomarse su tiempo para limpiar sus entornos de preproducción entre cada implementación.

Cuando los entornos se mantienen en ejecución durante mucho tiempo, resulta más difícil mantener bajo control todos los cambios en la configuración y las actualizaciones que se han aplicado a cada uno.

Con el tiempo, los entornos se desvían de la configuración original y entre sí, lo que significa que unas pruebas que se superan o no en uno, pueden no dar el mismo resultado en otro. Mantener entornos estáticos también supone un coste de mantenimiento, que puede ralentizar el proceso de control de calidad y retrasar el proceso de lanzamiento.

Usar contenedores para alojar entornos y ejecutar pruebas facilita agilizar y desglosar entornos para cada nueva implementación, utilizando un enfoque de infraestructura como código para elaborar el script de estos pasos. Crear instancias para un nuevo contenedor cada vez asegura la coherencia y le permite escalar entornos con más facilidad, para que pueda probar múltiples compilaciones en paralelo si lo necesita.

Una vez que haya invertido en la creación de un proceso de CI/CD fiable, rápido y seguro que le dé confianza en la calidad de sus compilaciones, ya no querrá boicotear ese esfuerzo permitiendo que alguien se salte el proceso por cualquier motivo.

Normalmente, cuando alguien desea tomar un atajo en el proceso de lanzamiento es porque el cambio es mínimo o urgente (o ambas), pero permitir este comportamiento es una "falsa economía".

Saltarse las etapas de control de calidad automatizado supone el riesgo de introducir problemas que se podrían haber evitado, además de que reproducir y depurar las incidencias resulta mucho más difícil, puesto que la compilación no está disponible para implementarse en un entorno de pruebas.

Es probable que, en algún momento, se le solicite que se salte el proceso "solo por esta vez". Probablemente, cuando esto suceda usted estará apagando fuegos, pero vale la pena emplear un análisis retrospectivo o "post-mortem" para comprender los motivos de esta petición. ¿El proceso parece demasiado lento? Quizá haya que realizar alguna mejora o ajuste en el rendimiento. ¿Existe algún malentendido acerca de cuándo debería utilizarse? Comunicar las ventajas de un proceso de CI/CD puede ayudarle a implicar a los interesados para evitar este tipo de demanda la próxima vez que el tiempo apremie.

Como parte de la creación de su proceso de CI/CD, probablemente haya implementado la monitorización de su entorno de producción para alertarle acerca de problemas potenciales lo antes posible.

Al igual que el producto que va a lanzar, su proceso de compilación también se verá beneficiado por un bucle de feedback.

Analizando las métricas recopiladas por su herramienta de CI/CD puede identificar posibles problemas y áreas mejorables.

• Comparar el número de compilaciones desencadenadas a la semana, al día o a la hora le da una perspectiva útil sobre cómo se utiliza la infraestructura de su proceso, si necesita ampliarla o reducirla, y cuándo tiende a sufrir picos de carga.
• Analizar la velocidad de las implementaciones a lo largo del tiempo y monitorizar si tienden a tardar cada vez más puede indicarle cuándo ha llegado el momento de invertir en optimizaciones de rendimiento.
• Las estadísticas de pruebas automatizadas pueden ayudarle a detectar áreas a las que les vendría bien una paralelización.
• Revisar los resultados de control de calidad para descubrir cuáles se ignoran de forma rutinaria puede permitir racionalizar la cobertura del control de calidad.

Para crear un flujo de trabajo eficaz de CI/CD es tan importante una cultura de equipo y de organización como las herramientas y procesos que emplea.

La integración, la entrega y la implementación continuas son prácticas de DevOps. Se basan en descomponer los silos tradicionales entre desarrolladores, ingenieros de control de calidad y operaciones, y fomentar la colaboración entre disciplinas.

Descomponer los silos da a los equipos más visibilidad del flujo de trabajo de extremo a extremo, así como la oportunidad de colaborar y sacar partido de las distintas áreas de conocimiento. El mantenimiento del proceso nunca debería ser responsabilidad de una sola persona. Implementar una plataforma de CI/CD también puede ayudar a mejorar las prácticas operativas.

Creando un sentimiento de responsabilidad compartida en la entrega de su software anima a todos los miembros del equipo a participar, tanto si es interviniendo para reparar la compilación, como si se trata de tomarse un tiempo para separar los entornos en contenedores o automatizar una tarea manual que no se realiza tan a menudo como debería.

Promover una cultura de confianza, en la que los miembros del equipo pueden experimentar y compartir ideas, no solo redunda en beneficio de las personas, sino también de la organización y del software que entrega. Si algo va mal, en lugar de dedicarse a buscar culpables entre los miembros de su equipo, el objetivo debería ser aprender del error; comprender la causa subyacente y cómo puede evitarse en el futuro.

Aproveche la oportunidad de mejorar su CI/CD y conviértalas en una práctica más robusta y eficaz. Permitiendo a los miembros del equipo que experimenten e innoven sin miedo a la recriminación creará un círculo virtuoso de mejora continua.