The configuration values are fetched at runtime from environment variables or configuration files directly.
Sembra che tu abbia già la possibilità di distribuzioni disaccoppiate perché dici che passi in configurazione in fase di esecuzione. Sembra che il tuo processo sia l'ostacolo alla distribuzione disaccoppiata della configurazione. La configurazione è accoppiata al software solo se fa parte degli artefatti in fase di compilazione e non può essere modificata in fase di runtime. Penso che tu stia confondendo i repository con le implementazioni. Non tutto ciò che è nello stesso repository deve essere distribuito insieme, e le cose che si trovano in repository separati possono essere distribuite insieme.
This would be for patches for instance where the application version x.y will fetch the latest configuration for x.y.*.
Che cosa intendi quando dici che la versione dell'applicazione x.y recupera la configurazione per x.y.* ? L'applicazione non dovrebbe essere scaricare config. La configurazione deve essere inoltrata da qualunque cosa avvii l'applicazione (tramite variabili d'ambiente o argomenti della riga di comando).
Penso che sia abbastanza importante mantenere la configurazione dello "sviluppatore" con il codice. Il codice dell'applicazione deve avere una configurazione appropriata per uno sviluppatore per clonare il repository, creare ed eseguire il software sul proprio sistema locale. Penso che le configurazioni dev, test e prod dovrebbero not essere nello stesso repository per un paio di motivi:
- Sicurezza - Anche se hai crittografato informazioni sensibili nella configurazione, non è ancora una buona idea tenerlo in VCS con il codice. Per esempio. non vorrai tenerlo in un repository open-source. Tale pratica incoraggia anche la chiave da condividere tra gli sviluppatori in modo che chiunque nel team possa aggiornare la configurazione quando cambia.
- Flessibilità: la base di codici dovrebbe essere progettata per essere eseguita con qualsiasi configurazione, non dovrebbe cercare di prevedere come verrà configurata una specifica implementazione di produzione. Ci possono essere infinite variazioni della configurazione, perché il repository del codice dovrebbe contenere quelle specifiche? Se vuoi creare più ambienti, avrai una proliferazione di file di configurazione.
- Separazione della responsabilità - In molte aziende il personale che scrive il software non è la stessa persona che ha configurato l'infrastruttura su cui verrà eseguito. Penso che sia più facile per il team che gestisce l'infrastruttura e l'implementazione del software per gestire la configurazione del software. Credo invece che gli ingegneri del software dovrebbero creare e mantenere la descrizione della configurazione e il team delle operazioni dovrebbe gestire quali host / database / password ecc. Vengano compilati.
The natural way to do this is to move the configuration values into a dedicated service that the applications will fetch them from, a REST API, backed by a database for instance
Non vedo questo come un miglioramento della tua configurazione attuale. In effetti è molto più complesso. Ora devi configurare il tuo sistema originale per parlare con il servizio di configurazione. Anche eseguire l'applicazione localmente ora richiederebbe l'esecuzione di un servizio aggiuntivo. Nello spirito di dipendenza dall'iniezione, il software non dovrebbe configurarsi da solo - la configurazione dovrebbe essere passata. Se dovessi sviluppare un servizio come lo stai descrivendo sarebbe meglio recuperare la configurazione dal servizio allora avvia l'applicazione con la configurazione scaricata anziché l'applicazione che recupera la propria configurazione.
I am a big proponent of keeping the code and configuration together in one repository. I just can't really quantify the upsides. Here are a few I can think of.
- Keeping configuration isolated from other applications'. Other application's configuration changes won't affect each other. (Changing a seemingly unshared configuration)
Non c'è nulla che ti impedisca di mantenere le configurazioni delle applicazioni separate l'una dall'altra e certamente la distribuzione di una configurazione non dovrebbe richiedere il ridistribuzione di tutte le configurazioni.
- Review of code and configuration at the same time in the same merge request.
Penso che sia strano. Significa che prima di rivedere il codice, è necessario decidere la configurazione di produzione? Se il mio cambiamento richiede un nuovo database, devo andare al team dell'infrastruttura, creare tutti i database per tutti gli ambienti, compilare i nomi degli host, i nomi utente e le password? Di nuovo se la descrizione della configurazione si trova nel repository di origine, che può essere rivista senza occuparsi della configurazione di produzione.