Contrôle de version pour les applications Web - comment gérer les révisions et les plannings de mise en production?

Question

J'utilise SVN pour la gestion du code source sur une application ASP classique que je développe/supporte. Je maintiens plusieurs versions de l'application comme requis par mon entreprise:

• Version Discovery/playground - où je fais tout le travail. Mon travail Copie
• versions Dev/test (pas d'accès à ces sites/serveurs)
• version live (pas d'accès à ces sites/serveurs)

Voici quand je des ennuis:

1. le travail se fait sur le projet a et est engagé
2. un projet est promu Dev/test à l'aide d'une exportation du journal
3. il y a un problème avec le projet a et il est stalle ed dans Dev/Test
4. Projet B se présente, est préparé et engagé
5. Projet B construit maintenant sur le projet A, mais il y a des parties du projet A ne sont pas prêts pour le prime time

court de seulement " faites attention à ne rien gâcher », y a-t-il quelque chose que je puisse faire pour m'assurer que certaines parties des projets peuvent se bloquer dans le processus de développement sans tout retarder?

La nécessité d'un serveur web dans le processus semble me causer des problèmes. Je sais que je peux brancher le projet A quand il passe à Dev/Test, puis le fusionner au tronc quand il est en direct. De cette façon, je peux retourner mon terrain de jeu devant la branche et faire le projet B sans que le projet A ait une chance d'aller vivre accidentellement. Cependant, je ne peux pas jouer avec le projet A sur mon terrain de jeu. Dois-je créer un nouveau site de terrain de jeu pour chaque branche? Je sais que c'est probablement trop spécifique à ma situation avec toutes ses contraintes, mais j'espère que quelqu'un d'autre a vécu quelque chose de similaire à ma situation.

Merci!

EDIT:

Voici ma solution actuelle: Maintenance des correctifs - changements qui pourraient aller immédiatement à la production - peut se fait dans WC et engagé dans le coffre. Tout ce qui a des dépendances sur un projet est ramifié. Les copies de travail le long du chemin de test peuvent être commutées pour pointer vers cette branche pour tester un projet. Les branches doivent être tenues à jour, et nous pouvons utiliser des hooks de commit pour tenir les gens informés. Lorsqu'une succursale est prête à être déployée en production, elle est fusionnée avec le réseau et déployée.

Cela a du sens et fonctionnerait, non?

Answer 1

Nous contrôlons notre base de code avec une instance de SVN et utilisons un autre pour contrôler les environnements et le contenu des serveurs Web pour chaque étape de test et éventuellement la production. Avoir l'histoire de ce qui a été dans chaque environnement nous a permis d'économiser un certain nombre de fois. Garder vos messages de journal significatifs sera certainement payant.

J'exporte de la compilation automatique envoyée à notre serveur de développement sur une version retirée des fichiers de test système, puis validez les modifications à cela.La mise à jour des serveurs dans la batterie de serveurs web est juste un cas de mise à jour de la révision HEAD sur toutes les cases. Le stockage intermédiaire est mis à jour à l'aide d'une exportation à partir du test système, puis la production est mise à jour à partir d'une exportation de stockage intermédiaire. Certaines parties de ce sont scriptées mais avoir une surveillance manuelle est pratique. Probablement le plus dur est de s'assurer que les fichiers de configuration sont corrects pour chaque environnement mais si vous ne le changez pas, vous ne le déployez pas.

Vous aurez probablement toujours envie de vous familiariser avec les branches de fonctionnalité ou les branches de libération et le strategies nécessaire pour recombiner la source. Vous devrez peut-être corriger quelque chose dans la production que vous n'auriez jamais imaginé, quelle que soit la qualité de votre stratégie de test. Une chose à noter est de ne pas utiliser la version client 1.6x avec un serveur SVN 1.5x car cela joue havok avec nos processus de fusion jusqu'à la mise à jour voir; http://ferventcoder.com/archive/2009/06/10/subversion-1.6-tree-conflicts-and-the-incompatibility-of-subversion-1.5.aspx

EDIT:

Chaque serveur dans notre environnement de déploiement a le client TortoiseSVN installé de telle sorte que les administrateurs système ont une interface graphique pour la mise à jour du référentiel vérifié.

Je leur ai également fait quelques scripts qui utilisent les utilitaires de ligne de commande SVN pour mettre à jour quelques dépôts sur les serveurs avec un travail automatisé. Cela permet à notre équipe de contenu de valider des fichiers sur leurs copies locales du dossier des ressources du serveur, puis de les mettre à jour toutes les heures. Ils ont seulement accès à un ensemble spécifique de dossiers que nous contrôlons avec le fichier auth sur le serveur SVN.

Nous avons deux machines distinctes sur lesquelles le serveur SVN est installé et qui sont sauvegardées quotidiennement. L'un concerne les référentiels de code source et l'autre les éventuels builds déployés dans chaque environnement. Cela signifie que nous avons un référentiel dupliqué complet pour le déploiement dans chaque environnement, mais le stockage n'est pas un problème.