Git pour les sites Web / post-réception / Séparation des sites test et de production
-
25-09-2019 - |
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:
-
Est-ce sécuritaire?
-
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.
-
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
La solution
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.
Autres conseils
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"?
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.