Un server di sviluppo è d’obbligo

by Giuseppe Lanzi on 24 aprile 2012

Prima di mettere in produzione un’applicazione è necessario ridurre al minimo la possibilità degli utenti di riscontrare errori, perché ogni volta che qualcuno vede un errore peggiora la sua percezione del prodotto. Queste che vi propongo oggi possono sembrare considerazioni scontate, ma la mia esperienza nel reparto di assistenza mi ha fatto scoprire che non lo sono.

Ho notato che c’è un accorgimento relativamente semplice, anche se purtroppo poco adottato, che permette di ottenere buoni risultati: sviluppare su un ambiente uguale a quello di produzione.

Infatti ricevo spesso richieste di assistenza per problemi che si manifestano solo in produzione, e in molti casi i due ambienti sono diversi. Può bastare poco per causare un comportamento inaspettato dell’applicazione.

Le cause più frequenti sono:

  • Ambiente di sviluppo a 32bit, server a 64 bit
    Se non si configura il server per far girare l’applicazione a 32 bit, le librerie esterne utilizzate possono dare errore in fase di caricamento. Anche la libreria del web server di In.de IDWS.dll si comporta in questo modo. E’ quasi un classico.
  • La versione di java/C# è diversa
    Potrebbero manifestarsi errori nel caricamento delle librerie, oppure nel caricamento del contesto applicativo a causa di direttive specifiche usate nella macchina di sviluppo ma non valide in produzione.
  • La versione/configurazione del database è diversa
    Cito due esempi eclatanti che non hanno bisogno di spiegazione: dalla versione 8.3 di PostgreSQL i parametri delle query non sono più convertiti automaticamente in character, mentre prima lo erano; MySQL 5.01+ considera tutti i “\” del codice SQL come caratteri escape, ma dispone del parametro no_backslash_escapes che spegne questa funzionalità;

In assistenza dico spesso “cercando le differenze troveremo anche la causa del problema”. Sono proprio le differenze tra i due ambienti a causare i comportamenti imprevisti. Ne consegue che sviluppando su un ambiente identico alla produzione gli eventuali problemi verranno fuori durante lo sviluppo, non dopo il deploy.

Predisporre una copia dell’ambiente di produzione in locale richiede tempo, ma penso che non sia un elemento opzionale nello sviluppo e nella manutenzione di un software.

Se non avete già una soluzione del genere, vi consiglio di predisporla quanto prima. E se proprio non volete dedicare un server a questo scopo, almeno una macchina virtuale!

Leave a Comment

Previous post:

Next post: