Base de datos de desarrollo y producción?

Question

Estoy trabajando con PHP & mySQL. Finalmente me he puesto manos a la obra con el control de fuente y estoy bastante contento con todo el desarrollo (prueba) v producción v el repositorio de la parte de PHP.

Mi nuevo dilema es qué hacer con la base de datos. ¿Creo uno para el entorno de prueba y otro para el entorno de producción? Actualmente solo tengo uno que utilizan ambos entornos, dejando mis datos de prueba allí. Siento que debería tener dos, pero estoy nerviosa en términos de asegurarme de que mi base de datos de producción se vea y sienta exactamente igual a la de mi prueba.

¿Alguna idea sobre qué camino tomar? Y, si piensa lo último, ¿cuál es la mejor manera de mantener las dos bases de datos iguales (aparte de los datos, por supuesto ...)?

Answer 1

Definitivamente debe tener dos. En cuanto a mantenerlos sincronizados, siempre debe crear DDL para crear sus objetos de base de datos. Trate estos scripts como lo hace con su código PHP; manténgalos en control de versiones. Cada vez que tenga que modificar la base de datos de prueba, haga una secuencia de comandos para hacerlo y compruébela. Luego, puede propocionar esos cambios al sistema de producción una vez que esté listo.

Answer 2

Cada entorno debe tener una base de datos separada. Escriba todos los objetos de la base de datos (tablas, vistas, procedimientos, etc.) y almacene los scripts en el control de código fuente. Los scripts se aplican primero a la base de datos de desarrollo, luego se promueven para probar (QA, UAT, etc.), luego la producción. Al aplicar los mismos scripts a cada base de datos, todos deberían ser iguales al final.

Si tiene que cargar datos (tablas de códigos, valores de búsqueda, etc.), haga una secuencia de comandos para cargar los datos como parte del proceso de creación de la base de datos.

Al programar todo y mantenerlo en control de código fuente, se puede recrear una estructura de base de datos en cualquier momento para cualquier nivel de compilación.

Answer 3

Una vez que he implementado mi base de datos, cualquier cambio realizado en mis bases de datos de desarrollo se realiza en un script SQL (no en una herramienta), y el script se guarda y numera.

deploy.001.description.sql 
deploy.002.description.sql 
deploy.003.description.sql 
... etc.. 

Luego ejecuto cada uno de esos scripts en orden cuando implemento.

Entonces les archivo en un directorio llamado algo así como

\deploy.YYMMDD\ 

y empezar todo de nuevo.

Si me equivoco, nunca vuelvo al script de implementación anterior, crearé un nuevo script y pondré mi solución allí.

Buena suerte

Answer 4

Como mínimo una base de datos para cada estación de trabajo de desarrollo y uno para la producción. Además, debe tener uno para el entorno de prueba, a menos que sea solo un desarrollador y tenga una configuración similar a la del entorno de producción.

Answer 5

Una cosa con la que he estado trabajando es crear una VM con la base de datos instalada. puede guardar la VM como un archivo de reproducción, incluidos sus datos. Lo que puede hacer entonces es tomar una instantánea del archivo de reproducción y poner en marcha tantas VM diferentes como quiera. Todos pueden ser idénticos, o puede modificar uno u otro. Aquí está lo bueno: suponiendo que tiene una versión de desarrollo de la base de datos que desea que salga, puede simplemente iniciar esa máquina virtual en su servidor de producción en lugar del servidor actual.

Es otro problema si tienes datos de producción que no están en tus máquinas de desarrollo. Sin embargo, en ese caso, una cosa que puede hacer es configurar una máquina virtual de seguimiento. Ejecute la replicación desde su base de datos principal a la máquina virtual de seguimiento. Cuando llegue a un punto en el que necesite ejecutar algunos cambios en la base de datos de producción, primero detenga el esclavo y guarde una instantánea.

Inicie una instancia de esa instantánea, sáquela completamente del modo esclavo, aplique los cambios y apunte a su cuadro de control de calidad en esa base de datos. Si funciona según lo previsto, puede ejecutar los parches contra su base de datos de producción principal. De lo contrario, abra la instantánea y recupérela del master nuevamente hasta que esté listo para repetir la prueba de actualización.

Answer 6

Ver también

How do you version your database schema?

Es una pregunta común y se ha preguntado y contestado muchas veces.

Thomas Owens: La replicación no se puede usar para los esquemas de versión, es para duplicar datos. Nunca querrá replicar desde dev a producción o viceversa.

Answer 7

Estaba teniendo los mismos dilemas. Me quedé atascado pensando que había una clara dicotomía entre production db versus development db. Es decir, eran dos lados de una moneda y nunca los dos se encontrarían.

Una gran cantidad de problemas desaparecieron cuando dejé de hacer mi solicitud 'pensar' en términos de "De cualquier production dbOdevelopment db". En cambio, mi aplicación usa un local db.

Cuando se ejecuta en mi máquina virtual (dev), esa db local es dev db. Mi aplicación realmente no 'sabe' eso sin embargo.

Por lo tanto, para la parte principal, el problema desaparece.

Pero a veces quiero ejecutar pruebas usando datos en vivo, o mover datos desde el código al archivo de producción en vivo y ver los resultados rápidamente.

Esto es cuando agregué el concepto de live-read-only db connection. La aplicación trata esto de manera diferente. Es un poco como la forma en que su aplicación podría tratar un servicio web como Google Apps. Es 'algún recurso externo que usa tu aplicación'.

De manera predeterminada, mi aplicación usa el local db y en algunas condiciones muy especiales (en el paquete de prueba) también usa el live-readonly db. (Debido a que es una conexión de solo lectura, no tengo miedo de hacer un lío de los datos en vivo durante las pruebas).

Así que en lugar de hacer la pregunta "dev dbOproduction db?", Se pregunta mi aplicación "local dbOlive-read-only db".

Obviamente, mi situación podría ser diferente a la tuya, pero este "avance en la comprensión" me resultó de gran utilidad.