database - programacion - meta tags generator

¿Cómo debería construir su base de datos desde el control de código fuente? (11)

Aquí hay algunas respuestas a sus preguntas:

¿Deben construirse entornos de prueba y producción a partir del control de origen? SÍ
- ¿Deben construirse ambos mediante la automatización, o la producción debe ser construida copiando objetos de un entorno de prueba estable y finalizado?
- Automatización para ambos. NO copie datos entre los entornos
- ¿Cómo lidiar con las posibles diferencias entre los entornos de prueba y producción en las secuencias de comandos de implementación?
- Use plantillas, de modo que en realidad produciría diferentes conjuntos de scripts para cada entorno (por ejemplo, referencias a sistemas externos, bases de datos vinculadas, etc.)
- ¿Cómo se prueba que las secuencias de comandos de implementación funcionarán tan eficazmente contra la producción como lo hacen en la prueba?
- Los prueba en el entorno de preproducción: prueba de implementación en una copia exacta del entorno de producción (base de datos y potencialmente otros sistemas)
¿Qué tipos de objetos deberían ser controlados por la versión?
- ¿Solo código (procedimientos, paquetes, disparadores, java, etc.)?
- Índices?
- Restricciones?
- Definiciones de tabla?
- Tabla de cambio de secuencias de comandos? (por ejemplo, scripts ALTER)
- ¿Todo?
- Todo y:
  - No olvide datos estáticos (listas de búsqueda, etc.), por lo que no necesita copiar CUALQUIER información entre entornos
  - Mantenga solo la versión actual de los scripts de la base de datos (por supuesto, la versión está controlada) y
  - Store ALTER scripts: 1 script GRANDE (o directorio de scripts llamados like 001_AlterXXX.sql, de modo que al ejecutarlos en orden natural se actualice de la versión A a la B)
¿Qué tipos de objetos no deberían ser controlados por la versión?
- Secuencias?
- ¿Subsidios?
- ¿Cuentas de usuario?
- ver 2. Si sus usuarios / roles (o nombres de usuario técnicos) son diferentes entre entornos, puede seguir scripts usando plantillas (vea 1.)
¿Cómo deberían organizarse los objetos de la base de datos en su repositorio de SCM?
- ¿Cómo se manejan cosas únicas como las secuencias de comandos de conversión o las secuencias de comandos ALTER?
- ver 2.
- ¿Cómo manejas el retiro de objetos de la base de datos?
- borrado de DB, eliminado del tronco / sugerencia de control de origen
- ¿Quién debería ser responsable de promover los objetos desde el desarrollo hasta el nivel de prueba?
- programa de desarrollo / prueba / liberación
- ¿Cómo se coordinan los cambios de múltiples desarrolladores?
- intente NO crear una base de datos separada para cada desarrollador. Usas el control de fuente, ¿verdad? en este caso, los desarrolladores cambian la base de datos y registran las secuencias de comandos. para estar completamente seguro, vuelva a crear la base de datos desde los scripts durante la construcción nocturna
- ¿Cómo se maneja la ramificación de objetos de base de datos utilizados por múltiples sistemas?
- difícil: trate de evitar a toda costa.
¿Qué excepciones, si las hay, se pueden hacer razonablemente en este proceso?
- ¿Temas de seguridad?
- no almacene contraseñas para prueba / prod. puede permitirlo para el desarrollo, especialmente si tiene reconstrucciones de DB diarias / nocturnas automáticas
- Datos con preocupaciones de desidentificación?
- ¿Scripts que no pueden ser completamente automatizados?
- documentar y almacenar con la información de liberación / script ALTER
¿Cómo puede hacer que el proceso sea resistente y ejecutable?
- Para el error de desarrollador?
- probado con compilación diaria desde cero, y compare los resultados con la actualización incremental (de la versión A a la B usando ALTER). comparar el esquema resultante y los datos estáticos
- Para problemas ambientales inesperados?
- use control de versiones y copias de seguridad
- compare el esquema de la base de datos PROD con lo que cree que es, especialmente antes de la implementación. SuperDuperCool DBA puede haber solucionado un error que nunca estuvo en su sistema de tickets :)
- Para la recuperación de desastres?
¿Cómo convencer a los tomadores de decisiones de que los beneficios de DB-SCM realmente justifican el costo?
- ¿Evidencia anecdótica?
- ¿Investigación de la industria?
- ¿Recomendaciones de mejores prácticas de la industria?
- Apela a las autoridades reconocidas?
- ¿Análisis coste-beneficio?
- si los desarrolladores y los DBA están de acuerdo, no es necesario que convenzas a nadie, creo (a menos que necesites dinero para comprar un software como un dbGhost para MSSQL)
¿Quién debería "poseer" objetos de base de datos en este modelo?
- Desarrolladores?
- DBAs?
- Analistas de datos?
- ¿Más de uno?
- Por lo general, los DBA aprueban el modelo (antes del check-in o después como parte de la revisión del código). Definitivamente poseen objetos relacionados con el rendimiento. Pero, en general, el equipo es el propietario [y empleador, por supuesto :)]

