Git Workflow con WordPress - Localhost to Live

Question

Tengo una pregunta de flujo de trabajo de WordPress básica pero común.

flujo de trabajo actual

1. que desarrollan todo a nivel local
2. archivos FTP (y volcado de la base de datos) hasta el servidor para mostrar cliente
3. Hacer cambios solicitados localmente
4. archivos FTP (y la base de datos volcado) en el servidor nuevamente
5. Más ediciones locales
6. FTP (an d dump database) de nuevo
7. Enjuague y repita

Esto se ha convertido en un dolor monstruo. Tiene que haber una mejor manera

flujo de trabajo Git Sospecha de

1. copia local será mi 'maestro'
2. archivos 'empuje' de hasta
3. archivos en algún lugar 'pull' de este lugar en el medio de mi servidor de prueba/en vivo

Creo que tengo una idea de cómo se debe hacer conceptualmente, pero no sé cómo debería Activamente hecho. ¿Debería usar un repositorio privado de Github en el medio? ¿Hay alguna manera de que mi sitio Live "tire" directamente de mi repositorio de localhost?

Disculpas si esto parece elemental o golpeado hasta la muerte, pero he buscado y no he encontrado una guía básica "Así se debe ver tu flujo de trabajo".

¡Gracias!

Terry

Answer 1

Parece que no está utilizando el control de versiones en absoluto. Es una buena idea que comiences. I solo convertido de SVN a Git, y estoy haciendo lo que estás haciendo en un nivel más grandioso. Vamos a empezar con sus objetivos:

1. Get control de versiones
2. establecer algún tipo de despliegue web a través de Git
3. anfitrión del control de versiones de forma remota

La gente le dirá que Git no es una web herramienta de implementación: pueden estar en lo cierto, pero hasta ahora funciona bien para mí, e hice algo similar. Por suerte para ti, practiqué en una instalación de Wordpress. Estos son los pasos que tomé.

1. Lo tengo todo con la instalación de Git y lo instalo hasta donde llega el cliente.
2. Descargó la última versión de Wordpress en una instalación de vanilla.
3. git init la base instalar sin modificaciones
4. ramificados en el maestro "dev" y "en vivo"
5. trabajo a nivel local, en la comisión de "dev", a continuación, una vez que se hacen cambios, se fusionaron para vivir.

Ahora, lo que terminé volviendo y haciendo fue crear una máquina virtual de servidor gitolite y usar eso como mi host - esto efectivamente reemplazó github en su ejemplo. Creo que conoces el valor de un repositorio remoto: definitivamente seguiría esa ruta.

Voy a retroceder un momento en el paso 2 de mis recomendaciones. Debes mantener la versión estándar de Wordpress en el maestro para que puedas actualizar el núcleo y ver cómo funciona con tu código personalizado, en lugar de actualizar el núcleo en algo así como una de tus ramas y todo lo demás. Esto ha sido muy conveniente para mí, y algo que definitivamente voy a usar en proyectos más grandes como Magento.

Bien, volviendo a la implementación. Puede poner un cliente git en su servidor web y tenerlo como pull desde su sucursal en el flujo de trabajo, pero debe tener en cuenta algunas consideraciones especiales de planificación. Es probable que sus archivos prod sean diferentes a sus archivos dev en ciertos lugares, particularmente en la configuración (base de datos, etc.); querrá asegurarse de que esos archivos estén en .gitignore, por lo que no está arrancando dev configs en su prod entorno.

He resumido todo lo que la gente me decía cuando comencé a trabajar en esto, así que espero que ayude. Una vez más, estoy un poco pasado donde estás, así que si alguien tiene correcciones/optimizaciones, no dude en comentar.

Answer 2

Empiezo a configurar tal flujo de trabajo para Wordpress. Ya lo tengo trabajando para algunos otros proyectos web.

Estoy usando la herramienta gitolite (https://github.com/sitaramc/gitolite/wiki/) para administrar repositorios simples (repositorios sin una verificación local) en una ubicación central, y luego activar un gancho de actualización en gitolite cuando una rama se empuja desde la ubicación de desarrollo.

Este enlace se envía al servidor en vivo (o la cuenta del cliente o lo que sea) con una clave privada compartida almacenada en el servidor de implementación, y realiza un git pull desde public_html o cualquier ubicación que tenga al servicio de su instalación de Wordpress.

Esto se hace usando una entrada de solo lectura en el archivo de configuración gitolite que es conf/gitolite.conf en el repositorio de configuración local. (Gitolite utiliza un repositorio Git para administrar sus archivos de configuración)

repo wp-versions 
    RW+ = tmzt 
    R = server1 
    R = server2 

La primera es mi clave pública primaria, que se almacena keydir/tmzt.pub en el mismo repositorio (mismo formato que .ssh/authorized_keys). Los otros dos son servidores web en vivo que tendrán acceso de solo lectura al repositorio. Agregue las tres claves a keydir y asegúrese de confirmar y presionar. Los cambios se realizarán automáticamente en la instalación de gitolite. (Las claves del servidor son compartidas por múltiples usuarios y copiadas al archivo .ssh/id_rsa de cada usuario, pero esto podría ser de datos www, si lo prefiere).

RW + significa que mi usuario principal ha leído, escrito y puede actualizar las ramas de avance rápido (útiles para revertir las confirmaciones en el servidor).