La integración continua (CI) es un proceso mediante el cual verificamos nuestro proyecto en cada cambio que ocurre en la base de código. ¿Qué es exactamente la integración? Depende de cómo se configure el proceso: puede ser tan simple como instalar las dependencias y compilar el proyecto o tan complicado como ejecutar muchos scripts diferentes para determinar si el código base está en un estado aceptable.

Compañera de trabajo diligente

Puedes pensar en CI como un compañero de trabajo diligente que siempre está ahí, esperando para verificar tus cambios antes de fusionarlos con la rama principal. Es una buena idea incluir solicitudes de combinación en su flujo de trabajo cuando CI está en su lugar, incluso si trabaja solo en el proyecto. Sus cambios serán revisados por la máquina, y dejarlos en una rama separada le permite solucionar cualquier problema antes de fusionarse con la rama principal.

Sin CI, todos y cada uno de los desarrolladores son responsables de verificar todos sus propios cambios. Por supuesto, de vez en cuando alguien lo olvidará —tal vez los cambios originales estaban bien, pero ¿qué pasa si después de una reorganización o fusión tienes un problema? Sin CI, permites que tus colegas menos cuidadosos empujen y se olviden de sus cambios, y otros se ven obligados a limpiar después de ellos.

Cómo está estructurado CI

La integración continua comprueba tus confirmaciones. Por cada cambio de código, CI generalmente ejecuta algunas tareas diferentes en un orden definido. Puedes utilizar la salida de un trabajo como entrada en otro; por ejemplo, puedes crear una aplicación en un paso y luego usar el paquete resultante en otro para realizar pruebas. Por lo general, administra CI con un archivo de configuración que se encuentra dentro del repositorio; por lo tanto, tu CI puede evolucionar junto con tu base de código.

Si todas las tareas pasan, entonces el commit será aprobado ; si alguno de ellos falla, entonces el commit será fallo . En una situación ideal, el contenido de confirmación por sí solo determina el resultado de CI: no depende de servicios externos y no hay ningún elemento aleatorio que pueda hacer que falle.

Para cada rama, CI muestra el resultado de la confirmación superior. La rama principal debe estar casi siempre de paso; cualquier problema afectará a todos en el equipo, por lo que solucionarlo debería ser una prioridad si ocurre alguna regresión. Para una rama de características, debe fusionarla solo si ha sido aprobado por el CI.

Tareas que puede delegar a su CI

Puedes configurar cualquier script que se ejecute en tu entorno local en CI. La lista puede ser larga en proyectos grandes, pero echemos un vistazo a las tareas de CI que puede esperar en proyectos de cualquier tamaño.

Construcción

La verificación más básica que puede realizar en su base de código: ¿compila? Es un paso que detectará cualquier dependencia que se instaló, pero no se guardó, cualquier discrepancia de tipo de script mecanografiado que se coló en el commit. Estas son soluciones fáciles mientras el desarrollador está en la tarea, pero esos errores pueden volverse confusos o molestos si se comparten con otros.

Análisis estático

El análisis estático implica verificar su código sin ejecutarlo. En los proyectos frontend, a menudo puede ver herramientas como:

• ESLint
• HTMLHint
• Stylelint

Esos programas son los más útiles cuando se integran con el editor de código. Ejecutarlos en CI es una verificación adicional que puede ayudarlo de dos maneras:

• identificará a cualquier desarrollador que se olvide de ejecutarlos localmente —por lo que se les puede pedir que lo hagan antes de que arruinen una gran cantidad de código
• identificará cualquier desajuste de versión o configuración que pueda ocurrir entre los diferentes entornos de desarrollo

Ejecutando pruebas

Tener un CI implementado y ejecutar pruebas en él es esencial si se toma en serio las pruebas automatizadas en su aplicación. El objetivo de las pruebas automatizadas es ejecutarlas con mucha frecuencia —¿Qué mejor momento para hacerlo que cuando algunos cambios en el código están a punto de hacerse públicos? No hacerlo es una invitación a un escenario en el que:

• un desarrollador introduce la regresión en el código
• otros agregan cambios no relacionados encima
• alguien finalmente ejecuta las pruebas que capturan la regresión original
• pierden el tiempo resolviendo problemas que no causaron, relacionados con cambios de los que potencialmente no están al tanto

En este escenario, el problema principal es que a medida que solucionas el problema, ni siquiera sabes cuándo se presentó; podrías estar en un compromiso anterior, o hace una semana. Podrías usar git blame o git bisect para salir de eso, pero es mucho más fácil saber simplemente el punto en el que las pruebas dejaron de funcionar.

Permíteme enfatizar otra cosa: escribir pruebas es una inversión en garantía de calidad. Es un esfuerzo del día a día. Si estás realizando este esfuerzo diario, tiene sentido dedicar tiempo, solo una vez, a configurar CI para aprovechar al máximo las pruebas que desarrolla.

Desplegando

A menudo verá CI junto con implementación continua (CD), abreviados juntos como CI/CD. Esto se debe a que mientras compila y verifica su código, tiene todo listo para implementar —al menos en el servidor de prueba. Un verdadero CD requeriría que lo entregues a producción, pero esto puede ser más desafiante, especialmente porque expone a los usuarios del proyecto a posibles regresiones.

Desventajas

¿Cuáles son las desventajas de CI?

Configuración complicada

La configuración puede llevar mucho tiempo, especialmente si nunca lo has hecho antes. Incluso los cambios más sencillos en la configuración pueden tardar un tiempo considerable en verificarse, ya que debe ejecutarlos en un servidor externo al que no tienes acceso directo.

Dependencia de un proveedor externo

Si integras Ci en tu flujo de trabajo, dependerás de tu proveedor de CI. Si están caídos, no puede fusionarse —al menos no con toda la red de seguridad a la que estás acostumbrado. Puede ser frustrante, especialmente si sucede con cierta frecuencia.

Costo

Muchos proveedores de CI tienen un plan gratuito que debería ser más que suficiente para ejercicios simples o proyectos de demostración. Para un proyecto en el que las personas trabajan a tiempo completo, es casi seguro que necesitarás un plan de pago, más tiempo adicional para que las máquinas de CI ejecuten sus scripts. El costo probablemente valdrá la pena, incluso si asume que el CI ahorra solo unos minutos por día para cada desarrollador de su equipo.

¿Y tú?

¿Estás interesado en obtener más información sobre cómo configurar CI? ¡Cuéntamelo en la encuesta! Estoy pensando en escribir algunas publicaciones más detalladas sobre la configuración de las herramientas de CI. Al saber qué herramienta te interesa más, puedo crear contenido que coincida con tus expectativas. ¡Así que, por favor, vota en la [encuesta] (strawpoll.com/co8pv72pr) a continuación! ⬇️⬇️⬇️️ Tu opinión es muy importante para mí. ¡Gracias!

¿Qué sigue?

Para obtener aún más valor de tu CI, ejecuta pruebas de extremo a extremo (E2E) en él. Configurar E2E en CI es un desafío y lo trataré en otro artículo. Mientras tanto, puedes ver cómo [comenzar con E2E] (conoce.dev/como-agregar-pruebas-de-extremo-..).