Estoy trabajando en mi primer proyecto de Drupal en XAMPP en mi MacBook. Es un prototipo y recibe comentarios positivos de mi cliente.¿Cuál es la mejor estrategia de implementación de Drupal?
Voy a implementar el proyecto en un VPS de Linux dos semanas después. ¿Hay una mejor manera de 'volver a hacer todo en el servidor desde cero?
Gracias
Un par de consejos:
Uso de control de origen, NO FTP/etc, para los archivos.. No importa lo que uses; tendemos a hacer girar una cuenta de subversión de Unfuddle.com para cada cliente, de modo que también tienen un lugar para registrar errores, pero el primer paso fundamental es conseguir que el árbol de código fuente completo de su sitio controle las versiones. Cuando se realizan cambios en el servidor de prueba o en el servidor de ensayo, puede ver si funcionan, si se confirma y luego se actualiza en el servidor activo. Los rollbacks y la implementación son mucho más simples. Para clústeres de múltiples webheads, puede repetir el proceso o rsync desde un único servidor "canónico".
Si usa SVN, también puede usar las comprobaciones de CVS de Drupal y otros módulos/temas y los metadatos SVN/CVS podrán vivir uno junto al otro felizmente.
Para carpetas voluminosas como el directorio de archivos, use un enlace simbólico en la ubicación "adecuada" para apuntar a un directorio del lado del servidor fuera de la raíz web. Eso permite que el repositorio de control de origen incluya todo el código y un enlace simbólico, en lugar de todo el código y todos los archivos que los usuarios cargaron.
Las bases de datos son más complicadas; limpiar el DB dev/staging y ponerlo a vivir es más fácil para el lanzamiento inicial, pero hay algunas arrugas al hacer actualizaciones incrementales de DB si los usuarios en el sitio en vivo también están generando contenido.
Hice una presentación en Drupal deployment best practices el año pasado. Siéntase libre de revisar las diapositivas.
¡Gracias por tus consejos! De hecho, vi su presentación antes de hacer esta pregunta ;-) Sigo buscando alternativas y experimentando sugerencias. Mi proveedor de VPS sugirió otra opción: Virtual Appliance + rsync + SQL dump/restore Cualquier comentario sobre eso frente al modo CVS ... – ohho
rsync definitivamente puede funcionar, aunque la mayoría de los proyectos en los que trabajo involucran equipos distribuidos donde SVN/CVS como mecanismo de sincronización central ayuda a algo más que el tiempo de implementación. SQL dump/restore es el método que usamos al sacar el DB para su "lanzamiento", aunque se necesitan otros métodos para actualizaciones continuas – Eaton
Una muy buena presentación Eaton. ¡Gracias! –
no trabajo con Drupal, pero trabajo mucho con Joomla. Implemento archivando todos los archivos en la raíz web (tar y gzip en mi caso, pero podría usar zip) y luego cargando y expandiendo ese archivo en el servidor de producción. Luego tomo un volcado de SQL (mysqldump -u usuario -h host -p nombrebasededatos> dump.sql), lo cargo y uso el comando inverso para insertar los datos (mysql -u produser -h prodDBserver -p prodDatabase < dump.sql) Si no tiene acceso a shell puede cargar los archivos de uno en uno y escribir un script PHP para importar dump.sql.
Hola Richard, ¿puedes por favor elaborar más sobre esto? Todavía estoy tratando de encontrar la mejor práctica en esto. Gracias – jtanmay
Esto no funcionará en un sitio web que tenga contenido generado por el usuario, porque el contenido generado por el usuario será sobrescrito por la copia del sitio dev. – Tronathan
-1 para Richard Finn y +100 para Tronathan. –
Si es la primera vez que implementa (y/o Drupal), asegúrese de hacer todo de una vez. Debe tener mucho cuidado una vez que hay usuarios que efectúan contenido mientras está trabajando en otra copia.
Es posible dejar las tablas relacionadas con el contenido real, taxonomía, usuarios, etc. en lugar de su estructura. Luego presione los relacionados con la configuración. Sin embargo, esto agrega un orden de magnitud de complejidad.
Disculpas si el despliegue es algo viejo para ti, por lo tanto, esto es vagamente insultante.
Hemos tenido una amplia discusión sobre esto en mi lugar de trabajo, y la forma en que finalmente nos decidimos fue empujando las actualizaciones de código (incluidos los módulos y temas) desde el desarrollo hasta la producción. Estamos utilizando Subversion para esto, y está funcionando bien hasta ahora.
Lo que es particularmente importante es que automatice un proceso para empujar la base de datos atrás desde la producción, para que sus desarrolladores puedan mantener sus copias de la base de datos lo más cerca posible de la producción. En un entorno de misión crítica, debe estar absolutamente seguro de que la actualización de un módulo no va a mangar su base de datos. El proceso que utilizamos es el siguiente:
Y eso es todo. Una cosa que nunca se puede esperar para un marco de trabajo comunitario como Drupal es poder mover su base de datos de las pruebas a la producción después de que se active. A partir de ese momento, todos los movimientos de la base de datos van desde la producción hasta la prueba, lo que complica un poco el proceso de implementación. ¡Ten cuidado! :)
Me sorprende que nadie haya mencionado el módulo Deployment. Aquí hay un extracto de su página de proyecto:
... diseñado para permitir a los usuarios ubicar fácilmente el contenido de un sitio de Drupal a otro. La implementación administra automáticamente las dependencias entre entidades (como las referencias de nodos). Está diseñado para tener una API enriquecida que se puede ampliar fácilmente para usarla en una variedad de situaciones de almacenamiento de contenido.
Se mencionó implícitamente en @ Eaton presentación. –
Usamos el módulo Características para capturar características y luego instalarlas fácilmente en el sitio de producción.
Una buena estrategia que he encontrado y actualmente estoy implementando es utilizar una combinación del módulo de implementación para migrar mi contenido, y luego arrastrar junto con dbscripts para fusionar y actualizar el núcleo y los módulos. Se encarga de la fusión de bases de datos, incluso si tiene contenido en vivo, seguridad y actualizaciones de módulos, y actualmente tengo la configuración de la mina para trabajar con svn.
Features.El módulo es una herramienta extremadamente poderosa para administrar los cambios de configuración de Drupal.
Los tipos de contenido, las configuraciones de CCK, las vistas, las variables de Drupal, los contextos, los ajustes preestablecidos de la memoria, menús, taxonomías y permisos se pueden transferir a una función que se puede controlar en el control de la versión. A partir de ahí, la implementación de un nuevo sitio o el envío de cambios a uno existente se puede administrar fácilmente con la interfaz de usuario de funciones o Drush.
Asegúrese de instalar Strongarm.module para exportar la configuración de drupal que se almacena en su tabla de variables. También puede incluir contenido/nodos estáticos (es decir: sobre nosotros, preguntas frecuentes, etc.) en Funciones instalando uuid_features.module.
Indiscutiblemente, esta es la mejor manera de trabajar con otros desarrolladores en el mismo sitio, y trasladar su sitio de Desarrollo a Pruebas a Puesta en escena y Producción.
Este es el camino que estoy siguiendo. Creo que es la solución más moderna. Drush + Features + Subversion. También estoy mirando a Hudson, Jenkins y Phing porque los he visto mencionar dentro de la comunidad de Drupal. –
Cualquier sistema de control de versiones (GIT, SVN) + Features módulo para implementar el código de Drupal + configuraciones personalizadas (tipos de contenido, campos personalizados, dependencias de módulos, vistas, etc.).
Como el módulo Deploy se encuentra todavía en modo de desarrollo, puede utilizar el módulo Node export en Drupal 7 para implementar su contenido/nodos.
Pregunta 37 arriba, 34 estrellas, respuesta 39 arriba, ahora cerrado como fuera del tema ... después de 3 años se formuló esta pregunta. Sin palabras. – ohho
Esta pregunta probablemente debería moverse a [Drupal.SE] (http://drupal.stackexchange.com). – dotancohen