Conditionnement avec NAnt, comment gérer différents environnements

Question

J'utilise NAnt pour créer un projet ASP.NET MVC. Le script NAnt crée ensuite un package zip contenant un script de déploiement et tous les fichiers nécessaires.

Le script de déploiement sauvegarde le site Web en cours d'exécution, configure la version la plus récente du site Web et met à jour la base de données.

Cela fonctionne très bien pour un environnement unique. Cependant, on nous demande de plus en plus de configurer un environnement de staging/acceptation à côté de la production. Ces environnements, bien sûr, diffèrent par la structure du fichier, le serveur de base de données, les paramètres de configuration, etc.

Comment puis-je gérer cela au mieux dans les scripts de déploiement? Je ne veux pas créer de variables séparées pour chaque environnement, distinguables uniquement par leur nom.

Fournir des valeurs par défaut et fournir les variables dans des fichiers séparés semble plus logique.

Est-ce que quelqu'un a des expériences pratiques avec cela?

Answer 1

Stockez les éléments que vous pensez susceptibles de changer entre les environnements dans les fichiers de configuration. Visual Studio peut faire le gros du travail ici si vous le souhaitez; Vous pouvez créer des paramètres et spécifier des valeurs par défaut à partir de l'onglet Paramètres des propriétés d'un projet Visual Studio.

Cela va créer le fichier de configuration pour vous et fournir un accès fortement typé par Properties.Settings.Default. En ce qui concerne la gestion de plusieurs environnements via votre build, j'ai vu certaines personnes recommander de conserver plusieurs copies des fichiers de configuration - un pour chaque environnement par exemple - et d'autres recommandent d'utiliser nant pour modifier les fichiers de configuration pendant la construction ou le déploiement phase. Vous pouvez utiliser une propriété transmise à nant sur la ligne de commande (par exemple) pour sélectionner l'environnement que vous construisez (ou déployer, selon la façon dont vous le faites).

Je ne recommande pas non plus de ces approches parce que:

1. Ils ont tous deux nécessitent des changements à votre construction pour soutenir les nouveaux environnements.
2. Si vous modifiez un paramètre dans un environnement déployé et oubliez de mettre à jour la génération, le déploiement suivant réinitialisera la modification (en défaveur des paramètres de configuration). Si quelqu'un crée un nouvel environnement (disons qu'il veut explorer les problèmes découlant de la mise à niveau vers une nouvelle version de SQL Server par exemple) et qu'il ne souhaite pas créer tous les nouveaux fichiers de configuration dans le système de construction, il peut décider de utiliser les paramètres d'un environnement existant. Disons qu'ils choisissent de déployer en utilisant les paramètres en direct et oublient de changer quelque chose après. Votre nouvel environnement 'test' pourrait maintenant pointer vers le kit live.

Je crée une copie de chaque fichier de configuration (appelé web.config.exemple, par exemple) et commente les paramètres qu'ils contiennent (sauf s'ils ont des valeurs par défaut significatives). Je les vérifie et les ai déployés au lieu de le vrai web.config (c.-à-d. Que web.config n'est PAS déployé automatiquement web.config.example est déployé comme web.config.example.

L'administrateur du nouvel environnement devra copier et renommer le fichier en web.config et fournir des valeurs significatives. Je mets aussi tous les appels aux paramètres derrière ma propre classe de wrapper - si un paramètre obligatoire est manquant, je lance une exception.

La construction et mes environnements ne dépendent plus les uns des autres - une construction peut être déployée dans n'importe quel environnement.

Si un paramètre est manquant (un nouvel environnement ou un nouveau paramètre dans un environnement existant), une exception claire est levée pour indiquer à l'administrateur ce qu'il doit faire.

Les paramètres existants ne sont pas modifiés après une mise à niveau car seuls les fichiers .example ont été mis à jour. C'est une tâche d'administration de comparer les paramètres actuels avec le dernier exemple et de réviser si nécessaire. Pour configurer le déploiement, vous pouvez placer tous les paramètres environnementaux (chemins d'installation, etc.) dans les propriétés nant et les déplacer dans un fichier séparé (settings.build par exemple), puis utiliser la tâche d'inclusion nant pour inclure ce fichier à le haut de votre fichier de déploiement (deploy.build par exemple). Vous pouvez ensuite déployer une nouvelle version de deploy.build sans écraser vos modifications de configuration telles qu'elles sont dans settings.build. Si une nouvelle propriété est introduite dans deploy.build nant échouera avec un bon message pour vous dire que vous n'avez pas défini cette propriété.