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.