Se ha debatido un poco sobre el wiki de la comunidad SO sobre si los objetos de la base de datos deberían ser controlados por la versión. Sin embargo, no he visto mucha discusión sobre las mejores prácticas para crear un proceso de automatización de compilación para objetos de base de datos.

Este ha sido un tema polémico para mi equipo, especialmente porque los desarrolladores y los administradores de bases de datos a menudo tienen objetivos, enfoques e inquietudes diferentes a la hora de evaluar los beneficios y los riesgos de un enfoque de automatización para la implementación de la base de datos.

Me gustaría escuchar algunas ideas de la comunidad SO sobre qué prácticas han sido efectivas en el mundo real.

Me doy cuenta de que es algo subjetivo qué prácticas son realmente las mejores, pero creo que un buen diálogo sobre qué trabajo podría ser útil para muchas personas.

Estas son algunas de mis preguntas sobre las áreas de preocupación en este tema. No se pretende que sean una lista definitiva, sino un punto de partida para que la gente entienda lo que estoy buscando.

¿Deben construirse entornos de prueba y producción a partir del control de origen?
- ¿Deben construirse ambos mediante la automatización, o la producción debe ser construida copiando objetos de un entorno de prueba estable y finalizado?
- ¿Cómo lidiar con las posibles diferencias entre los entornos de prueba y producción en las secuencias de comandos de implementación?
- ¿Cómo se prueba que las secuencias de comandos de implementación funcionarán tan eficazmente contra la producción como lo hacen en la prueba?
¿Qué tipos de objetos deberían ser controlados por la versión?
- ¿Solo código (procedimientos, paquetes, disparadores, java, etc.)?
- Índices?
- Restricciones?
- Definiciones de tabla?
- Tabla de cambio de secuencias de comandos? (por ejemplo, scripts ALTER)
- ¿Todo?
¿Qué tipos de objetos no deberían ser controlados por la versión?
- Secuencias?
- ¿Subsidios?
- ¿Cuentas de usuario?
¿Cómo deberían organizarse los objetos de la base de datos en su repositorio de SCM?
- ¿Cómo se manejan cosas únicas como las secuencias de comandos de conversión o las secuencias de comandos ALTER?
- ¿Cómo manejas el retiro de objetos de la base de datos?
- ¿Quién debería ser responsable de promover los objetos desde el desarrollo hasta el nivel de prueba?
- ¿Cómo se coordinan los cambios de múltiples desarrolladores?
- ¿Cómo se maneja la ramificación de objetos de base de datos utilizados por múltiples sistemas?
¿Qué excepciones, si las hay, se pueden hacer razonablemente en este proceso?
- ¿Temas de seguridad?
- Datos con preocupaciones de desidentificación?
- ¿Scripts que no pueden ser completamente automatizados?
¿Cómo puede hacer que el proceso sea resistente y ejecutable?
- Para el error de desarrollador?
- Para problemas ambientales inesperados?
- Para la recuperación de desastres?
¿Cómo convencer a los tomadores de decisiones de que los beneficios de DB-SCM realmente justifican el costo?
- ¿Evidencia anecdótica?
- ¿Investigación de la industria?
- ¿Recomendaciones de mejores prácticas de la industria?
- Apela a las autoridades reconocidas?
- ¿Análisis coste-beneficio?
¿Quién debería "poseer" objetos de base de datos en este modelo?
- Desarrolladores?
- DBAs?
- Analistas de datos?
- ¿Más de uno?

