Controllo della versione e file di configurazione personale

Il nostro progetto utilizza un file di configurazione specifico dell'utente. Questo file non è attualmente nel controllo versione, poiché è diverso per ciascun utente. Il problema è che ogni volta che uno sviluppatore aggiunge un nuovo modulo che richiede la configurazione o cambia il nome di un modulo esistente, gli altri sviluppatori ottengono errori perché i loro file di configurazione privati ​​non vengono aggiornati.

Per risolvere il problema, abbiamo pensato di lavorare con due file di configurazione: un file di configurazione predefinito / globale che sarà nel controllo della versione e verrà aggiornato regolarmente da ogni sviluppatore che aggiunge un nuovo modulo e un file di configurazione privato che verrà tenuto fuori del controllo versione e conterrà solo le modifiche specifiche dell'utente.

Tuttavia, questa sembra ancora una soluzione ad hoc.

Puoi proporre una soluzione migliore?

Cosa fanno i professionisti?

Sebbene tu abbia già ottenuto delle buone risposte qui, molti di loro mancano la causa principale del tuo problema: i tuoi file di configurazione dell'utente sembrano contenere più di informazioni specifiche dell'utente, contengono anche informazioni (forse ridondanti) che sono sotto controllo della versione da qualche altra parte , probabilmente in file diversi, come i nomi dei moduli.

Posso pensare a due possibili soluzioni qui:

• cerca di separare rigorosamente tali informazioni. Ad esempio, non utilizzare alcun nome di modulo nella configurazione dell'utente. Utilizzare i numeri ID (ad esempio, GUID) per fare riferimento ai moduli e lasciare che tali numeri ID non cambino mai dopo che sono stati assegnati a un modulo. Naturalmente, ciò ha probabilmente lo svantaggio che i file di configurazione dell'utente perdono un po 'della loro semplicità che potrebbero avere ora. Sarà forse necessario creare uno strumento GUI per modificare i file di configurazione invece di utilizzare un semplice editor di testo.

• assegna al tuo formato di file di configurazione un numero di versione e ogni volta che qualcosa come un nome di modulo viene modificato, assegna loro un nuovo numero di versione. Quindi è possibile fornire uno script di aggiornamento che controlla i numeri di versione e, se il file di configurazione non è aggiornato, cambia tutti i nomi dei moduli che trova all'interno del file e successivamente aumenta il numero di versione. Questo può essere automatizzato, quindi il processo di aggiornamento non disturberà i tuoi compagni di squadra nel loro lavoro quotidiano.

EDIT: dopo aver letto di nuovo il tuo post, penso che la tua presunta soluzione sia ragionevole, purché vengano aggiunti nuovi moduli, ma non rinominati. Ciò che ho scritto sopra consentirà di modificare in seguito i nomi dei moduli o la struttura della configurazione dei moduli esistenti. Ma se non ne hai bisogno, mi atterrei alla soluzione più semplice.

È una soluzione ragionevole.

È necessario un modo per specificare i valori iniziali di tutti i nuovi elementi di configurazione. Questi devono essere archiviati da qualche parte e un file di configurazione globale, di sola lettura, è la scelta ovvia.

Quindi quando ogni utente modifica la propria configurazione personale, scrivi queste modifiche nella loro copia locale.

Il codice dovrà prima leggere la configurazione globale e quella specifica dell'utente per sovrascrivere i valori modificati. Questo sarà molto più semplice che leggere quello locale e poi provare a capire quali non sono stati impostati e quindi hanno bisogno di leggere dal file delle impostazioni globali.

Se usi qualcosa come XML per l'archiviazione, non devi preoccuparti di gestire il caso in cui rimuovi le impostazioni. Non verranno richiesti dalla copia del file dell'utente e se si ricrea il file al momento del salvataggio verranno rimossi la prima volta che l'applicazione viene utilizzata dopo la modifica.

Abbiamo una soluzione un po 'interessante, siamo principalmente sviluppatori PHP, quindi utilizziamo Phing che ti consente di creare attività automatizzate scritte in PHP, quindi invece di fare il nostro normale aggiornamento svn, facciamo un "aggiornamento phing" che chiama svn update, e quindi sostituisce le nostre configurazioni con le variabili appropriate, ad esempio una configurazione:

$db_user = "${test.db_user}";

