pruebas - Mejores prácticas de integración continua con el proyecto de SQL Server o un archivo mdf local en el proyecto

integración continua en desarrollo de software

Question

Hoy mantengo un proyecto que tiene una base de datos realmente desordenada que necesita una gran cantidad de refactorización y publicación en las máquinas clientes.

Sé que podría agregar un proyecto de base de datos de SQL Server que contenga solo scripts de la base de datos y cree un archivo .dacpac que me permita cambiar las bases de datos de los clientes automáticamente.

También sé que solo podría agregar un archivo .mdf a App_Data o incluso a la carpeta Solution_Data y tener mi base de datos allí. Supongo que el localDb que ya existe me permite iniciar mi solución sin SQL Server

Y además, sé que Entity Framework existe con sus propias migraciones. Pero no quiero usarlo, porque no puedo agregar y cambiar índices con sus migraciones y no tengo una flexibilidad de pensamiento cuando necesito describir escenarios de migraciones difíciles.

Mis metas:

1. Generar scripts de migración a los clientes DB''s automáticamente.
2. Haga que mi solución sea autónoma, que cualquier nuevo programador que vino al proyecto ni siquiera necesita instalar SQL Server en su máquina.
3. Ser capaz de actualizar la base local (desarrollo) en 1-2 clics.
4. Ser capaz de retroceder en el historial de cambios de db (tengo servidor TFS)
5. Ser capaz de tener db limpio (solo con diccionarios o tablas de búsqueda) en solución con un esquema de base de datos actualizado.
6. Además, quiero poder actualizar mi modelo de base de datos ( EF o .dbml ) de forma automática o muy sencilla.

Entonces, ¿qué puedo preguntar?

• ¿Cuáles son las fortalezas y debilidades de usar estos 2 enfoques si quiero alcanzar mis metas?

• ¿Podría ser que debería usar una especie de combinación de estas herramientas?

• ¿O no sé sobre otra herramienta existente de MS?

• ¿Hay alguna manera de actualizar mi modelo DAL desde esta base de datos?

Answer 1

¿Cuáles son las fortalezas y debilidades de usar estos 2 enfoques si quiero alcanzar mis metas?

El uso de un proyecto de base de datos le permite controlar la versión de todos los objetos de la base de datos. Puede publicar en varias instancias de la base de datos e implementar cambios de forma incremental, en lugar de tener que eliminar y volver a crear la base de datos, conservando así los datos. Estos cambios pueden ser en forma de un dacpac, un script SQL, o se pueden hacer a través de la interfaz VS. Obtendrá un gran control sobre las implementaciones utilizando scripts previos y posteriores a la implementación y publicando perfiles. Se requerirá que los desarrolladores instalen SQL Server (la edición de desarrollador / Express suele ser lo suficientemente buena).

Es más fácil trabajar con LocalDB: puede hacer sus cambios directamente en la base de datos sin tener que publicar. LocalDB no tiene un proceso de publicación incorporado para impulsar cambios a otras instancias. No requiere instalación de SQL Server.

Use un proyecto de base de datos si necesita control de versión para sus objetos de base de datos, si tiene varios usuarios realizando cambios simultáneamente o si tiene varias aplicaciones que utilizan la misma base de datos. Use LocalDB si no se aplica ninguna de estas condiciones o para aplicaciones pequeñas que requieren su propia base de datos independiente.

¿Podría ser que debería usar una especie de combinación de estas herramientas?

Sí. Según el comentario de Kevin a continuación, "Si el Proyecto de base de datos se configura como su proyecto de inicio, al presionar F5 se implementará automáticamente en LocalDB. En este caso, ni siquiera necesita un perfil de publicación".

¿O no sé sobre otra herramienta existente de MS?

El enfoque de Entity Framework Code First se acerca.

¿Hay alguna manera de actualizar mi modelo DAL desde esta base de datos?

El generador de POCO de Entity Framework funciona bien a menos que realice cambios en sus clases de DAL, entonces esos cambios se perderán la próxima vez que ejecute el generador.

Existe una nueva herramienta llamada SqlSharpener que puede generar clases a partir de los archivos SQL en un proyecto de base de datos. No lo he usado, así que no puedo responder por él, pero parece prometedor.

Answer 2

Una forma de generar un script de cliente para cambios en la base de datos es usar una herramienta de modelado de base de datos como ERWin que tiene una edición comunitaria gratuita. La mejor manera de cumplir con el requisito de control de versión de su base de datos y la generación fácil de secuencias de comandos es Redgate SQL Source Control . Usando la herramienta Redgate cumplirás los primeros cinco objetivos mencionados. Además, ahora puede actualizar el modelo EF con un solo clic después de cambiar el esquema de base de datos (es decir, el primer enfoque de la base de datos) como se requiere en el objetivo 6.

No recomiendo usar LocalDB en absoluto. Siempre genera problemas con el control de origen como "El archivo DB está en uso y no se puede confirmar ..." Además, el desarrollador en el proyecto no tendrá un conjunto común de datos actualizados para trabajar, a menos que un desarrollador agregue datos de prueba al o solicite a otros que obtengan la última versión y sobrescriban su propia base de datos O genere un script de actualización con la herramienta mencionada anteriormente y solicite a cada desarrollador que lo ejecute en su localDB. La mejor forma en su situación es usar SQL Server en la red. Una versión maestra que utilizan todos los desarrolladores. Ya que tiene control de versiones en la base de datos utilizando la herramienta mencionada anteriormente, puede revertir cualquier cambio defectuoso en el servidor de la base de datos.

Si cree que la herramienta RedGate es costosa para el presupuesto de su proyecto. Un segundo enfoque es generar un solo archivo SQL desde su base de datos que tenga todo el objeto de la base de datos y los otros desarrolladores actualicen el archivo SQL en el control de origen según sus cambios. Esto se puede hacer fácilmente usando la herramienta de comparación de esquemas en Visual Studio y agregando el script generado al archivo SQL en el control de origen. Con el enfoque de EF DB First, no tendrá que agregar muchas clases de migración como en el Código EF primero.