Branching: diversi file di configurazione per release / sviluppo

Ho ereditato un progetto e stiamo usando git. Abbiamo un numero di ambienti (dev, test, prod). Il team precedente ricreava praticamente ogni cosa su ogni istanza, usando gli stessi account, password, sid, ecc. L’unica cosa che cambiava era il mapping degli hostname in / etc / hosts. In modo che si connetterebbe a un server di database diverso.

Ora, questo crea un problema, perché non posso, ad esempio, copiare uno schema in modo che uno sviluppatore possa eseguire un esperimento utilizzando la stessa istanza di database del server di sviluppo principale. Fondamentalmente devo creare una nuova istanza di database su un altro host e cambiare / etc / hosts in modo che puntino a quel nuovo server.

Mentre questa è attualmente una configurazione funzionante, sto cercando di trovare un modo per mantenere diversi file di configurazione per ogni istanza. es .: diverse versioni di applicationConfig.xml seconda del ramo. Immagino che si possa obiettare che mantenere le credenziali del database nel repository non è una grande idea, ma lasciate semplicemente ignorare questo per un secondo.

Un’altra situazione che potrebbe giustificare avere una versione diversa di un file potrebbe essere il debug. Supponiamo che io stia usando un framework di logger javascript e aggiungo il codice di debug che non vorrei spedire con una release di produzione. Non voglio dover aggiungere il materiale del logger quando lo sviluppo / test e poi rimuoverlo di nuovo prima di rilasciare. Si potrebbe dimenticare di farlo.

Qual è il modo corretto di gestire diverse “versioni” di un file per diversi rami? C’è un modo per avere un ramo che rimane sincronizzato con l’ultimo codice sul master, ma con alcuni file di configurazione / codice modificati? Non mi aspetto che rimanga sincronizzato automaticamente, ma mi piacerebbe non poter unire i file di configurazione (o parte di essi) senza ignorarli completamente (?). Ad esempio: non unire le righe 6,7 (nome utente e password db), ma unire le altre modifiche ai file.

Sembra che dovresti leggere gli attributi git. Controlla la sezione in fondo a questa pagina

Questo è utile se un ramo nel tuo progetto è divergente o è specializzato, ma vuoi essere in grado di unire le modifiche da esso e vuoi ignorare determinati file. Supponiamo che tu abbia un file delle impostazioni del database chiamato database.xml che è diverso in due rami e che desideri unire all’altro ramo senza rovinare il file del database.

Come hai già detto, non è una buona idea memorizzare le impostazioni di configurazione all’interno del tuo codice. Soprattutto, a mio parere, i tuoi sviluppatori non dovrebbero nemmeno conoscere le credenziali per il database di produzione.

Quello che facciamo qui è che su ogni server abbiamo variabili d’ambiente predefinite che puntano a un file di configurazione che ha le credenziali necessarie. Poiché stiamo usando Java qui, questo è un file come database.properties e questo file non è mai all’interno di un sistema di controllo della versione.

Ciò consente inoltre di avere impostazioni diverse e credenziali diverse su ciascun server