¿Cómo maneja el cambio constante de las dimensiones de la base de datos?

Durante los últimos dos meses más o menos, he estado buscando soluciones o prácticas para manejar la administración de versiones dentro de las bases de datos. Estoy buscando lo que la gente ve como el mejor proceso para manejar esto.

Tenemos 3 entornos para nuestras bases de datos:

• Desarrollo
• Prueba de aceptación del usuario (UAT)
• Producción

El problema es que a veces estamos haciendo cambios en varias cosas dentro de nuestra base de datos de desarrollo y llega el momento de implementar, algunas de las características pueden no estar listas para ser lanzadas a UAT.

Recientemente hemos comenzado a usar el control de Red Gate SQL Source para almacenar todas nuestras entidades (con confirmaciones regulares).

Estaba pensando en basarme en los conjuntos de cambios (es decir, todo, desde el conjunto de cambios X y viceversa, ahora se está enviando a UAT), sin embargo, esto significa que las personas solo están verificando su código en el control de origen justo antes de que hagamos una implementación que puede ser confusa ( especialmente porque las personas son olvidadizas). Otro problema con el enfoque del conjunto de cambios es que si hay un error en un procedimiento almacenado que necesita ser corregido, el número del conjunto de cambios terminaría estando fuera del alcance de nuestro conjunto de cambios máximo para la revisión, por lo tanto, si es necesario recrear la base de datos a partir de un conjunto de cambios máximo, estaríamos eliminando el error nuevamente.

¿Alguna sugerencia sobre un proceso?

Gracias

Migraciones

Un arriba y un abajo, que están en su repositorio y etiquetados junto con su aplicación.

Incluso puede hacer bricolaje con archivos planos sql que modifican su esquema y actualizan la versión del esquema. Todo lo que realmente tienes que hacer es:

• mantenga sus migraciones al lado del código fuente, deben ser versionadas y etiquetadas juntas
• siempre use cambios gestionados (migraciones) en todos los entornos
• nunca permita modificaciones ad-hoc en ningún entorno

Bueno, puedes hacer cambios de desarrollo en el desarrollo, pero siempre debes eliminar tu db y reconstruirlo con migraciones una vez que hayas capturado el cambio.

¡Fuente de control!

No despliega sus binarios de desarrollo directamente en producción sin pasar por svn / git / p4, entonces, ¿por qué solo sus bases de datos harían eso? Obtenga instancias privadas para que los desarrolladores prueben sus cambios locales, pero cuando tiene que ir a la base de datos de desarrollo, tiene que ir a través de los archivos ddl registrados. Incluso puede escribir herramientas para aplicar estos cambios ddl automáticamente (no conozco ninguna forma existente de hacerlo correctamente).

Una vez que tenga las restricciones sobre los cambios en el esquema db (¡No más sqlplus -> emita ddl!) Y tenga un control estricto de la cuenta (sin acceso ddl para todos), esto debería ser más manejable.

Seguir con la sugerencia de usar migraciones ... quizás use un O / RM que admita migraciones como Ruby on Rails y Entity Framework 4.3. Sin embargo, el problema con ambos enfoques es que una migración es todo o nada. No puede (generalmente) seleccionar qué Migraciones se aplican como puede hacerlo en términos de conjuntos de cambios.

Otra opción viable (si está en la pila de Microsoft, nunca mencionó la plataforma) es administrar su SQL con las herramientas de Visual Studio Database. Se ha incorporado la refactorización (renombrar / eliminar columnas, etc.) y verifica el modelo. Si, por ejemplo, un proceso almacenado hace referencia a una columna que ya no está allí, se lo informará.