sirve - Control de fuente de SQL Server
sql server versiones (8)
Hace poco escribí una secuencia de comandos para ayudarnos a resolver este problema: no es un control completo de la fuente, pero es solo un procedimiento almacenado que almacena el historial de los objetos de su base de datos en una tabla. Puede programarlo con el Agente SQL para que se ejecute. cuantas veces quieras
Si bien tomará instantáneas en un punto en el tiempo, en realidad no es compatible con los registros, pero ha guardado nuestro tocino varias veces cuando un proceso almacenado se cae o se cambia sin una copia de seguridad, y la versión anterior se restaura fácilmente.
http://trycatchfinally.net/2011/06/roll-your-own-lightweight-sql-server-source-control/
Cuando empezamos a utilizar el control de código fuente, los desarrolladores simplemente editarían los scripts en la base de datos y, justo antes del lanzamiento, se realizaría un script grande con todos los cambios. Esto funcionó muy bien hasta que uno de los desarrolladores eliminó accidentalmente un procedimiento almacenado y se perdió todo el trabajo.
Después de eso, colocamos todos los scripts para crear los procedimientos almacenados en archivos de texto y los almacenamos en el control de origen. El problema aquí es que los desarrolladores a veces actualizan el procedimiento almacenado en el control de origen o en la base de datos y se olvidan de actualizar el otro.
Mi sueño es tener un sistema donde un desarrollador ingrese y revise un procedimiento almacenado. Luego, después de realizar los cambios, la base de datos se actualiza automáticamente.
¿Esto es solo un sueño? ¿Cuál es la mejor manera de controlar el origen de SQL Server?
He trabajado en un entorno donde el control de origen era parte del procedimiento de lanzamiento.
Los DBA recibieron notas de lanzamiento que requerían que el DBA obtuviera el control de origen y luego liberara los cambios de procedimientos almacenados o los scripts de SQL desde allí. Si puede hacer que los DBA estén de lado, esta es una buena manera de evitar lanzamientos abortados, ya que debería poder probar el SQL en un sistema UAT.
Si los datos no se liberan en el control de origen, entonces no se liberan.
Se utilizaron ramas de integración para liberar el código.
Hemos estado utilizando Visual Studio Team System Database Edition recientemente, y debo decir que ha funcionado muy bien. Todos los procedimientos almacenados se almacenan como archivos y se registran dentro y fuera del control de origen, y tiene herramientas para generar scripts, etc.
Además, en el pasado hemos usado scripts almacenados como archivos de texto que están dentro y fuera del control de origen. La regla era que tenía que desproteger el archivo, luego editarlo, por ejemplo, Management Studio, y guardarlo, y volver a ingresarlo. En la parte superior de cada archivo de script de procedimientos almacenados, se eliminaría el proceso almacenado existente. y luego use la sentencia CREATE para crear una nueva (soluciona el problema CREATE / ALTER). Luego, tuvimos una herramienta que ejecutaría todos los scripts en el orden correcto para construir una base de datos en blanco desde cero, y luego usamos el producto de comparación de RedGate para generar un script para actualizar nuestras bases de datos existentes. Admito que fue tedioso.
Casi al mismo tiempo trabajé en un sistema con otros 10 desarrolladores, e implementaron un riguroso procedimiento de gestión de cambios en la base de datos. Había muchas, muchas aplicaciones que dependían de un conjunto de 2 o 3 bases de datos. Cada vez que un esquema de base de datos tenía que cambiar (solo hablamos de tablas, columnas y vistas aquí), se creaba un documento que explicaba el cambio, y luego había una matriz que enumeraba los cambios frente a las aplicaciones que pensábamos que tendrían impacto . Luego, el documento fue circulado y tuvo que ser revisado por alguien responsable de cada solicitud, y tuvieron que buscar en su aplicación para que pudiera verse afectado, etc. Fue un procedimiento largo y arduo, pero funcionó. Sin embargo, los procesos almacenados solo se almacenaron como archivos de texto en el control de origen.
En el pasado más lejano, con proyectos más pequeños que se parecían más a las aplicaciones de escritorio con una base de datos como el almacén de datos, cada vez que se iniciaba la aplicación, yo:
- Compruebe si existe la base de datos, y si no, créela
- Compruebe que todas las tablas existían, y si no, créalas
- Compruebe que todas las columnas existieron, y si no, agréguelas
Siempre que tuviera que cambiar el esquema, simplemente agregaría más código al final del código de inicio para modificar el esquema según sea necesario, teniendo cuidado de migrar cualquier información existente. La ventaja de esto era que simplemente podía desinstalar y reinstalar una nueva versión del software, y actualizaría automáticamente la base de datos existente a la última versión. Instalación, actualizaciones y mantenimiento fue un sueño. Sin embargo, eso no funcionaría para más sistemas "empresariales".
Puede reducir algunos de estos problemas adoptando Entidades ADO.Net u otro Entity Framework similar, como Entity Spaces . Estas son capas de mapeo objeto-relacionales. Generan automáticamente las clases para cada entidad (tabla) en su base de datos, incluidas las propiedades para cada columna, etc. Luego, le permiten extender esas clases con lógica personalizada. Si puede evitar tener su lógica de negocios en los procedimientos almacenados y colocarlos en las clases de Entidad, el beneficio es que están fuertemente tipados. Por lo tanto, si cambia el nombre de una columna, o elimina una columna y regenera sus clases de entidad, su IDE o compilador marcará automáticamente todos los lugares donde se rompe el código. Obviamente, todo el código de la entidad está naturalmente en el control de la fuente con el resto de su código fuente también.
La clave es limitar el derecho a presionar solo a unos pocos individuos e insistir en que nunca realicen cambios, excepto al llamar un script desde el control de código fuente. En las nuevas versiones de SQl Server, también puede configurar el registro DDL para averiguar exactamente quién cambió esa tabla a una versión que no está en Source Control.
La primera vez que cambiamos al uso del control de código fuente en nuestra base de datos, todos tenían derechos de producto (algo que ya hemos corregido), por lo que periódicamente realizamos una comparación de los controles de control de origen con la base de datos de producto real y eliminamos cualquier cambio no autorizado. . Solo tomó una vez hacerlo para convencer a los desarrolladores de que tenían que usar el control de código fuente.
La forma en que he visto que el control de origen funcionaba mejor para SQL Server en un entorno de equipo era cuando el DBA hacía compilaciones regulares de la base de datos utilizando el código registrado. Por lo general, solo se necesita una sola vez para perder algo porque no se registró antes de que los desarrolladores obtuvieran la imagen de que el hecho de registrar su código significa algo.
Espero que esto ayude,
Cuenta
Lograr que los desarrolladores recuerden cometer código es complicado.
El otro extremo es un poco más fácil porque una vez que las actualizaciones están en el control de origen, pueden automatizarse con scripts para construir una nueva base de datos o eliminar y recrear una base de datos desde el control de origen.
Echa un vistazo a este product gratuito que te ayudará a configurar una línea de base de una base de datos de SQL Server.
La herramienta también creará una base de datos a partir del control de origen, por lo que, en teoría, puede hacer que los desarrolladores de X trabajen en el proyecto y todos ellos puedan ejecutar sus confirmaciones de origen en su propia base de datos, y viceversa, volver a implementar sus actualizaciones en fuente de control.
Desafortunadamente, no puedo pensar en cómo hacer que los desarrolladores recuerden los cambios de base de datos. Tal vez podrían ejecutar una herramienta (o archivo por lotes) que realizará una extracción de la base de datos local para controlar la fuente y luego adquieran el hábito de ejecutar esta tarea repetitiva a través de un archivo por lotes, cada vez que realizan una extracción / confirmación en la fuente. ¿controlar?
Red Gate SQL Source Control integra completamente el control de origen a SQL Server Management Studio. Esto efectivamente vincula su (s) base (s) de datos de desarrollo a su sistema de control de fuente existente (TFS y SVN), lo que le permite cometer cambios y recuperar los cambios de otros desarrolladores con solo hacer clic en un botón.
http://www.red-gate.com/products/SQL_Source_Control/
Ahora hemos agregado el soporte de VSS y SourceGear Vault a una versión de EA. Más detalles aquí: http://www.red-gate.com/MessageBoard/viewtopic.php?t=12265
Siempre hemos utilizado la utilidad scptxfr que viene con SQL Server 2000 para enviar la base de datos a un archivo que está almacenado bajo el control de código fuente.
Lo ejecutamos antes de hacer un chequeo y se resaltará cualquier posibilidad que haya ocurrido (sea esperado o no). No viene con 2005 o posterior, pero si tiene alguna instalación anterior de 2000, todavía funciona con las versiones más recientes. Puede tener problemas con esquemas complejos, pero es un buen punto de partida. También se podría convertir en un proceso automático cuando se combina con activadores de control de fuente o integración continua.