Git para sitios web/post-recepción/separación de sitios de prueba y producción

Question

Estoy usando Git para administrar el código fuente y la implementación de mi sitio web, y actualmente tengo los sitios de prueba y en vivo en la misma casilla. A raíz de este recurso http://toroid.org/ams/git-website-howto originalmente, se me ocurrió la siguiente secuencia de comandos posterior a recibir el gancho para diferenciar entre empuja a mi sitio vivo y empuja a mi sitio de prueba:

while read ref 
do 
    #echo "Ref updated:" 
    #echo $ref -- would print something like example at top of file 
    result=`echo $ref | gawk -F' ' '{ print $3 }'` 
    if [ $result != "" ]; then 
    echo "Branch found: " 
    echo $result 
    case $result in 
     refs/heads/master) 
     git --work-tree=c:/temp/BLAH checkout -f master 
     echo "Updated master" 
     ;; 
     refs/heads/testbranch) 
     git --work-tree=c:/temp/BLAH2 checkout -f testbranch 
     echo "Updated testbranch" 
     ;; 
     *) 
     echo "No update known for $result" 
     ;; 
    esac 
    fi 
done 
echo "Post-receive updates complete" 

Sin embargo, no tengo dudas de que esto es realmente segura:) De ninguna manera soy un experto en Git, pero supongo que Git probablemente realiza un seguimiento de la rama actual de la ramificación, y este enfoque probablemente tiene el potencial de confundirlo sin fin.

Así que un par de preguntas:

1. Es esto seguro?

2. ¿Sería mejor tener mi repositorio base como el repositorio del sitio de prueba (con el directorio de trabajo correspondiente) y luego hacer que el repositorio cambie a un nuevo repositorio de sitios en vivo, que tenga un directorio de trabajo correspondiente al vivo base del sitio? Esto también me permitiría mover la producción a un servidor diferente y mantener intacta la cadena de implementación.

3. ¿Hay algo que me falta? ¿Existe una forma diferente y clara de diferenciar entre implementaciones de prueba y producción cuando se usa Git para administrar sitios web?

Como una nota adicional a la luz de la respuesta de Vi, ¿hay una buena manera de hacer esto que se ocuparía de deleciones sin ensuciar con el sistema de archivos tanto?

Gracias, -Walt

PS - El guión que se le ocurrió para los múltiples repositorios (y estoy usando menos que oír mejor) es el siguiente:

sitename=`basename \`pwd\`` 

while read ref 
do 
    #echo "Ref updated:" 
    #echo $ref -- would print something like example at top of file 
    result=`echo $ref | gawk -F' ' '{ print $3 }'` 
    if [ $result != "" ]; then 
    echo "Branch found: " 
    echo $result 
    case $result in 
     refs/heads/master) 
     git checkout -q -f master 
     if [ $? -eq 0 ]; then 
      echo "Test Site checked out properly" 
     else 
      echo "Failed to checkout test site!" 
     fi 
     ;; 
     refs/heads/live-site) 
     git push -q ../Live/$sitename live-site:master 
     if [ $? -eq 0 ]; then 
      echo "Live Site received updates properly" 
     else 
      echo "Failed to push updates to Live Site" 
     fi 
     ;; 
     *) 
     echo "No update known for $result" 
     ;; 
    esac 
    fi 
done 
echo "Post-receive updates complete" 

Y entonces el repositorio en ../Live/$sitename (estos son repos "desnudos" con árboles de trabajo añadió después de init) tiene la básica después de la recepción:

git checkout -f 
if [ $? -eq 0 ]; then 
    echo "Live site `basename \`pwd\`` checked out successfully" 
else 
    echo "Live site failed to checkout" 
fi 

Answer 1

¿Un mejor enfoque es tener mi repositorio base sea el repositorio sitio de prueba (con el correspondiente trabajo directorio), y luego tener que repositorio de empuje cambia a una nueva vivo repositorio sitio, que tiene una correspondiente directorio de trabajo a la base de sitio en vivo ?Esto también me permitiría mover la producción a un servidor diferente y mantener intacta la cadena de implementación .

Sí definitivamente. Es muy raro que desee que su sitio de prueba se aloje justo al lado de su sitio de producción. Es peligroso y poco profesional en casi todos los aspectos, por no hablar de corrupción de bases de datos, bloqueos de servidores web, etc.

Normalmente tengo una configuración de máquina virtual para realizar pruebas. Funciona muy bien y puedo tenerlo conmigo en mi computadora portátil mientras viajo.

El uso de git para implementar su sitio web es una muy buena idea, hay muchas otras personas que lo hacen (por ejemplo, Rob Conery). Si de todos modos tiene un sitio en vivo y de prueba, debe tener sucursales separadas para ellos en su repositorio, configurado como sucursales de seguimiento remoto en los repositorios de servidor correspondientes. Su flujo de trabajo se vuelve tan fácil como hacer trabajo en su rama de prueba, presionarlo para probarlo, probarlo, fusionarlo para vivir y publicar en vivo.

Honestamente, no lo haga demasiado difícil para usted.

Answer 2

Piense que ambas formas funcionarán.

También puede usar "git archive master | tar -C c:/temp/BLAH -x" y "git archive live-site | ssh live-site 'tar -C/var/www -x'".

Mantener repositorios separados puede ser útil, pero "empujar dentro de otro gancho relacionado con el impulso" parece complicado y espero que sea lento. Tipo de cadena larga que será lenta y frágil.

¿Las actualizaciones del sitio en vivo pueden ser activadas manualmente después de probar la versión de "prueba"?

Answer 3

También seguí la misma guía en toroid.org, pero me gustaría señalar que aunque comenzó con un repositorio simple, al agregar un directorio de trabajo, es muy probable que necesite un manejo adicional. He descubierto que el siguiente gancho es útil si tiene contenido que puede cambiar de forma dinámica o de otra manera y no quieren perder los datos cuando se utiliza git checkout -f

pre-reciben

#!/bin/sh 
git add -A 
git diff --quiet --cached 
if [ $? -gt 0 ]; then 
    git commit --quiet -m "autocommit" 
    echo "Working Directory was out of sync. Pull to receive updated index." 
    exit 1 
fi 

Esto evitará que un empujón si hay son cambios en el directorio de trabajo remoto. Piénselo como alguien (el servidor web) que hace cambios pero se olvida de comprometerlos. El uso de checkout con -f descartará esos cambios. Este gancho es un buen lugar para evitar que esto ocurra, pero sería bueno si también hubiera un gancho llamado en el servidor remoto antes de tirar para que pueda recibir estos cambios sin problemas.

posterior a recibir

#!/bin/sh 
git checkout -f 
echo "Working directory synced." 

Respecto tiene dos ramas, pensé que su primera solución era más elegante que tener que lidiar con múltiples repositorios. Si realmente desea mantener su sitio de producción aislado, podría usar rsync localmente, que tiene parches delta similares. Tendría una rama estable y de prueba en el repositorio con solo el sitio de prueba como el directorio de trabajo. Cuando esté listo para lanzar fusionar la prueba en la rama estable, presione y tenga un gancho que busque comprometerse con una rama estable, realice la llamada a rsync.