Git para sites / pós-recebimento / separação de sites de teste e produção

Question

Estou usando o GIT para gerenciar o código e a implantação do meu site e atualmente tenho os sites de teste e vivos em execução na mesma caixa. Seguindo este recurso http://toroid.org/ams/git-website-owto Originalmente, criei o seguinte script de gancho pós-recebimento para diferenciar os empurrões para o meu site ao vivo e empurrar para o meu site de teste:

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"

No entanto, tenho dúvidas de que isso é realmente seguro :) Não sou especialista em git, mas acho que o GIT provavelmente acompanha a atual cabeça do ramo check-out, e essa abordagem provavelmente tem o potencial de confundi-la para nenhum fim.

Então, algumas perguntas:

1. Isso é seguro?

2. Uma abordagem melhor seria fazer com que meu repositório base fosse o repositório do site de teste (com o diretório de trabalho correspondente) e, em seguida, termos esse repositório de alterações em um novo repositório de sites ao vivo, que possui um diretório de trabalho correspondente para a base do site ao vivo? Isso também me permitiria mover a produção para um servidor diferente e manter intacta a cadeia de implantação.

3. Tem algo que estou perdendo? Existe uma maneira diferente e limpa de diferenciar entre as implantações de teste e produção ao usar o GIT para gerenciar sites?

Como uma nota adicional à luz da resposta de VI, existe uma boa maneira de fazer isso que lide muito com as exclusões sem mexer muito com o sistema de arquivos?

Obrigado, -walt

PS - O script que eu criei para os vários repositórios (e estou usando a menos que ouço melhor) é o seguinte:

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"

E então o repo em ../live/$sitename (estes são repositórios "vazios" com árvores de trabalho adicionadas após o init) tem o pós-recepção básico:

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

Uma abordagem melhor seria fazer com que meu repositório base fosse o repositório do site de teste (com o diretório de trabalho correspondente) e, em seguida, termos esse repositório de alterações em um novo repositório de sites ao vivo, que possui um diretório de trabalho correspondente para a base do site ao vivo? Isso também me permitiria mover a produção para um servidor diferente e manter intacta a cadeia de implantação.

Sim definitivamente. É uma ocasião muito rara que você deseja que seu site de teste seja hospedado ao lado do seu site de produção. É perigoso e pouco profissional em quase todos os aspectos, não falar sobre corrupção do banco de dados, trava do servidor da web etc.

Normalmente, tenho uma configuração de VM para fins de teste. Funciona muito bem e eu posso tê -lo comigo no meu laptop enquanto viaja.

Usar o Git para implantar seu site é uma ideia muito boa, há muitas outras pessoas fazendo isso (por exemplo, Rob Conery). Se você tiver um site de testes e ativo, de qualquer maneira, você deve ter ramos separados para eles no seu repositório, configurado como ramificações de rastreamento remoto nos repositórios de servidores correspondentes. Seu fluxo de trabalho se torna tão fácil quanto trabalhar na sua filial de teste, pressioná -lo para testar, testá -lo, fundir -se para viver e empurrar ao vivo.

Honestamente, não fique muito difícil para si mesmo.

Answer 2

Pense que ambos os lados funcionarão.

Você também pode usar "Git Archive Master | TAR -C C:/temp/blah -x" e "Git Archive Live -site | ssh -ssh -site 'tar -c/var/www -x'".

Manter os repositórios separados pode ser útil, mas "empurrar dentro de outro gancho relacionado ao push" parece complicado e espero que seja lento. Tipo de cadeia longa que será lenta e frágil.

Pode ser que as atualizações do site ao vivo devem ser acionadas manualmente após o teste da versão "Testing"?

Answer 3

Também segui o mesmo guia em toroid.org, mas gostaria de observar que, embora você tenha começado com um repositório nu, adicionando um diretório de trabalho, provavelmente será necessário um manuseio extra. Descobri que o gancho a seguir é útil se você tiver conteúdo que pode mudar dinamicamente ou não e não quiser perder dados ao usar git checkout -f

pré-recebimento

#!/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

Isso interromperá um empurrão se houver alterações no diretório de trabalho remoto. Pense nisso como alguém (o servidor da web) fazendo alterações, mas esquecendo de comprometi -las. Usando checkout com o -f descartará essas mudanças. Esse gancho é um bom lugar para impedir que isso aconteça, mas seria bom se também houvesse um gancho chamado no servidor remoto antes de uma tração, para que você recebesse essas alterações perfeitamente.

pós-recepção

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

Em relação a ter duas filiais, pensei que sua primeira solução era mais elegante do que ter que lidar com vários repositórios. Se você realmente deseja manter o site de produção isolado, pode usar o RSYNC localmente, que possui patches delta semelhantes. Eu teria uma ramificação de teste e estável no repositório apenas com o site de teste como diretório de trabalho. Quando estiver pronto para liberar, mesclar os testes no ramo estável, empurre e tenha um gancho procurando commits to estável, faça a chamada para o RSYNC.