¿Cómo implementar entornos Dev, Stage y Production para sitios WordPress?

Tengo una configuración de la que estoy bastante orgulloso y que funciona extremadamente bien para mi equipo.

Estructura General

Mantengo toda la instalación bajo git. Todos los cambios, ya sea una actualización del sistema, agregar/actualizar un plugin, agregar/actualizar un tema, pasan por el mismo flujo de trabajo. Los cambios se pueden revertir en cualquier momento. Tengo un servidor de despliegue (un antiguo escritorio P4) ejecutando gitosis, pero podrías usar fácilmente github o gitolite. En git, tengo dos ramas "especiales", master y develop (explicadas más adelante). Mis servidores de producción y staging están basados en la nube.

Entornos de Desarrollo

Cada desarrollador ejecuta su propio servidor de desarrollo en su máquina local. En términos de bases de datos, rara vez ha sido necesario tener datos en vivo. Principalmente usamos los datos de prueba de temas unitarios. De lo contrario, exportar e importar cubre la mayoría de las necesidades. Si la parte de la base de datos fuera crucial, podrías configurar replicación o algo para sincronización bajo demanda. Cuando configuré inicialmente esta estructura, pensé que esto sería crucial, así que comencé a escribir un conjunto de herramientas para hacerlo, pero para mi sorpresa, realmente no fueron necesarias. (nota: como no fueron necesarias, nunca las pulí, así que tienen errores, por ejemplo, reemplazarán el dominio en datos serializados).

Entorno de Staging

Cuando se envían commits desde la rama develop a gitosis, se despliegan automáticamente en nuestro servidor de staging. La base de datos de staging es esclava de la base de datos de producción.

Entorno de Producción

Cuando se envían commits a gitosis en la rama master, se despliegan automáticamente al servidor de producción.

El problema de wp-config.php

Quieres que wp-config.php sea único de servidor a servidor, pero también quieres mantenerlo bajo control de versiones. Mi solución fue usar .gitignore para ignorar wp-config.php y almacenar las versiones de staging y producción como archivos con nombres diferentes. Luego, en cada servidor, creo un enlace simbólico, por ejemplo wp-config.php -> wp-config-production.php. Cada usuario mantiene su propia base de datos con sus propias credenciales, con sus propios ajustes (no rastreados) en wp-config.php.

Otras Notas

Uso Rackspace Cloud, que es fenomenal y económico. Con él puedo mantener mis servidores de staging y producción idénticos. También estoy escribiendo plugins ahora que usan su API para permitirme controlar mis servicios directamente desde WordPress, es maravilloso.

Los directorios de caché, directorios de subida de archivos, etc., se agregan a .gitignore. Si quisieras, podrías configurar una tarea cron para verificar rutinariamente las subidas y enviarlas a gitosis, pero eso nunca me pareció necesario.

La estructura master/develop está configurada para imitar parcialmente el modelo de ramificación de Vincent Driessen. También uso su extensión de git git-flow y lo recomiendo encarecidamente.

He tenido alrededor de 10 desarrolladores trabajando con esta estructura durante más de un año y ha sido un sueño trabajar con ella. Confiable, segura, rápida, funcional y ágil, ¡no se puede pedir mucho más!

En primer lugar, creo que es importante considerar qué vas a incluir en el control de versiones. Recomendaría no poner todo el directorio de WP bajo VC. Creo que tiene más sentido poner wp-content/themes/NombreDeTuTema bajo control de versiones. Para un sitio grande con muchos plugins complejos, podría verse el caso de incluir también wp-content/plugins. Si fuera absolutamente necesario, podrías incluir wp-content/uploads. Las respuestas a continuación cambiarán un poco dependiendo de lo que controles en versiones.

Dicho esto, esto es lo que yo uso:

Local: Configura un stack LAMP en tu máquina. Usa la misma URL que tu sitio de desarrollo. Utiliza VirtualHosts y entradas en el archivo .host para simular el entorno de desarrollo desde el punto de vista de la URL. Si solo estás controlando versiones de tu tema, considera usar SSHFS para enlazar con wp-content/plugins, wp-content/uploads. Considera usar la base de datos de tu instalación de desarrollo del proyecto a menos que estés haciendo un trabajo realmente intensivo.

Desarrollo: Haz checkout de una copia de trabajo de tu repositorio en tu entorno WP. Configura un Hook POST-COMMIT en SVN para actualizar este repositorio en cada commit. Esto lo mantendrá sincronizado. (Considéralo una forma básica de integración continua).

Producción: Haz checkout de una etiqueta de versión nombrada que represente un candidato final. Cuando necesites usar una nueva versión, cambia la etiqueta y actualiza el repositorio.

Recientemente descubrimos RAMP. Nota: esto es solo una parte de todo el proceso, pero sincronizar bases de datos de contenido entre servidores es probablemente la parte más difícil del mismo.

Yo hago esto con git y mercurial, solo asegúrate de usar un repositorio privado.

Opción 1.

El único problema es el config.php, al cual puedes indicarle a git que lo ignore al hacer push o antes del init.

Usa .gitignore o git update-index --assume-unchanged config.php (lee un poco sobre el comando assumed-unchanged antes de usarlo)

Opción 2.

Usa un condicional en el config.php que verifique la URL y aplique las credenciales correctas, algo como "si la URL del servidor = dev entonces usa credenciales A, sino usa credenciales B", etc.

Mark lo explica mejor, http://markjaquith.wordpress.com/2011/06/24/wordpress-local-dev-tips/

PD. También puedes servir los archivos directamente desde un repositorio remoto en lugar de tener un "servidor de archivos" tradicional. (video realmente aburrido que hice sobre esto http://www.youtube.com/watch?v=8ZEiFi4thDI)