Por qué siempre digo que la gestión de versiones es imprescindible. Una experiencia real ilustrativa

No suena tan “cool”, ni tal ágil, ni tan data, ni tan cloud, ni tan lean. Pero siempre lo repetiré: no existe un proyecto software sobre que funcione mínimamente bien (en lo que refiere a calidad, productividad y tranquilidad) sin una buena gestión de la configuración y control de versiones.
Es decir, y sin perdernos en definiciones, que si no controlas correctamente los cambios que se realizan en los productos del ciclo de vida, el cómo varias personas trabajan a la vez sobre, por ejemplo, los mismos fuentes, como gestionar diferentes versiones del mismo producto en producción en diferentes clientes, cómo una vez solucionado un cambio en una versión se replica el parche en el resto versiones para no arrastrar errores, etc. Si no tienes una estrategia para lo anterior, acabaras, como poco, duplicando el número de personas del equipo (euros) o perderás el control del software (euros).
Experiencias reales terroríficas te podría contar decenas (perdida de fuentes, bugs reparados que vuelven a aparecer, programadores que no pueden trabajar mientras los tester prueban, etc.) porque me he encontrado casi de todo, y supongo que aún me queda por ver. Pero por no entristecerte mucho la mañana, te voy a dejar sólo una…
Recuerdo que hace ya muchos años “me invitaron” a revisar la calidad del desarrollo de un proyecto. El responsable del departamento quería que le diera mi opinión, ya que a él le parecía que el equipo era poco productivo, vamos que había demasiada gente para el trabajo que se hacía, y que se le estaban disparando los costes de mantenimiento del producto software que desarrollaban.
Como en “toda casa de vecino”

, había muchas cosas que se podían mejorar, pero lo que más me llamó la atención era un grupo de gente llamado el “equipo de replicación”. Y siempre que aparecen equipos transversales con nombres poco claros… algo raro pasa.
Resulta que el famoso equipo de replicación hacía lo siguiente: llegaba un bug, desarrollo lo solucionaba en una versión del software que había igual a la que tenía en producción el cliente que reporto el error… y una vez solucionado el bug el equipo de replicación se encargaba de buscar «a mano» y corregir ese mismo bug en más de veinte versiones software, que supuestamente eran igual a la anterior, pero que estaban en repositorios separados, había un repositorio separado por cliente, pero teniendo todos el mismo producto software.
En vez de una rama principal, y ramas para versiones, estabilización, “merges”, etc., había realmente más de 20 versiones en más de 20 repositorios diferentes.
Así claro que se necesitaba un equipo de repicación. Porque no se desarrollaba un producto con varias versiones… se mantenían más de 20.
Por si te interesa saber cómo terminó la historia, al final, con tanto lío, realmente las múltiples versiones ya no eran muy iguales, porque la mitad de bugs no se replicaban por tiempo, y tampoco se conocían las diferencias entre ellas, lo que se juntó con que era inviable el coste de «replicación».
La empresa se quedó sin dinero, se prescindió de las personas del equipo de replicación, se dejó de “replicar”, y se asumió que de por vida habría que mantener muchos productos (euros), ahora diferentes, pero a la vez similares.
Por esto, y por muchas otras historias que cuando tenga tiempo escribiré a modo “mis memorias” en post, siempre digo que la gestión de la configuración y el control de versiones son imprescindibles. Si yo pudiera, metería en cada una de las Universidades, en cada escuela de informática, una asignatura obligatoria sólo de gestión de la configuración.
No hay excusa, hay expertos en el tema, hay decenas de libros (te recomiendo encarecidamente leer el que para mí es el mejor libro sobre el tema, el Configuration Patterns de Berczuk y Appleton) que cuentan cómo gestionar como Dios manda las versiones, hay patrones, el área es madura, hay herramientas, las hay de software libre, y hasta una de las mejores herramientas es española (Plastic SCM, la de los amigos de Codice).

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

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.

0 comentarios en “Por qué siempre digo que la gestión de versiones es imprescindible. Una experiencia real ilustrativa”

  1. Pingback: Bitacoras.com

  2. No hace falta trabajar en la NASA para darse cuenta que un producto software sólo debe ser uno y único. Haberá que meterle paarámetros por un tubo para que cada cliente sólo vea lo suyo, pero nunca jamás se debe separar en una versión con las cosas de fulano y otra con las cosas de mengano, si haces eso estás muerto.

  3. gracias por la referencia al libro, lo desconocía.
    Ya estoy esperando las memorias!
    En la universidad si se enseña control de versiones, calidad de software etc. El problema es que son asignaturas TRONCALES pero el título es único (ingeniero en informatica). Luego, el mercado laboral valora el título pero no la especialidad (la administración pública por ejemplo) y pasa lo que pasa, que informaticos de otras especialidades acaban programando sin estar preparados. (Esto me pasó a mi, cuando en el 2000 acabé la carrera)
    El título debería reflejar la especialidad: Ingeniero en Informatica especialidad Ingenieria del Software.

  4. sigo..
    aunque pensándolo, si un tema como este del control de versiones da para para escribir un libro, dudo que tratarlo como una tema dentro de una asignatura se dé con la misma profundidad.
    Cada vez estoy mas convencido que la Ingenieria del Software es una especialidad por si misma, no 2 asignaturas.

  5. Super ilustrativo el ejemplo, ya que en contraste con la importancia del tema está lo difícil que puede ser explicarlo o que los alumnos lo vean como algo interesante y crucial en la Universidad!

  6. Hola,
    Yo creo que como profesores debemos hacer ver lo que realmente es importante en nuestra profesion. Utilizar casos de estudio, como este u otros, puede ser una buena manera de acercar la realidad a clase.
    Saludos

  7. Pingback: La revolución Github: el servicio líder para compartir código (y hoy también artículos, informes, etc.) - Javier Garzás, sobre calidad software y otros temas relacionados

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *