Tracciamento efficace delle modifiche alla configurazione da dev a prod


9

Questa domanda prende ad esempio un servizio di avvio a molla, ma potrebbe essere qualsiasi tecnologia.

Supponendo quanto segue:

  • Gli ambienti (dev / QA / prod) sono di proprietà di diversi team. Questo significa che dev non deve avere accesso alla configurazione del prod.
  • La configurazione (diciamo application.properties) è esternalizzata, cioè non fa parte del binario
  • Lo stesso binario / pacchetto (diciamo service.jar) è distribuito in ogni ambiente e controllato da una distribuzione automatizzata

Mentre le modifiche all'artefatto binario (service.jar) vengono propagate automaticamente in ciascun ambiente, le modifiche alla configurazione necessitano comunque di un intervento manuale, che inevitabilmente finisce per essere sincronizzato in ogni ambiente.

Ad esempio, supponiamo che il team di sviluppo aggiunga alcune coppie chiave-valore a application.properties nel loro ambiente. Quale sarebbe il modo migliore per registrare queste nuove chiavi, in modo che quando la distribuzione si verifica nel team operativo sappia esattamente quali chiavi aggiungere, in modo da ridurre al minimo il rischio di avviare il nuovo servizio e vederlo fallito a causa di una chiave mancante?

So che ci saranno dei passaggi manuali, ma vorrei sapere come le persone affrontano questo problema e trovare il modo più efficace.


Snarky risposta: abbattere i silos. Crea team interfunzionali di sviluppatori e operatori (e chiunque altro tu abbia bisogno di sviluppare un prodotto, UX, marketing, QA, ecc.), Rendi il tuo team responsabile dello sviluppo, dell'implementazione e del supporto del prodotto, controlla tutte le configurazioni in VCS , automatizza le distribuzioni in tutti gli ambienti (sì, compresi i prodotti) e vai avanti con la tua vita.
RubberDuck,

Team pieni di funzionalità interfunzionali possono essere difficili da raggiungere in alcuni ambienti in cui la sicurezza costituisce un grosso limite.
Mathieu Fortin,

Conosco @MathieuFortin. Ecco perché ho commentato e lo ho preceduto con "risposta snarky" invece di rispondere. È la mia soluzione ideale, ma non quella che funzionerà per te, purtroppo.
RubberDuck,

Risposte:


3

Questo è principalmente un problema di comunicazione, ma è possibile rendere gli errori meno probabili con alcune semplici misure tecniche e organizzative. Innanzitutto, è necessario fornire una documentazione di alta qualità di tutte le voci nei file di configurazione, nonché alcuni esempi facilmente accessibili o file di configurazione "predefinito". Il file di esempio può essere distribuito automaticamente in ciascun ambiente, poiché non è progettato per essere modificato direttamente dal team di produzione.

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

Ad esempio, supponiamo che il team di sviluppo aggiunga alcune coppie chiave-valore a application.properties nel loro ambiente. Quale sarebbe il modo migliore per registrare queste nuove chiavi, in modo che quando la distribuzione si verifica nel team operativo sappia esattamente quali chiavi aggiungere, in modo da ridurre al minimo il rischio di avviare il nuovo servizio e vederlo fallito a causa di una chiave mancante?

Il modo migliore per ridurre il rischio di errori è evitare di modificare l'applicazione in modo da richiedere le nuove chiavi, quindi l'applicazione dovrebbe essere retrocompatibile con i file di configurazione precedenti quando possibile. Spesso, l'applicazione può comportarsi in modo ragionevole fornendo valori predefiniti incorporati per le nuove chiavi nel caso in cui manchino.

Tuttavia, se ciò non è possibile, il sistema dovrebbe rendere il più semplice possibile per il team di produzione scoprire perché il nuovo servizio non si avvia quando manca la chiave. Dovrebbe esserci un messaggio di errore chiaro, che indica esattamente quale chiave manca in quale file e, se necessario, dove trovare le informazioni sulla chiave mancante o un suggerimento o 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 usando il browser Web Firefox e ad ogni nuova versione (che ottengo automaticamente), alcune cose vengono aggiunte alla configurazione locale che è possibile controllare nella pagina "about: config". Questo è paragonabile alla configurazione nel tuo ambiente di "produzione". Poiché l'intera configurazione è mantenuta strettamente compatibile con le versioni precedenti, non devo mai aggiungere nuove chiavi alla configurazione solo perché c'è una nuova versione del browser. E nel caso in cui volessi cambiare qualcosa lì (forse una nuova voce che non faceva parte della versione precedente), utilizzo il menu Strumenti / Opzioni o la pagina "about: config" e posso trovare la voce più alcuni tipo di documentazione. Quindi consiglio di provare a implementare il tuo sistema in modo comparabile.


0

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

Nel tuo esempio, uno sviluppatore aggiorna il file localmente, lo archivia per il controllo del codice sorgente e quindi qualcuno richiederebbe al team di compilazione di fare una nuova build "solo configurazione" che ha estratto i file di configurazione e li ha distribuiti, ma non ha ricompilato o ridistribuire l'intera applicazione.

Spetta ai membri del team aggiornare i file di configurazione per altri ambienti al momento opportuno. Quando era il momento di eseguire l'aggiornamento per la produzione, il team di compilazione doveva aggiornare il file, tramite una richiesta esplicita da parte del responsabile del team di sviluppo, sebbene di solito la richiesta fosse semplicemente "copia il file app.config da QA1 a PROD". Elementi sensibili come le password si trovavano 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 norichiedere modifiche ai file delle password perché non avrebbero avuto password di produzione. L'unica volta che hanno chiesto al team di build di aggiornarlo è stato quando hanno aggiunto una nuova password per un nuovo servizio. E anche allora, gli sviluppatori probabilmente non conoscono la password di produzione, saprebbero solo la chiave da aggiungere al file (come "newService2.password").

La tecnologia utilizzata per gestire molto di tutto ciò era Jenkins. C'era anche uno strumento interno che veniva utilizzato per richiedere e pianificare build tramite Jenkins.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.