+1 para Liquibase : LiquiBase es una biblioteca de fuente abierta (LGPL), independiente de la base de datos, para rastrear, administrar y aplicar cambios en la base de datos. Se basa en una premisa simple: todos los cambios de la base de datos (estructura y datos) se almacenan en una forma descriptiva basada en XML y se controlan en el control de la fuente. Lo bueno es que los cambios DML se almacenan semánticamente, no solo diff, para que pueda seguir el propósito de los cambios.

Podría combinarse con el control de versión GIT para una mejor interacción. Voy a configurar nuestro entorno dev-prod para probarlo.

También podría usar los sistemas de compilación Maven y Ant para generar código de producción a partir de scripts.

Lo que menos conviene es que LiquiBase no se integre en IDE SQL generalizados y usted mismo debe realizar operaciones básicas.

Además de esto, podría usar DBUnit para pruebas de DB: esta herramienta permite utilizar scripts de generación de datos para probar su entorno de producción con la limpieza posterior.

EN MI HUMILDE OPINIÓN:

Almacene DML en archivos para que pueda versionarlos.
Automatice el proceso de creación de esquemas desde el control de origen.
Para fines de prueba, el desarrollador podría usar la base de datos local construida desde el control de origen mediante el sistema de compilación + datos de prueba de carga con scripts o scripts DBUnit (desde el control de fuente).
LiquiBase le permite proporcionar una "secuencia de ejecución" de scripts para respetar las dependencias.
Debe haber un equipo de DBA que verifique el brunch maestro con TODOS los cambios antes de usar la producción. Quiero decir que revisan el tronco / rama de otros DBA antes de comprometerse con el tronco MASTER. Entonces ese maestro siempre es consistente y está listo para la producción.

Nos enfrentamos a todos los problemas mencionados con cambios de código, fusión, reescritura en nuestra base de datos de producción de facturación. Este tema es ideal para descubrir todo eso.

Al hacer "preguntas teaser", parece que está más interesado en una discusión que en la opinión de alguien sobre las respuestas finales. La lista de correo activo (> 2500 miembros) agileDatabases ha abordado muchas de estas cuestiones y, en mi experiencia, es un foro sofisticado y civil para este tipo de debate.

Básicamente estoy de acuerdo con cada respuesta dada por van . Para obtener más información, mi punto de referencia para la gestión de bases de datos es la serie de K. Scott Allen (una lectura obligada, en mi humilde opinión. Y también la opinión de Jeff ).

Los objetos de base de datos siempre se pueden reconstruir desde cero iniciando un único archivo SQL (que puede llamar a otros archivos SQL): Create.sql . Esto puede incluir la inserción de datos estáticos (listas ...).
Los scripts de SQL están parametrizados de manera que no se almacena ninguna información dependiente del entorno y / o sensible en archivos sin formato.
Utilizo un archivo por lotes personalizado para iniciar Create.sql : Create.cmd . Su objetivo es principalmente verificar los requisitos previos (herramientas, variables de entorno ...) y enviar parámetros al script SQL. También puede cargar datos estáticos de archivos CSV para problemas de rendimiento.
Normalmente, las credenciales del usuario del sistema se pasarán como un parámetro al archivo Create.cmd .

En mi humilde opinión, la carga dinámica de datos debería requerir otro paso, dependiendo de su entorno. Los desarrolladores querrán cargar su base de datos con prueba, basura o sin datos, mientras que en el otro extremo los gerentes de producción querrán cargar datos de producción. También consideraría almacenar datos de prueba en el control de fuente (para facilitar las pruebas de unidad, por ejemplo).

Una vez que la primera versión de la base de datos se haya puesto en producción, no solo necesitará compilar scripts (principalmente para desarrolladores), sino también actualizar scripts (basados en los mismos principios):

