Sé que lo que voy a comentar y mostrar puede causar incomodidad, fundamentalmente porque voy a hacer “propaganda involuntaria” a un producto comercial, pero antes de decir el nombre que espero solo mencionarlo una única vez, en toda la entrada, quiero aclarar, que no trabajo para esta empresa, en ningún sentido y que mi intensión no es venderles una copia del mismo, solo es argumentar en base a dicho producto, las opiniones que voy vertiendo.
Primero contarles, que he trabajado, con varios productos de control de código o control de versiones (como lo llamare indistintamente), desde el CVS, pasando por SVN, arribando misteriosamente a Visual SourceSafe (gajes del oficio) y finalmente entrando al increíble y vasto mundo de Team Foundation System. En todas estas experiencias, cada una de ellas mejor que la otra, bueno, no tanto SourceSafe comparada a SVN pero si en lo que se refiere a su integración con Visual Studio, obviamente algo que SVN deja mucho que desear, por muy Tortoise o Visual SVN, que se use J, esta experiencia me ha expuesto a diferentes formas de trabajar en equipo, desde equipos pequeños de 3 personas (desarrolladores) hasta un equipo de más de 25 programadores (mi actual laburo), cada uno de ellos con diferentes problemas desde la comunicación hasta extrañas rencillas personales y en todos ellos un denominador técnico común, la existencia de errores de compilación en el código que se sube al control de versiones.
Les describo un escenario, que seguramente es común, en muchos lugares; supongamos que estamos en el escenario más pequeño donde 3 programadores trabajan sobre una cantidad de archivos, que seguramente tampoco es muy enorme,
- El programador A inicia su día y como sería lo más recomendable, realiza un get-latest de toda la solución, antes de empezar su jornada, comienza editando unos archivos y porque le parece innecesario comenta un método en un archivo, el método no está siendo utilizado en ningún lugar, para que alguien deja un método sin uso!!! (Check-out) Y en la clase que él ha programado, pero sin darse cuenta que este método es importante para el programador B.
- El programador B que estuvo trabajando toda la madrugada, sin editar ese método ni el archivo, programo otras clases confiando en la existencia del método, hace get-latest antes de hacer chekin y procede a subir sus cambios al servidor, todo compila para mi (dice el programador B)
- El programador A, 5 segundos después del programador B, hace checkin si hacer get-latest porque está trabajando también desde su casa, su perrito cachuchin se murió esa noche, no está de humor para esperar a recuperar la solución entera de nuevo!!, hace unos minutos hizo get-latest que pudo haber pasado, y repite todo compila para mi (dice el programador A)
En este escenario ya existen problemas de compilación con el código que está en el control de versiones; puede analizarse el problema desde diferentes puntos de vista, entre ellos.
- Es culpa del programador A, porque no cumple con la norma de get-latest antes de hacer checkin, opinión valida, pero la defensa del programador A también es válida, el puede argüir hace x minuto(s) hizo get-latest y todo estaba bien
- Falta de comunicación, entre programadores, quizá hubiese bastado que el programador A, le avise al programador B que iba a hacer ese cambio, pero nuevamente, en entornos de alta concurrencia y exigencia, el averiguar quién es el dueño de una línea de código puede representar minutos valiosos.
Las soluciones van de la mano quizá, de los problemas que se encontraron:
- Incrementar el nivel de comunicación de las políticas de construcción (build), como ser get-latest al principio de las ediciones, get-latest antes de hacer checkin
- Incrementar el nivel de comunicación entre programadores.
- Dividir la solución en trozos más manejables evitando interferencias mutuas.
En fin puede encontrarse diferentes formas más, de encarar, este problema y créanme que aplique muchas de ellas con éxitos parciales y yo catalogo a estas soluciones en reactivas y proactivas, todas las que incluyen hacer algún procedimiento manual, comunicativo, de partición o arreglo, son reactivas, porque tarde o temprano caerán en alguien reaccionara para resolver el problema de ese archivo en el control de código y créanme que esto se vuelve una bola de nieve y cuando hay más de dos programadores involucrados hay varios más adicionalmente parados porque no pueden compilar la solución entera, hasta que arreglen el problema. La solución proactiva que encontré, quizá al leer esto alguno me de otra proactiva, es algo que en mis días y noches de trabajo pensé…. En estas fases:
- ¿Por qué no compilar la solución antes de hacer checkin?, bueno eso ya estaba en la norma, del papel, no funcionaba.
- ¿Por qué no, obligar a todos a hacer get-latest antes de hacer checkin? Es algo que es simple de poner en la norma pero no todos la pueden cumplir, hay algunos que tienen trabajo remoto, problemas de ancho de banda, etc., tampoco funcionaba.
- ¿Por qué no, dejar que el servidor de integración continua haga las dos cosas anteriores por mí?
- Un momento para que suceda esto tengo que enviar todos los cambios que haya hecho yo, al servidor, el los debe recibir, obtener versión (get-latest) de todo, unirla a mis cambios, compilar, si es exitosa la compilación recién hacer checkin por mi e informarme de esto…..uffff
¿Esta idea estaba correcta? Decidí averiguar mas y encontré que mis ideas locas estaban sustentadas en un libro de patrones de integración continua, que creo que algunos de los miembros de los equipos de Microsoft u otros fabricantes de herramientas de integración continua, no lo hojearon y mencionan como Private Builds (Construcciones Privadas), sin embargo el concepto no correspondía exactamente al que yo tenía en mente, hasta que me encontré con Team City.
Este motor o servidor de integración continua, muy a pesar de mi querido TFS Build, había implementado una característica llamada Pre-test commit o Remote Private Build, que concuerda con todas mis expectativas, a tal punto que inmediatamente pude, es decir en cuanto tuve la oportunidad en mi nuevo laburo, instalamos y pusimos en producción esta idea experimental, a esto debo agradecer enormemente el apoyo recibido por parte de Andrés Gonzales y Dulfredo Rojas, sin quienes mis ideas y expectativas de probar esas “teorías”, solo hubieran quedado en eso.
Antes de pasar a explicar los beneficios del Pre-test Commit y como afecto esto a nuestra compañía, déjenme decirles que esto lo comente personalmente con dos personas de Microsoft, una de Argentina y otra de Perú, de las cuales me abstengo de dar nombres para evitarme problemas, pero que se que son lectores míos y con todo respeto, ambos quedaron totalmente sorprendidos de que existiese una herramienta similar.
La siguiente imagen muestra unas estadísticas de su uso, sobre las cuales voy a ir dando las bondades que obtuvimos:
Antes de la puesta en producción, nuestra tasa de Builes o construcciones exitosas del producto, con suerte llegaban al 30%, en el grafico pueden observar que paulatinamente pasan los meses y las tasas de construcción automática exitosas, se van estabilizando e incrementando, hoy alcanzamos un poco más del 80%, esto quiere decir que el código que está en el servidor, prácticamente es estable en compilación, antes los programadores tenían miedo hacer el get-latest, hoy es una práctica mucho más segura, el incremento paulatino se debe fundamentalmente al tiempo de adaptación que tuvieron los programadores y el tema de hacer olvidar a todos ellos la frase: “Compila para mi” o “compila en mi equipo (computadora)”
Pasemos al segundo, grafico, que me permitirá resolver otra de las preguntas que puede que algunos estén haciéndose, cuán rápido puede ser el proceso de hacer remote prívate Builes, y este grafico muestra que en promedio nuestros Builes ya sean personales o normales tardan 2 minutos, nuestra solución tiene algo más de 70 proyectos (ya se vamos a particionar la solución 🙂 )y el compilar en una maquina local tarda entre 10 a 15 minutos, una solución Windows Forms y muchos chiches mas, la solución de compilación que compila en nuestro servidor de integración continua está basado en Nant y con algunas optimizaciones. Algunos podrán preguntarse y porque no MS-Build y la verdad la respuesta es que mis pruebas las programe inicialmente en Nant por simplicidad y luego el migrar todo a Ms-build pues nos tomara un cachito pero estoy consciente que funcionara bien
El ultimo gráfico, muestra una característica que tiene este servidor de integración continua y es el encolamiento de solicitudes de build, que aunque no está asociado directamente al Pre-test Commit les da una idea de que en promedio tenemos 2.5 minutos de encolamiento, hay días pésimos y otros maravillosos, pero ya tenemos pensado agregar un segundo servidor que disminuirá enormemente este tiempo.
La herramienta de por si tiene varias características, entre ellas que soporta muchos lenguajes scripts de construcción automática como Nant y MS-Build entre otros, soporta diferentes controles de versiones, CVS, Perfore, SVN, etc., se conecta e integra perfectamente a Visual Studio, escala perfectamente, aunque tenemos algunas dudas que seguramente las solucionaremos pronto, tiene interfaces de notificación y configuración para todos los gustos, en fin ingresen a la pagina y podrán encontrar mucha información.
Quizá la más grande cuestión que queda es, ¿porque no TFS Build? Y principalmente porque no tiene la característica de Pre-test Commit, que es la principal razón por la que escogimos este servidor.
Dos recomendaciones una a Microsoft como a otros fabricantes tales como CruiseControl, implementen esta característica, realmente eleva los niveles de productividad, en ambientes de alta concurrencia, pues es un método pro-activo, al impulsar al programador a tomar la responsabilidad de pensar en un “build sano” y permitiría que un servidor de integración continua, haga algo más que hacer Builes y mi última recomendación a los programadores (usuarios finales), los métodos reactivos tarde o temprano fallan, tomen uno proactivo.
Lo conversaba con mi colega Andrés Gonzales y otra idea genial seria que Microsoft, aceptaría en el TFS la posibilidad de intercambiar su motor de control de código, por otro como CVS (nooo que dije), algo así como su proxy con SVN pero mucho más nativo, esto abriría enormes posibilidades, pero este comentario, es harina de otro artículo.
Un abrazo y si les gusto quizá me dan una idea de donde más explicar algunos detalles.
Saludos
