search
top

La integración continua y el "smoke test"

Dos buenas prácticas esenciales en un equipo de desarrollo software de alta productividad y que ofrece resultados de calidad. De manera resumida la integración continua consiste en que diariamente se intenta (a veces no se consigue) crear una versión ejecutable del producto, es decir, cada fichero es compilado, enlazado con las librerías correspondientes, desplegado, etc. Y por si esto fuera poco la integración continua aún puede alcanzar mayor valor si viene acompañada de la segunda práctica, el llamado “smoke test”: conjunto de comprobaciones preliminares a las que se somete la versión para evaluar si funciona correctamente y la calidad con que ha sido desarrollada.

La dificultad de integrar es inversamente proporcional a la frecuencia en que se realizan las integraciones (más frecuencia menos dificultad), y la integración continua permite que los problemas y riesgos de la integración se minimicen. Cuanto más trabajo hacen los desarrolladores de manera autónoma e independiente del trabajo del resto menos compatibles suelen ser las partes. Hay equipos que integran cada semana, cada mes, cada varios meses e incluso sólo justo antes de terminar una versión que ha de pasar a producción, lo que en muchas ocasiones produce que estos periodos de integración sean interminables; desgraciadamente conocemos varios casos de empresas de desarrollo que por procesos de integración muy pobres, junto con equipos poco cooperativos, emplean mas horas hombre en integrar las versiones que en el propio desarrollo de la versión e incluso errores de integración que pueden llegar a cancelar proyectos.

Por su lado el “smoke test” es una de las prácticas más efectivas para reducir los problemas de calidad de las versiones (realmente en este contexto es un conjunto de pruebas e inspecciones que se lanzan casi a diario), ya que permite que los problemas de calidad se vayan observando poco a poco, de manera diaria, cuando aún son fáciles de solucionar.

¿Nuevas o modernas? No, en línea con lo que comentaba Parnas ¿Prácticas “ágiles”? Sólo buenas prácticas, apliquense en el contexto que uno quiera, pueda, aplique y necesite. ¿Casos conocidos? El más popular es el de Windows NT (antes de que alguien lo diga: es conocido y además de éxito) ¿Y qué no sean “de libro”? En nuestra experiencia profesional muchos y en importantes empresas; cuando hay problemas suelen venir, como comentaba Cockburn, del factor humano que puede oponerse a cambiar la manera de trabajar, muchas veces los desarrolladores “protestan”, comentan que la integración continua y diaria es poco práctica. Pero en la mayoría de los equipos, involucrados, proactivos y con ganas de aprender, esta práctica es muy motivadora, ya que a diario ven como evoluciona el producto.

Cierto es que si bien es una práctica antigua el nivel de las actuales herramientas software la facilita muchísimo. Una infraestructura típica sería “continuum” o “cruise control”, ambas para planificar (p.ej. cada noche a las 24:05) cuando se lanza la integración y el “smoke test”. Más concretamente la lista de acciones se suele escribir en un pom de maven; acciones como por ejemplo un “checkout” de la versión, integrar, compilar, etc., y lanzar el smoke test, que puede estar compuesto de las pruebas unitarias, otras, y numerosas inspecciones (PMD, Checkstyle, etc.); luego los resultados pueden enviarse por correo y almacenarse en una BBDD según un esquema concreto que permita para crear un cuadro de mando e indicadores estratégicos sobre la calidad del producto software según PSM e ISO 9126 con Kemis.

Para ampliar información. En el libro de fábricas software nosotros hablamos algo, breve y en el contexto de la estrategia para organizar un departamento de desarrollo, Pablo Santos en su capítulo sobre SCM comenta algunos problemas que se pudieran derivar, como el patrón mainline. Y como suele suceder, dos cosas típicas: la mayoría de las referencias en inglés, destacando para comenzar a McConnell, 1996 y Fowler; y la segunda que no existe una terminología estándar, la integración continua puede encontrarse como “daily building” o “continuous integration”, aunque hay quien comenta que existen sutiles diferencias: “daily builds are for wimps and real developers do continuous integration.” (vamos cosa de tip@s dur@s :-)

Sin respuestas to “La integración continua y el "smoke test"

Trackbacks/Pingbacks

  1. Las metodologías Crystal. Otras metodologías ágiles que, quizás, te puedan encajar más que Scrum - Javier Garzás, sobre calidad software y otros temas relacionados - [...] 7 – Entorno técnico con pruebas automatizadas, gestión de la configuración e integración continua. Prácticas comunes en casi todas…
  2. De dónde viene el Lean, el Lean Software Development y por qué se asocia con la agilidad - Javier Garzás, sobre calidad software y otros temas relacionados - [...] continua pero planificada, en la que diariamente se compila el software y se pasan algunas pruebas unitarias automatizadas, o…

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top