Ayuda de flujo de trabajo de Wordpress Git

Estoy buscando una idea de flujo de trabajo optimizada para trabajar con Wordpress.

1. Me gustaría tener mi entorno git en mi propio servidor internamente, sin usar Github para manejar repos.
2. Creación automática de subdominios en la creación de la rama git (development.domain.com, ryan.development.domain.com) - Probablemente algún gancho de script de shell sería ideal para esto.
3. Phing PHP / Shell Script Manejo de la migración db (algo así como http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) para manejar el reemplazo de la base de datos serializada al presionar

La operación probablemente sería algo como esto:

1. obteniendo la última versión actual de WordPress y ramificándola, el nombre de la sucursal obtiene una entrada de subdominio (branchdevelopment.domain.com)
2. submodule el tema que desee si está disponible (me gustaría hacer mi propio repositorio de git para esto, ya que uso la tesis me gustaría tener una configuración de repositorio de git de tesis en blanco para obtener internamente en el servidor que ya se ha creado)
3. pagar y realizar cambios, revisiones de clientes, una vez que se activa, el script de la base de datos comenzará a cambiar automáticamente los valores de URL serializados de localhost (o subdominio) a la URL en vivo

es posible? Escuché que Capistrano también es bueno para utilizar con esto, pero no estoy seguro de cómo funciona Capistrano por completo.

Ejecuto alrededor de 200 sitios en mi propio servidor y me gustaría comenzar a implementar estos sitios en un entorno de flujo de trabajo de git fuerte para que pueda optimizar mi trabajo mucho mejor. A partir de ahora, básicamente descargo una imagen del sitio y trabajo en ella localmente y luego vuelvo a cargar los cambios en el servidor. Esto es muy tedioso en estos tiempos.

¿Alguien tiene alguna solución con respecto a este tipo de flujo de trabajo / ha trabajado con esto en el pasado? Si es así, algunos recursos / respuestas serían muy apreciados.

Preguntas generales respondidas

Nr.1. Me gustaría tener mi entorno git en mi propio servidor internamente, sin usar Github para manejar repos.

Lo primero que haría es consultar al compositor y cómo funciona con WordPress , que es un proyecto de Andrey "@Rarst" Savchenko .

Nr.2. Creación automática de subdominios tras la creación de la rama git ( development.example.com, ryan.development.example.com) - Probablemente algún gancho de script de shell sería ideal para esto.

Esto es algo fuera del alcance de este sitio. Solicite ayuda en StackOverflow o solicite a su proveedor de alojamiento. Algunos anfitriones no permiten editar estas entradas usted mismo.

Nr.3. Phing PHP / Shell Script Manejo de la migración db (algo así como http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) para manejar el reemplazo de la base de datos serializada al presionar

Configuraría una instalación multisitio / red. Esto permite gestionar fácilmente todas las tablas, mantener a los usuarios en un lugar central, etc.

WP Gear , un proyecto de Robert "@Wyck" Ellison , tiene una lista de scripts de compilación alternativos. Incluyendo WordPhing escrito por él mismo. El script @TomJNowells /Interconnect.it hasta ahora no está en esa lista.

Operación Preguntas respondidas

Nr. 1. obteniendo la última versión actual de WordPress y ramificándola, el nombre de la sucursal obtiene una entrada de subdominio (branchdevelopment.domain.com)

No estoy seguro de por qué uno quiere hacer esto: un subdominio para cada rama. Cuando miras el repositorio sincronizado de WordPress GitHub y la lista de ramas , verás que cada rama tiene un nombre X.Y-branch. Entonces sus subdominios recibirían un nombre, por ejemplo 3.6-branch. No estoy seguro de si un subdominio puede comenzar con un dígito (debería serlo, pero pregúntele a su proveedor de alojamiento) y luego está el problema de que obtendrá un sub-subdominio llamado 6-branch, que tiene un sub-sub-subdominio llamado 3y otro llamado 2. Y supongo que emparejar ramas de 2 y 3 versiones en un subdominio no es lo que desea lograr.

En resumen: solo checkout 3.6-branchsi necesita cambiar de rama.

Nr.2. submódulo el tema que desee si está disponible (me gustaría hacer mi propio repositorio de git para esto, ya que uso la tesis me gustaría tener una configuración de repositorio de git de tesis en blanco para tomar internamente en el servidor que ya se ha creado)

Thomas "@toscho" Scholz ha escrito un buen complemento que nos permite usar un subdominio para manejar temas fuera del directorio de WordPress. Puedes encontrarlo en esta respuesta y en esta . Incluso las actualizaciones automáticas funcionarán para los temas desde WP 3.6.

Puede hacer lo mismo para MU-Plugins y Plugins simplemente configurando las siguientes constantes en su wp-config.phparchivo:

define( 'WP_PLUGIN_DIR',   'path/to/your/plugins.dev/folder/plugins' );
define( 'WP_PLUGIN_URL',   'https://plugins.dev/plugins' );
define( 'WPMU_PLUGIN_DIR', 'path/to/your/plugins.dev/folder/mu-plugins' );
define( 'WPMU_PLUGIN_URL', 'https://plugins.dev/mu-plugins' );

Ahora simplemente coloque todos sus complementos y temas bajo control de versiones y empújelos a su servidor. Puede hacer que todos estén disponibles fácilmente utilizando complementos mu o complementos predeterminados que se activan en la red.

Nr.3 pago y realización de cambios, revisiones de clientes, una vez que se activa, el script de la base de datos comenzará a cambiar automáticamente los valores de URL serializados de localhost (o subdominio) a la URL en vivo

