Mi equipo se enfrentó a un problema similar. Usamos git para versionar nuestro propio código personalizado, como complementos y el tema que escribimos. Usamos Composer para administrar dependencias como complementos que no escribimos. Verificamos los archivos composer.json y composer.lock en git para mantener a todos sincronizados. Se espera que cada desarrollador extraiga la rama maestra de git y se ejecute composer update
en sus corralitos con frecuencia para que todos estén actualizados.
En la base de datos, los desarrolladores se preocupan principalmente por la configuración, y a menudo utilizamos WP-CLI para mantener la configuración sincronizada. Por ejemplo, tenemos un script de shell que ejecuta un comando WP-CLI para habilitar o deshabilitar complementos por host; algunos complementos solo se usan en nuestro host de almacenamiento de contenido, por ejemplo, por lo que el script se puede ejecutar en cualquier host y solo habilitará el conjunto apropiado en ese host. Algunas configuraciones que requieren demasiado tiempo para la secuencia de comandos solo se documentan y se reproducen manualmente si es necesario.
También tenemos un script perl que clonará completamente la base de datos de nuestro servidor de almacenamiento de contenido en un QA o host de desarrollo. Los desarrolladores pueden usar esto periódicamente si quieren todo el contenido actual, aunque eso suele ser menos importante que tener el código y la configuración. El script realiza estas tareas:
- volcado mySQL de la base de datos del servidor de almacenamiento de contenido, cambiar los nombres de las tablas, cargar en la base de datos del servidor de destino
- use wp-cli para cambiar las referencias al servidor de ensayo dentro de la base de datos para referirse al servidor de destino
- sincronice el directorio de cargas en el servidor de destino con las cargas del servidor de almacenamiento de contenido
Hay algunas soluciones prometedoras para versionar la base de datos que están llegando rápidamente. VersionPress y Mergebot son los dos que conozco y puede haber otros.
Escribí más detalles técnicos sobre cómo configuramos WordPress para trabajar con git y Composer en mi blog. Era necesario ejecutar con el núcleo de WordPress en su propio directorio para hacer una separación limpia entre el código que queremos mantener en git y el núcleo de WordPress. Tratamos a WordPress como una dependencia y lo gestionamos con Composer.