Visual Studio - Nom d'utilisateur/Mot de passe pour le déploiement/contrôle de source/partage de code source

Question

Je souhaite une méthodologie simplifiée pour pouvoir exécuter localement (le travail est effectué sur plusieurs machines), déployer et valider le contrôle de version où les informations sensibles jusqu'à (mot de passe, nom d'utilisateur, port (s), nom d'hôte, nom de base de données inclus) sont automatiquement absentes (ou supprimées) et importées en fonction de la situation?

Les données sensibles ont été répertoriées par ordre d'importance, alors si les solutions par mot de passe sont les bonnes, plus la chaîne est avancée, mieux c'est. L'autre avantage serait qu'il existe un fichier d'exemple fictif pour que quelqu'un d'autre essaie le projet sur sa propre machine avec son propre hôte en remplissant simplement les parties manquantes du fichier fictif.

Quelles sont mes options à suivre pour cette fonctionnalité? J'ai pensé à ajouter les paramètres pertinents au fichier machine.config local, mais les informations sont enregistrées dans le fichier machine au lieu d'être chiffrées dans mon fichier de documents utilisateur. De plus, cela ne se prête pas très bien à un fichier fictif local pour les nouveaux programmeurs à brancher et à jouer. Ce que je pense est la solution la plus propre est un fichier .config local dans la racine du projet qui n'est pas ajouté au contrôle de version.

S'il y a un moyen de le crypter de manière à ce que le serveur soit le seul avec une clé pour déchiffrer le fichier (plutôt que le projet capable de le faire) qui sera déployé . Ensuite, je pourrais avoir les données stockées dans le contrôle de la source, partager la source avec d'autres personnes intéressées à étudier le projet, sans qu'ils obtiennent les informations réelles nécessaires pour apporter des changements de rupture ou regarder des informations privées.

Answer 1

Nous utilisons plusieurs fichiers .config: un pour le développement, un pour l'intégration, un pour l'assurance qualité, un pour la pré-production et un pour la production. Chaque fichier est étiqueté avec un suffixe (par exemple: .prod).

Les fichiers contiennent tout ce dont le logiciel a besoin pour se connecter aux bases de données et aux serveurs, à l'exception du fichier .config de production, où les chaînes de connexion, les utilisateurs et les mots de passe ont été remplacés par des espaces réservés.

Lorsque nous envoyons une nouvelle version du logiciel à l'équipe de production, nous envoyons un fichier .config à jour, mais "neutralisé". L'équipe de production ajoute ensuite les informations manquantes.

Je pense que crypter le fichier (ou l'information) ne sont pas une solution: vous auriez alors un nouveau problème: comment cacher les clés utilisées pour le cryptage ...

(Note: nous utilisons des transformations à générer le fichier .config correct pour chaque environnement.)