Contrôle de version et fichier de configuration personnel
Notre projet utilise un fichier de configuration spécifique à l'utilisateur. Ce fichier n'est actuellement pas en contrôle de version, car il est différent pour chaque utilisateur. Le problème est que lorsqu'un développeur ajoute un nouveau module qui nécessite une configuration ou modifie le nom d'un module existant, les autres développeurs obtiennent des erreurs car leurs fichiers de configuration privés ne sont pas mis à jour.
Pour résoudre le problème, nous avons pensé à travailler avec deux fichiers de configuration: un fichier de configuration par défaut/global qui sera en contrôle de version et sera mis à jour régulièrement par chaque développeur qui ajoute un nouveau module, et un fichier de configuration privé qui sera tenu à l'écart du contrôle de version et ne contiendra que les modifications spécifiques à l'utilisateur.
Cependant, cela semble toujours être une solution ad hoc.
Pouvez-vous proposer une meilleure solution?
Que font les professionnels?
Bien que vous ayez déjà obtenu de bonnes réponses ici, la plupart d'entre elles manquent la cause première de votre problème: vos fichiers de configuration utilisateur semblent contenir plus que des informations spécifiques à l'utilisateur, ils contiennent également des informations (peut-être redondantes) qui sont sous contrôle de version ailleurs , probablement dans des fichiers différents, comme les noms de modules.
Je peux penser à deux solutions possibles ici:
essayez de séparer ces informations de manière rigoureuse. Par exemple, n'utilisez aucun nom de module dans votre configuration utilisateur. Utilisez des numéros d'identification (par exemple, des GUID) pour faire référence aux modules et laissez ces numéros d'identification ne jamais changer après qu'ils ont été attribués à un module. Bien sûr, cela a probablement l'inconvénient que vos fichiers de configuration utilisateur perdent une partie de leur simplicité qu'ils pourraient avoir maintenant. Vous devrez peut-être créer un outil GUI pour modifier vos fichiers de configuration au lieu d'utiliser un éditeur de texte brut.
donnez à votre format de fichier de configuration un numéro de version, et chaque fois que quelque chose comme un nom de module est modifié, attribuez-leur un nouveau numéro de version. Ensuite, vous pouvez fournir un script de mise à niveau qui vérifie les numéros de version et si le fichier de configuration n'est pas à jour, il modifie tous les noms de modules qu'il trouve dans le fichier et augmente ensuite le numéro de version. Cela peut être automatisé, de sorte que le processus de mise à niveau ne dérangera pas vos coéquipiers dans leur travail quotidien.
EDIT: après avoir relu votre message, je pense que votre supposée solution est raisonnable, tant que de nouveaux modules sont juste ajoutés, mais pas renommés. Ce que j'ai écrit ci-dessus permettra de changer les noms de modules ou la structure de la configuration des modules existants par la suite. Mais si vous n'en avez pas besoin, je m'en tiendrai à la solution la plus simple.
C'est une solution raisonnable.
Vous avez besoin d'un moyen de spécifier la ou les valeurs initiales de tout nouvel élément de configuration. Ceux-ci doivent être stockés quelque part et un fichier de configuration global en lecture seule est le choix évident.
Ensuite, lorsque chaque utilisateur modifie sa configuration personnelle, vous écrivez ces modifications dans sa copie locale.
Votre code devra d'abord lire la configuration globale et celle spécifique à l'utilisateur pour remplacer toutes les valeurs modifiées. Ce sera beaucoup plus simple que de lire le fichier local puis d'essayer de déterminer ceux qui n'ont pas été définis et doivent donc être lus dans le fichier de paramètres globaux.
Si vous utilisez quelque chose comme XML pour le stockage, vous n'avez pas à vous soucier de gérer le cas où vous supprimez des paramètres. Ils ne seront pas demandés à la copie utilisateur du fichier et si vous recréez le fichier lors de l'enregistrement, ils seront supprimés la première fois que l'application sera utilisée après la modification.
Nous avons une solution quelque peu intéressante, nous sommes principalement des développeurs PHP, donc nous utilisons Phing qui vous permet de créer des tâches automatisées écrites en PHP, donc au lieu de faire notre mise à jour svn normale, nous faisons un "phing update" qui appelle svn update, puis remplace nos configurations par les variables appropriées, par exemple, une configuration:
$db_user = "${test.db_user}";
Ainsi, les fichiers de configuration sont tous versionnés avec cette syntaxe intéressante, puis nous générons un fichier de configuration adhoc, non versionné pour mon instance spécifique, qui remplace ces "variables" par des paramètres non versionnés spécifiés dans les fichiers ini non versionnés. De cette façon, nous pouvons modifier tous les fichiers spécifiques à l'utilisateur et faire en sorte que les changements soient appliqués à d'autres copies de travail.
Le programme doit avoir un paramètre par défaut dans le code lorsque la valeur n'est pas trouvée dans le fichier de configuration. De cette façon, à mesure que de nouvelles choses sont ajoutées, cela ne se cassera pas, votre chemin de mise à niveau serait plus fluide et vos utilisateurs auront également un repli lorsqu'ils gâcheront le fichier de configuration.
Un autre exemple plus complexe serait au démarrage du programme ou à un autre point clé, ouvrir le fichier de configuration à l'aide d'un module d'initialisation et ajouter les valeurs par défaut manquantes, mais cela semble assez lourd.
Mettez un numéro de version dans le fichier de configuration personnel (le numéro de version du format de fichier de configuration).
Assurez-vous que le code qui traite le fichier de configuration personnel vérifie le numéro de version et, s'il est obsolète, exécutez une procédure de mise à jour. Donc, fondamentalement, toute personne qui modifie les fichiers de configuration existants doit augmenter le numéro de version du format de fichier de configuration et écrire une procédure pour mettre à jour les fichiers de configuration de la version précédente (renommer les sections, etc.) et réenregistrer leur.
De toute façon, vous voudrez probablement un processus comme celui-ci pour les utilisateurs finaux, alors vous pourriez aussi bien l'utiliser pour faciliter la vie de vos développeurs.
Généralement, ce que j'ai vu, c'est d'avoir un fichier de configuration avec des valeurs par défaut archivées dans le référentiel. Il peut s'agir, par exemple, des valeurs nécessaires sur le serveur de test. Ensuite, lorsqu'un développeur extrait le fichier, il aura toutes les valeurs. Si un nouveau champ est ajouté ou un champ est supprimé, cela est géré dans une fusion. Un développeur vérifiera la valeur requise pour le serveur cible et n'archivera aucune autre modification des champs qui sont pour son environnement de développement personnel.
Il prend soin de s'assurer que la fusion est effectuée correctement, mais cela me semble assez sûr.
Ce que nous faisons ici, c'est créer des blocs de paramètres. Cela peut être fait dans Zend comme ceci:
[production]
key1: parameter1
key2: parameter2
[testing: production]
key1: parameter2
key3: parameter4
Cela signifie que le test hérite de la production et l'étend avec key3. Il suffit alors à chaque développeur de définir son environnement (test ou production dans ce cas)
Nous avons construit un outil appelé Config qui gère les problèmes de configuration comme celui-ci. Vous allez créer (ou importer) 1 fichier de configuration principal. Créez ensuite un environnement appelé Local. Dans l'environnement local, créez plusieurs instances, 1 instance par utilisateur. Si vous devez apporter une modification courante sur toute la carte, comme ajouter une nouvelle entrée de configuration ou modifier le nom du module, effectuez simplement la modification, et elle sera appliquée sur toute la carte. Si vous souhaitez modifier une instance/un utilisateur, faites de cette valeur de configuration une variable, puis modifiez la variable. Cette modification ne sera appliquée qu'à votre instance/utilisateur. Tous ces éléments sont sous contrôle de version. Vous déployez les fichiers de configuration via Push ou Pull. L'option pull est similaire à git pull, mais pour cette instance/cet utilisateur spécifique.
Config vous offre des fonctionnalités supplémentaires telles que la comparaison des configurations entre les utilisateurs, la recherche, le balisage, la validation et le workflow. C'est SaaS donc pas vraiment pour ceux qui ne sont pas encore prêts pour le cloud, mais nous avons un plan sur site.
Ceci est une solution utile basée sur la publication: Garder les mots de passe dans le contrôle de code source
En résumé, la stratégie consiste à "conserver une version chiffrée du fichier de configuration sous contrôle de source, puis à fournir un moyen par lequel l'utilisateur peut chiffrer et déchiffrer ces données".
- Créez un fichier de configuration factice et .gitignore.
- Créez un makefile qui peut crypter et décrypter le fichier de configuration
- Stockez le makefile et le fichier de configuration crypté dans le référentiel
- Le makefile demande un mot de passe et comment contacter l'auteur pour le mot de passe.
- Lors de la construction du projet, si le makefile n'a pas été exécuté, informez l'utilisateur avec console.error ("Fichier de configuration [conf/settings.json] manquant! Avez-vous oublié d'exécuter
make decrypt_conf? "); - Une vérification est décrite pour s'assurer que le fichier de configuration est à jour.