Insights

Noticias, novedades e información sobre el mundo Hard Tech

Errores frecuentes en la Integración Continua

por: Inmetrics em

| 24.09.2018

Algunos ejemplos de errores que debemos evitar si buscamos una Integración Continua eficiente.

¿Alguna vez usted se preguntó el motivo de la Integración Continua, a pesar de poseer todas las herramientas e infraestructuras necesarias, no lograr agregar el valor esperado a su proyecto? Tal vez el problema esté en otras etapas del ciclo de vida del software, o incluso en los procesos y la cultura del equipo en su forma de trabajar.

Para empezar, debemos comprender el principal objetivo de esta práctica de desarrollo de software para así saber qué podemos esperar de ella.

El objetivo de la Integración Continua es reducir el tiempo entre el desarrollo y la liberación de una actualización del software funcionando en producción, proporcionando retroalimentación rápida si el paquete puede causar cualquier tipo de problema para la aplicación.

En este post explicaré algunas técnicas, procesos y también algunos errores frecuentes que deben ser evitados para alcanzar mejores resultados con la Integración Continua.

Feedback no confiable

Una de las ventajas de la Integración Continua es poseer varios pipelines que devuelven feedbacks rápidos para ahorrar tiempo y permitir que el responsable tome las debidas providencias cuanto antes.

No hay beneficios en poseer una estructura completa de Integración Continua si los feedbacks no son confiables.
Por ejemplo: el pipeline de pruebas automatizadas se interrumpe, pero se lo ignora porque no es lo suficientemente confiable para identificar el motivo de la interrupción solamente por el feedback. El motivo puede ser simplemente una inestabilidad del ambiente, la masa utilizada, o también el código mismo de la aplicación que tiene un error.
Otro ejemplo sería en el momento de build, donde tenemos un feedback que apunta dónde está el error, pero el equipo responsable no tiene la cultura de corregirlo de inmediato, dejando la corrección para un momento posterior, junto con muchos otros errores.

No tiene sentido disponer de un feedback rápido si no es confiable o si ninguna acción se toma de inmediato.

Feedback lento

Sólo utilizar una buena herramienta de Integración Continua no garantiza que tengamos feedbacks rápidos y fiables. Es necesario también aplicar buenas prácticas de su concepto.
Imagínese trabajar sin una estructura organizada, sin pipelines para realizar las pruebas automatizadas, sin paralelismo y recibir el feedback de error sólo después del término de la ejecución de toda la batería de pruebas. ¿Es realmente necesario aguardar todo este proceso para recibir el feedbach? ¡Por supuesto que no!

Para empeorar la situación, ¿y si esta batería de pruebas tuviese más pruebas de UI que unitarias? Además de no ser recomendado, podría aumentar drásticamente el tiempo de ejecución y de espera del feedback.

Técnicas como la Pirámide de Automatización de Prueba (poseer más pruebas Unitarias que de Servicios, y estas más que de UI), Smoke Test (ejecutar las principales funcionalidades de forma separada, antes de la batería de pruebas de regresión), y utilizar recursos como paralelismo en las ejecuciones son ejemplos que ayudan a recibir un feedback rápido. Por tanto, si descubrimos un problema al principio, podemos detener las pruebas y enfocarnos en la corrección cuanto antes, y así ahorrando algo muy valioso en cualquier proyecto: tiempo.

Acumulación de código local pendiente de integración

Una cultura que no armoniza con la Integración Continua es la del equipo que no realiza la integración de su código con el repositorio al menos una vez al día. Al realizar la integración de grandes códigos o de branchs antiguas se aumentan las posibilidades de generar conflicto con el código principal, lo que incrementa también el tiempo, la complejidad y el costo de corrección.

Una de las ventajas de la Integración Continua es permitir que los desarrolladores hagan refactoring e integren su código con rapidez, pues cada integración es analizada por una build automatizada que comprueba si el nuevo paquete no generará ningún conflicto o quiebra de código, pudiendo ser a través de análisis estática de código o pruebas (desde unitarias hasta de UI). Y si el paquete de la actualización es pequeño y reciente, facilita la búsqueda del origen de la falla de integración del código, en caso de que ocurra.

Con eso, se incentiva mucho la cultura de todos del equipo de realizar siempre la integración del código por lo menos una vez al día, lo que evita trabajar con branchs de larga vida.

Ambientes específicos

Hacer las pruebas automatizadas en un ambiente compartido con otros equipos –como de pruebas manuales o de desarrollo– es muy arriesgado, ya que los cambios en el ambiente para otros fines pueden ocasionar resultados falsos negativos de pruebas (por ejemplo, la prueba falla debido a la secuencia de comandos de automatización y no debido a la aplicación probada), lo que hace que el equipo pierda la confianza en los feedbacks, o incluso falsos positivos (por ejemplo, la prueba es realizada, pero hay un error que no fue encontrado porque fue encubierto por un cambio en el ambiente), lo que significa que las pruebas no son eficientes para encontrar errores reales.

¿La Integración Continua es ideal para todos los momentos?

A pesar de muchos beneficios ofrecidos por esta práctica de desarrollo, con base en lo que se ha escrito hasta ahora, se recomiendan algunos requisitos mínimos para su implementación:

  • Aplicación de pruebas automatizadas en todas las capas de aplicación
    * Sin pruebas automatizadas, la integración continua no será capaz de verificar si el nuevo paquete puede perjudicar la aplicación cuando se implementa.
  • Uso del versionamiento de código
    * Para realizar la integración del código es necesario poseer un versionador, que también podrá ser el disparador de las pipelines de prueba
  • Objetivo de descubrir problemas (errores, errores, fallas…) lo antes posible para tratarlos de inmediato
    * La Integración Continua no tendrá buenos resultados si el equipo no tiene mentalidad ágil para resolver los problemas y analizar los feedbacks
  • Objetivo de realizar entrega y/o deploy continuo
    * La entrega o deploy continuo acaba por transformarse en consecuencia de una Integración Continua eficiente, pues torna casi todo el proceso automático
  • Objetivo de obtener infraestructura para la creación de ambientes de forma automática
    * La creación de ambientes también debe ser automática, pues así se puede garantizar que las pruebas serán ejecutadas en un ambiente exclusivo y no habrá ningún factor desconocido que pueda influir en su resultado. Por lo tanto, es más fiable

… y pensando más allá de la Integración Continua

Después de la Integración Continua, como se dijo anteriormente, también es una buena sugerencia pensar en implantar el Continuous Delivery (procedimiento automatizado iniciado manualmente para implementar una nueva versión en determinado ambiente) o incluso el Continuous Deployment (semejante al Delivery, pero el proceso se inicia automáticamente después de la Integración Continua).

Todas estas sugerencias y errores que deben evitarse buscan mejorar la eficiencia de la Integración Continua, pues además de la herramienta, el equipo debe conocer y trabajar sobre el concepto de su práctica.

Gracias a Walmyr Filho.