Git: configurazione dell'applicazione e diversi ambienti

Question

Utilizziamo la git per la maggior parte delle applicazioni Web che costruiamo nel nostro negozio, e sebbene le applicazioni stesse utilizzino una varietà di tecnologie (PHP, Rails, ecc.), Generalmente abbiamo una produzione e una produzione server per ogni sito. In genere, questi server dispongono di serie diverse di credenziali del database nonché di diverse impostazioni di configurazione basate sull'ambiente (ad esempio la memorizzazione nella cache). Il nostro flusso di lavoro generalmente prevede il mantenimento di due rami git per progetto: master, che riflette il server di produzione e la gestione temporanea, che riflette la gestione temporanea. Le nuove funzionalità sono sviluppate su staging (o su un sotto-ramo) e sono unite al master una volta completate e implementate.

La mia domanda riguarda il modo migliore per mantenere i file di configurazione specifici per ramo e ambiente. Ho visto le risposte di domande simili here e here e nessuna delle due soddisfa davvero. I due principali approcci sembrano essere: a) utilizzare l'esclusione di gitignore per lasciare file di configurazione al di fuori della portata di git, oppure b) scrivere un codice riflettente e sensibile all'ambiente che determina ad es. quali credenziali del database utilizzare in base al nome host. Il mio problema con a) è che consente solo a un set di file di configurazione di esistere nella base di codice (indipendentemente dal ramo corrente), quindi i file di configurazione di altri ambienti vengono persi. b), d'altra parte, sembra semplicemente richiedere modifiche non necessarie della base di codice in un modo che non sembra correlato alle funzionalità dell'applicazione.

Idealmente, mi piacerebbe un modo per "bloccare" i file di configurazione all'interno di un certo ramo, in modo che ogni volta che eseguo il checkout, ottengo i file di configurazione principale e ogni volta che eseguo il checkout, ottengo i file di configurazione della staging. Inoltre, l'unione della gestione temporanea in master non dovrebbe influire in alcun modo sui file di configurazione principali. Ad oggi, ci siamo occupati di questo fatto avendo cartelle contenenti file di configurazione specifici per l'ambiente al di fuori della root git e spostando manualmente i file appropriati in codebase durante la distribuzione, ma questo è ovviamente inutilmente hackish (e potenzialmente pericoloso).

C'è un modo per farlo usando git?

Grazie per la vostra considerazione!

Answer 1

Non sono sicuro del motivo per cui le persone pensano di poter andare via senza una sorta di strumento di installazione. Git riguarda il tracciamento dell'origine, non la distribuzione. Dovresti comunque avere uno strumento di tipo "make install" per passare dal repository git alla distribuzione effettiva, e questo strumento potrebbe fare varie cose come l'espansione del template o la selezione di file alternativi.

Ad esempio, è possibile che "config.staging" e "config.production" siano archiviati in git e, quando si distribuisce in staging, lo strumento di installazione seleziona "config.staging" da copiare in "config". Oppure potresti avere un singolo file "config.template", che sarà messo in forma per creare "config" nella distribuzione.

Answer 2

Suppongo che di solito, master registri solo commit che sono già in staging. Se aggiungi un commit aggiuntivo a master che contiene le differenze di configurazione tra i due rami, quindi la modifica di questo commit in cima a qualsiasi cosa estratta da staging dovrebbe mantenere la configurazione. Questo non è così semplice come "la fusione della messa in scena in master non dovrebbe influenzare in alcun modo i file di configurazione master", ma poiché in questi casi si otterrebbe un conflitto di unione, potrebbe essere abbastanza vicino.

Answer 3

Si potrebbe provare a utilizzare i ganci post-merge o post-checkout per verificare che tutto sia come dovrebbe essere e correggerlo in caso contrario. Questo in realtà seems to be suggested by the ProGit book.

Il concetto è fondamentalmente quello di scrivere quegli hook per fungere da mini script "make install" che assicurano la corretta configurazione per ramo, per host, per presenza o contenuto di altri file, da qualsiasi cosa tu voglia.I ganci potrebbero anche riscrivere i tuoi file di configurazione o ricrearli compilando i modelli.