Quelle est la manière la plus simple de gérer les fichiers de configuration de projet?

Il est très courant d’avoir au moins un fichier de configuration dans un projet. Chaque fois que je partage un projet avec git , j’ai le même problème avec:

  • informations sensibles (chaque développeur a des mots de passe différents, etc.)
  • informations spécifiques à la tâche (lorsque le développeur travaille sur certaines tâches où il est nécessaire de modifier certains parameters)

De toute évidence, les configs doivent être ignorés pour empêcher les données spécifiques au développeur d’inonder le référentiel principal. Maintenant, il y a plusieurs façons dont j’avais l’habitude d’utiliser, chacune avec quelques défauts:

  • .gitignore les fichiers de configuration
    • la manière la plus simple
    • lorsque le développeur clones repo, le fichier de configuration est manquant et il faut trouver où les configs ont été les recréer
  • Le fichier de configuration n’est pas ignoré. Il contient des informations factices et chaque développeur les débloque et les place dans son .git/info/exclude ou set git update-index --assume-unchanged ... dans le fichier
    • les fichiers sont disponibles pour quiconque clone un repo
    • il contient des techniques avancées qui pourraient confondre les personnes qui travaillent avec git pour la première fois
    • quand quelqu’un commet des fichiers de configuration par accident, cela ne permet pas aux gens de tirer / récupérer (comme exclut ne fonctionne pas de la même manière que .gitignore )
  • dissortingbuer des fichiers de configuration avec le suffixe, par exemple, _original tout en ayant les vrais fichiers dans .gitignore . Chaque développeur renomme alors les fichiers en vrais noms
    • les fichiers sont disponibles pour quiconque clone un repo
    • il faut rechercher toutes les configurations dans l’application et les renommer

Y a-t-il d’autres moyens, peut-être, de mieux gérer cela? Je pense que je manque quelque chose, du plugin au moins.

Les pilotes de filtre sont la manière “automatique” d’implémenter l’option 3, comme détaillé dans ” quand vous avez une clé secrète dans votre projet, comment pousser vers GitHub est possible? “:

entrer la description de l'image ici

Le script smudge , à la caisse:

  • détecter les bons fichiers de configuration à modifier
  • récupère les informations nécessaires (mieux conservées en dehors de tout repository Git ) et remplace les valeurs du modèle par les valeurs réelles.

A partir de là, les développeurs peuvent apporter toutes sortes de modifications à ces fichiers de configuration.
Cela n’a pas d’importance, car le script clean va, lors de la validation, restaurer le contenu de ce fichier à sa valeur d’origine (modèle). Aucune poussée accidentelle là-bas.

La façon dont nous l’avons fait sur le dernier projet sur lequel je travaillais était d’avoir un fichier de configuration maître chargé d’un fichier de configuration local si celui-ci était présent, ce qui pourrait écraser les parameters par défaut. en maître. Le fichier local a été ajouté à gitignore. De cette façon, tous les éléments courants peuvent être partagés et une configuration est toujours présente et chaque développeur peut modifier son local.

Dans les projets que j’ai été, nous avons une configuration par défaut et les développeurs ont leur propre configuration à un endroit particulier en dehors du contrôle de version (convention sur configuration) – les valeurs de ces derniers sont utilisées pour remplacer celles du premier.

Nous avons commencé à utiliser le chiffrement pour les détails sensibles dans la configuration: Gestion des mots de passe dans la configuration de production pour un déploiement automatisé

Dans le cas de git, vous pouvez regarder l’ git atsortingbutes filter atsortingbute pour effectuer à la fois le remplacement des valeurs locales et le décryptage des valeurs sensibles de manière automatisée.

Vous pouvez aussi avoir des sous-modules qui ont le production.yml et qui ont un access restreint au repo du sous-module.

Comme il m’a fallu un certain temps pour trouver une solution de travail avec les astuces de @VonC, voici un exemple complet de comment ignorer les mots de passe avec un filtre git clean dans un fichier d’en-tête Objective-C.

  1. Supposons que vous avez un script de configuration par défaut nommé Config.h contenant cette

     // Change "12345" to your password #define kPass @"12345" #define kConstant 42 
  2. Créez un script hidepass.sh correspondant aux lignes critiques et imprimez la ligne par défaut

     #!/bin/sh awk '{ if (/#define kPass/) print "#define kPass @\"12345\""; else print $0; }' exit 0 
  3. Rendre le script exécutable et l’append au repository

  4. Dites à git de filtrer votre fichier de configuration en ajoutant cette ligne à .gitatsortingbutes (ajoutez également .gitatsortingbutes à votre repository)

     Config.h filter=hidepass 
  5. Dites à git d’utiliser le script hidepass.sh pour le filtre caché lors du nettoyage:

     git config filter.hidepass.clean ./hidepass.sh 

Ça y est, vous pouvez maintenant changer le mot de passe dans Config.h mais git ne commettra pas ce changement car il remplace toujours cette ligne par la ligne par défaut lors de l’archivage.

