Git pour les sites Web / post-réception / Séparation des sites test et de production

Question

J'utilise Git pour gérer le code source de mon site et le déploiement, et actuellement le test et les sites en direct en cours d'exécution sur la même case. Suite à cette ressource http://toroid.org/ams/git-website-howto A l'origine, je suis venu avec le script de crochet après réception suivant pour différencier les pousse à mon site en direct et pousse sur mon site de test:

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"

Cependant, je doute que ce soit réellement sûr :) Je suis en aucun cas un expert Git, mais je devine que Git garde probablement la trace de la tête en cours de branche check-out, et cette approche a probablement le potentiel de le confondre sans fin.

Alors quelques questions:

1. Est-ce sécuritaire?

2. serait une meilleure approche d'avoir mon dépôt de base soit le dépôt de site d'essai (avec répertoire de travail correspondant), et alors que les changements de poussée du référentiel vers un nouveau référentiel de site en direct, qui a un répertoire de travail correspondant au base de site en direct? Cela me permettra aussi de transférer la production vers un autre serveur et de garder la chaîne de déploiement intact.

3. Y at-il quelque chose que je suis absent? Y at-il une autre façon, propre à différencier les déploiements de test et de production lors de l'utilisation Git pour la gestion de sites Web?

Comme une note supplémentaire à la lumière de la réponse de Vi, est-il une bonne façon de le faire qui traiterait des suppressions sans déblayage avec le système de fichiers bien?

Merci, -Walt

PS - Le script que je suis venu avec pour les multiples prises en pension (et je utilise à moins que j'entends mieux) est la suivante:

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"

Et puis la prise en pension à ../Live/$sitename (ces sont des prises en pension « nus » avec des arbres de travail ajoutés après init) a base après réception:

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

  

serait une meilleure approche d'avoir mon   dépôt de base soit le site de test   référentiel (avec travail correspondant   répertoire), et alors que   dépôt les modifications au nouveau direct   dépôt de site, qui a une   répertoire de travail correspondant au   base de site en direct? Cela permettrait également   moi de passer la production à un   serveur différent et de garder la   chaîne déploiement intact.

Oui certainement. Il est une occasion très rare que vous voulez que votre site de test hébergé juste à côté de votre site de production. Il est dangereux et non professionnelle dans presque tous les égards, sans parler de la corruption de base de données, etc. verrouillages webserver

Je n'ai généralement une configuration VM à des fins de test. Fonctionne très bien et je peux l'avoir avec moi sur mon ordinateur portable en voyage.

Utilisation de git pour déployer votre site web est une très bonne idée, il y a beaucoup d'autres personnes le faire (par exemple Rob Conery). Si vous arrive d'avoir un site en direct et les tests de toute façon, vous devriez avoir des branches séparées pour eux dans votre dépôt, mise en place en tant que branches de suivi à distance sur les dépôts de serveur correspondant. Votre flux de travail devient aussi facile que de faire le travail dans votre branche de test, pousser à tester, tester, fusionner pour vivre et pousser en direct.

Honnêtement, ne faites pas trop dur pour vous-même.

Answer 2

Pensez que les deux façons fonctionneront.

Vous pouvez également utiliser "maître archives git | tar C c: / temp / BLA -x". Et "archives git en direct site | ssh en direct site 'tar C / var / www -x'"

Garder les dépôts séparés peuvent être utiles, mais « pousser dans un autre crochet lié push- » regarde délicate et je pense qu'il est lent. Une sorte de longue chaîne qui sera lente et fragile.

Peut être mises à jour en direct du site doivent être déclenchées manuellement après avoir testé la version "testing"?

Answer 3

J'ai également suivi le même guide à toroid.org, mais je voudrais noter que même si vous avez commencé avec un dépôt nu, en ajoutant un répertoire de travail, la manutention supplémentaire sera probablement nécessaire. Je trouve que le crochet est utile si suivante vous avez du contenu qui peut changer de façon dynamique ou autrement et ne veulent pas perdre des données lors de l'utilisation git checkout -f

pré-réception

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

Cela arrêtera une poussée s'il y a des changements dans le répertoire de travail à distance. Pensez-y comme une personne (le serveur web) apporter des changements, mais en oubliant de les commettre. En utilisant checkout avec le -f annulera ces changements. Ce crochet est un bon endroit pour éviter que cela se produise, mais ce serait bien s'il y avait aussi un crochet appelé sur le serveur distant avant une traction afin que vous recevriez ces changements de façon transparente.

post-recevoir

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

En ce qui concerne ont deux branches, je pensais que votre première solution était plus élégante que d'avoir à traiter avec de multiples référentiels. Si vous voulez vraiment garder votre site de production isolé, vous pouvez utiliser rsync localement qui a patcher delta similaire. J'aurais un essai et branche stable dans le référentiel avec seulement le site de test que le répertoire de travail. Lorsque vous êtes prêt à libérer fusionner les tests dans la branche stable, poussée, et un crochet à la recherche de commits branche stable font l'appel à rsync.