Quindi i file di configurazione sono tutti versionati con quella sintassi interessante, e quindi generiamo un file di configurazione ad hoc, non verificato per la mia istanza specifica, che sostituisce quelle "variabili" con impostazioni senzaversi specificate in file ini senzaversi. In questo modo possiamo modificare qualsiasi file specifico dell'utente e fare in modo che le modifiche vengano popolate in altre copie funzionanti.

Il programma dovrebbe avere un'impostazione predefinita nel codice per quando il valore non viene trovato nel file di configurazione. In questo modo, quando vengono aggiunte nuove cose, non si romperà, il percorso di aggiornamento sarà più fluido e gli utenti avranno il fallback anche quando confondono il file di configurazione.

Un altro esempio più complesso potrebbe essere all'avvio del programma o in qualche altro punto chiave, aprire il file di configurazione utilizzando un modulo di inizializzazione e aggiungere eventuali valori predefiniti mancanti, ma questo sembra piuttosto pesante.

Inserire un numero di versione nel file di configurazione personale (il numero di versione del formato del file di configurazione).

Fai in modo che il codice che elabora il file di configurazione personale controlli il numero di versione e, se non è aggiornato, esegui una procedura di aggiornamento. Quindi, fondamentalmente, chiunque apporti una modifica che interromperà i file di configurazione esistenti deve superare il numero di versione del formato del file di configurazione e scrivere una procedura per aggiornare i file di configurazione della versione precedente (rinominare sezioni, ecc.) E salvare nuovamente loro.

Probabilmente vorrai comunque un processo come questo per gli utenti finali, quindi potresti anche usarlo per rendere più facile la vita dei tuoi sviluppatori.

In genere, come ho visto, è necessario avere un file di configurazione con valori predefiniti controllati nel repository. Questi potrebbero essere, ad esempio, i valori necessari sul server di test. Quindi, quando uno sviluppatore estrae il file, avrà tutti i valori. Se viene aggiunto un nuovo campo o viene rimosso un campo, questo viene gestito in un'unione. Uno sviluppatore verificherà il valore necessario per il server di destinazione e non verificherà altre modifiche ai campi relative al proprio ambiente di sviluppo personale.

Si prende cura di garantire che l'unione sia fatta bene, ma mi sembra abbastanza sicura.

Quello che facciamo qui è creare blocchi di impostazioni. Questo può essere fatto in Zend in questo modo:

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

Ciò significa che il testing eredita la produzione e la estende con key3. Tutto ciò che ogni sviluppatore deve fare è impostare il proprio ambiente (test o produzione in questo caso)

Questa è una soluzione utile basata sul post: mantenere le password nel controllo del codice sorgente

In sintesi, la strategia consiste nel "mantenere una versione crittografata del file di configurazione nel controllo del codice sorgente e quindi fornire un mezzo attraverso il quale l'utente può crittografare e decrittografare tali dati".

1. Crea un file fittizio comfig e .gitignore.
2. Crea un makefile in grado di crittografare e decrittografare il file di configurazione
3. Archivia il makefile e il file di configurazione crittografato nel repository
4. Il makefile richiede una password e come contattare l'autore per la password.
5. Quando si crea il progetto, se il makefile non è stato eseguito, avvisare l'utente con console.error ("File di configurazione [conf / settings.json] mancante! Hai dimenticato di eseguire make decrypt_conf?");
6. Viene descritto un controllo per assicurarsi che il file di configurazione sia aggiornato.

Abbiamo creato uno strumento chiamato Config che gestisce problemi di configurazione come questo. Quello che farai è creare (o importare) 1 file di configurazione principale. Quindi creare un ambiente chiamato Local. Nell'ambiente locale, creare più istanze, 1 istanza per utente. Se è necessario apportare una modifica comune a tutta la scheda, come l'aggiunta di una nuova voce di configurazione o la modifica del nome del modulo, è sufficiente apportare la modifica e verrà applicata su tutta la scheda. Se si desidera modificare un'istanza / utente, impostare il valore di configurazione come variabile, quindi modificare la variabile. Questa modifica verrà applicata solo alla tua istanza / utente. Tutti questi sono sotto controllo della versione. Distribuisci i file di configurazione tramite push o pull. L'opzione pull è simile a git pull, ma per quella specifica istanza / utente.

Config ti offre funzionalità aggiuntive come il confronto delle configurazioni tra utenti, ricerca, tag, validazione e flusso di lavoro. È SaaS quindi non proprio per quelli non ancora pronti per il cloud, ma abbiamo un piano locale.