Control de Versiones: Abandona ya CVS y Sourcesafe!
Ineludible…. hay que tener repositorios de control de código. Eso de tener una carpeta compartida sin control, o avisarnos a viva voz de “espera, espera!! que estoy yo editando eso”… me temo que para los días que corren es una solemnte chapuza :_)
El otro día tuvimos un evento de lanzamiento de Visual Studio y a una pregunta de mano alzada, la respuesta fue que la mayor parte de la audiencia utilizaba sistemas de control de versiones antiguos (sourcesafe).
Supongo que será por comodidad, porque más o menos les funciona y están acostumbrados a lidiar con los errores que aparecen,pero personalmente a esa situación la considero…vagancia :) Y no dudo que alguno tendrá sus motivos, pero me jugaría algo a que la mayoría ha sido por no andar mirando cómo se migra y que opciones hay ;)
De todos modos… empecemos con una pregunta… ¿Sólo quieres control de código? A día de hoy hay un montón de herramientas alrededor del código fuente generado. Gestión de tareas alrededor del código, trazabilidad de los cambios, plantillas metodológicas, reportes sobre estas tareas y archivos, cobertura de código por las pruebas…. herramientas ALM (application lifecycle management) en definitiva. Todos estamos de acuerdo en que estas herramientas son deseables para un equipo de desarrollo. Ayudan a medir el impacto de una decisión, a prevenir situaciones incómodas en un proyecto, a justificar una u otra decisión, a estimar tiempos, etcétera… Al ser un apoyo tan importante, en mayor o menor medida todas estas herramientas van entrando en los equipos, así que, además del hecho de contar con ellas, también se vuelve de vital importancia cómo están estas herramientas conectadas entre sí. No te vale de nada tener 4 herramientas magníficas si el pegamento entre ellas es tu esfuerzo personal en hacer control+c y control+v ;)
Volviendo al control de código puro y duro, ahí va un resumen de cada una de las opciones más utilizadas en el mercado.
El cretácico: CVS y Sourcesafe.
No nos engañemos, son dos opciones totalmente desactualizadas, estas out. Fueron buenas alternativas en su momento pq no había otra cosa, pero actualmente han sido sobrepasadas de largo por otras opciones. Normalmente el cambio natural es que si estás en CVS pases a GIT y si estás en sourcesafe pases a TFS ( la migración está tirada y tienes un herramientas y docs para ayudar… http://msdn.microsoft.com/en-us/library/ms253060.aspx ).
Opciones reales de control de código: Subversion, Git y TFS
Desarrolles en lo que desarrolles TIENES que tener una de estas 3 opciones, no hay más vuelta de hoja. Si no estás entre estos 3 es porque ya las has evaluado y eres el 1% que no puede migrar por alguna razón ineludible.
SVN / Subversion. Empezó en el 2000 y fue diseñado para reemplazar al CVS, añadiendo algunas funcionalidades y corrigiendo algunos de los fallos más garrafales de éste ( renombrado, manejo de archivos binarios ). Ha sido ampliamente utilizado por la comnidad open source (apache, mono, ruby, php…). Tiene multitud de clientes disponibles para acceder al servicio. Es independiente del sistema operativo.
Tiene algún problema reconocido con el renombrado de elementos, porque los mantiene como copias así como falta de sistemas de gestión y administración.
No tener el apoyo de la comunidad de desarrollo del kernel y el hecho de que se implementasen su propio sistema (Git) le hizo mucho daño a SVN.
Git. Tiene un padrino de excepción, Linus Torvalds. EL diseño de Git esta influenciado por la experiencia de Linus en la gestión del gódigo fuente de Linux. Surgió por necesidad, cuando los desarrolladores del kernel se vieron forzados a dejar su control de código habitual, CVS y su sucesor SVN no les parecieron opciónes válidas, de modo que diseñaron y construyeron Git. Ese apoyo ha hizo que que git cobrase muchos adeptos rápidamente.
Team Foundation Server. Parte de una base diferente al resto, si bien ofrece servicios de control de código, tiene las herramientas adicionales incluidas. Parte de su funcionalidad sustituye lo que ofrecía Visual Source Safe.
OJO!! Es importante destacar que el hecho de que vengan incluidas las herramientas de ALM no significa necesariamente que haya que utilizarlas ;) Puede instalarse TFS únicamente para realizar tareas de gestión del código fuente, de hecho creo que es el primer paso pare perderle el respeto miedo.
Tener toda la solución ALM incluida y ser un producto de pago ha hecho que en el mundo Microsoft mucha gente siga con SourceSafe por respeto a adoptar toda la solución de golpe. Es un error por desconocimiento, a ver si ahora con la versión 2010 empujando y teniendo el TFS gratis con el entorno de desarrollo cambia el panorama.
Personalmente creo que la lucha estaría entre Git y TFS. Pero… si bien Git es un producto muy bueno para el control de código, y una de las funciones de TFS es control de código, creo que no son comparables, dado que TFS tiene la ventaja de tener la solución ALM integrada (plantillas metodológicas, workitems, reportes, portal de proyecto…) y conectada con diferentes herramientas (excel, project, visual studio,… ).
De modo que en 9.5/10 casos para desarrollos en .NET … instálate el TFS ya hombre!!! :D
Más opiniones
http://consultingblogs.emc.com/jamesdawson/archive/2009/07/28/tfs-vs-svn-vs-git.aspx
http://ayende.com/Blog/archive/2007/04/29/TFS-Vs.-Open-Source-tools.aspx
http://stackoverflow.com/questions/661389/tfs-vs-svn
https://git.wiki.kernel.org/index.php/GitSvnComparsion
Happy hacking!
~ds