Debe haber una manera de recuperar la versión de la base de datos (utilizo un procedimiento almacenado, pero una tabla también lo haría).
Antes de lanzar una nueva versión, creo un archivo Upgrade.sql (que puede llamar a otros) que permite actualizar la versión N-1 a la versión N (siendo N la versión que se está lanzando). Guardo este script bajo una carpeta llamada N-1 .
Tengo un archivo por lotes que realiza la actualización: Upgrade.cmd . Puede recuperar la versión actual (CV) de la base de datos a través de una declaración SELECT simple, Upgrade.sql secuencia de comandos Upgrade.sql almacenada en la carpeta CV y repetir hasta que no se encuentre ninguna carpeta. De esta manera, puede actualizar automáticamente desde, digamos, N-3 a N.

Los problemas con esto son:

Es difícil comparar automáticamente esquemas de base de datos, dependiendo de los proveedores de la base de datos. Esto puede conducir a scripts de actualización incompletos.
Cada cambio en el entorno de producción (generalmente por parte de los DBA para el ajuste del rendimiento) también debe llegar al control de origen. Para asegurarse de esto, generalmente es posible registrar cada modificación en la base de datos a través de un disparador. Este registro se restablece después de cada actualización.
Más idealmente, sin embargo, los cambios iniciados por DBA deberían ser parte del proceso de lanzamiento / actualización cuando sea posible.

En cuanto a qué tipo de objetos de base de datos desea tener bajo control de origen? Bueno, diría tanto como sea posible, pero no más ;-) Si desea crear usuarios con contraseñas, obtenga una contraseña predeterminada (inicio de sesión / inicio de sesión, práctica para pruebas de unidades) y haga que la contraseña cambie a una operación manual . Esto sucede mucho con Oracle, donde los esquemas también son usuarios ...

Cada desarrollador debe tener su propia base de datos local y usar el control de código fuente para publicar en el equipo. Mi solución está aquí: http://dbsourcetools.codeplex.com/ Diviértete, - Nathan

Creo firmemente que una base de datos debe ser parte del control de la fuente y, en gran medida, parte del proceso de compilación. Si está en control de fuente, entonces tengo las mismas protecciones de seguridad de codificación cuando escribo un procedimiento almacenado en SQL que cuando escribo una clase en C #. Hago esto al incluir un directorio de scripts DB bajo mi árbol fuente. Este directorio de scripts no tiene necesariamente un archivo para un objeto en la base de datos. Eso sería un dolor en el trasero! Desarrollo en mi db solo una vez en mi proyecto de código. Luego, cuando estoy listo para registrarme, hago una diferencia entre la última versión de mi base de datos y la actual en la que estoy trabajando. Utilizo SQL Compare para esto y genera una secuencia de comandos de todos los cambios. Esta secuencia de comandos se guarda en mi directorio db_update con una convención específica de nomenclatura 1234_TasksCompletedInThisIteration donde el número es el siguiente número en el conjunto de guiones que ya están allí, y el nombre describe lo que se está haciendo en esta verificación. Lo hago así porque parte de mi proceso de compilación empiezo con una nueva base de datos que luego se compila programáticamente usando los guiones de este directorio. Escribí una tarea NAnt personalizada que itera a través de cada script que ejecuta su contenido en el db desnudo. Obviamente, si necesito algunos datos para acceder a la base de datos, también tengo scripts de inserción de datos. Esto también tiene muchos beneficios. Una, todas mis cosas están versionadas. Dos, cada compilación es una compilación nueva, lo que significa que no habrá ningún tipo de astucia en mi proceso de desarrollo (como datos sucios que causan rarezas en el sistema). Tres, cuando se agrega un nuevo tipo al equipo de desarrollo, simplemente necesitan obtener lo último y su desarrollador local está diseñado para ellos sobre la marcha. Cuatro, puedo ejecutar casos de prueba (¡no lo llamé una "prueba de unidad"!) En mi base de datos ya que el estado de la base de datos se restablece con cada compilación (lo que significa que puedo probar mis repositorios sin preocuparme por agregar datos de prueba al db).

Esto no es para todos.

Esto no es para cada proyecto. ¡Suelo trabajar en proyectos de campo verde que me permiten esta conveniencia!

