Git per siti Web / post-ricezione / Separazione dei siti di test e di produzione

Question

Sto utilizzando Git per gestire il codice sorgente e la distribuzione del mio sito Web e attualmente ho i siti di test e quelli live in esecuzione sulla stessa macchina.Seguendo questa risorsa http://toroid.org/ams/git-website-howto originariamente, ho creato il seguente script di hook post-ricezione per distinguere tra push al mio sito live e push al mio sito di prova:

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"

Tuttavia, dubito che questo sia effettivamente sicuro :) Non sono affatto un esperto di Git, ma immagino che Git probabilmente tenga traccia dell'attuale testata del ramo estratto, e questo approccio probabilmente ha il potenziale per confonderlo senza fine.

Quindi alcune domande:

1. E' sicuro?

2. Un approccio migliore sarebbe quello di fare in modo che il mio repository di base sia il repository del sito di test (con la directory di lavoro corrispondente) e quindi fare in modo che il repository invii le modifiche a un nuovo repository del sito live, che ha una directory di lavoro corrispondente alla base del sito live?Ciò mi consentirebbe anche di spostare la produzione su un server diverso e mantenere intatta la catena di distribuzione.

3. C'è qualcosa che mi sfugge?Esiste un modo diverso e pulito per distinguere tra distribuzioni di test e di produzione quando si utilizza Git per la gestione dei siti Web?

Come nota aggiuntiva alla luce della risposta di Vi, esiste un buon modo per gestire le eliminazioni senza interferire troppo con il file system?

Grazie, -walt

PS: lo script che ho ideato per i repository multipli (e che sto utilizzando a meno che non senta meglio) è il seguente:

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 poi il repository in ../Live/$sitename (questi sono repository "nudi" con alberi funzionanti aggiunti dopo init) ha la post-ricezione di base:

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

  

Sarebbe un approccio migliore è quello di avere il mio   repository di base sia il sito di prova   repository (con corrispondente lavoro   directory), e poi che   spinta repository si trasforma in una nuova vivo   repository sito, che ha una   corrispondente directory di lavoro alla   Base sito live? Ciò consentirebbe anche   mi trasferisca la produzione ad un   altro server e mantenere la   catena di distribuzione intatta.

Sì, sicuramente. Si tratta di un'occasione molto rara volete che il vostro sito di prova ospitato proprio accanto al tuo sito di produzione. E 'pericoloso e poco professionale in quasi ogni punto di vista, per non parlare di corruzione del database, server web blocchi ecc

Io di solito hanno una configurazione VM a scopo di test. Funziona molto bene e posso avere con me sul mio portatile durante il viaggio.

Utilizzando git di rilasciare il sito è una buona idea, ci sono un sacco di altre persone farlo (ad esempio Rob Conery). Se vi capita di avere un sito vivo e test in ogni caso, si dovrebbe avere rami separati per loro nel vostro repository, set-up come a distanza di tracciamento rami sulle corrispondenti repository del server. Il flusso di lavoro diventa facile come fare il lavoro nella vostra filiale di prova, spingere al test, test di esso, si fondono per vivere e spingere dal vivo.

Onestamente, non rendono troppo difficile per te stesso.

Answer 2

Pensa che entrambi i modi funzioneranno.

Puoi anche utilizzare "git archive master | tar -C c:/temp/BLAH -x" e "git archive live-site | ssh live-site 'tar -C /var/www -x'".

Mantenere repository separati può essere utile, ma "push inside another hook relativo al push" sembra complicato e mi aspetto che sia lento.Una sorta di catena lunga che sarà lenta e fragile.

È possibile che gli aggiornamenti live del sito debbano essere attivati ​​manualmente dopo aver testato la versione "di prova"?

Answer 3

Ho anche seguito la stessa guida a toroid.org, ma vorrei sottolineare che, anche se si è iniziato con un repository nuda, con l'aggiunta di una directory di lavoro, molto probabilmente sarà necessaria la manipolazione supplementare. Ho trovato che il seguente gancio è utile se si dispone di contenuti che possono cambiare dinamicamente o in altro modo e non si desidera i dati perdono quando si utilizza git checkout -f

pre-ricevere

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

Questo si fermerà una spinta se ci sono cambiamenti nella directory di lavoro remota. Pensate a come qualcuno (il server web) di apportare modifiche, ma dimenticando di commetterli. Uso checkout con la -f scarterà tali modifiche. Questo gancio è un buon posto per evitare che ciò accada, ma sarebbe bello se ci fosse anche un gancio chiamato sul server remoto prima di un tiro in modo che si desidera ricevere questi cambiamenti senza soluzione di continuità.

post-ricezione

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

Per quanto riguarda avere due rami, ho pensato che la prima soluzione era più elegante di avere a che fare con più repository. Se davvero si vuole mantenere il vostro sito di produzione isolato, si potrebbe usare rsync a livello locale, che ha simili delta patch. Avrei un test e ramo stabile nel repository con solo il sito di test come la directory di lavoro. Quando si è pronti a rilasciare unire il test nel ramo stabile, spingere, e hanno un gancio alla ricerca di commit ramo stabile effettuare la chiamata a rsync.