Cómo versionar los archivos de configuración de control pragmáticamente?

Question

Supongamos que tenemos un archivo de configuración con contraseñas confidenciales. Me gustaría controlar la versión de todo el proyecto, incluido el archivo de configuración también, pero no quiero compartir mis contraseñas.
Eso podría ser bueno, si este archivo de configuración:

database_password=secret 
foo=bar 

convierte

database_password=* 
foo=bar 

y los demás usuarios de las VCS también podría configurar la contraseña en su propiedad. Ignorar el archivo no es un buen enfoque, los desarrolladores deben tener en cuenta si el archivo de configuración cambia.

Ejemplo:

versión local:

database_password=own_secret 
foo=bar 

archivo de configuración en VCS:

database_password=* 
foo=bar 

Entonces, de repente, el archivo de configuración cambios:

database_password=* 
foo=bar 
baz=foo 

y lo local versión w debería ser para cada desarrollador:

database_password=own_secret 
foo=bar 
baz=foo 

Esta es mi solución. ¿Cómo podría lograr este comportamiento? ¿Cómo almacena sus archivos de configuración? ¿Hay alguna manera de hacerlo, o debería piratear algo?

Answer 1

En lugar de controlar la versión del archivo de configuración real, puede poner una plantilla o archivo predeterminado en control de versión y un script que solicite información de DB y credencial para generar el archivo de configuración real, que se excluirá de (es decir, ignorado por) control de versiones. Al finalizar la compra, los desarrolladores podrían ejecutar este script para obtener un entorno de trabajo. Este script también se puede invocar como parte de cualquier proceso de instalación que use su aplicación.

También see my answer a una pregunta similar.

Answer 2

En mis proyectos utilizo un directorio que contiene este tipo de archivos pero no se carga en el servidor, por lo que mi archivo de configuración db está en ese directorio y está configurado para el servidor donde se ubica el proyecto. Si alguien cambia el archivo de configuración, cambiará el archivo de configuración del servidor y cualquiera que actualice la revisión verá los cambios en ese archivo y necesitará cambiar manualmente su configuración local.

No veo la manera de hacerlo en lugar de eso. Si encuentra un enfoque diferente, por favor comparta.

Answer 3

¿Tiene un archivo separado con SÓLO los secretos, que no está bajo control de versión?

O, idealmente, elimine las contraseñas y use openssh, o similar, y realice la autenticación de clave pública/privada para cada usuario.

Answer 4

Estoy acostumbrado a hacer un archivo txt con la estructura del archivo de configuración. Y después de eso, haré una copia y cambiaré la extensión y dejaré que mi sistema de control de versiones ignore este (s) archivo (s).

Por lo tanto, cuando realice cambios en el archivo de configuración, simplemente actualice la versión de texto. Esa es la única opción que se me ocurre, que es la lógica, así (en mis ojos)

Answer 5

No

seguro de cómo se implementa su configuración, pero tener overides jerárquica es cómo iba a manejar esto.

Tiene una configuración principal que contiene configuración común más nombre de usuario/contraseña ficticia (o los omite por completo). Cada desarrollador crea un override.config local (o lo que sea) con su nombre de usuario/contraseña específico. La configuración principal pasa a estar bajo control de fuente, las modificaciones locales del desarrollador (o máquina) no lo hacen.

He hecho esto en .NET pero no en PHP, así que no sé qué tan fácil sería, me temo.

Answer 6

¿Qué tal un gancho precompromiso para borrar los campos confidenciales? Esto supone que te sientes cómodo enviando el archivo a través de la red en primer lugar, por supuesto.

Actualización para el otro extremo del problema:
Para tratar las actualizaciones, que había ya sea quiere forzar una fusión manual de los archivos confidenciales, o modificar el proceso de construcción locales sobreescribir las líneas sensibles con el contenido de un local/privado/archivo ignorado.

Answer 7

Tuve algo similar a esto aunque no sé si funcionaría para usted. Tenía un directorio que contenía archivos que contenían contraseñas. Este directorio no estaba controlado por la versión. Los archivos fueron nombrados después de las aplicaciones que los usaron y en los archivos de configuración, obtuve el archivo de contraseña apropiado en el momento en que era necesario. Esto exigiría que su analizador de configuración pueda manejar el origen.

Answer 8

Crea un archivo de modificaciones locales que contiene la información específica del usuario como variables de PHP.

Por ejemplo crear un archivo llamado local_overrides.php que contiene lo siguiente:

$local_password = 'qUzaEAFK13uK2KHy'; 

A continuación, en el archivo que incluye su contraseña de base de hacer algo como esto

$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!' 
} 

El archivo se anula locales nunca debe ser visto por control de fuente.

Answer 9

Mi respuesta preferida a esto ya se mencionó aquí: compruebe un archivo ficticio, genere el archivo "real" copiando el archivo ficticio en tiempo de ejecución e ignore el archivo "real" en su VCS.

ya he respondido a una pregunta similar, con un ejemplo completo de cómo hacer esto en Visual Studio:
how to ignore files in kiln/mercurial using tortoise hg "that are part of the repository"