Buenas,
anoche estuvimos con los amigotes de MadridDotNet en las oficinas de AulaVulcan hablando de nuestras experiencias con las herramientas para la gestión de código fuente. Si bien el ambiente era bastante heterogéneo (todos con tecnologías Microsoft), confirmé que una vez más en este aspecto no hay soluciones mágicas que apliquen a todos los escenarios.
Hablamos de bastantes cosas, desde herramientas hasta Moles, pero para resumir dejo los siguientes puntos:
Herramientas de control de código fuente
En este punto hubo 2 herramientas que se utilizaban: Visual Source Safe y Team Foundation Server 2010.
Si bien es una herramienta que da muchos problemas, no tiene soporte y es bastante pobre todavía hay muchos VSS en el mundo. Yo comenté mis nefastas experiencias con SubVersion y la verdad me hubiese gustado escuchar a alguien que utilice GIT o Mercurial de manera más frencuente para tener una opinión válida del mundo de los DVCS.
Estrategias de Branching
Parece imposible pero todavía en el 2011 y todavía existen equipos que no tienen definida una estrategia de Branching. Si nunca has visto este tema y no sabes de que va, pues la Visual Studio TFS Branching Guide 2010 de Codeplex, seguro que te abre los ojos. Si en cambio ya sabes de que va el tema, como era el caso de @javierholguera pues aquí la cosa se pone más interesante.
Javi y su compañero nos comentaron como era su estructura actual de código fuente y comentaron un caso interesante > “No hacen un full branch para las ramas donde trabajan”. A primera vista esto puede parecer un poco ilógico, pero despues de ver un poco el modelo de negocio con el que se manejan, pues la cosa tiene bastante sentido, aunque claro también nos comentaron que cuando hacen los MERGEs tienen cuidado especial.
Miedo al MERGE (más que a la crisis !!!)
Esto lleva otro tema > mucha gente le tiene miedo a los MERGE. Personalmente yo creo que la acción de merge no es mala, es más, prefiero enfrentarme a los merge lo antes posible porque eso significa que estoy integrando trabajo en early stages. Cuanto más frecuentes sean los merges menos problemáticos serán los mismos. Aunque claro, eso es solo mi opinión y no es lo mismo hacer Merge con la herramienta que trae por defecto Visual Studio 2010 que con WinMerge.
¿Debemos mantener los históricos?
Sobre la marcha y relacionado con el tema anterior también surgió el tema de si era necesario mantener o no los históricos en el Source Control. A mi el instinto me dice que no destruya nunca nada, pero claro “cada bit se paga en €uros” y cuando trabajas con soluciones grandes, o tienes muchas ramas, pues esto se paga en espacio en disco, backup, etc.
El tema también estaba relacionado con la forma de trabajo de los equipos > “siempre hacemos un Get Latest de todo el Source Control en local y claro, eso es mucho”; aquí Luis (@lfraile) sugirió la posibilidad de configurar los Workspaces utilizando Cloack en los mismos para no tener que descargar todo (sobre esto escribí hace más de 2 años aquí) y quedó como una solución. Aunque yo no descarto educar un poco al equipo de trabajo y solo descargar lo que necesito para trabajar, esta es una de las ideas principales en las que se basan los Workspaces en Team Foundation Server.
CheckOut exclusivo > good or evil
Pues en el medio de checkin/checkout, workspaces, source control y demás, no podía dejar de aparecer el clásico y popular > “CheckOut exclusivo”. Aquí @javierholguera, Gisela, Jorge y otros estaban a favor de habilitar el checkout exclusivo para evitar problemas de MERGE, especialmente en archivos de proyectos donde el auto merge hace verdaderas obras de arte en Visual Studio.
Yo defendí mi posición “anti checkout exclusivo”, pero como no había cervezas de por medio apostadas, pues decidí no darle más vueltas, aunque veo que si bien es un cambio muy agradable incorporado en TFS2005, hay personas que prefieren trabajar con modo “lock”.
Organización de la estructura del Source Control
La última para no hacer de un post un libro, comentaré sobre otro tema que está atado a todo lo demás > “Cómo organizo mis soluciones?” aqui Javier comentó escenarios complejos de organización teniendo en cuenta proyectos de bases de datos, fachadas de servicios, etc. Un escenario interesante que se planteó fué el de como llevar adelante el desarrollo de productos que utilicen varias bases de datos SQL Server y cada una de ellas gestionada con proyectos dbproj. El problema surgía cuando nuevos productos compartían parte de un schema en una DB existente y se quería lograr tener integración contínua en las builds utilizando los proyectos de db para 2 productos diferentes. Básicamente se estaba mezclando por un lado funcionalidad de negocio en una misma base de datos, pero si se separaba quedaba un tanto complicado el proceso de CI. La solución: pues no hay ninguna de libro, aqui toca adoptar un modelo y ver si el mismo funciona 
Links, herramientas y otras cosillas para revisar
Finalmente dejo un pequeño listado de cosillas para ver que surgieron durante el evento:
Conclusión
Finalmente yo creo que lo mejor es lo siguiente:
- Formación
- Conocer las capacidades de las herramientas
- Conocer la problemática del negocio
- Tomar una decisión para comenzar a trabajar
- Cada 6 semanas/meses ajustar la forma de trabajo
- Go To 2
Update: me he olvidado de hablar un poco de la charla de café con las magdalenas y los cafecitos que nos tomamos después !!! Lo siento . Obviamente esto fué lo mejor
Saludos @ Here
El Bruno
. We’ll see topics as diverse as Silverlight, ASP..NET, Ajax, JQuery, TDD, Kinect, Coded UI Tests, SharePoint, ASP.NET MVC, Windows Phone, testing performance, etc.
.png)
