Administración de base de datos de SQL Server con integración continua

StackOverflow https://stackoverflow.com/questions/405192

Pregunta

Digamos que tenemos un servidor de integración continua. Cuando hago el check-in, el post-hook tira el último código, ejecuta las pruebas, empaqueta todo. ¿Cuál es la mejor manera de automatizar también los cambios en la base de datos?

Lo ideal sería crear un instalador que pudiera construir una base de datos desde cero o actualizar una existente usando algún método de sincronización automatizada.

¿Fue útil?

Solución

Si tiene la oportunidad de definir y controlar todo el proceso de creación de la base de datos y la creación de la base de datos, observe detenidamente DB Ghost : es más que una herramienta, es un proceso.

Si te gusta y puedes implementarlo, obtendrás excelentes beneficios, pero es un poco de " todo o nada " tipo de enfoque Recomendado.

Otros consejos

Recientemente me he topado 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.

Éstos son algunos de los puntos clave:

  • En muchas tiendas, el código se prueba en la unidad en el punto de confirmación. Para las bases de datos, es preferible ejecutar todas las pruebas unitarias a la vez y en secuencia contra una base de datos de control de calidad, vs desarrollo, como parte del paso de prueba
  • El paso de prueba es una parte crítica de cualquier proceso de CI / CD. Las secuencias de comandos de prueba, incluidas las propias pruebas unitarias, también deben ser versionadas en el control de origen, extraídas en el punto del paso de compilación y ejecutadas
  • Extraer datos de la producción es atractivo como un expediente rápido, pero nunca es una buena idea
  • El mejor enfoque es utilizar una herramienta o script para crear datos sintéticos de prueba de forma rápida, repetida y confiable para sus tablas transaccionales
  • Ejecutar pruebas unitarias para producir resultados de resumen manuales para el consumo humano anula el propósito de la automatización. Necesitamos resultados legibles por máquina, que puedan permitir que un proceso automatizado aborte, se ramifique y / o continúe.
  • La ejecución de un proceso de CI, que requiere que se apruebe el 100% de todas las pruebas, es similar a no tener CI en absoluto, si el flujo de trabajo se configura de forma atómica para detenerse en caso de fallo, lo que debería. Para enhebrar la aguja, las pruebas deben tener umbrales incorporados, que generarán un error basado en el% de pruebas que fallan o en algunos casos, si fallan ciertas pruebas de alta prioridad.
  • En última instancia, todos los procesos deben producir un resultado booleano de aprobación o falla, pero algunos procesos no automatizados pueden encontrar fácilmente su camino en el flujo de trabajo de CI (por ejemplo, pruebas de unidad). El software debe ser plug-n-play en cualquier flujo de trabajo, tomando entradas conocidas y produciendo salidas esperadas, como pasar, fallar.
  • El proceso de CI / CD debe abortarse en caso de error y debe enviarse inmediatamente un correo electrónico de notificación para que continúe su ciclo.
  • El proceso de CI no debe realizar un ciclo de nuevo hasta que se solucionen los errores en la última compilación. En caso de fallo, todo el equipo debe recibir la notificación de fallo, incluidos todos los detalles sobre lo que falló como sea posible.
  • Si una tubería tarda 1 hora, de principio a fin, en completarse, incluidas todas las pruebas, todos los intervalos de compilación deben configurarse en no menos de una hora y todas las confirmaciones nuevas deben ponerse en cola y aplicarse a la siguiente construir.
  • No deben existir contraseñas de texto sin formato en los scripts de automatización

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 activadores y las vistas como artefactos de desarrollo de primera clase. Los efectos secundarios es que puede ir un paso más allá y usarlos para crear una nueva base de datos cuando lo desee, lo ideal es que también tenga algunos datos que puedan insertarse en la base de datos.

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

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

Red Gate es una solución bastante robusta y funciona fuera 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-synchronization-with-RedGate

Si necesita saber más sobre esto, no dude en preguntar

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

La última versión (5.0) de DB Ghost no tiene el carácter " no ASCII " problema (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 forma independiente para realizar las diversas funciones (creación de secuencias de comandos, construcció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 global mayor que la suma de sus partes.

En esencia, para realizar cambios en el esquema, actualice los scripts de creación de objetos individuales y los scripts de inserción por tabla (para datos de referencia) que se mantienen bajo el control de código fuente, como si estuviera desarrollando un & # 8220; day one & # 8221; Base de datos greenfield. Las herramientas DB Ghost se utilizan para habilitar todo esto mediante la creación de estos scripts en una nueva base de datos (utilizando una integración continua si es necesario) y luego comparando y actualizando una base de datos de destino, que puede ser una copia de la base de datos de producción. Este proceso produce un script 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

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

  1. Los desarrolladores ejecutan cambios de SQL individuales y los confirman en la fuente controlar.
  2. Nuestro programa ( OneScript ) extrae los archivos de script de cambio de     fuente de control, los filtra y los ordena, y genera un solo     liberar archivo de script.
  3. Ese archivo de script de lanzamiento se aplica 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 hace esto Pasos automáticamente desde un gancho de Subversion. Tan pronto después de un compromiso, el desarrollador recibe un correo electrónico que dice si el lanzamiento fue exitoso o si tuvo errores. El código de PowerScript está incluido.

Descargo de responsabilidad: estoy trabajando en la compañía que hace OneScript.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top