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

9

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

— judda
fuente

Parece que los scripts de su base de datos no están en el mismo control de origen que su código "real". ¿Por qué es esto? ¿Puedes tratarlo como "código fuente" y ponerlo con las ramas individuales?

— Mike M.

Actualmente, solo almacenamos la versión de desarrollo de los scripts en control de código fuente y UAT / Production no están sincronizados con el desarrollo activo. Cada uno de los scripts en el control de código fuente se actualiza cada vez que un desarrollador realiza una confirmación. El problema con las sucursales individuales es que tenemos 1 base de datos centralizada que todos usan (para cambios más grandes ramificamos las bases de datos separadas).

1

Puede crear una rama para la versión y solo confirmar los cambios relacionados con la versión. Todos los demás cambios deben realizarse en el maletero. Necesitaría dos bases de datos de desarrollo para lograr esto. ¿Sería esto un problema?

Parece que es probable que uno caduque con bastante rapidez. ¿No? Para uno de mis proyectos, estamos en medio de una revisión masiva de la base de datos, por lo que lo ramificamos para que el desarrollo activo aún pueda ocurrir en la versión no modificada de la base de datos. Sin embargo, cada día veo que nuestra versión ramificada está cada vez más desactualizada, lo que no estoy seguro de si eso está bien o no ... Nunca he tenido que lidiar con situaciones como esta antes.

— Judda

5

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.

— dietbuddha
fuente

¿Qué pasaría si se encontrara un error en los scripts? ¿Vuelve al script sql y lo actualiza?

— Judda

1

No, crea una nueva migración (que aumenta la versión del esquema). Así es como sabe que la solución se ha implementado, mirando la versión del esquema en la base de datos.

— dietbuddha

Gracias por tu ayuda. A primera vista, parece ser un enfoque muy sólido y similar a nuestra estrategia de ramificación.

— Judda

2

¡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.

— Subu Sankara Subramanian
fuente

1

Lamentablemente, nuestras bases de datos son demasiado grandes para pasarlas entre desarrolladores para que se ejecuten las sesiones privadas. Además, eso realmente no parece inclinarse hacia un desarrollo más basado en el equipo porque en este momento, hago back-end mientras hablo con la gente para el trabajo de UI que une a los dos. Tendría que comenzar comprobando todos los cambios y luego conseguir que obtengan lo último en la base de datos, lo que parece ser una molestia bastante grande.

— Judda

¿Por qué su base de datos de desarrollo tiene que ser del mismo tamaño que la base de datos de producción? Pueden tener el mismo esquema e incluso puede tener una flota especial de pruebas de carga con todos los datos, pero las bases de datos de desarrollo locales pueden ser pequeñas. Esto también evita los problemas de fuga de datos, etc. - en teoría, los datos de producción no deberían afectar el desarrollo en absoluto.

— Subu Sankara Subramanian

Todos nuestros datos se cargan a través de nuestro proceso de carga de datos que procesa los archivos que nos proporciona el cliente y luego los transforma en los datos que necesitamos. Por lo tanto, es imposible para nosotros separar los datos de desarrollo y producción dado que todas las cargas de datos deben verificarse en el desarrollo de todos modos. Supongo que no necesita ser del mismo tamaño, sin embargo, necesita cantidades comparables de datos para que los informes que creamos generen información significativa.

— Judda

Toda la base de datos no necesita ser replicada. En Oracle, cada usuario tiene su propio esquema y nosotros tenemos un esquema de aplicación. Cree sinónimos públicos para todos los objetos en el esquema de la aplicación. Luego, cada usuario puede cambiar los objetos (tablas, SP) en su propio esquema y si se conectan ellos mismos, se usarán sus nombres de objeto. Para los objetos que no están en el esquema, se utilizarán los sinónimos. Así es como trabajamos.

— softveda

0

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á.

— Michael Brown
fuente