Utiliser git pour gérer un site Web de production?

Question

J'ai un site web avec environ 15 000 fichiers sur un serveur de production. Un développeur distant effectue maintenant la plus grande partie du travail sur le site, mais j'ai parfois besoin de faire quelques modifications. Il est évident que nous avons besoin d'un contrôle de version, et donc j'essaie de mettre en place git. Je voudrais vraiment garder la configuration simple et directe. Nous n'avons besoin d'aucune sorte d'intégrateur pour examiner nos changements - nous sommes tous deux entièrement dignes de confiance pour apporter des changements au site de production. Je ne vois pas non plus la nécessité de pousser les modifications à un serveur de transfert avant de les mettre en ligne, car nous ne pouvons rien tester sur nos machines locales. Je veux simplement quelque chose qui nous empêchera de nous tabasser les uns les autres. Voici le scénario que j'ai à l'esprit:

  Production Server 
       ↗↙ ↖↘   
Developer1(LAMP) Developer2(WAMP) 

Questions:

1. Est-ce que ce flux de travail de sens pour une équipe de deux développeurs (dont ne fait que des modifications ponctuelles) ou y at-il de meilleurs ?

2. Y a-t-il un avantage à ajouter un serveur de stockage intermédiaire entre les développeurs et le serveur de production? Je suppose que le serveur de production doit être un simple repo avec un pointage post-réception pointant vers le dossier webroot, que nous clonons une copie sur la machine de chaque développeur, puis git commit/git push pour lancer les modifications à la production?

3. Existe-t-il un moyen simple de créer un repo nu sur le serveur de production et d'y ajouter les 15 000 fichiers existants du site? Ou dois-je les télécharger dans le repo de clones sur mon poste de travail local, puis faire git add/commit/push pour les charger dans le repo du serveur de production? (Ils pourraient prendre près de 13 heures à télécharger.)

Merci!

Answer 1

Rien à redire sur le flux de travail, en soi. Mais généralement le référentiel "canonique" est séparé, et vous déployez sur votre serveur de production manuellement avec un autre mécanisme comme rsync. De cette façon:

1. Vos mises à jour de serveur de production ne sont pas liées à votre flux de travail de développement. Si votre serveur de production (jamais!) A besoin d'un travail après un changement de code - redémarrer le serveur web, vider le cache, faire un changement de schéma, etc. - alors soudainement le système de production interfère avec votre capacité à mettre à jour le code.

2. Vous n'avez pas à vous inquiéter d'un accès accidentel à votre répertoire .git et à l'exposition de tout votre code source et de l'historique de développement.

3. Il faut deux accidents pour casser le site (ruin master et deploy) au lieu d'un seul (ruin master).

4. Peut-être pas un problème avec vous deux, mais il est utile d'avoir le bouton "mettre à jour le site" ont une autorisation différente de celle du bouton "mettre à jour le code".

Les serveurs de stockage existent pour être similaires à la production, mais peuvent être cassés.Vous n'avez que deux développeurs, mais vous utilisez déjà des systèmes d'exploitation très différents; Je suis assez certain au moins un de vous n'utilise pas un environnement de développement identique à la production. :)

Et non, vous ne pouvez pas ajouter de fichiers à un référentiel nu. Vous avez besoin d'une copie de travail pour faire n'importe quoi avec l'arbre de travail.