Nello sviluppo software moderno, in particolare quando si rilasciano nuove versioni, capita spesso di dover distribuire la stessa applicazione con configurazioni diverse. A seconda dell'ambiente di destinazione e di altri fattori o requisiti correlati, queste configurazioni possono modificare il comportamento dell'applicazione. Qualche esempio di queste variabili: aree geografiche multiple, nuove localizzazioni, casi d'uso differenti e così via.
Developer's Choice
**Configurazioni software: facciamo il punto**
Quando parlo di configurazioni diverse, è fondamentale capire che la maggior parte del software resta identica. A cambiare sono soltanto alcune parti relativamente piccole. Facciamo un esempio: immaginiamo di gestire una catena di negozi al dettaglio e di dover distribuire il software per le casse. La maggior parte delle installazioni sarà identica: non avrebbe senso un software completamente diverso per ogni cassa in base alla località del punto vendita. Anche se, in certi scenari, potrebbe pure essere così.
Torniamo alla configurazione. Restiamo sull'esempio dell'applicazione per le casse del retail. Ogni postazione che esegue l'applicazione deve avere un identificatore univoco: ecco la configurazione. Paesi diversi possono richiedere lingue predefinite differenti: di nuovo configurazione. Ci sono poi gli sviluppatori, che hanno bisogno del proprio "dev environment": ancora una volta, configurazioni leggermente diverse. Ma il software, in tutti questi casi, è lo stesso. Avete colto il concetto.
Tutte le modifiche al codice sorgente del nostro software le archiviamo già in version control. In alcuni casi abbiamo un processo che compila il codice sorgente in vari tipi di asset binari, archivi o container Docker. Il motivo è semplice: distribuire la "versione" giusta del software in modo più efficiente.
Separare per ottimizzare e migliorare
L'asset software distribuito deve incontrare la configurazione dell'ambiente in cui verrà eseguito: di norma si tratta di porzioni di configurazione rilevanti a livelli diversi, con una certa gerarchia. Questa configurazione può arrivare all'applicazione attraverso vari canali: variabili d'ambiente, caricamento di file predefiniti con i dati di configurazione, risposte a chiamate API hardcoded o "configurate" (tramite un altro metodo) e così via.
L'idea di fondo è che questa configurazione è dinamica e cambia nel tempo. Si potrebbe racchiudere TUTTA la configurazione e distribuirla OVUNQUE ogni volta insieme all'applicazione. Ma è un'attività dispendiosa che può (e deve) essere ottimizzata meglio. Il modo per farlo è adottare una cadenza diversa per il deployment e il rilascio dei dati di configurazione, separandoli dall'applicazione vera e propria.
Ed è proprio qui il punto chiave dell'ottimizzazione: separare il version control e la gestione dei dati di configurazione dal codice applicativo. Questa separazione funziona meglio quando la configurazione ha un proprio spazio di versioning, con un processo di deployment dedicato per distribuire e rilasciare le modifiche di configurazione. Un processo disaccoppiato da quello dei deployment applicativi e con una cadenza tutta sua.
Cosa ne pensate?
Grazie per la lettura! Per restare in contatto, seguiteci sul DoiT Engineering Blog , sul canale LinkedIn di DoiT e sul canale Twitter di DoiT . Per scoprire le opportunità di carriera, visitate https://careers.doit-intl.com .