Procedimientos almacenados / esquema de base de datos en control de fuente
¿Ustedes hacen un seguimiento de los procedimientos almacenados y el esquema de la base de datos en el sistema de control de su elección?
Cuando realiza un cambio (agrega una tabla, actualiza un proceso almacenado, ¿cómo obtiene los cambios en el control de origen?
Usamos SQL Server en el trabajo, y comencé a usar darcs para el control de versiones, pero me interesarían las estrategias generales y las herramientas útiles.
Editar: ¡Guau, gracias por todas las buenas sugerencias, chicos! ¡Ojalá pudiera seleccionar más de una "Respuesta aceptada"!
Elegimos guiar todo, y eso incluye todos los procedimientos almacenados y los cambios de esquema. No se necesitan herramientas wysiwyg ni programas sofisticados de 'sincronización'.
Los cambios de esquema son fáciles, todo lo que necesita hacer es crear y mantener un solo archivo para esa versión, incluidos todos los cambios de esquema y datos. Esto se convierte en su script de conversión de la versión x a x + 1. Luego puede ejecutarlo contra una copia de seguridad de producción e integrarlo en su 'compilación diaria' para verificar que funciona sin errores. Tenga en cuenta que es importante no cambiar o eliminar el esquema/datos ya escritos cargando sql, ya que puede terminar rompiendo cualquier sql escrito más adelante.
-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO
-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO
Para los procedimientos almacenados, elegimos un solo archivo por sproc, y utiliza el formulario soltar/crear. Todos los procedimientos almacenados se recrean en la implementación. La desventaja es que si se realizó un cambio fuera del control de la fuente, el cambio se pierde. Al mismo tiempo, eso es cierto para cualquier código, pero su DBA debe ser consciente de esto. Esto realmente evita que las personas fuera del equipo se burlen de sus procedimientos almacenados, ya que sus cambios se pierden en una actualización.
Usando SQL Server, la sintaxis se ve así:
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [usp_MyProc]
GO
CREATE PROCEDURE [usp_MyProc]
(
@UserID INT
)
AS
SET NOCOUNT ON
-- stored procedure logic.
SET NOCOUNT OFF
GO
Lo único que queda por hacer es escribir un programa de utilidad que comparta todos los archivos individuales y cree un nuevo archivo con todo el conjunto de actualizaciones (como un solo script). Para ello, primero agregue los cambios de esquema y luego vuelva a recurrir a la estructura del directorio e incluya todos los archivos de procedimientos almacenados.
Como una ventaja para hacer scripts de todo, será mucho mejor leyendo y escribiendo SQL. También puede hacer que todo este proceso sea más elaborado, pero este es el formato básico de cómo controlar la fuente de todos los sql sin ningún software especial.
anexo: Rick tiene razón en que perderá permisos en los procedimientos almacenados con DROP/CREATE, por lo que es posible que deba escribir otro script que volverá a habilitar permisos específicos. Este script de permiso sería el último en ejecutarse. Nuestra experiencia encontró más problemas con ALTER versos DROP/CREATE semántica. YMMV
cree un "Proyecto de base de datos" en Visual Studio para escribir y administrar su código sQL y mantener el proyecto bajo control de versiones junto con el resto de su solución.
La solución que utilizamos en mi último trabajo fue numerar los scripts a medida que se agregaban al control de origen:
01.CreateUserTable.sql
02.PopulateUserTable
03.AlterUserTable.sql
04.CreateOrderTable.sql
La idea era que siempre supiéramos en qué orden ejecutar las secuencias de comandos, y podríamos evitar tener que gestionar los problemas de integridad de datos que podrían surgir si intentara modificar la secuencia de comandos n. ° 1 (lo que presumiblemente haría que los INSERTOS en la n. ° 2 fallaran).
Estoy de acuerdo con (y voté) la práctica de Robert Paulson. Eso supone que usted tiene el control de un equipo de desarrollo con la responsabilidad y la disciplina de cumplir con dicha práctica.
Para "forzar" eso en mis equipos, nuestras soluciones mantienen al menos un proyecto de base de datos de Visual Studio Team Edition para profesionales de bases de datos . Al igual que con otros proyectos en la solución, el proyecto de base de datos obtiene control versionado. Lo convierte en un proceso de desarrollo natural para dividir todo en la base de datos en trozos mantenibles, "disciplinando" a mi equipo en el camino.
Por supuesto, al ser un proyecto de Visual Studio, no es casi perfecto. Hay muchas peculiaridades con las que te encontrarás que pueden frustrarte o confundirte. Se necesita un poco de comprensión de cómo funciona el proyecto antes de lograr que realice sus tareas. Ejemplos incluyen
- desplegando datos de archivos CSV .
- implementación selectiva de datos de prueba según el tipo de compilación .
- Visual Studio falla al comparar con bases de datos con cierto tipo de ensamblaje CLR incrustado dentro .
- no hay forma de diferenciar entre las bases de datos de prueba/producción que implementan diferentes esquemas de autenticación: usuarios de SQL frente a usuarios de Active Directory.
Pero para los equipos que no tienen la práctica de versionar sus objetos de base de datos, este es un buen comienzo. La otra alternativa famosa es, por supuesto, el conjunto de productos de SQL Server de Red Gate , que la mayoría de las personas que los usan consideran superior a la oferta de Microsoft.
Una cosa a tener en cuenta con sus scripts de caída/creación en SQL Server es que se perderán los permisos a nivel de objeto. Cambiamos nuestro estándar para usar scripts ALTER en su lugar, lo que mantiene esos permisos.
Hay algunas otras advertencias, como el hecho de que soltar un objeto elimina los registros de dependencia utilizados por sp_depends, y crear el objeto solo crea las dependencias para ese objeto. Entonces, si suelta/crea una vista, sp_depends ya no sabrá de ningún objeto que haga referencia a esa vista.
Moraleja de la historia, use scripts ALTER.
Creo que debería escribir un script que configure automáticamente su base de datos, incluidos los procedimientos almacenados. Este script debe colocarse en el control de origen.
Un par de perspectivas diferentes de mi experiencia. En el mundo de Oracle, todo fue administrado por "crear" scripts DDL. Como mencionó ahockley, un script para cada objeto. Si el objeto necesita cambiar, su secuencia de comandos DDL se modifica. Hay una secuencia de comandos de contenedor que invoca todas las secuencias de comandos de objetos para que pueda implementar la compilación de base de datos actual en el entorno que desee. Esto es para el núcleo principal crear.
Obviamente, en una aplicación en vivo, cada vez que empuja una nueva compilación que requiere, por ejemplo, una nueva columna, no va a soltar la tabla y crearla nueva. Vas a hacer un script ALTER y agregar la columna. Entonces, cada vez que este tipo de cambio tiene que suceder, siempre hay dos cosas que hacer: 1) escribir el DDL alternativo y 2) actualizar el DDL de creación central para reflejar el cambio. Ambos entran en el control de origen, pero el script de alteración individual es más un cambio momentáneo en el tiempo, ya que solo se usará para aplicar un delta.
También podría usar una herramienta como ERWin para actualizar el modelo y generar el DDL, pero la mayoría de los DBA que conozco no confían en una herramienta de modelado para generar el script exactamente de la manera que desean. También puede usar ERWin para realizar ingeniería inversa de su secuencia de comandos DDL principal en un modelo periódicamente, pero eso es una gran molestia para que se vea bien (cada vez que lo hace).
En el mundo de Microsoft, empleamos una táctica similar, pero utilizamos el producto Red Gate para ayudar a administrar los scripts y deltas. Todavía poner los scripts en control de fuente. Todavía un script por objeto (tabla, sproc, lo que sea). Al principio, algunos de los DBA realmente preferían usar la GUI de SQL Server para administrar los objetos en lugar de usar scripts. Pero eso hizo que fuera muy difícil administrar la empresa de manera consistente a medida que crecía.
Si el DDL está en control de origen, es trivial usar cualquier herramienta de compilación (generalmente hormiga) para escribir un script de implementación.
He descubierto que, con mucho, la forma más fácil, rápida y segura de hacer esto es simplemente morder la bala y usar el control de código fuente SQL de RedGate. Scripted y almacenado en el repositorio en cuestión de minutos. Solo desearía que RedGate considerara el producto como un líder de pérdidas para que pudiera tener un uso más generalizado.
En experiencias anteriores, mantuve el origen de los cambios en la base de datos controlado de tal manera que para cada versión del producto, los cambios en la base de datos siempre se registraron y almacenaron en la versión en la que estamos trabajando. El proceso de compilación implementado automáticamente llevaría la base de datos a la versión actual basada en una tabla en la base de datos que almacenaba la versión actual para cada "aplicación". Una aplicación de utilidad .net personalizada que escribimos luego se ejecutará y determinará la versión actual de la base de datos, y ejecutará cualquier secuencia de comandos nueva en el orden de los números de prefijo de las secuencias de comandos. Luego realizamos pruebas unitarias para asegurarnos de que todo estaba bien.
Almacenaríamos los scripts en el control de origen de la siguiente manera (estructura de carpetas a continuación):
Estoy un poco oxidado en las convenciones de nomenclatura actuales en tablas y procedimientos almacenados tan desnudos con mi ejemplo ...
[raíz]
[solicitud]
[versión]
[Guión]
\guiones
Mi aplicación\
1.2.1 \
001.MyTable.Create.sql
002.MyOtherTable.Create.sql
100.dbo.usp.MyTable.GetAllNewStuff.sql
Con el uso de una tabla de versiones que tomaría en cuenta la aplicación y la versión, la aplicación restauraría la copia de seguridad de producción semanal y ejecutaría todos los scripts necesarios en la base de datos desde la versión actual. Al usar .net pudimos empaquetar esto fácilmente en una transacción y, si algo fallaba, retrocederíamos y enviaríamos correos electrónicos, por lo que sabíamos que la versión tenía scripts incorrectos.
Por lo tanto, todos los desarrolladores se asegurarán de mantener esto en el control de origen para que la versión coordinada se asegure de que todos los scripts que planeamos ejecutar en la base de datos se ejecuten con éxito.
Probablemente sea más información de la que estaba buscando, pero funcionó muy bien para nosotros y, dada la estructura, fue fácil lograr que todos los desarrolladores participaran.
Cuando llegara el día del lanzamiento, el equipo de operaciones seguiría las notas del lanzamiento y recogería los scripts del control de código fuente y ejecutaría el paquete contra la base de datos con la aplicación .net que usamos durante el proceso de compilación nocturno que empaquetaría automáticamente los scripts en las transacciones. algo falló, retrocedería automáticamente y no se produjo ningún impacto en la base de datos.
Similar a Robert Paulson, arriba, nuestra organización mantiene la base de datos bajo control de fuente. Sin embargo, nuestra diferencia es que tratamos de limitar la cantidad de scripts que tenemos.
Para cualquier proyecto nuevo, hay un procedimiento establecido. Tenemos un script de creación de esquema en la versión 1, un script de creación de proceso almacenado y posiblemente un script de creación de carga de datos inicial. Todos los procesos se guardan en un único archivo, ciertamente grande. Si usamos Enterprise Library, incluimos una copia del script de creación para el registro; si se trata de un proyecto ASP.NET que usa el marco de aplicación ASP.NET (autenticación, personalización, etc.), también incluimos ese script. (Lo generamos a partir de las herramientas de Microsoft, luego lo ajustamos hasta que funcionó de manera replicable en diferentes sitios. No es divertido, sino una valiosa inversión de tiempo).
Utilizamos la magia CTRL + F para encontrar el proceso que nos gusta. :) (Nos encantaría que SQL Management Studio tuviera código de navegación como VS. ¡Suspiro!)
Para versiones posteriores, generalmente tenemos los scripts upgradeSchema, upgradeProc y/o updateDate. Para las actualizaciones de esquema, ALTERAMOS las tablas tanto como sea posible, creando nuevas según sea necesario. Para actualizaciones de proceso, DROP y CREATE.
Aparece una arruga con este enfoque. Es fácil generar una base de datos, y es fácil actualizar una nueva en la versión actual de DB. Sin embargo, se debe tener cuidado con la generación de DAL (lo que actualmente hacemos, por lo general, con SubSonic), para garantizar que los cambios de DB/esquema/proceso se sincronicen limpiamente con el código utilizado para acceder a ellos. Sin embargo, en nuestras rutas de compilación hay un archivo por lotes que genera el DAL SubSonic, por lo que es nuestro SOP para verificar el código DAL, volver a ejecutar ese archivo por lotes, luego verificarlo nuevamente en cualquier momento el esquema y/o cambio de procs. (Esto, por supuesto, desencadena una compilación de origen, actualizando las dependencias compartidas a las DLL apropiadas ...)
En mi empresa, tendemos a almacenar todos los elementos de la base de datos en el control de origen como scripts individuales, tal como lo haría con archivos de código individuales. Las actualizaciones se realizan primero en la base de datos y luego se migran al repositorio de código fuente para mantener un historial de cambios.
Como segundo paso, todos los cambios de la base de datos se migran a una base de datos de integración. Esta base de datos de integración representa exactamente cómo debería verse la base de datos de producción después de la implementación. También tenemos una base de datos de control de calidad que representa el estado actual de producción (o la última implementación). Una vez que se realizan todos los cambios en la base de datos de Integración, utilizamos una herramienta de diferencia de esquema (Diferencia SQL de Red Gate para SQL Server) para generar un script que migrará todos los cambios de una base de datos a otra.
Hemos encontrado que esto es bastante efectivo ya que genera un solo script que podemos integrar fácilmente con nuestros instaladores. El mayor problema que tenemos a menudo es que los desarrolladores se olvidan de migrar sus cambios a la integración.
Los procedimientos almacenados obtienen 1 archivo por sp con el estándar si existen declaraciones drop/create en la parte superior. Las vistas y funciones también obtienen sus propios archivos para que sean más fáciles de versionar y reutilizar.
El esquema es todo 1 script para comenzar, luego haremos cambios de versión.
Todo esto se almacena en un proyecto de base de datos de Visual Studio conectado a TFS (@ work o VisualSVN Server @ home para cosas personales) con una estructura de carpetas de la siguiente manera:
- proyecto
- funciones
- esquema
-- procedimientos almacenados
-- puntos de vista
Hemos estado utilizando un enfoque alternativo en mi proyecto actual: no tenemos la base de datos bajo control de origen, sino que hemos utilizado una herramienta de diferencia de base de datos para escribir los cambios cuando llegamos a cada versión.
Ha funcionado muy bien hasta ahora.
Mantenemos procedimientos almacenados en control de fuente.
Almacenamos todo lo relacionado con una aplicación en nuestro SCM. Los scripts de DB generalmente se almacenan en su propio proyecto, pero se tratan como cualquier otro código ... diseñar, implementar, probar, confirmar.
Script todo (creación de objetos, etc.) y almacenar esos scripts en el control de origen. ¿Cómo llegan los cambios allí? Es parte de la práctica estándar de cómo se hacen las cosas. ¿Necesitas agregar una tabla? Escribe un script CREATE TABLE. ¿Actualizar una sproc? Edite el script del procedimiento almacenado.
Prefiero un script por objeto.
Para los procesos, escriba los procesos con envoltorios de script en archivos simples y aplique los cambios de esos archivos. Si se aplicó correctamente, puede registrar ese archivo y también podrá reproducirlo desde ese archivo.
Para los cambios de esquema, es posible que deba ingresar los scripts para realizar incrementalmente los cambios que ha realizado. Escriba el script, aplíquelo y luego instálelo. Puede construir un proceso para aplicar automáticamente cada script de esquema en serie.
Mantenemos los procedimientos almacenados en el control de origen. La forma en que lo hacemos (o al menos yo) es agregar una carpeta a mi proyecto, agregar un archivo para cada SP y copiar manualmente, pegar el código en él. Entonces, cuando cambio el SP, necesito cambiar manualmente el archivo de control de origen.
Me interesaría saber si la gente puede hacer esto automáticamente.