J'utilise git pour suivre les changements locaux dans mes applications Web PHP et je me demandais si ce serait une bonne idée d'utiliser GIT sur le serveur, de sorte que je puisse simplement utiliser git push code > Déployer mes modifications. Y aurait-il des pièges avec cette approche? P>
6 Réponses :
Je pense que c'est une bonne façon de le faire. Je gère les choses de la même manière que les sites en direct ne sont qu'une reprise du référentiel, et je les mettez à jour si nécessaire. P>
+1. Cela rend les choses très agréables si vous souhaitez vérifier les modifications sur le serveur (tout ce que vous devez exécuter est une commande d'état à rechercher des fichiers nouveaux ou modifiés) ...
et les correctifs en ligne peuvent être repoussés au développement.
Être capable de faire un statut GIT code> sur un système en direct peut être un épargnant en direct. P>
Allez-y! P>
N'est-ce pas ce qu'est une étape QA? Donc, vous ne faites jamais de correctifs en ligne? Heck La plupart des endroits ne laissent même pas que leurs développeurs ont accès au serveur de production, mais seuls réparer les choses vivent ... (mais c'est un point valable sur les correctifs de soutien) ...
Parce qu'après la phase Q & A, le projet est toujours plus bugfree ...? Je veux le nom de la société qui fait votre Q & A;)
Non, mais parce que les correctifs de bugs sont tenus de passer par QA avant d'être mis en production (tenter d'éliminer la possibilité de régressions) ...
Cela semble être une bonne façon de faire des choses. Si vous marquez et que vous vous ramenez correctement, il vous permettra de revenir rapidement aux versions de travail de votre site également dans le cas où quelque chose se casse. P>
Je serais en faveur d'une technique comme celle-ci si seulement, car vous pouvez être sûr que tout sur votre site déployé est également en cours de suivi de GIT. C'est-à-dire qu'il encourage une meilleure pratique et décourage les changements ad hoc qui ne sont pas sous contrôle source. P>
Pour une autre alternative, consultez cet article sur la façon dont Twitter utilise BitTorrent pour gérer le déploiement: http://torrentfreak.com/Twitter-User-BitTorrent-for-Server-Deployment-100210/ C'est probablement le plus utile lorsque vous devez vous déployer rapidement sur une grande collection de serveurs. P>
Je pense que c'est une excellente solution. Je l'utilise pour déployer mon site Web depuis longtemps ... c'est agréable parce que vous pouvez presque instantanément pousser vos modifications à la production simplement en mettant à jour le dossier. J'ai rencontré des problèmes de sécurité ni quoi que ce soit avec elle. P>
profiter! p>
Git va bien mais vous pouvez faire beaucoup mieux, alors simplement utiliser Git Tirez. Jetez un coup d'œil à Railess Déployer pour Capistrano . P>
Capistrano essentiellement une combinaison de RSYNC et de GIT pour déployer des copies de votre site Web. Il prend en charge le roletage, la mise en scène et les déploiements distribués. P>
@BCAT: Merci pour la modification. Je ne sais pas comment j'ai raté celui-là.
Le piège extrêmement évident est que si vous appuyez sur un référentiel non nu, l'arbre de travail (les fichiers actuels) sera pas i> être mis à jour. Je ne peux pas croire qu'aucune des réponses ne mentionne que.
@Jefromi: Très vrai. En fait, j'étais vient de trouver une solution à cela.
Oui, c'est solvable, il suffit de le faire en savoir plus. Vous voudrez également configurer le repo pour permettre explicitement la poussée dans la branche actuelle, qui est refusée par défaut. Le paramètre de configuration est
recevoir.denycurrentbranch code>.