WordPress y Git Workflow

Sé que esta pregunta se ha hecho miles de veces, pero realmente estoy tratando de descubrir cómo sacar el máximo provecho de Git cuando trabajo con WordPress.

Recorrí la web y leí docenas de artículos, todos los cuales parecen cubrir el tema brevemente. Aquí hay algunos de los más notables que he leído recientemente.

- Control de versiones de WordPress

- Administrar implementaciones de temas de WordPress con Git

- Administre su tema personalizado de WordPress usando git en lugar de FTP

Actualmente, mi flujo de trabajo se ve así.

• Instalar WordPress localmente
• Desarrollar tema
• Exportar bases de datos de WordPress desde el servidor local
• Importar la base de datos de WordPress al servidor remoto
• Sube archivos y temas de WordPress a través de FTP
• El cliente hace cambios
• Descargue archivos y temas de WordPress a través de FTP y exporte bases de datos de WordPress desde un servidor remoto
• Reemplazar archivos localmente
• Hacer cambios de desarrollo
• Vuelva a cargar a través de FTP, exporte e importe la base de datos al servidor remoto

Me doy cuenta de que Git puede simplificar este proceso. Parece que la mejor manera de hacer esto es tener un archivo .gitignore que ignore ciertos directorios que no necesitan ser rastreados, así como tener un archivo wp-config.php local y remoto.

Pero, ¿cómo manejas las bases de datos? Los clientes generalmente harán cambios (publicaciones / páginas / complementos). ¿Todavía necesito exportar desde la base de datos remota e importar de nuevo en mi servidor local?

¿Alguien puede sugerirme el mejor flujo de trabajo aquí? Y guíame por los escalones.

Además, probablemente me gustaría usar Bitbucket ya que los repositorios privados con ellos son gratuitos, a diferencia de GitHub.

Cualquier ayuda sería apreciada.

¡Gracias por adelantado!

Soy uno de los desarrolladores de WP Migrate DB Pro , y me gustaría responder a la pregunta de @ Ennui:

"¿Sabe si el script de reemplazo de URL de DB que ejecuta tiene en cuenta las cadenas serializadas?"

Sí, maneja datos serializados. De hecho, esa es la razón principal por la que desarrollé la versión gratuita del complemento en 2009. :)

Desafortunadamente solo tengo una reputación de 41 años, así que no pude responder al comentario de @ Ennui. Lo siento por eso.

Estoy al borde de votar para cerrar esto como "no constructivo", ya que parece ser el tipo de cosa que solicitará debate y opinión en lugar de respuestas. Pero...

Ese no es el aspecto de mi flujo de trabajo, y hace que mi enfoque (y respuesta) sea diferente de la mayoría del resto de las respuestas hasta ahora.

1. Instalar WordPress localmente
   1. Esto se clona a partir de un repositorio de Git desnudo local que contiene la última versión estable.
   2. También guardo una copia local de la última versión de algunos complementos que casi siempre instalo.
2. Cree el tema y los complementos necesarios
3. Subir a un servidor de ensayo público
   1. El cliente tiene acceso pero no puede cambiar el código y le dijo que las ediciones de la base de datos no se transferirán al sitio de producción.
   2. Esto significa que no hay ninguna razón para volver a descargar el código en el servidor de desarrollo.
   3. Y no hay razón para volver a sincronizar la base de datos local
4. Realice cambios en el sitio local en función de nuestro personal y los comentarios del cliente.
5. Subir cambios
6. Repita según sea necesario (pero con resistencia creciente :))
7. Si estamos proporcionando contenido, que no siempre es el caso, nosotros (no el cliente) limpiaremos la base de datos en el servidor de ensayo y cargaremos contenido.
8. Implemente cargando el código local en el sitio de producción.
9. Si hemos creado contenido, el contenido se exporta desde el sitio de preparación a través de la herramienta de exportación de vainilla y se importa al sitio de producción.
   1. Esta es la única vez que tengo que mover la base de datos, y se hace con herramientas bastante estándar. Voy a utilizar terciopelo azules Actualizar URL para limpiar la base de datos si es necesario.
10. Depurar
11. El fin

Básicamente, mantengo al cliente alejado de mis cosas tanto como sea posible hasta que entreguemos el sitio.

El código se mueve en una dirección: de local a puesta en escena o producción. Nunca se mueve para otro lado. Eso elimina algunos de sus pasos y me da tranquilidad. No quiero que se me culpe por las modificaciones del cliente en mi código y no quiero importar algún archivo pirateado, que es una posibilidad distinta de cero.

Y la base de datos solo se mueve una vez, si es que lo hace, lo que reduce en gran medida el problema. Así que supongo que manejo el problema del "movimiento de la base de datos" al reducir o eliminar la necesidad de mover la base de datos. También reduce los problemas de corrupción de la base de datos que pueden surgir y reduce las posibilidades de importar un hack.

Es cierto que tengo que configurar el sitio de producción: enlaces permanentes, menús, etc., pero eso me obliga a trabajar en el sitio de producción, así que lo considero una especie de depuración. Me ayuda a confirmar que las cosas funcionan en el sitio de producción como deberían.

https://github.com/nathanielks/Wordpress-Capistrano-Deploy

No lo he intentado yo mismo (todavía), pero dice implementar todo, incluida la base de datos.

También hay un tutorial que lo acompaña: Tutorial parte 1 | parte 2

Echa un vistazo a la pila de roca madre . Utiliza Composer para administrar la versión de Wordpress y complementos de terceros, y también incluye capistrano para implementaciones y vagabundo / ansioso para configurar servidores que incluyen servidores virtuales locales para el desarrollo.

Recientemente hice muchas pruebas con respecto a esto y aquí está el flujo de trabajo que uso, que hace más o menos lo que estás pidiendo:

• Uso wp-cli para administrar el núcleo de wordpress y actualizar wordpress.
• Uso composer junto con http://wpackagist.org para administrar las dependencias de plugins y temas.
• Uso git y pongo los archivos centrales de wp en .gitignore. Por lo tanto, la mayoría de los archivos wp-config.php y temas secundarios están en git.

No estoy familiarizado con las herramientas de migración de db, pero sería una gran adición a este flujo de trabajo.

Aquí están los detalles completos sobre el flujo de trabajo http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

Con respecto a la "clonación" de la base de datos, utilizo WP Migrate DB Pro: http://deliciousbrains.com/wp-migrate-db-pro/

Es un servicio pago, pero no cuesta mucho, y le permite fácilmente extraer o empujar su base de datos de su desarrollador a su servidor en vivo y viceversa. Cambia las URL y todo lo que necesita cambiar en el camino.