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 ejecutándose en el mismo cuadro.Siguiendo este recurso http://toroid.org/ams/git-website-howto Originalmente, se me ocurrió el siguiente script de enlace posterior a la recepción para diferenciar entre envíos a mi sitio en vivo y envíos 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, tengo dudas de que esto sea realmente seguro :) De ninguna manera soy un experto en Git, pero supongo que Git probablemente realiza un seguimiento del encabezado de rama actual, y este enfoque probablemente tiene el potencial de confundirlo. sin fin.

Entonces algunas preguntas:

1. ¿ES esto seguro?

2. ¿Un mejor enfoque sería que mi repositorio base fuera el repositorio del sitio de prueba (con el directorio de trabajo correspondiente) y luego hacer que ese repositorio envíe los cambios a un nuevo repositorio del sitio en vivo, que tenga un directorio de trabajo correspondiente a la base del sitio en vivo?Esto también me permitiría trasladar la producción a un servidor diferente y mantener intacta la cadena de implementación.

3. ¿Se me escapa algo?¿Existe una manera diferente y limpia de diferenciar entre implementaciones de prueba y de producción cuando se usa Git para administrar sitios web?

Como nota adicional a la luz de la respuesta de Vi, ¿existe una buena manera de hacer esto que maneje las eliminaciones sin alterar mucho el sistema de archivos?

Gracias, -walt

PD: el script que se me ocurrió para los múltiples repositorios (y que estoy usando a menos que escuche 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 luego el repositorio en ../Live/$sitename (estos son repositorios "básicos" con árboles funcionales agregados después de init) tiene la recepción posterior básica:

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

¿Sería un mejor enfoque tener mi El repositorio base será el sitio de prueba repositorio (con el correspondiente trabajo directorio), y luego tener ese directorio cambios de inserción de repositorio en un nuevo archivo en vivo repositorio del sitio, que tiene un repositorio directorio de trabajo correspondiente al directorio de trabajo ¿Base del sitio en vivo?Esto también permitiría para trasladar la producción a un servidor diferente y mantener el cadena de despliegue intacta.

Sí definitivamente.Es muy rara la ocasión en la que desea que su sitio de prueba esté alojado 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 VM para realizar pruebas.Funciona muy bien y puedo tenerlo conmigo en mi computadora portátil mientras viajo.

Usar git para implementar su sitio web es una muy buena idea, hay muchas otras personas que lo hacen (p. ej.Rob Conery).Si de todos modos tiene un sitio activo y de prueba, debe tener ramas separadas para ellos en su repositorio, configuradas como ramas de seguimiento remoto en los repositorios del servidor correspondiente.Su flujo de trabajo se vuelve tan fácil como trabajar en su rama de prueba, enviarlo para probarlo, probarlo, fusionarlo para vivir y publicarlo.

Honestamente, no te lo pongas demasiado difícil.

Answer 2

Piensa que ambas maneras funcionarán.

También puede utilizar "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 "insertar dentro de otro gancho relacionado con la inserción" parece complicado y espero que sea lento.Una especie de cadena larga que será lenta y frágil.

¿Es posible que las actualizaciones del sitio en vivo deban activarse 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 comenzaste con un repositorio básico, al agregar un directorio de trabajo, lo más probable es que necesites manejo adicional.Descubrí que el siguiente enlace es útil si tiene contenido que puede cambiar dinámicamente o de otra manera y no desea perder datos al usarlo. git checkout -f

pre-recibir

#!/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 detendrá el envío si hay cambios en el directorio de trabajo remoto.Piense en ello como si alguien (el servidor web) hiciera cambios pero se olvidara de confirmarlos.Usando checkout con el -f descartará esos cambios.Este enlace es un buen lugar para evitar que esto suceda, pero sería bueno si también se llamara a un enlace en el servidor remoto antes de realizar una extracción para que pueda recibir estos cambios sin problemas.

post-recibir

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

En cuanto a tener dos ramas, pensé que su primera solución era más elegante que tener que lidiar con múltiples repositorios.Si realmente desea mantener aislado su sitio de producción, puede 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 directorio de trabajo.Cuando esté listo para lanzar, combine las pruebas en la rama estable, presione y haga que un gancho busque confirmaciones en la rama estable y realice la llamada a rsync.