Si el script / plugin de Toms no lo ayuda hasta ahora, entonces tenga en cuenta que acepta la solicitud de extracción en GitHub .

No hay tiempo para escribir una respuesta de función completa (sé un poco cojo) pero probablemente valga la pena compartir de todos modos (podría editar esto porque también planeo una publicación de blog sobre esto):

• Estoy clonando Wordpress desde Github (incluso puedes hacer esto para el árbol fuente desde aquí: tierra / wordpress )

• Luego lo uso como una combinación de subárbol en mi propio repositorio de sitios (incluso ejecuté un error en git pero su solución está aquí: -X subárbol = ... ).

Eso significa que puede tener alguna configuración de WP basada en troncal / versión de rama que puede hackear completamente, incl. temas y complementos.

Como este es un repositorio independiente (local), puede enviar esto a través de ssh a otros repositorios, por ejemplo uno:

• Eso se encuentra en el host remoto donde se debe implementar el sitio (repositorio).
• Eso tiene ganchos para hacer que otro repositorio en ese host realmente se fusione con los cambios que acaba de presionar.

Esto se describe en un flujo de trabajo Git centrado en la web (noviembre de 2008; por Joe Maller) .

Si luego tiene un conmutador de configuración que elige el concreto en wp-config.phpfunción del sistema en el que se está ejecutando, incluso puede configurar centralmente todos los hosts (desarrollo, en vivo, puesta en escena, amigos, ...) dentro del repositorio.

Los cambios anteriores en WP solo se obtienen y se combinan en el subárbol.

Complementos que solo actualiza y confirma.

La implementación es simple $ git push remote.

Ejecute copias de seguridad diarias en el host remoto para los repositorios git, la base de datos y los archivos cargados y esto es económico, fácil de usar y flexible. Esto funciona bien para configuraciones de desarrollador único, así como para equipos pequeños porque todos pueden realizar el pago desde la reproducción simple en el control remoto.

Hay algunas advertencias:

• Los alias de git git accept-theirsy git accept-theirsson útiles en caso de que haya cambios de línea de base conflictivos que claramente sabes con cuál prefieres lidiar. Lo encuentras aquí: herramienta simple para 'aceptar la suya' o 'aceptar la mía' en un archivo completo usando git
• Hola muñequita. La maldición de toda una generación. Necesitas rm siempre.

Ahora con su lista de verificación y la configuración como se describe anteriormente:

1. Me gustaría tener mi entorno git en mi propio servidor internamente, sin usar Github para manejar repos.

Github solo maneja repositorios ascendentes aquí (Wordpress), no el suyo.

2. Creación automática de subdominios al crear una rama git (development.domain.com, ryan.development.domain.com) - Probablemente algún gancho de script de shell sería ideal para esto.

La configuración como se describe es un enfoque modular con un repositorio por sitio. Puede manejar tantos hosts de desarrollo como desee, podría funcionar igualmente bien con una instalación de múltiples sitios para manejar múltiples dominios, pero eso contaría como una configuración de WordPress en este enfoque.

3. Phing PHP / Shell Script Manejo de la migración db (algo así como http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) para manejar el reemplazo de la base de datos serializada al presionar

Esto no es necesario aquí ya que solo el código está bajo control de versión, las bases de datos son independientes entre el desarrollo (, la puesta en escena) y la producción como debería ser.

Es posible que esté buscando una secuencia de comandos de instalación que realice correctamente la migración del dominio, pero incluso con un mejor código (que está disponible) que se ocupa de la búsqueda y el reemplazo de datos serializados, en esta configuración aquí normalmente no es necesario, ya que simplemente empuja los cambios a vivir , para los casos de prueba, puede crear rápidamente el contenido en la base de datos de desarrollo, que normalmente es el problema más pequeño (desde mi experiencia práctica, la suya puede diferir, pero también sugeriría mantener dichos temas relacionados con la migración de la base de datos en cuestiones de propio aquí en el sitio, pero pregúnteles).

Ejecuto alrededor de 200 sitios en mi propio servidor y me gustaría comenzar a implementar estos sitios en un entorno de flujo de trabajo fuerte de git para que pueda optimizar mi trabajo mucho mejor.

No puedo imaginar cómo esos sitios se convertirían en un entorno de flujo de trabajo de cadena git. Quizás las secuencias de comandos de configuración y los datos de configuración que administra aquí se mantendrán bajo el control de versión de git. Eso podría tener sentido. De lo contrario, por la gran cantidad de sitios, creo que no tiene ningún sentido mantener a todos en un repositorio git. Quizás ni siquiera uno de esos porque lo que describí anteriormente es para los sitios que desarrolla (incluido el código central de WP), no solo para las tareas de instalación. Por lo tanto, es probable que primero necesite crear un pequeño mapa de esos 200 sitios y cómo interactúan entre ellos y en qué paquetes (núcleo WP, complementos, temas) consisten esos sitios. Lo primero podría ser crear una hoja de cálculo / matriz y colocar todos los sitios.

Luego puede guardarlo como CSV, ponerlo bajo control de versiones y hacer que los scripts de implementación hagan su trabajo en función de ese archivo.

Y si he aprendido algo con las tareas de automatización: siga la filosofía de Unix, use las herramientas existentes y que funcionan bien (es mejor pasar medio día leyendo sobre algunos comandos y luego tratar de buscar alternativas porque para la mayoría de los trabajos, los problemas han sido ya resuelto) y se centran en las herramientas de línea de comandos. Ellos son los más poderosos.