La migración es del entorno local al entorno de producción. El entorno de producción ha corrido algún tiempo y ha creado muchos artículos.
Para agregar cosas nuevas a mi sitio, agregué un tema personalizado e instalé CCK, Vistas y otros módulos en mi entorno de prueba local. Ahora que el entorno de prueba local está terminado, ¿cómo lo migro al entorno de producción, sin destruir el contenido de su base de datos?
Este es un problema no trivial para el que casi todos tienen una respuesta diferente: no hay una forma canónica de Drupal para manejar la puesta en escena de los empujes de producción. Dries Buytaert, el tipo que dirige el show de Drupal, lo convirtió en una de las iniciativas clave de Drupal 8 . Por supuesto, Drupal 7 acaba de ser lanzado, por lo que pasará un tiempo antes de que dé frutos.
El problema se puede dividir en dos cuestiones separadas:
El primero puede ser manejado principalmente por el módulo Características , que tomará la configuración de su sitio y lo convertirá en un módulo que puede agregar a su instalación de Drupal: de esta manera, puede agregarlo a su sistema de control de versiones y no tener que preocuparse por ello. quedar impresionado cuando migras tu contenido.
Esto último es realmente complicado, porque en un sitio activo, es probable que el contenido cambie en producción incluso después de haber realizado la sincronización inicial con su entorno de desarrollo. Esto evita el reemplazo total de contenido durante la puesta en escena como puede hacer con la configuración.
Además, Drupal no utiliza identificadores universalmente únicos (UUID) para el contenido: cada vez que se agrega un nodo o un usuario, la ID aumenta en uno. Entonces, lo que podría ser el nodo 45 en su sitio de desarrollo podría ser el nodo 90 en su sitio de producción.
Desafortunadamente, no tengo una gran solución para esto: el contenido provisional es una debilidad real de Drupal. Lo que personalmente hago es agregar contenido solo en el sitio de producción. Si un cliente quiere ver cómo se ve el contenido antes de que se publique, configuraré un clon del sitio de producción al que solo puede acceder el cliente. Luego, una vez aprobado, los mismos cambios se realizan directamente a la producción.
Existe otra alternativa: el módulo de implementación . Se supone que aprovecha los Servicios para que el contenido de la presentación sea relativamente sencillo. Pero no puedo garantizar su efectividad y no tiene una versión de Drupal 7.
En nuestro proceso
Estamos utilizando Hudson para reconstruir nuestras ramas de desarrollo / puesta en escena para sincronizar las ramas en vivo y de desarrollo.
Dado que estamos usando Git, cada tarea que estamos haciendo tiene su propia rama, luego, cuando se pasa al control de calidad, la fusionamos para dominarla como nuestro servidor de ensayo para pruebas de regresión.
Cuando el maestro está listo, hacemos una versión de prueba para nuestra
Release Serverque es una réplica de live (configuración, hardware, etc.).Usamos el
Featuremódulo para implementar configuraciones. Algunas cosas aún no son compatibles con la función, por lo que usamos hook_update_N y luego ejecuta updatedb.php odrush -vd updbdrush fra --yes) para revertir todas las características anuladas.Como estamos usando Boost (moviéndonos a Varnish) y Memcache, necesitamos borrar el caché (
drush cc all).Estamos usando rsync para sincronizar nuestras imágenes / video, etc.
fuente
Para migrar de un servidor XAMPP a otro servidor, seguí las instrucciones en este sitio .
Asegúrese de mantener la misma estructura en su servidor de producción que en su servidor de desarrollo. También tuve que editar algunos archivos en el panel de administración de Drupal ubicado en: admin / config / media / file-system
Asegúrese de que la ruta del sistema de archivos públicos y el directorio temporal tengan las ubicaciones correctas establecidas.
fuente