Versioning SQL Server?

Question

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

Como nuestro repositorio ha crecido Source Safe realmente ha comenzado a mostrar sus limitaciones y estamos considerando cambiar a otra solución. Para discusión están Team Foundation Server, Subversion, Git y Mercurial.

Nos son en gran parte una tienda de datos, por lo que otro factor importante para nosotros es poder fácilmente la versión de SQL Server 2005/2008 proyectos. 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 la forma de implementarlos.

Answer 1

Git y Mercurial son los únicos que debe considerar en mi humilde opinión, los otros 2 son demasiado antigua. 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.

No tengo experiencia previa con la integración de SSM SCM, pero AFAIK ninguno de los sistemas mencionados (excepto de 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 se pasa de SVN (con integración VS usando Ankh) a Git (sin integración) ...

Answer 2

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.

Answer 3

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

Answer 4

Hay potencialmente un buen número de alternativas - SQL Server Management Studio (SSMS) admite la integración con cualquier proveedor de interfaz de control de código fuente de Microsoft MSSCCI. 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?

E.g.

• ¿le interesaría establecer CI (integración continua)?
• automatizado construye/versiones automatizado?
• ¿soporte para múltiples entornos?
• configuración de gestión?
• ¿Qué tamaño de equipo tiene usted? 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 despliegue de TFS)?

Answer 5

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 la siguiente Manor:

• Utilizamos TortoiseSVN solamente. Sin integración VS/SSMS en absoluto.
• Tenemos un principio de "automatizar todo", por lo que nunca dependemos de las herramientas 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 de esquema se numeran 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!
• Evitamos todos los scripts cuando sea posible, ya que usamos NHibernate para que haya menos problemas con el control de versiones de script de todos modos.

Desde esta estructura, podemos volver a crear el entorno y la base de datos en cualquier momento en cualquier máquina que sea importante.

No lo usamos para pruebas unitarias, sin embargo, confiamos en 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.

Answer 6

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

Está diseñado para que sea fácil de control de versiones en cualquier sistema, y ​​gestiona las secuencias de comandos de actualización de una manera sana.

Answer 7

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).

Eche un vistazo a las características en el blog de Gert Drapers, comenzando con this post.

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

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

Answer 8

Ahora hemos agregado compatibilidad con VSS a SQL Source Control, que se integra con SSMS para proporcionar control de fuente totalmente integrado para el desarrollo de bases de datos. Para probar esto, visite: http://www.red-gate.com/MessageBoard/viewtopic.php?t=12265