Comment mieux mettre à jour un site Web de subversion

Question

J'ai un site Web PHP soutenu par une base de données MySQL et une petite équipe de programmeurs soumettant du code à subversion. Généralement, nous écrivons du code, nous le testons localement, nous validons la subversion, puis nous copions les fichiers modifiés dans une zone cachée pour les tests en ligne.

Cependant, des erreurs peuvent être commises. Occasionnellement, je veux rafraîchir le site pour que je sache, sans aucun doute, que le code du site et la base de données représentent vraiment ce qu'il y a dans subversion. Je voudrais être le plus proche possible d'une solution en un clic pour que tout soit à toute épreuve.

Quelle est la meilleure façon de faire cela?

BTW, si c'est important, nous développons sur les machines Windows.

Answer 1

L'exportation peut être fait automatiquement après chaque commit avec un crochet post-commit:

http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.post-commit.html

Vous pouvez configurer le crochet pour exporter automatiquement le projet dans la zone cachée pour les tests en ligne.

Answer 2

Que diriez-vous de vérifier le code à l'endroit où vous voulez l'exécuter?

Answer 3

Je ne vous recommande pas de vérifier votre code sur votre serveur de production. Cela peut potentiellement exposer les fichiers de contrôle svn (.svn) sur le serveur.

Je recommande d'utiliser un script (python, ruby, etc.) combiné avec la ligne de commande svn et le client FTP pour exporter les fichiers de svn et ftp les fichiers vers le serveur. La commande svn export peut être utilisée pour extraire un ensemble de fichiers du serveur svn sans tous les répertoires .svn. De plus, n'oubliez pas d'étiqueter le référentiel svn lorsque vous faites cela afin d'avoir un point de contrôle de ce que vous avez déployé.

Answer 4

La gestion de version de code et la gestion de version de base de données sont deux problèmes très différents. La solution que je préfère est faite en trois étapes (Test, Test de déploiement, Live) plutôt que deux.

• Mise à jour du code et appliquer les modifications de la base de données via des scripts dans l'environnement de développement
• Télécharger la base de données en direct à un environnement de test de déploiement, restaurer et appliquer la modification des scripts
• Test du code contre la « synchronisée » base de données en direct
• Mise à jour le environnement en direct via svn de la branche concernée sur le référentiel (nous le faisons via un tunnel SSH car il est un environnement linux) et appliquer les scripts de modification de la db en direct

Éditer: La mise à jour de l'environnement en direct est mieux faite en utilisant l'exportation plutôt que la vérification/mise à jour. Cela ne laisse pas traîner le fichier de contrôle de svn. Cela peut avoir ou non des implications sur le plan de la sécurité, mais cela vous oblige à spécifier quelle branche vous voulez vérifier à chaque fois.

Votre 'un clic' pourrait probablement être scripté pour la dernière étape.

Answer 5

Je recommande:

• copie chaque ancienne construction dans son propre répertoire (pour les restaurations rapides, vous avez seulement besoin de garder un de ces) dans une partie non accessible par Internet de votre serveur.
• Ensuite, utilisez svn export pour obtenir la nouvelle version complète de svn. N'utilisez pas svn checkout, car cela laissera des répertoires .svn partout.

Answer 6

Si vous installez le client de ligne de commande Subversion, il est assez facile de faire un script fichier batch/shell qui fera une caisse exportation de la dernière révision du référentiel vers un dossier sur le serveur. Cela nécessite que vous ayez la même structure de fichiers dans Subversion que sur le serveur (sauf si vous voulez ajouter la logique pour changer la structure dans le script, bien sûr).

Answer 7

Je vous recommande d'écrire une sorte de script qui fait cela pour vous. Que vous le fassiez avec PHP ou autre chose dépend de vous. Gardez juste la sécurité à l'esprit quand vous faites cela.

L'exportation de votre projet n'exportera pas les fichiers svn: externals que vous avez définis, ce qui signifie que vous devez effectuer plusieurs exportations. Lorsque vous écrivez ceci, cela ne devrait pas poser de problème. Autre chose avec les exportations, si vous projetez est grand (si vous utilisez beaucoup de vidéo, PDF etc.) alors une exportation peut être assez lourde, surtout lorsque votre contrôle de version est hébergé hors site et uniquement disponible via HTTP.

Je vous recommande de faire une extraction et de vous assurer que votre serveur ne peut pas servir les fichiers situés dans les dossiers cachés .svn.

Answer 8

Nous déployons via Subversion et utilisons des outils de migration de base de données (avec le versioning de schéma) pour ce faire.

(http://blog.lavablast.com/post/2008/02/I2c-for-one2c-welcome-our-new-revision-control-overlords!.aspx)

(Nous développons en .NET)

Answer 9

Merci pour toutes les réponses, m'a beaucoup aidé à prouver que je n'étais pas faire trop mal. Nous développons et testons un contrôle local d'un référentiel de subversion en ligne. Lorsque nous voulons déployer une nouvelle version, nous exécutons un script qui supprime fondamentalement l'exportation en cours sur un serveur de tests en ligne, crée une nouvelle exportation, puis la déploie sur tous les serveurs Web via rsync.

Problème avec ceci: Rsync copie toujours tous les fichiers lors du déploiement sur le serveur de données en raison de l'exportation complètement nouvelle. En fait, je n'ai jamais pris le temps de découvrir comment mettre à jour une exportation.

Sur une autre machine que je viens d'une caisse déployables avec rsync --without svn

Answer 10

Avez-vous vérifié Beanstalk? http://beanstalkapp.com/ C'est un serveur SVN/GIT et il dispose d'un déploiement FTP automatique.