Fondo

Me estoy acercando a las etapas finales de la construcción de mi primer sitio de WordPress bastante grande, y ahora encuentro algunas fricciones. En su mayor parte, el sitio se desarrolló en mi máquina local y enviaría los cambios a un servidor provisional para su revisión ( consulte esta pregunta para obtener más información ). La solución con la que terminé funcionó bastante bien cuando solo estaba yo editando contenido, pero ahora algunas otras personas están editando el contenido mientras todavía tengo características para agregar. La idea era: podríamos hacer las cosas más rápidamente si las características y el contenido se unieran en concierto ... pero ahora no estoy tan seguro.

Actualmente hay un contenido diferente en la base de datos en el servidor intermedio que en mi máquina local. Eso está bien por sí mismo, ya que no necesito la copia del cuerpo final en mi máquina local, pero necesito hacer más desarrollo que afectará a la base de datos (instalar / escribir un par de complementos más que necesitan sus propias tablas).

Mi pregunta es:

¿Hay una manera fácil de automatizar la fusión de bases de datos para que varias personas puedan trabajar en una instalación de WordPress? Podría, por supuesto, exportar las tablas que sé que han cambiado en mi máquina local y llevarlas al servidor de ensayo, pero es posible que también haya cosas en el servidor de ensayo que me gustaría eliminar. Podría obtener la salida SQL de ambos DB y diferenciarlos ... pero eso parece tedioso y hackeo. Me pregunto si este es un problema que otros han resuelto; si hay una forma aceptada por la comunidad para manejar este tipo de cosas.

¡Gracias!

Hice esta pregunta hace más de un año, y durante ese tiempo hemos agregado más personas a nuestro equipo y hemos desarrollado una cantidad mucho mayor de sitios en WordPress. Quería recorrer nuestro proceso en caso de que pueda ayudar a alguien más.

Todo en Git

Esto era algo que estaba haciendo incluso cuando hice la pregunta, pero es bueno señalar este punto. Usar Git no solo nos ha ayudado a ser más productivos, sino que también nos ha salvado el trasero colectivo varias veces.

¿Alguna vez ha necesitado realizar renovaciones estructurales importantes en un sitio, obtener la aprobación de esas renovaciones de un cliente y, al mismo tiempo, realizar actualizaciones menores a la versión no renovada? Tenemos, y Git nos dejó hacerlo. Describir esta configuración sería un poco largo, pero lo básico es que creamos una nueva rama, colocamos esa rama en el servidor y adjuntamos un subdominio a esa rama.

También hemos sido salvados por Git. Por supuesto, nos permite revertir los cambios, lo cual es genial, pero también nos permite recuperar versiones antiguas de archivos. Esto significa que si un cliente pregunta: "¿Recuerdas cómo funcionaba esta parte del sitio hace aproximadamente un año? ¿Podemos recuperar eso?", La respuesta es sí, incluso si la persona a la que se le preguntó no estuvo en ese proyecto un año hace.

Además de estos puntos, también significa que nunca estamos atrapados sin los archivos que necesitamos. Siempre podemos extraer la versión más reciente del sitio desde cualquier máquina y comenzar a hacer cambios.

Usa Git para implementar

Hacemos nuestro alojamiento de WordPress en Media Temple , y realmente nos gustan. No son el proveedor más barato, pero su servicio es excelente y sus servidores están realmente bien configurados. También proporcionan Git por defecto. Esto significa que podemos configurar el servidor como un repositorio Git y extraer los cambios de esa manera en lugar de usar SFTP. También significa que trabajar en el servidor no está en peligro de sobrescribirse (ya que esos cambios solo se pueden fusionar y volver a subir).

Debido a que usamos BitBucket como nuestro host Git, aquí se requiere un poco de trabajo extra. En primer lugar, utilizamos archivos .ssh / config para poder escribir cosas como ssh sitenameiniciar sesión en nuestros servidores (también utilizamos SSH sin contraseña , lo que hace que esto sea muy fácil). También nos aseguramos de usar siempre frases de contraseña ssh (Mac OS X lo hace muy fácil al permitirle almacenar su frase de contraseña en Keychain.app ). Finalmente, agregamos una línea ForwardAgent a la entrada .ssh / config en los hosts de los que queremos extraer. Esto significa que solo necesitamos la clave pública SSH de cada persona en BitBucket, y no la clave pública de cada servidor. También nos aseguramos de mantener el .gitdirectorio un directorio por encima del directorio HTML público.

Bases de datos automatizadas

Una vez que el servidor está en modo de producción, nos aseguramos de hacer una copia de seguridad automática de nuestra base de datos, por si acaso .

Todos tienen su propia wp-config

