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 🙂
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Pingback: 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
Pingback: 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
Hola Javier,
El artículo de Parnas ya no se encuentra hospedado en la página de Kybeles consulting, así como tampoco el de «Los objetivos del negocio y la ingniería».
Tampo se encuentra ya hospedada en el servidor de Maven la herramienta de «Continuum». Jejeje Que pena de verdad, se qué este es un post de 2007 pero apenas descubrí tu blog y me dí a la tarea de leer cada interesante blog, así que disculpame por molestarte con estas sandeces.