Environnement de production contrôlé par la version

Question

Ma question est, comment puis-je contrôler la version de l'environnement de production dans le bon sens?

Voici notre environnement actuel:

• (serveur interne) Développement - Code source contrôlée Version
• (serveur client) l'environnement de test d'acceptation
• (serveur client) environnement Mise en scène
• (Client serveur) Environnement de production

Lorsque nous publions de nouvelles fonctionnalités pour accepter Après un test, nous faisons une publication dans Visual Studio, compressons les changements et les appliquons sur le serveur de test. Là, nous créons un dossier de sauvegarde (afin que nous puissions annuler les modifications) et nous créons un dossier de version afin que nous puissions déplacer ces modifications vers le transfert lorsqu'elles sont approuvées. Il s'agit de beaucoup de travaux manuels créant des dossiers de sauvegarde, des dossiers de version, recréant la structure du répertoire et essayant de suivre la fonctionnalité qui va dans quelle version. C'est fastidieux et il y a toujours un problème avec un développeur qui ne suit pas la procédure de publication.

---

En théorie je pourrais faire un dépôt pour l'environnement de test. (oubliez le code source, il s'agit de l'application publiée) Sur chaque version, le développeur fait un commit et fournit un commentaire sur les fonctionnalités qu'il libère. Lorsque la fonctionnalité doit être déplacée de Test à Staging, nous exportons les modifications apportées depuis la date de mise à jour de l'environnement de stockage intermédiaire et les copions dans l'application de stockage intermédiaire. Là, nous faisons un commit qui plus tard peut être extrait pour être libéré dans l'environnement de production. Les inconvénients de ceci est que l'utilisation de subversion encombrera l'application avec ces répertoires .svn. Cela peut être réparé en interdisant l'accès à ces répertoires dans IIS ou web.config. Une autre solution serait d'utiliser Git dans le répertoire au dessus du répertoire racine de l'application. Mais Git est plus difficile à travailler pour un développeur inexpérimenté dans un environnement Windows.

Quelqu'un at-il déjà rencontré ce problème? Comment contrôlez-vous la version de votre environnement de production? Que faire si vous devez annuler une version, avez-vous un dossier de sauvegarde que vous avez créé avant la publication? J'ai discuté de cela avec nos développeurs, et ils ne voient aucun problème avec l'utilisation de subversion pour le versioning et la sauvegarde de l'environnement de test/staging/production. Au contraire, ils seraient heureux de ne pas créer des dossiers de version/sauvegarde chaque fois qu'ils ont besoin de libérer de nouvelles fonctionnalités.

Dans le même temps, il y a une certaine insécurité à ce sujet. Personne n'en a entendu parler auparavant, ayant l'application dans un système de contrôle de version et nous ne savons pas quels seraient les inconvénients.

Si vous avez l'expérience d'un scénario comme celui-ci, je serais heureux d'en entendre parler.

Mikael Lundin

Answer 1

J'utilise mercurial (Hg) en tant que système de contrôle de version de production. (Pas le code, mais les binaires réellement déployés). Cela fonctionne plutôt bien. Subversion n'est pas tout à fait correct dans mon scénario, car je veux pouvoir synchroniser les changements de production (tels que les fichiers de configuration) avec les tests et peut-être même le développement. subversion est plus difficile à synchroniser/fusionner entre différents dépôts (beaucoup d'adaptation manuelle). Et avec la mise à jour hg tag et hg, il est très facile de revenir à une balise stable (ou instable).

Oh, et je suis tout à fait d'accord, vous devriez utiliser un buildserver (cruisecontrol.net) ou quelque chose et garder toutes vos affaires là aussi. Mon scénario n'est pas suffisant car la config d'un système de production client est, bien, spécifique à la custom, et même avec des tests poussés et quoi qu'il puisse y avoir de config qui ne font plus la même chose entre deux releases (ou les données entrantes ont considérablement changé)

Answer 2

Une autre façon de faire serait d'utiliser un serveur de construction. Chaque fois que vous archivez du code, le serveur de génération crée et empaquette la nouvelle version dans l'environnement de développement. Puis vérifie dans le paquet déployable avec votre code.

Vous pouvez ensuite déployer la génération empaquetée dans les autres environnements. De cette façon, vous n'avez pas besoin de sauvegarder les versions car vous avez déjà toutes les versions construites dans votre dépôt principal. Si vous vous assurez que le déploiement est entièrement automatisé et peut être effectué avec une seule commande (PowerShell?), Il n'est plus nécessaire de conserver les sauvegardes sur les serveurs.

C'est en fait mieux et plus facile à maintenir que la solution que vous proposez. Parce que chaque version de la construction est conservée à côté du code, vous pouvez toujours trouver un environnement de développement complet pour tout paquet de construction. Si vous contrôlez vos serveurs séparément et que vous trouvez un bug quelque part, il peut être difficile de trouver la version du code qui provoque le bug.

Answer 3

Merci pour vos réponses et suggestions.

Je vois que je dois repenser la façon dont nous gérons les versions de ces environnements. Avoir un serveur de build avec toutes les versions jamais faites pourrait résoudre une partie du problème. J'obtiendrai les commentaires de validation sur le code source, et un meilleur contrôle de la fonctionnalité qui va dans quelle construction. J'ai encore besoin de garder une trace sur ce que la construction est dans quel environnement pour être en mesure de revenir à une version en cas de problème.

@Jonke Je vais jeter un coup d'œil à Mercurial. Peut-être qu'un environnement de production contrôlé par la version est trop puissant si vous avez un système de construction où chaque révision a un code source contrôlé par la version. Mais j'aimerais quand même avoir un moyen rapide de rétablir les modifications apportées à une révision précédente si quelque chose ne va pas lors du déploiement de nouvelles fonctionnalités. J'aime aussi la façon dont vous obtenez des fichiers de configuration contrôlés par la version sur le serveur, car l'environnement de production a toujours une configuration différente de celle de l'environnement de développement.

Peut-être que je suis à la recherche de la solution miracle :)

Answer 4

Nous utilisons la subversion comme un moyen de déployer des choses à nos différents serveurs (prod, demo, dev, etc.) et vous ne rencontrez des difficultés. Les seules choses à surveiller sont les différences de base de données et les différences de fichiers de configuration. Les fichiers de configuration peuvent être modélisés, afin de ne pas écraser les fichiers dans chaque déploiement différent, mais vous n'obtenez pas ces versions pour les modifications apportées à cette plate-forme spécifique. Avec ce type de système, vous pouvez utiliser les balises subversion pour mettre à jour/restaurer facilement des versions de déploiement spécifiques.