En lugar de entrar en argumentos de la torre blanca, aquí hay una solución que me ha funcionado muy bien en problemas del mundo real.

La creación de una base de datos desde cero se puede resumir como administración de secuencias de comandos sql.

DBdeploy es una herramienta que verificará el estado actual de una base de datos, por ejemplo, qué scripts se han ejecutado previamente, qué scripts están disponibles para ejecutarse y, por lo tanto, qué scripts se necesitan ejecutar.

A continuación, recopilará todos los scripts necesarios y los ejecutará. A continuación, registra qué scripts se han ejecutado.

No es la herramienta más bonita o la más compleja, pero con una administración cuidadosa puede funcionar muy bien. Es de código abierto y fácilmente extensible. Una vez que la ejecución de los scripts se maneja muy bien, se logran fácilmente algunos componentes adicionales, como un script de shell que verifica las últimas secuencias de comandos y ejecuta dbdeploy contra una instancia en particular.

Vea una buena introducción aquí:

http://code.google.com/p/dbdeploy/wiki/GettingStarted

Es posible que encuentre que LiquiBase maneja mucho de lo que está buscando.

Tenemos nuestro proyecto Silverlight con base de datos MSSQL en control de versiones Git. La forma más fácil es asegurarse de tener una base de datos reducida (en lo que respecta al contenido) y hacer un volcado completo desde fe Visual Studio. Luego puede hacer ''sqlcmd'' desde su script de compilación para recrear la base de datos en cada máquina de desarrollo.

Para la implementación esto no es posible ya que las bases de datos son demasiado grandes: esa es la razón principal para tenerlas en una base de datos en primer lugar.

Usamos integración continua a través de TeamCity. En cada registro en el control de origen, la base de datos y todos los datos de prueba se vuelven a generar desde cero, luego el código y luego las pruebas unitarias se ejecutan contra el código. Si está utilizando una herramienta de generación de código como CodeSmith, también se puede colocar en su proceso de compilación para generar nueva capa de acceso a los datos con cada compilación, asegurándose de que todas sus capas "coinciden" y no producen errores debido a parámetros SP no coincidentes o columnas faltantes.

Cada compilación tiene su propia colección de scripts SQL que se almacenan en el directorio $ project / SQL / en control de fuente, se le asigna un prefijo numérico y se ejecuta en orden. De esa forma, estamos practicando nuestro procedimiento de implementación en cada construcción.

Dependiendo de la tabla de búsqueda, la mayoría de nuestros valores de búsqueda también se almacenan en scripts y se ejecutan para garantizar que los datos de configuración sean los que esperamos, digamos, "códigos_de_razones" o "códigos_de_país". De esta forma podemos hacer un cambio de datos de búsqueda en dev, probarlo y luego "promocionarlo" a través de QA y producción, en lugar de usar una herramienta para modificar los valores de búsqueda en producción, lo que puede ser peligroso para el tiempo de actividad.

También creamos un conjunto de scripts "reversibles" que deshacen nuestros cambios en la base de datos, en caso de que la construcción de la producción se torne desagradable. Puede probar los scripts de retrotracción ejecutándolos y luego volver a ejecutar las pruebas de unidad para la versión de compilación uno debajo del suyo, una vez que se ejecuten los guiones de implementación.

Trato el SQL como código fuente cuando sea posible

Si puedo escribirlo en el SQL que cumple con los estándares, generalmente va en un archivo en mi control de fuente. El archivo definirá tanto como sea posible, como los SP, las sentencias Table CREATE.

También incluyo datos ficticios para probar en control de fuente:

proj / sql / setup_db.sql
proj / sql / dummy_data.sql
proj / sql / mssql_specific.sql
proj / sql / mysql_specific.sql

Y luego abstraigo todas mis consultas SQL para poder construir todo el proyecto para MySQL, Oracle, MSSQL o cualquier otra cosa.

La automatización de compilación y prueba utiliza estos scripts de compilación ya que son tan importantes como el origen de la aplicación y prueba todo, desde la integridad hasta los desencadenadores, los procedimientos y el registro.