Controllo della versione e file di configurazione personale

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

Posso pensare a due possibili soluzioni qui:

• cerca di separare queste informazioni rigorosamente. Ad esempio, non utilizzare nomi di moduli nella configurazione utente. Utilizzare i numeri di identificazione (ad esempio, GUID) per fare riferimento ai moduli e lasciare che quei numeri di ID non cambino mai dopo che sono stati assegnati a un modulo. Ovviamente, questo probabilmente ha lo svantaggio che i file di configurazione dell'utente perdono parte della loro semplicità che potrebbero avere ora. Avrai forse bisogno di creare uno strumento GUI per modificare i tuoi file di configurazione invece di usare un editor di testo semplice.

• dai al tuo file di configurazione il formato di una versione, e ogni volta che qualcosa come il nome di un modulo viene cambiato, assegna loro un nuovo numero di versione. Quindi è possibile fornire uno script di aggiornamento che verifica 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 aumenta successivamente il numero di versione. Questo può essere automatizzato, quindi il processo di aggiornamento non disturberà i 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é i nuovi moduli siano appena aggiunti, ma non rinominati. Quello che ho scritto sopra permetterà di modificare i nomi dei moduli o la struttura della configurazione dei moduli esistenti in seguito. Ma se non ne hai bisogno, mi attengo alla soluzione più semplice.

È una soluzione ragionevole.

Hai bisogno di un modo per specificare il / i valore / i iniziale / i di ogni nuovo elemento (i) di configurazione. Questi devono essere memorizzati da qualche parte e un file di configurazione globale, di sola lettura, è la scelta più ovvia.

Quindi, quando ciascun utente modifica la sua configurazione personale, scrive queste modifiche sulla sua copia locale.

Il tuo codice dovrà leggere prima la configurazione globale e quella specifica dell'utente per sovrascrivere qualsiasi valore modificato. Questo sarà molto più semplice della lettura di quella locale e quindi cercando di capire quali non sono stati impostati e quindi è necessario leggere dal file delle impostazioni globali.

Se si utilizza qualcosa come XML per l'archiviazione, non è necessario preoccuparsi di gestire il caso in cui si rimuovono le impostazioni. Non verranno richiesti dalla copia degli utenti del file e se si ricrea il file al salvataggio verranno rimossi la prima volta che l'applicazione viene utilizzata dopo la modifica.

Abbiamo una soluzione alquanto interessante, siamo principalmente sviluppatori PHP, quindi usiamo Phing che ti permette di creare attività automatizzate scritte in PHP, quindi invece di fare il nostro normale svn update, facciamo un "phing update" 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 revisionati con quella sintassi interessante, e quindi generiamo un file di configurazione ad hoc, non modificato per la mia specifica istanza, che sostituisce quelle "variabili" con impostazioni non modificate specificate nei file ini non verificati. In questo modo possiamo modificare qualsiasi file specifico dell'utente e far sì che le modifiche si diffondano su tutte le altre copie di lavoro.

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

Un altro esempio più complesso potrebbe essere all'avvio del programma o ad altri punti chiave, aprire il file di configurazione usando un modulo di inizializzazione e aggiungere eventuali valori di default mancanti, ma questo sembra piuttosto pesante.

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

Crea il codice che elabora il file di configurazione personale, controlla il numero di versione e, se non è aggiornato, esegui una procedura di aggiornamento. Quindi, in pratica, chiunque apporti una modifica che interrompa i file di configurazione esistenti deve eseguire il bump del numero di versione del formato di file di configurazione e scrivere una procedura per aggiornare i file di configurazione della versione precedente (rinominare le sezioni, ecc.) E ri-salvare loro.

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

In genere, come ho visto fare è avere un file di configurazione con i valori predefiniti controllati nel repository. Questi potrebbero essere, ad esempio, i valori necessari sul server di test. Quindi, quando uno sviluppatore controlla il file, avranno 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 che sono per il suo ambiente di sviluppo personale.

Ci si assicura che l'unione sia eseguita correttamente, ma a me sembra abbastanza sicuro.

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 test eredita la produzione e la estende con key3. Tutti gli sviluppatori devono quindi 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 comfig fittizio e .gitignore.
2. Crea un makefile in grado di crittografare e decodificare 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 ("Config file [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 Locale. Nell'ambiente Locale, crea più istanze, 1 istanza per utente. Se è necessario apportare una modifica comune su tutta la linea, ad esempio aggiungendo una nuova voce di configurazione o modificando il nome del modulo, è sufficiente apportare la modifica e verrà applicata su tutta la linea. Se si desidera modificare un'istanza / utente, impostare tale valore su una variabile, quindi modificare la variabile. Questa modifica verrà applicata solo all'istanza / utente. Tutti questi sono sotto controllo di versione. Distribuisci i file di configurazione tramite push o pull. L'opzione pull è simile a git pull, ma per quella specifica istanza / utente.

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