2009-10-11 9 views
3

Quels outils et procédures recommanderiez-vous ou vous utiliser pour aider à rationaliser le sceanario suivant: (Je sais que longue, mais toute aide est appréciée)Outils et méthodes

Je travaille dans une équipe qui ont une application de commerce électronique que nous développons chez nous. C'est une application LAMP raisonnablement standard que nous développons depuis et vers 3 ans. Nous développons l'application sur un domaine de test, ici nous ajoutons de nouvelles fonctionnalités et corrigeons des bugs etc. Notre suivi de bogues et le développement de fonctionnalités sont tous gérés dans une solution de subversion hébergée (unfuddle.com). Au fur et à mesure que des bogues sont signalés, nous faisons ces corrections sur le domaine de test, puis nous validons les modifications de svn quand nous sommes heureux que le bogue ait été corrigé. Nous suivons cette même procédure avec l'ajout de nouvelles fonctionnalités.

Il convient de souligner l'architecture générale de notre système et de notre application sur nos serveurs. Chaque fois qu'une nouvelle fonctionnalité est développée, nous déployons cette mise à jour sur tous les sites utilisant notre application (toujours un serveur que nous contrôlons). Chaque site utilisant notre système utilise essentiellement exactement les mêmes fichiers pour 95% de la base de code. Nous avons quelques dossiers dans chaque site qui contiennent des fichiers sur mesure à ce site - fichiers CSS/images, etc. Autrement, les différences entre chaque site sont définies par divers paramètres de configuration dans la base de données de chaque site.

Ceci aboutit au déploiement proprement dit. Au fur et à mesure que nous sommes prêts à déployer une mise à jour, nous exécutons une commande sur le serveur sur lequel le site de test est activé. Ceci exécute une commande de copie (cp -fru/testsite// otherite /) et passe par chaque force vhost mettant à jour les fichiers en fonction de la date de modification. Chaque serveur additionnel sur lequel nous hébergeons a un vhost que nous avons rsync la base de code de production et nous répétons ensuite la procédure de copie sur tous les sites sur ce serveur. Au cours de ce processus, nous déplaçons les fichiers que nous ne voulons pas être écrasés, en les déplaçant lorsque la copie est terminée. Notre script de déploiement remplit un certain nombre d'autres fonctions telles que l'application de commandes SQL pour modifier chaque base de données, ajouter des champs/nouvelles tables, etc.

Nous sommes de plus en plus préoccupés par le fait que notre processus n'est pas assez stable, tolérant aux pannes et aussi un peu d'une méthode de force brute. Nous sommes également conscients que nous n'utilisons pas au mieux Subversion car nous avons une position où travailler sur une nouvelle fonctionnalité nous empêcherait de déployer une correction de bogue importante car nous n'utilisons pas de branches ou de balises. Il semble également erroné que nous ayons tellement de réplication de fichiers sur nos serveurs. Nous ne sommes pas non plus en mesure d'effectuer facilement un retour en arrière sur ce que nous venons de déployer. Nous effectuons un diff avant chaque déploiement afin que nous puissions obtenir une liste de fichiers qui seront modifiés afin que nous sachions ce qui a été modifié après, mais le processus de restauration serait toujours problématique. En termes de base de données, j'ai commencé à chercher dans dbdeploy comme solution potentielle. Ce que nous voulons vraiment cependant, c'est quelques conseils généraux sur la façon dont nous pouvons améliorer la gestion et le déploiement de nos fichiers. Idéalement, nous souhaitons que la gestion des fichiers soit plus étroitement liée à notre référentiel afin qu'un rollout/rollback soit plus connecté à svn. Quelque chose comme utiliser la commande export pour s'assurer que les fichiers du site sont les mêmes que les fichiers repo. Il serait également bon que la solution arrête la réplication de fichiers autour de nos serveurs. En ignorant nos méthodes actuelles, il serait vraiment bon d'entendre comment d'autres personnes abordent le même problème.

pour résumer ...

Quelle est la meilleure façon de faire des fichiers sur plusieurs serveurs rester synchronisés avec svn?

Comment devrions-nous empêcher la réplication de fichiers? liens symboliques/autre chose?

Comment devrions-nous structurer notre repo afin que nous puissions développer de nouvelles fonctionnalités et réparer les anciennes?

Comment devrions-nous déclencher les rollouts/rollbacks?

Merci d'avance.

Répondre

4

Pour rollback et tester de nouvelles fonctionnalités, les concepts de subversion standard des branches et des balises doivent être suffisantes:

  • toujours créer une étiquette avant le déploiement et déploiement cette étiquette. Rollback signifierait alors revenir à l'étiquette précédente.
  • développer de nouvelles fonctionnalités dans les branches et fusionner au tronc une fois terminé; alternativement, développer de nouvelles fonctionnalités dans le tronc, et avoir une branche de maintenance qui ne reçoit que des corrections de bogues.
  • conservez les fichiers par site dans des répertoires distincts dans subversion et utilisez un fichier de configuration sur chaque site ou un lien symbolique pour que les sites renvoient à leurs fichiers spécifiques.

Pour réduire la duplication de fichiers, je recommande d'utiliser NFS (en particulier lorsque tous les sites sont des machines virtuelles sur le même hôte - faire l'hôte du serveur NFS, et les sites clients NFS, ou alternativement, faire un dédié VM le serveur NFS). Pour déployer une mise à jour, installez uniquement les nouveaux fichiers sur le serveur NFS; les clients vont ramasser les changements automatiquement.

Si vous avez besoin d'une mise à jour en plusieurs étapes (par exemple mettre à jour les bases de données dans chaque client, puis mettre à jour le code), vous devez toujours utiliser NFS, mais ajouter des liens symboliques. Extrayez le nouveau code dans un répertoire distinct sur le serveur NFS, puis accédez à toutes les machines virtuelles, mettez à jour les bases de données et modifiez le lien symbolique dans la machine virtuelle pour pointer vers le nouveau code. Lorsque vous avez terminé, supprimez l'ancien code sur le serveur NFS.

0

vous pouvez regarder cet article qui couvre le déploiement des applications PHP. http://blog.digitalstruct.com/2009/10/07/deployments-php-applications/

Plus précisément, il mentionne quelques outils qui pourraient aider:

  1. Phing
  2. Ant
  3. Liquibase
  4. DbDeploy

J'ai aussi entendu quelques personnes parler en utilisant capistrano donc vous pourriez vouloir regarder cela aussi.

EDIT:

de regarder ce sondage http://twtpoll.com/3zwfox il semble que l'exportation SVN est une méthode commune dans la communauté pour déployer des applications PHP. Ce sondage semble avoir été utilisé dans cette présentation slideShare http://www.slideshare.net/ccornutt/taming-the-deployment-beast

Questions connexes