sql-server - services - ssisdb database

SQL Server Database Management con integración continua (8)

La última versión (5.0) de DB Ghost no sufre el problema de "carácter no ASCII" (solo significa que el archivo está codificado en UTF8) y debería poder hacer exactamente lo que necesita.

Además, las herramientas se pueden usar de manera independiente para realizar las diversas funciones (creación de scripts, compilación, comparación, actualización y empaquetado) si lo desea, es solo que usarlas todas juntas proporciona un proceso completo de extremo a extremo, lo que hace que el valor total mayor que la suma de sus partes.

En esencia, para realizar cambios en el esquema, se actualizan scripts de creación de objetos individuales y scripts de inserción por tabla (para datos de referencia) que se mantienen bajo el control de código fuente tal como se estaba desarrollando una base de datos de campo "day one". Las herramientas DB Ghost se utilizan para habilitar todo al compilar estos scripts en una nueva base de datos (utilizando integración continua si es necesario) y luego comparar y actualizar una base de datos de destino, que puede ser una copia de la base de datos de producción. Este proceso produce una secuencia de comandos delta que se puede utilizar en la base de datos de producción real durante la puesta en marcha.

Incluso puede producir un proyecto de base de datos de Visual Studio y agregarlo a cualquier solución que tenga actualmente.

Malc

Digamos que tenemos un servidor de integración continua. Cuando ingreso, el post-hook extrae el código más reciente, ejecuta las pruebas, empaqueta todo. ¿Cuál es la mejor manera de automatizar también los cambios en la base de datos?

Idealmente, construiría un instalador que podría construir una base de datos desde cero o actualizar una existente utilizando algún método de sincronización automática.

Advertiría contra el uso de una copia de seguridad de db como un artefacto de desarrollo, la mayoría de las mejores prácticas de CI sugieren que administre el esquema, los procedimientos, los desencadenantes y las vistas como artefactos de desarrollo de primera clase. Los efectos secundarios son que puede ir un paso más allá y usarlos para construir una nueva base de datos cuando lo desee, idealmente también tiene algunos datos que pueden insertarse en la base de datos.

Aquí hay una versión de notas del acantilado para mojarse los pies, pero hay muchos por ahí en este espacio: http://www.infoq.com/news/2008/02/versioning_databases_series

Me gustan algunas de las ideas que Scott Ambler tiene aquí también, el sitio es bueno, pero el libro es sorprendentemente profundo para un conjunto de problemas tan difícil. http://www.agiledata.org/ http://www.amazon.com/exec/obidos/ASIN/0321293533/ambysoftinc

Red Gate es una solución bastante robusta y funciona de la caja. Pero lo mejor es que puede integrarlo con su proceso de integración continua. Lo uso con Msbuild y Hudson. explicando rápidamente cómo funciona: http://blog.vincentbrouillet.com/post/2011/02/10/Database-schema-synchronisation-with-RedGate

si necesita saber más sobre esto, siéntase libre de preguntar

Si tiene la oportunidad de definir y controlar toda la gestión de la base de datos y el proceso de creación de db, eche un vistazo serio a DB Ghost ; es más que solo una herramienta, es un proceso.

Si le gusta y puede implementarlo, obtendrá grandes beneficios, pero es un tipo de enfoque de "todo o nada". Recomendado.

El enfoque de Red Gate utilizando SQL Source Control y la línea de comandos de SQL Compare Pro se detalla con ejemplos de código aquí: http://downloads.red-gate.com/HelpPDF/ContinuousIntegrationForDatabasesUsingRedGateSQLTools.pdf

Troy Hunt escribió un artículo sobre Simple Talk titulado "Integración continua para bases de datos SQL Server": http://www.simple-talk.com/content/article.aspx?article=1247

Sé que esta publicación es antigua, pero tenemos una nueva solución que adopta el siguiente enfoque:

Los desarrolladores crean cambios SQL individuales y los comprometen con el control de origen.
Nuestro programa ( OneScript ) extrae los archivos de script de cambio del control de origen, los filtra y los ordena, y genera un único archivo de script de lanzamiento.
Ese archivo de script de lanzamiento se aplica luego a una base de datos para hacer un lanzamiento.

Nuestra página de inicio aquí explica este proceso con más detalle y tiene un enlace a un ejemplo que realiza estos pasos automáticamente desde un enlace de Subversion. Tan pronto después de una confirmación, el desarrollador recibe un correo electrónico que dice si la versión fue exitosa o si hubo errores. El código de PowerScript está incluido.

Exención de responsabilidad: estoy trabajando en la empresa que fabrica OneScript.

Recientemente me encontré con un artículo , que podría ser de utilidad.

El autor explicó algunas de las mejores prácticas de integración continua, incluidas las pruebas, el procesamiento y la automatización.

Estos son algunos de los puntos clave:

En muchas tiendas, el código se prueba en unidades en el momento de la confirmación. Para las bases de datos, se prefiere ejecutar todas las pruebas unitarias de una vez y en secuencia contra una base de datos de control de calidad, en comparación con el desarrollo, como parte del paso de prueba
El paso de prueba es una parte crítica de cualquier proceso de CI / CD. Los scripts de prueba, incluidas las pruebas unitarias, también deben tener versiones en el control de código fuente, extraerse en el punto del paso de compilación y ejecutarse
Extraer datos de producción es atractivo como un recurso rápido, pero nunca es una buena idea
El mejor enfoque es utilizar una herramienta o secuencia de comandos para crear de forma rápida, repetida y confiable datos sintéticos de prueba para sus tablas transaccionales
Ejecutar pruebas unitarias para producir resultados de resumen manuales para el consumo humano derrota el propósito de la automatización. Necesitamos resultados legibles por máquina, que pueden permitir que un proceso automatizado aborte, se bifurque y / o continúe.
Ejecutar un proceso de CI, que requiere que pase el 100% de todas las pruebas, es similar a no tener CI en absoluto, si la línea de flujo de trabajo está configurada atómicamente para detenerse en caso de falla, lo cual debería ocurrir. Para enhebrar la aguja, las pruebas deben tener umbrales integrados, lo que generará un error según el porcentaje de fallas de las pruebas o, en algunos casos, si fallan ciertas pruebas de alta prioridad.
Todos los procesos deberían en última instancia producir un resultado booleano de aprobación o rechazo, pero algunos procesos no automáticos pueden encontrar fácilmente su camino en la cartera de flujo de trabajo de CI (por ejemplo, pruebas unitarias). El software debe ser plug-n-play en cualquier canal de flujo de trabajo, tomando las entradas conocidas y produciendo las salidas esperadas, como pasar, fallar.
El proceso de CI / CD debe interrumpirse en caso de falla y se debe enviar un correo electrónico de notificación de inmediato en lugar de continuar el ciclo de la tubería.
El proceso de CI no debe volver a realizar ciclos hasta que se corrijan los errores en la última compilación. En caso de falla, todo el equipo debe recibir la notificación de falla, incluidos todos los detalles sobre lo que falló como sea posible.
Si una canalización tarda 1 hora, de principio a fin, en completarse, incluidas todas las pruebas, todos los intervalos de compilación deben establecerse en no menos de una hora y todas las confirmaciones nuevas deben ponerse en cola y aplicarse a la siguiente compilación.
No deben existir contraseñas de texto sin formato en las secuencias de comandos de automatización

¿Has mirado a FluentMigrator ? La descarga predeterminada incluye scripts de Nant que serían fáciles de agregar a un elemento de configuración. Gratis, de código abierto y fácil de usar. Funciona para una amplia variedad de bases de datos.