Tracciamento efficace delle modifiche alla configurazione da dev a prod

Questo è principalmente un problema di comunicazione, ma è possibile rendere gli errori meno probabili da alcune semplici misure tecniche e organizzative. Innanzitutto, dovresti fornire una buona documentazione di alta qualità di tutte le voci nei tuoi file di configurazione, oltre a un esempio facilmente accessibile o un file di configurazione "predefinito". Il file di esempio può essere distribuito automaticamente in ogni ambiente, poiché non è destinato a essere modificato dal team prod direttamente.

Successivamente, con ogni nuova versione, fornisci un log delle modifiche, in cui sono documentate importanti modifiche. Le modifiche alla configurazione che potrebbero impedire al sistema di funzionare quando sono mancanti sono sempre importanti, quindi assicurati che le informazioni siano disponibili.

For example, lets say dev team adds a few key-value pairs to application.properties in their environment. What would be the best way to record these new keys, so that when the deployment occurs in the ops team they know exactly which keys to add, so the risk of starting the new service and seeing it failed because of a missing key is minimized ?

Il modo migliore per ridurre il rischio di errori è quello di evitare di cambiare la tua applicazione in modo che richieda le nuove chiavi, quindi l'applicazione dovrebbe essere retrocompatibile con i file di configurazione più vecchi quando possibile. Spesso, l'applicazione può comportarsi in modo ragionevole fornendo valori predefiniti integrati per le nuove chiavi per il caso che mancano.

Tuttavia, se ciò non è possibile, il tuo sistema dovrebbe rendere il più semplice possibile il team prod per scoprire perché il nuovo servizio non si avvia quando la chiave è mancante. Dovrebbe esserci un messaggio di errore chiaro, che dice esattamente quale chiave manca in quale file e, se necessario, dove trovare le informazioni sulla chiave mancante , o un suggerimento o un esempio su una voce significativa per questa chiave.

Se la configurazione è complessa e il formato cambia in un modo in cui la modifica manuale diventa soggetta a errori, potresti anche considerare di fornire strumenti per la modifica delle configurazioni e per la migrazione a una versione più recente.

Ad esempio, sto utilizzando il browser Web Firefox e, con ogni nuova versione (che ottengo automaticamente), alcune cose vengono aggiunte alla configurazione locale che è possibile esaminare nella pagina "about: config". Questo è paragonabile alla configurazione del tuo ambiente di "produzione". Poiché l'intera configurazione è strettamente compatibile con le versioni precedenti, non devo mai aggiungere manualmente nuove chiavi alla configurazione solo perché c'è una nuova versione del browser. E per il caso voglio cambiare qualcosa lì (forse una nuova voce che non faceva parte della versione precedente), o usare il menu Strumenti / Opzioni, o la pagina "about: config", e posso trovare la voce più alcuni tipo di documentazione. Quindi ti consiglio di provare a implementare il tuo sistema in modo comparabile.

In un posto in cui una volta ho lavorato, avevano un problema simile. La configurazione di produzione era controllata dal team di build, solo loro avevano accesso ad esso nel repository di codice. Le configurazioni dev, qa, test, ecc ... potrebbero essere viste da tutti.

Nel tuo esempio, uno sviluppatore aggiornerebbe il file localmente, lo controllerà al controllo del codice sorgente, quindi qualcuno richiederebbe al team di build di creare una nuova build "config only" che verificasse i file di configurazione e li distribuisse, ma < em> non ricompilare o ridistribuire l'intera applicazione.

Spetta ai membri del team aggiornare i file di configurazione per altri ambienti al momento opportuno. Quando è arrivato il momento di aggiornare per la produzione, il team di build ha dovuto aggiornare il file, tramite una richiesta esplicita dal responsabile del team di sviluppo, anche se in genere la richiesta sembrava semplicemente "copia il file app.config da QA1 a PROD". Le cose sensibili come le password erano in un file di configurazione separato e, di nuovo, solo il team di build poteva accedere al file delle password di produzione. La differenza era che gli sviluppatori di solito non richiedevano modifiche ai file di password perché non avrebbero avuto password di produzione. L'unica volta in cui avrebbero chiesto al team di sviluppo di aggiornarlo era quando si aggiungeva una nuova password per un nuovo servizio. E anche allora, gli sviluppatori probabilmente non conoscono la password di produzione, conoscono solo la chiave da aggiungere al file (come "newService2.password").

La tecnologia utilizzata per gestire gran parte di questo è stata Jenkins. C'era anche uno strumento interno che veniva usato per richiedere e pianificare build attraverso Jenkins.