Comment le contrôle de version des fichiers de configuration de façon pragmatique?

Question

Supposons que nous avons un fichier de configuration avec des mots de passe sensibles. J'aimerais la version de contrôle de l'ensemble du projet, y compris le fichier de config, mais je ne veux pas partager mes mots de passe.
Qui pourrait être bon, si ce fichier de configuration:

database_password=secret
foo=bar

devient

database_password=*
foo=bar

et les autres utilisateurs de la vcs pouvez également configurer le mot de passe sur leur propre. Pour ignorer le fichier n'est pas une bonne approche, les développeurs doivent être conscients, si le fichier de configuration changements.

Exemple:

Version locale:

database_password=own_secret
foo=bar

fichier de config dans vcs:

database_password=*
foo=bar

Puis tout à coup, le fichier de configuration changements:

database_password=*
foo=bar
baz=foo

Et la version locale allait devenir pour chaque développeur:

database_password=own_secret
foo=bar
baz=foo

C'est ma solution. Comment pourrais-je atteindre ce comportement? Comment conservez-vous vos fichiers de configuration? Est-il un moyen de le faire, ou devrais-je hack quelque chose?

Answer 1

Au lieu de la version-le contrôle de la réelle fichier de configuration, vous pouvez placer un modèle ou un fichier de paramètres par défaut dans le contrôle de version, et un script qui demande la DB de l'information et des titres de compétences pour générer le vrai fichier de configuration, qui seraient exclus de (c'est à dire ignoré par) de contrôle de version. À la caisse, les développeurs pourraient exécuter ce script pour obtenir un environnement de travail. Ce script peut également être invoquée dans le cadre de tout processus d'installation de votre application utilise.

Aussi voir ma réponse à une question similaire.

Answer 2

Vous ne savez pas comment votre config est mis en œuvre, mais ayant hiérarchique overides est comment je pourrais gérer cela.

Vous avez une configuration principal qui contient de la commune de config plus factice nom d'utilisateur/mot de passe (ou laissez-les en tout). Chaque développeur crée alors une redéfinition locale.config (ou autre) avec leur nom d'utilisateur/mot de passe. Le principal config passe sous contrôle de code source, le développeur (ou la machine) les remplacements locaux ne pas.

J'ai fait cette dans le .NET, mais pas de PHP donc je ne sais pas comment facile ce serait, je le crains.

Answer 3

Créer un local remplace le fichier qui contient l'utilisateur spécifiques info comme des variables PHP.

Par exemple, créez un fichier appelé local_overrides.php qui contient les éléments suivants:

$local_password = 'qUzaEAFK13uK2KHy';

Puis dans le fichier qui contient votre base de données mot de passe de faire quelque chose comme ceci

$overrides = 'local_overrides.php';

if (file_exists($overrides)) {
   #include_once($overrides);
   $db_password = $local_password;
} else {
   // perform appropriate action: set default? echo error message? log error?    
   $db_password = 'l1m1t3d!'
}

Le local remplace le fichier n'a jamais à être vu par le contrôle de source.

Answer 4

Que penser d'un pre-commit hook à blanc les champs de nature délicate? Cela suppose que vous êtes à l'aise d'envoyer le fichier sur le réseau, en premier lieu, bien sûr.

Mise à jour pour l'autre bout du problème:
Pour gérer les mises à jour, vous feriez voulez forcer une fusion manuelle des fichiers sensibles, ou de modifier les locaux processus de construction de remplacer le sensible lignes avec le contenu d'un local/privé/ignorés fichier.

Answer 5

Avoir un fichier séparé avec SEULEMENT les secrets, qui n'est pas sous contrôle de version?

Ou, idéalement, de faire disparaître les mots de passe totalement l'utilisation d'openssh, ou similaire, et faire de clés publique/privée l'authentification de chaque utilisateur.