Debido a que todos tenemos nuestros propios nombres de usuario y contraseñas de bases de datos locales, y debido a que podríamos usar diferentes nombres y mecanismos de servicio, cada uno conserva nuestro propio archivo wp-config. Cada uno de ellos se registra en Git con un nombre como wp-config-gavin.phpy cuando queremos usar esa configuración, que crear enlaces a wp-config.php(que es ignorado por el uso de Git .gitignore ).

Esto también nos permite anular la siteurlopción en la wp_optionstabla de la base de datos de esta manera:

define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');

Esto evita que WordPress busque en la base de datos la ubicación del servidor, y significa que no hay diferencias extrañas en la ubicación entre las instalaciones locales y del servidor.

Una nota final sobre los archivos wp-config.php: asegúrese de almacenarlos sobre el directorio HTML público y haga que los permisos sean de solo lectura para el usuario web . Esto hace una gran diferencia en asegurar WordPress.

El problema de la base de datos

Finalmente, la carne del asunto.

Lo que tuve que aceptar es que, al usar WordPress, no hay una buena manera de "fusionar" los cambios en la base de datos. En cambio, necesitábamos desarrollar reglas de conducta para resolver esto. Las reglas son bastante simples y nos han servido bien hasta ahora.

Durante el desarrollo, hay una sola persona que "posee" el sitio. Esa persona generalmente realiza la configuración (reunir el paquete de alojamiento, iniciar el proyecto Basecamp, dividir el diseño, ese tipo de cosas). Una vez que esa persona está en un punto razonable, volcar la base de datos para la instalación de WordPress y ponerla en Git. A partir de ese momento, todos los que realizan el desarrollo utilizan ese volcado de la base de datos, y el propietario es el único que realiza cambios en la base de datos.

Una vez que la construcción del sitio avanza un poco más, el sitio se coloca en un servidor. A partir de ese momento, la base de datos del servidor es canónica. Todos (incluido el propietario) deben realizar todos los cambios en la base de datos en el servidor y eliminar los cambios para el desarrollo y las pruebas locales.

Este proceso no es perfecto. Todavía es posible que alguien necesite hacer cambios en el backend de WordPress localmente durante el desarrollo, y luego tener que hacer esos cambios nuevamente en producción. Sin embargo, hemos encontrado que ese tipo de cosas son raras, y este proceso funciona bastante bien para nosotros.

Trabajo en dicha instalación y he respondido preguntas como esta antes . A continuación se muestra mi configuración preferida para este tipo de trabajo. Debido a que desea fusionar bases de datos en lugar de reemplazar una base de datos existente, agregaría a estas advertencias que no use el indicador --add-drop-table cuando realice el volcado de MySQL.

• Paso 1. Mysqldump su base de datos de desarrollo
• Paso 2. Reemplace todas las instancias de development.domain.com a production.domain.com ^^
• Paso 3. Inicie sesión en MySQL, ejecute un comando SOURCE para importar datos, por ejemplo source /path/to/file

^^ Cómo reemplazar todas las instancias de dominio antiguo con nuevo: (1) Copie el script a continuación. (2) chmod +xeso. (3) Ejecútalo.

Uso: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g

Estoy experimentando con diferentes soluciones a este mismo problema en este momento. Definitivamente es complicado.

Mi solución actual es hacer un volcado mysql local usando el indicador --skip-extended-insert. Creo que esta marca hace que se genere una instrucción de registro de inserción para cada fila de la base de datos, lo que hace que el volcado sea un poco más fácil de combinar. Aprendí ese truco de este artículo: http://www.viget.com/extend/backup-your-database-in-git/ .

Luego controlo el archivo resultante .sql datadump usando Git junto con los archivos fuente del sitio. Cuando otro desarrollador despliega los cambios de código, el archivo .sql viene junto con él. Luego importa este archivo a su versión local de la base de datos. Ambos hemos configurado nuestras bases de datos locales respectivas de la misma manera en ambas máquinas, usando MAMP, por lo que no hay necesidad de hacer ninguna búsqueda y reemplazo.

Ha habido problemas de fusión, por lo que estamos tratando de adoptar un enfoque de "turnarse" para cualquier cosa que cause un cambio en la base de datos. Antes de hacer algo en Wordpress que cambie la base de datos, me aseguro de que haya revisado su último volcado, tire de él e impórtelo, y luego le pido que no haga ningún cambio en la base de datos hasta que haya hecho y revisado el mío. Obviamente, esto no es ideal y estoy buscando una solución mejor, pero es un comienzo. También nos da el control de versión de la base de datos, lo cual es bueno.

Puedo terminar configurando una base de datos de desarrollo compartido en el servidor e intentar conectar nuestras dos copias locales del sitio web a la misma base de datos a través de túneles SSH. Sin embargo, este enfoque tendrá problemas cada vez que uno de nosotros instale un complemento. Básicamente, los archivos PHP y MySQL DB estarán fuera de sincronización.

Estoy ansioso por escuchar cómo otros están lidiando con este problema.