sql-server-2005 svn git version-control mercurial

sql server 2005 - ¿Versión de SQL Server?



sql server version 852 (8)

Mi grupo de desarrollo usa Visual Source Safe para el control de versiones; esta elección se realizó originalmente debido al costo y su estrecha integración con Visual Studio.

A medida que nuestro repositorio creció, Source Safe comenzó a mostrar sus limitaciones y estamos considerando cambiar a otra solución. Para discusión están Team Foundation Server, Subversion, Git y Mercurial.

Somos en gran medida una tienda de datos, por lo que otro factor importante para nosotros es poder realizar versiones de proyectos SQL Server 2005/2008 fácilmente. Este es uno de los beneficios de usar Source Safe, y también de Team Foundation Server: la integración con Microsoft SQL Server Management Studio.

Me pregunto si alguien ha tenido experiencia en la creación de versiones de SQL Server con Subversion, Git o Mercurial y puede proporcionar algunos pros / contras sólidos para cada uno de estos sistemas, así como también la forma en que los implementó.

A TFS le faltan algunas características de VSS, especialmente la expansión de palabras clave. Si no incrusta la información de palabra clave de revisión dentro de sus archivos fuente, entonces no debería ser una preocupación.

Esta podría ser una herramienta útil para ti: http://www.liquibase.org/

Está diseñado para que sea fácil el control de versiones en cualquier sistema y gestiona tus scripts de actualización de una manera sensata.

Existen muchas alternativas posibles: SQL Server Management Studio (SSMS) admite la integración con cualquier proveedor MSSCCI de interfaz de control de código fuente de Microsoft. De modo que puede ampliar la búsqueda a los sistemas de control de origen que cuentan con un proveedor compatible con MSSCCI.

En SSMS, consulte Herramientas -> Opciones -> Control de fuente para ver qué complementos de proveedor están instalados en su sistema.

Por ejemplo, la integración de Team Foundation Server con SQL Management Studio es cortesía del proveedor TFS MSSCCI. Creo que hay un proveedor para CVS / Subversion ("Aigenta Unified SCC"), y así sucesivamente.

En cuanto a una lista de pros y contras, creo que siempre que haya un proveedor compatible, puede abrir la pregunta a un público más amplio. Mi experiencia principal es con VSS, TFS y Subversion. Realmente se trata de tu equipo y del entorno. ¿Puedes elaborar más sobre tu entorno?

P.ej

  • ¿le interesaría establecer CI (integración continua)?
  • compilaciones automatizadas / versiones automatizadas?
  • soporte para múltiples entornos?
  • gestión de configuración?
  • ¿Qué tamaño de equipo tienes? es probable que tenga muchas fusiones / ramificaciones, etc.
  • ¿ya tiene implementado un sistema de seguimiento de errores (obtiene elementos de trabajo / seguimiento de errores como parte de un lanzamiento de TFS)?

Git y Mercurial son los únicos que debes considerar en mi humilde opinión, los otros 2 son demasiado anticuados. Los SCM modernos deberían tratar ramas como lo hace git.

Para las comparaciones git vs. mercurial ver: http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/ , http://www.russellbeattie.com/blog/distributed-revision-control-systems -git-vs-mercurial-vs-svn .

Sin embargo, no tengo experiencia previa con la integración SSM SCM, pero AFAIK ninguno de los sistemas mencionados (excepto TFS) tiene uno. No lo llamaría una desventaja a pesar de que la GUI, por ejemplo, es una herramienta muy útil, que le resultará más agradable que dicha integración. Este es al menos mi caso cuando me paso de SVN (con integración VS usando Ankh) a Git (sin integración en absoluto) ...

Mercurial tiene integración VS con VisualHG , si cree que DVCS es el camino a seguir. Lo usamos para proyectos C ++ / C # en nuestra tienda, y funciona lo suficientemente bien. (OTOH, nunca he usado ninguna integración "completa", así que estoy feliz de trabajar con la extensión de explorador y / o la línea de comandos para un trabajo de VC detallado).

Mi respuesta honesta es no hacer ninguna integración con sus herramientas de base de datos y SCM si puede evitarlo. Use el sistema de archivos donde sea posible. Es otra capa de integración que va a ser un dolor. Pequeñas herramientas separadas son mejores que un gigante.

Usamos Subversion y SQL 2005 juntos en el siguiente señorío:

  • Usamos TortoiseSVN solamente. Sin integración VS / SSMS en absoluto.
  • Tenemos un principio de "automatizar todo", por lo que nunca dependemos de herramientas de GUI para hacer el trabajo.
  • Mantenemos todos los scripts dentro de SVN junto con el código. El código, el esquema y los scripts se versionan juntos.
  • Los cambios del esquema están numerados por orden de aplicación, es decir, 000-create-table-users.sql. Anotamos el número máximo de scripts desplegado en cada entorno. Cada script realiza una migración al siguiente número de base de datos r. Cuando implementamos, revisamos la fuente y ejecutamos todos los scripts desde el último número de versión hasta el número más alto.
  • Cualquier scripts que no sean esquemas (sprocs / views) son idempotentes (se pueden ejecutar cualquier cantidad de veces con el mismo resultado). Se aplican a través de un complemento nant que escribimos. Estos se reemplazan cada vez que implementamos. ¡No te olvides de refrescar tus vistas!
  • Siempre que sea posible, evitaremos los scripts ya que usamos NHibernate para que haya menos problemas con el control de versiones del script de todos modos.

A partir de esta estructura, podemos recrear el entorno y la base de datos en cualquier momento en cualquier máquina que sea importante.

Sin embargo, NO lo usamos para pruebas unitarias: dependemos de la generación del esquema NHibernate para hacer esto sobre una base de datos SQLite.

El único punto negativo que hemos encontrado ha sido asegurarnos de que los desarrolladores se adhieran al proceso. Pastorear gatos es una descripción muy apropiada.

Visual Studio Team System 2008 Database Edition (nombre en clave "DataDude") es lo que necesita.

Le permite versionar los objetos de su base de datos de maneras que le dejarán sin palabras. (por ejemplo, actualizar un sitio del cliente a una versión específica, o revertir a una versión anterior sin destruir ningún dato).

Echa un vistazo a las características en el blog de Gert Drapers, comenzando con esta publicación .

O si prefiere un podcast, escuche DotNetRocks con Chris Sells en el show 494 .

No sé si está limitado a TFS para el control de código fuente cuando usa DataDude, pero es el miembro inmerecidamente infrautilizado de la familia de Visual Studio.