Immaginiamo una situazione molto semplice quanto comune: è necessario cambiare il puntamento al server del database della nostra applicazione dopo che tutto è stato migrato nel nostro nuovissimo e scintillante Cloud™.

Tale situazione può essere messa in moto da un’innocente e-mail, inviata a mezza organizzazione, in un sonnolento martedì pomeriggio da un anonimo sistemista nascosto dietro un indirizzo mail di gruppo. Finito il rimpallo di “non capisco perché’ mandate questa mail al nostro gruppo”, “Di cosa stiamo parlando?”, “non capisco, ma comunque non abbiamo il budget per farlo!” rimane comunque il problema.

La cosa sembrerebbe semplice, giusto?

Cerchiamo nel file di configurazione la vecchia stringa di connessione, la modifichiamo, facciamo girare i test di integrazione e possiamo tornare a casa felici.

Ecco, chiunque abbia mai messo mano ad un’applicazione reale di una certa dimensione, sa bene che la questione spesso non è mai così semplice e così diretta.

La prima cosa che balza subito agli occhi dopo una rapida e sempre più affannosa ricerca è:

“bene, ma dov’è configurata la connessione al database?” O peggio ancora “ma se io ho modificato la connessione nel file web.xml, perché’ continuo a collegarmi al vecchio database?”

Step by step: soluzioni comuni ed errori da non ripetere

“To a man with a hammer, everything looks like a nail.”
— Twain/Maslow/Kaplan/Baruch/Buddha/Unknown

Ecco una raccolta di quello che normalmente si è fatto, e si fa tuttora per gestire tutte le configurazioni necessarie ad un sistema ma che possono variare nel tempo (nessuno vuole ricompilare e reinstallare un intero sistema per cambiare un logo in una pagina di menu vero? Siate onesti, almeno una volta nella vita l’avete dovuto fare).

1. File di configurazione

   Questa probabilmente è la tecnica più usata ed abusata della storia dell’informatica. Nella stragrande maggioranza dei casi è una tecnica assolutamente valida, semplice, manutenibile, ma è molto facile farsi del male, spesso da soli; mi vengono in mente alcuni esempi, tra i peggiori che ho potuto collezionare negli anni.

   La prima causa di dolore quando si ha a che fare con un file di configurazione è il formato del file che si è scelto. Xml, Json, ini… tutti belli e funzionali, senza dubbio, ma vogliamo parlare di Yaml, o meglio ancora Toml? (se non lo conoscete, andate a cercarlo, è un bel monito su come non organizzare un formato file).

   Altro problema è dove posizionare il file, un esempio illustre per tutti? L’uso poco felice dei file di properties di Java, che nella maggior parte dei casi vengono piazzati all’interno dell’applicazione stessa, obbligandoci ad una ricompilazione o comunque di mettere mano all’archivio per poter modificare un qualunque parametro.

2. Database

   Altra possibilità classica è il database: a chi non piace una bella tabella di parametri da cui andare a prendere tutte le configurazioni? Anche questo è un sistema molto usato e ha una serie di campi di applicazione assolutamente legittimi, ma anch’esso si porta dietro dei pericoli nascosti.

   I primi due che mi vengono in mente sono: la crescita spesso smisurata di queste tabelle di configurazione (mio malgrado devo usare il plurale) che ad un certo punto perdono il loro significato iniziale e diventano dei mostri ingestibili e il problema dell’uovo e della gallina: se ho la mia configurazione in un database… dove configuro la connessione al database?

3. Riga di comando o variabili d’ambiente

   Queste sono tecniche più usate nel mondo Unix, ma probabilmente tra le più vecchie.
   Anche in questo caso, di per sé sono ottime, ma può essere problematico passare configurazioni molto articolate, sono molto complesse da comprendere per chi non ha le competenze specifiche su quell’applicazione e capire l’attuale configurazione di un’applicazione in esecuzione può non essere così banale, soprattutto quando sono usate assieme.

   Queste tecniche, soprattutto le variabili d’ambiente, stanno tornando in voga moltissimo in ambienti containerizzati, come docker, kubernetes o il cloud.

4. Altri metodi

   Nella storia sono stati ideati molti altri metodi, più o meno funzionali, più o meno specifici in campi ristretti, alcuni molto eleganti, altri estremamente dannosi anche ad anni di distanza (sto pensando con un brivido al registro di Windows), altri inutilmente complessi e di difficile gestione (sto pensando a Websphere e ai suoi livelli multipli di configurazione).

Questa breve panoramica sui diversi metodi di configurazione ci ha permesso di capire le problematiche più comuni e gli errori da non fare.

Ma allora qual è il modo più corretto di gestire questa situazione?

Continua con la lettura: COME CONFIGURARE UN’APPLICAZIONE IN MODO EFFICACE E CON UN OCCHIO AL FUTURO – PARTE 2