Ceci est une solution rapide pour un mot de passe d’une ligne, vous pouvez devenir fou et par exemple terminer les lignes à ignorer avec une chaîne spéciale et vérifier les lignes avec cette chaîne.

Une chose à laquelle je peux penser est similaire à la méthode 2 et à la méthode 1 ci-dessus. Où vous avez un répertoire dans lequel vous stockez des éléments complexes propres au site, tels que des répertoires de fichiers de configuration, des fichiers téléchargés par l’utilisateur, etc.

Vous ne conservez que le fichier de configuration lui-même hors du contrôle de version, mais vous avez alors une copie factice nommée légèrement différemment de ce que le site utilise réellement et ce fichier contient des instructions détaillées sur les parameters de configuration et une copie renommée.

Par exemple, disons que vous avez un répertoire “site_profile”. Dans ce répertoire, vous créez un fichier appelé “README.settings.php” avec un répertoire “files” contenant les fichiers téléchargés par l’utilisateur (à la fois par les administrateurs et les utilisateurs frontaux). Tout cela est sous contrôle de version.

Cependant, le site exécutera ses parameters depuis “settings.php” qui n’existera pas ici. Mais si vous deviez renommer “README.settings.php” en “settings.php”, alors vous auriez le fichier de configuration dont vous avez besoin (après avoir bien sûr ajouté vos parameters personnalisés).

Cela vous permettra de dire aux autres développeurs ce dont ils ont besoin dans leur fichier de configuration tout en conservant votre propre fichier de configuration hors du mix. Il suffit de définir votre fichier de configuration pour qu’il soit ignoré ou de ne jamais faire de couverture pour ce répertoire et de le réduire.

C’est ce que nous faisons avec les sites Drupal où je travaille et ça marche vraiment bien.

Pour les deux cas, vous mentionnez:

  • informations sensibles (chaque développeur a des mots de passe différents, etc.)

    Ecrivez vos scripts pour que ces fichiers sensibles soient stockés dans le répertoire de base du développeur plutôt que dans le répertoire du projet.

  • informations spécifiques à la tâche (lorsque le développeur travaille sur certaines tâches où il est nécessaire de modifier certains parameters)

    Les parameters par défaut sont généralement archivés dans le référentiel. Lorsque vous préparez vos commits, vous pouvez facilement vérifier si vous avez modifié l’un de ces parameters et les annuler avant de les valider.

J’ai sauvegardé mes modifications de configuration locales sur un git stash. J’utilise git stash plutôt que pop, de sorte que je ne le retire jamais de la queue. De cette façon, je peux utiliser reset –hard chaque fois que j’en ai envie.

N’ayant aucune expérience avec Git, mais ayant traité les mêmes problèmes dans d’autres contextes (identifiants de connexion Hibernate dans une suite Spring JUnit ou scripts ANT), pour tout élément spécifique à l’utilisateur ou dépendant de l’environnement local d’un utilisateur:

  1. Avoir un fichier README répertoriant ces dépendances et comment configurer votre env local pour qu’il exécute le script.
  2. Remplacez ces dépendances dans votre conf par des appels aux propriétés du système ou un moyen de structure pour extraire des valeurs externes. Dans un script ANT, par exemple, vous pouvez remplacer des chaînes par , où jdbc.username est une variable système (que vous pouvez définir dans Eclipse ).

Les développeurs peuvent archiver ce qu’ils veulent, car la configuration est indépendante de l’utilisateur.

Beaucoup de bonnes options listées. Quelques autres options à mentionner:

  • Ajoutez toutes les configurations à .gitignore. Ensuite, ayez un projet git séparé , avec juste les fichiers de configuration. (Gardez ce GIT # 2 dans un dossier totalement différent.) Dans ce GIT # 2, faites quelques scripts similaires à apply-config /path/to/my_git1 , save-config /path/to/my_git1 qui copient ou sauvegardent fichiers de configuration du repository principal GIT.
    • Je préfère cela à l’utilisation de sous-modules. J’ai trouvé que travailler avec des sous-modules encombrants dans une grande équipe.
    • Vous pouvez ensuite suivre les configurations ou utiliser plusieurs repos GIT pour des choses telles que les parameters de production, les parameters de débogage, des parameters plus optimisés, etc.
    • Utilise un outil (GIT) que tout le monde comprend.
  • J’aime l’idée de chercher dans le dossier de base des informations sensibles telles que les informations de connexion à la firebase database. (Mentionné par @avh)
  • Pour les DevOps, vous pouvez envisager des choses comme Ansible / Salt / Chef / Puppet pour automatiser les déploiements et les parameters.

Une autre option très courante, popularisée par The Twelve-Factor App , consiste à ne pas inclure de variables de configuration dans les fichiers, mais à les charger à partir de variables environnementales. De cette façon, les fichiers du référentiel ne nécessitent aucun traitement particulier.