Cómo configurar la integración continua

No todas las pruebas son iguales, y puedes ver las compensaciones que harás con la pirámide de pruebas desarrollada por Mike Cohn.

Fuente

Las pruebas unitarias son rápidas y baratas de implementar, ya que en su mayoría hacen comprobaciones en pequeñas piezas de código. Por otro lado, la implementación de las pruebas de interfaz de usuario será compleja y su ejecución, lenta. Esto es así porque suelen necesitar un entorno completo y múltiples servicios para emular comportamientos en navegadores o dispositivos móviles. Por esto, puede que quieras limitar el número de pruebas de interfaz de usuario complejas y confiar en buenas pruebas unitarias para agilizar la compilación y dar feedback a los desarrolladores lo antes posible.

Para adoptar la integración continua, deberás ejecutar tus pruebas cada vez que se envíe un cambio a la rama principal. Para ello, deberás contar con un servicio que pueda supervisar tu repositorio y que esté atento a los nuevos envíos al código base. Hay muchas soluciones para elegir, tanto locales como en la nube. Para elegir servidor, hazte estas preguntas:

• ¿ Dónde se aloja tu código? ¿El servicio de CI puede acceder a tu código base? ¿Tienes alguna restricción especial sobre dónde puede residir el código?
• ¿ Qué sistema operativo y que recursos necesitas para la aplicación? ¿Es compatible tu entorno de aplicación? ¿Puedes instalar las dependencias adecuadas para compilar y probar el software?
• ¿Cuántos recursos necesitas para las pruebas? Algunas aplicaciones en la nube pueden limitar los recursos que puedes utilizar. Si tu software consume muchos recursos, puede que quieras alojar el servidor de CI detrás del firewall.
• ¿Cuántos desarrolladores hay en tu equipo? Si tu equipo aplica CI, cada día se enviarán muchos cambios al repositorio principal. Para que los desarrolladores reciban feedback rápidamente, tienes que reducir el tiempo de cola de las compilaciones y querrás contar con un servicio o un servidor que te ofrezcan la simultaneidad correcta.

Antes tenías que instalar un servidor de IC independiente, como Bamboo o Jenkins, pero ahora puedes encontrar soluciones en la nube mucho más sencillas de adoptar. Por ejemplo, si tu código está alojado en Bitbucket Cloud, puedes ver la función de Pipelines en el repositorio para ejecutar pruebas con cada envío sin tener que configurar un servidor aparte ni agentes de compilación, y sin restricciones de concurrencia.

Ejemplo de configuración de pruebas de un repositorio de JavaScript con Bitbucket Pipelines.

Cuando adoptes pruebas automatizadas, es recomendable combinarlas con una herramienta de cobertura de pruebas que te permita saber qué parte del código base cubre tu conjunto de pruebas.

Está bien aspirar a una cobertura superior al 80 %, pero hay que tener cuidado con no confundir un porcentaje de cobertura elevado con un buen conjunto de pruebas. Una herramienta de cobertura de código te ayudará a encontrar código no sometido a pruebas, pero es la calidad de las pruebas la que marcará la diferencia al fin y al cabo.

Si acabas de empezar, no tengas prisa por alcanzar una cobertura del 100 % del código base. En lugar de eso, utiliza una herramienta de cobertura que te permita identificar partes críticas de la aplicación que aún no tienen pruebas, y empieza por ahí.

Automatizar las pruebas es una parte importante de la CI, pero con eso no basta. Es posible que debas cambiar la cultura del equipo para que los desarrolladores no trabajen durante días en una función sin fusionar los cambios en la rama principal; también tendrás que imponer la filosofía de las compilaciones con "luz verde".

Con esto, deberías tener unos conceptos básicos sobre la integración continua, que podrían reducirse a los siguientes puntos:

1. Empieza escribiendo pruebas para las partes críticas de tu código base.
2. Obtén un servicio de CI que ejecute esas pruebas automáticamente cada vez que se hace un envío al repositorio principal.
3. Asegúrate de que tu equipo integra los cambios a diario.
4. Corrige la compilación en cuanto se rompa.
5. Escribe pruebas para cada nueva historia que implementes.

Aunque puede parecer sencillo, para que todo vaya bien necesitarás el compromiso del equipo. Al principio, tendrás que ralentizar tus publicaciones y necesitarás el apoyo de los propietarios del producto para que no metan prisa a los desarrolladores para lanzar funciones sin pruebas.

Te recomendamos comenzar poco a poco y con pruebas sencillas, para hacerte a la nueva rutina antes de pasar a implementar un conjunto de pruebas más complejo que pueda ser difícil de administrar.

Aprende a usar la integración continua con Bitbucket Pipelines Y, si quieres crear una cadena de herramientas de DevOps, asegúrate de echar un vistazo a Open DevOps, que incluye integraciones con los principales proveedores y aplicaciones de Marketplace.