Les meilleures pratiques de mise à jour d'un site Web

Question

actuellement mon flux de travail est la suivante:

localement sur une machine que je maintiens un git sur chaque site je travaille, quand vient le temps de publier quelque chose que je Comprimer le dossier et télécharger ce fichier unique sur le serveur de production via ssh puis je décompresse, tester les changements d'un mouvement les changements dans le dossier en direct et je me débarrasse du dossier .git. Je me demandais si l'utilisation d'un repo git sur le serveur live était une bonne idée, semble être au début, mais il peut être problématique si une modification ne semble pas la même sur le serveur de production par rapport à la machine de développement local ... cela pourrait déclencher un feu ... Qu'en est-il de la création d'un repo nu sur un dossier sur le serveur de production puis clonage de là vers le dossier public poussant ainsi les mises à jour de la machine locale vers le repo nu nue sur le dossier public du serveur de production ... que quelqu'un puisse fournir des commentaires.

Plus tard, je lu sur Capistrano http://capify.org mais je n'ai aucune expérience w/ce logiciel ...

votre expérience, quelle est la meilleure pratique/méthodologie pour réaliser un déploiement de site/mises à jour?

Merci d'avance et pour vos commentaires.

Answer 1

Je n'avais jamais pensé à avoir une copie de référentiel sur le serveur. Après l'avoir lu, j'ai pensé que ça pourrait être cool ... Cependant, mettre à jour les fichiers directement dans l'environnement en direct sans test n'est pas une bonne idée.

Vous devez toujours mettre à jour un environnement secondaire correspondant exactement le live (serveur Web + version DB, le cas échéant) et tester là. Si tout se passe bien, mettez le site en ligne sous maintenance, mettez à jour les fichiers et revenez en direct. Donc, je ne voudrais pas faire du site en ligne une copie du dépôt, mais vous pourriez le faire avec le test env. Vous économiserez le temps de compression SSH +, plus vous pouvez vérifier toute révision spécifique que vous souhaitez tester.

Answer 2

Je ne pense pas que notre méthode puisse être qualifiée de meilleure pratique, mais elle nous a bien servis. Nous avons plusieurs grandes bases de données pour notre application (20gb +), donc le maintien de copies locales sur chaque ordinateur des développeurs n'a jamais vraiment été une option, et même si nous ne développons pas contre la base de données en direct, nous devons faire la le développement d'une base de données aussi proche que possible de la réalité. En conséquence, nous utilisons aussi un serveur web central, et nous y conservons une branche de développement de notre tronc subversion. Généralement, nous ne travaillons pas sur la même partie du système à la fois, mais quand nous avons besoin de le faire, ou que quelqu'un apporte beaucoup de changements substantiels, nous branchons le tronc et créons un nouveau serveur virtuel sur le serveur de développement.

Nous avons également une vérification du code sur les serveurs de production, donc après que nous ayons fini de tester, nous faisons simplement une mise à jour svn sur les serveurs de production. Nous avons implémenté un script qui exécute la commande update sur tous les serveurs utilisant ssh. Ceci est extrêmement pratique, car notre base de code est grande et prend beaucoup de temps à télécharger. Subversion ne copiera que les fichiers qui ont été modifiés, donc c'est beaucoup plus rapide. Cela a très bien fonctionné pour nous, et la seule chose à surveiller est de faire des changements sur les serveurs de production directement (ce qui est bien sûr un non-non depuis le début) car cela pourrait provoquer des conflits lors de la mise à jour.

Answer 3

Capistrano est génial. Les recettes par défaut La documentation est inégale, mais la liste de diffusion est active, et la mise en place est assez facile. Courez-vous Rails? Il a quelques trucs bien intégrés pour les applications Rails, mais est également utilisé assez fréquemment avec d'autres types de webapps.

Il y a aussi Webistrano, qui est basé sur Capistrano mais a une interface web. Je ne l'ai pas utilisé moi-même. Un autre système de déploiement qui semble gagner du terrain, au moins parmi les utilisateurs de Rails, est Vlad the Deployer.