wordpress - tag - wp site title php

Git Post-recibir gancho con parte del árbol de trabajo

Question

Me gustaría usar git para implementar un sitio web en un servidor de prueba. Mi sitio web es un tema de wordpress creado con gulp y el repositorio parece

theme.git/
-- gulpfile.js
-- src/
-- build/

He seguido los pasos explicados here y here que configuran un repositorio simple en el servidor, configuran la ubicación del árbol de trabajo git y escriben un enlace posterior a la recepción para enviar el repositorio a esa ubicación.

El problema es que solo estoy buscando mover o copiar la build/ carpeta a su ubicación en el servidor. Mi único pensamiento fue escribir un enganche posterior a la recepción que arrastre el repositorio a una ubicación del árbol de trabajo (porque creo que leí que los repositorios no suelen tener un árbol de trabajo), y luego cp es la carpeta de compilación en wp-content/themes/

Parece innecesariamente complicado, así que me pregunto si hay una manera más eficiente / más común de hacerlo. ¡Gracias!

Answer 1

Este es un trabajo sencillo de git read-tree . Mantenga un índice conocido como lo que está en su directorio de implementación y maneje sus actualizaciones con una recepción previa como:

#!/bin/sh
while read old new ref; do [[ $ref = refs/heads/master ]] && {
export GIT_INDEX_FILE=deployment-manifest
export GIT_WORK_TREE=/path/to/deployment
git read-tree -um `git write-tree` $new:build || exit 1
}; done

Tenga en cuenta que si algún archivo que se está implementando de esta manera se ha modificado en el árbol de implementación, el git read-tree aquí y el envío fallarán porque git no sobrescribirá el contenido del que no se lo ha dicho.

Answer 2

Su aproximación para usar git tan extensamente para la implementación parece un poco extraño, principalmente porque git es un sistema de administración de código fuente primario, no una herramienta de implementación. Es cierto que puedes hacer muchos tipos de cosas raras con los ganchos de git, pero por alguna razón u otra, siento que esa es una tendencia a volver a atormentarte.

Normalmente, le recomendaría que utilice algún tipo de herramienta de integración continua para el trabajo. Un posible flujo de trabajo, que podría utilizar yo mismo, sería

1. Almacene sus archivos de temas en un repositorio público en GitHub . Es gratis, probablemente no haya grandes secretos en el código fuente de tu tema, y ​​como un bono adicional puedes incluso abrir tu tema de código abierto.
2. Configure un trabajo de CI con Travis CI para su repositorio. Básicamente, obtiene una instancia de máquina de compilación gratuita en la nube, y puede hacer todo tipo de cosas antes o después de la compilación. Usted podría por ejemplo. ejecute gulp build (o cualquiera que sea el nombre de su tarea) allí, para que no tenga que almacenar el directorio de build en el repositorio de git.
3. En el gancho de Travis after_success , podría copiar el directorio de compilación al servidor de destino, por ejemplo, utilizando scp . Aquí hay un ejemplo de hacer lo mismo con FTP . Travis admite el cifrado de datos confidenciales , por lo que no tiene que preocuparse (al menos tanto) de almacenar el nombre de usuario y la contraseña en el repositorio de git.

Ese flujo es útil cuando desea implementar la compilación cada vez que confíe algo en el repositorio de git. Por cierto, cuando lo usas por primera vez, realmente se siente como magia: "Acabo de hacer este git push , y ahora el cambio ya está activo en mi servidor".

Sin embargo, mencionó que desea implementar el código en un servidor de prueba . Es cierto que las herramientas de CI (como Travis) se pueden usar para mantener un flujo entre diferentes pasos de implementación, de los cuales muchos están probando servidores. Un ejemplo de flujo para grandes proyectos podría ser

development -> tests passing? -> release -> tests passing? -> integration -> tests passing? -> staging -> tests passing? -> production

... donde el flujo podría ser parcial o totalmente automatizado con una herramienta de CI.

Sin embargo, lo hizo sonar así, en su caso, la implementación de la compilación es una cosa de una sola vez, lo que a veces solo quiere hacer manualmente. (Pido disculpas si lo malinterpreté). Para este tipo de tareas únicas, el uso de scripts de shell o herramientas de administración de tareas es más adecuado.

Mencionaste que ya estás usando gulp . Esa es una herramienta muy útil para el trabajo, especialmente porque puede combinar fácilmente "flujos de tareas". Podría tener una tarea para crear el tema ( gulp build ) y otra para la implementación del servidor de prueba ( gulp deploy-test ), que solo amplía la tarea de build con un paso adicional para copiar los archivos en el servidor de prueba. gulp-scp parece un excelente complemento para la tarea (aunque no lo he usado, solo fue el primer resultado de búsqueda de Google). Si eso no funciona, siempre puede llamar a scp manualmente con gulp-shell o similar.

Incluso podría parametrizar las tareas de implementación para hacer algo como: gulp deploy --test y gulp deploy --production

Ahí tienes, esta fue tu primera lección en devops . Hay todo un mundo de cosas que aprender si este tipo de automatización de tareas en proyectos de software le parece interesante.

Answer 3

Yo dividiría tu proyecto en dos repositorios.

1. Fuente. Incluye fuente y lo que sea. Excluye el directorio / build /. Use esto solo para control de fuente. Esto nunca va al sitio web (puede no ser seguro almacenar su código en el sitio web, incluso en la forma de un repositorio git).

2. Despliegue. Solo el directorio / build /. Puede iniciar un nuevo repositorio git dentro del directorio. Esto tiene un repositorio remoto en el servidor; puede utilizar el enlace posterior a la recepción para desplegar, como antes.

Answer 4

Yo uso git para la implementación todo el tiempo. No hay nada raro en eso, y no sé qué tiene @cido en contra. Hay un gran valor en poder retroceder en el tiempo a cualquier punto de su sucursal de ''despliegue'' y poder ver con precisión qué era en vivo en su servidor en ese momento.

No confunda el repositorio de git que está usando para el almacenamiento versus el que está usando para la implementación. Debería tener un árbol de git completamente limpio en su área de producción (sea lo que sea) y, como sugerí, querrá tener una sucursal separada llamada "despliegue" o "producción" o "puesta en escena" o lo que sea.

Su gancho posterior a la recepción solo necesita ejecutar un script que vaya a su área de producción y extraiga su rama de implementación para actualizar.

Si necesita que esto sea sólido para que no se coloquen archivos allí fuera de lo que hará git (por ejemplo, los archivos temporales generados en tiempo de ejecución), es posible que desee llamar a git clean -dfx antes de tirar. Y hay otras cosas que puede hacer si espera que este servidor se reconstruya desde cero regularmente (por ejemplo, en una implementación en la nube) pero parece que hacer la configuración inicial manualmente debería estar bien para su caso de uso. .

cp colocar el directorio de compilación en su lugar suena bien, solo usaría rsync porque generalmente será más rápido si los cambios son solo incrementales.