Question
Y a-t-il une raison légitime de NE PAS utiliser SVN pour les déploiements de production, ou s'agit-il simplement d'un cas de préférence personnelle et il n'y a pas de véritable cas contre SVN?
Contexte
Mon lieu de travail a une culture de balisage des versions dans SVN, puis de déploiement de ces versions directement sur les différents serveurs Web en utilisant svn co
ou en svn switch
incluant directement en production.
J'ai personnellement un problème avec cela car je crois que sans utiliser un script de construction et de déploiement ou un formulaire ou un déploiement automatisé, vous perdez les paramètres de l'environnement d'intégration car ils ne sont pas documentés. Cependant, plus que cela, j'ai le sentiment profond qu'il peut y avoir un danger caché à faire ce qui a été négligé, quelque chose qui n'a pas encore éveillé sa tête laide.
J'ai soulevé mes préoccupations avec le personnel des opérations qui est responsable du déploiement du code dans nos différents environnements (staging, pré-production, production) etc. Leurs arguments étaient à peu près que cela fonctionnait assez bien jusqu'à présent, aucune raison de changer.
Éditer:
Ce que je veux dire sur la construction et le déploiement:
Par exemple, si un développeur requiert un paramètre web.config ajouté pour un environnement particulier. Web.config n'est généralement pas conservé dans svn et ces fichiers sont donc mis à jour manuellement sans aucune forme de script de construction automatisé. Donc, s'ils sont perdus ou que OPS oublie d'ajouter un champ au web.config pour une version, vous avez des problèmes.
Un script de construction qui dit utilise XMLPoke pour générer automatiquement un web.config approprié pour un environnement particulier est idéal en ce que vous disposez d'un script versionnable qui documente toutes les modifications nécessaires pour chacun de vos environnements.
Méthode actuelle de génération et de déploiement
Pour le projet en question, un développeur crée une version manuellement, pour d'autres projets, l'étape de génération est automatisée avec NANT ou MSBuild, ce qui est OK.
Les migrations de base de données pour la plupart des projets se font via des scripts DB ou des scripts de migration (Migrator.NET) ou des packages CMS.
Le CI est généralement effectué par Team City sur une base par enregistrement, nous avons un processus de révision du code que tous les tickets sont effectués dans les succursales et ensuite examinés par les pairs pour la validation et l'exactitude / qualité avant de vérifier dans le coffre (fonctionne bien).
Cependant, le déploiement de code réel se fait presque toujours via SVN, soit via une extraction d'une version balisée, soit plus généralement un commutateur SVN. C'est quelque chose qui me semble étrange que nous utilisons notre référentiel dans le cadre du processus de déploiement.
La configuration ne change généralement pas très souvent, les seules choses qui seront dans les fichiers de configuration sont des informations spécifiques à l'environnement. Tout le reste est dans la base de données.
Ne vous méprenez pas, cela fonctionne, cela fonctionne bien. Cependant, je veux essayer de pousser pour une construction et un déploiement automatisés. Je l'ai utilisé avec Rails et Capistrano, et pour des projets personnels utilisant Cygwin, Nant et SSH.
Plus important encore, j'aurais besoin d'arguments valides très spécifiques pour amener mes collègues à utiliser une génération et un déploiement automatisés.
Ou n'y a-t-il PAS de véritables arguments valables contre l'utilisation de SVN spécifiquement pour le déploiement en production?