Páginas de WordPress y control de versiones

Somos una empresa de desarrollo de software y estamos utilizando WordPress para la parte estática del website. Naturalmente, todo nuestro flujo de trabajo se basa en el control de versiones: múltiples desarrolladores -> continuous integration -> puesta en escena -> implementación.

Nuestro desafío con la integración de WordPress en nuestro flujo de trabajo es que su database está atascada como un hueso en la garganta: no puede ponerlo en el control de versiones, retroceder fácilmente, promover desde la transición a la producción, etc.

Me pregunto qué hace la gente en situaciones similares. Me gustaría encontrar una forma de integrar WP en el flujo de trabajo de desarrollo y no al revés 🙂

Aclaración: queremos "desarrollar" y probar páginas en el sistema de etapas y, cuando esté listo, moverlas a la producción como parte del process de actualización de la versión. No queremos hacer una replicación completa de la database provisional a producción.

Esa es una pregunta común y una que he trabajado en abordar. He escrito un código para abordar estos problemas, aunque el código no está listo para su distribución. Básicamente, la idea es crear scripts para importar el contenido y luego controlar las versiones de los scripts . (En realidad, mi enfoque utiliza un formatting personalizado de import / export diseñado para ser fácil de modificar manualmente, pero la idea es similar).

De todos modos, hay algunas preguntas relacionadas más en el sitio hermano de StackOverflow WordPress Respuestas :

  • Preguntas labeldas con el término [assembly]
  • Preguntas labeldas con el término [implementar]

ACTUALIZAR

Según la aclaración, esto probablemente sería útil también:

  • ¿Hay alguna forma de networkingactar una revisión de una página o publicación publicada? ¿Qué soluciones has usado?

Espero que esto ayude.

-Micro

Acabo de golpear el mismo problema. Por ahora estamos usando files de volcado de MySQL para exportar / importar contenido de la database, pero se pone feo con varias personas que trabajan en los cambios de la database.

Como el equipo que trabaja en el proyecto es todo interno y está formado por solo unas pocas personas, estoy pensando en bloquear el file de volcado de database en VCS. Subversion tenía esta funcionalidad incorporada, pero estamos usando git, que, creo, es conceptualmente opuesto a cualquier tipo de locking.

Probablemente tendremos una secuencia de commands provisional con el enlace precompromiso para verificar la existencia de un file de locking al lado del volcado. La persona que cometió el file de locking será la única autorizada a enviar el volcado. Una vez que termine el trabajo, deberá comprometer la eliminación del file de locking.

Suena feo, lo sé. Pero lo he pensado por un time y todavía no veo una solución elegante.

Si solo está utilizando WordPress para contenido estático, entonces cualquier herramienta / metodología para las bases de datos de control de versiones debería funcionar; por ejemplo, utilice las herramientas de command-line de mysql en sus rutinas de deployment y CI.