Come gestire ambienti di sviluppo e produzione con AngularJS

Una prassi comune lavorando nel mondo server-side è definire diversi ambienti di esecuzione e di deploy per le proprie applicazioni. Solitamente troviamo almeno un ambiente dedicato allo sviluppo ed un altro che rappresenta l’ambiente di produzione. I vari ambienti si differenziano utilizzando diversi valori per parametri comuni quali le credenziali di accesso al database, l’attivazione degli strumenti di log, il modello di autenticazione, ecc.

Uno dei primi ostacoli che si incontrano lavorando con un framework client-side come AngularJS è quello di trovare un meccanismo per poter differenziare l’ambiente di esecuzione della propria applicazione senza poter contare sugli strumenti abituali disponibili lato server.

In questo articolo mostreremo una possibile soluzione realizzata collaborando assieme a PhotoSì e Fabio Masini basata sulla riscrittura dei nostri file sorgenti tramite task Grunt che valorizza determinate variabili JavaScript a seconda che si voglia eseguire la nostra applicazione in un ambiente di sviluppo o in un ambiente test.

In particolare vedremo come utilizzare diversi endpoint REST a seconda dell’ambiente di esecuzione che vogliamo utilizzare.

Premessa

Per Grunt esistono diversi moduli che offrono la possibilità di effettuare text-replacing. In questo articolo utilizzeremo (string-replace) essendo molto facile da configurare ed integrare nel processo di build del proprio progetto.

Il codice mostrato nell’articolo fa riferimento ad una possibile applicazione creata usando il popolare tool di scaffolding (Yeoman).

File di settings

Una buona pratica che gli sviluppatori JavaScript hanno mutuato dal mondo server-side è centralizzare la parametrizzazione della propria applicazione in uno o più file di setting. Di seguito possiamo vedere un esempio di file di settings contenente gli endpoint REST usati dalla nostra applicazione per recuperare i dati. Il file utilizza la variabile ‘RUNNING_ENV’ per determinare se l’ambiente di esecuzione corrisponde a quello di test o a quello di produzione:

angular.module('myApp')
 .factory('settings', function () {
 //questa variabile viene riscritta dal task 'distProd' valorizzandola a 'PROD_ENV'
 var RUNNING_ENV = 'TEST_ENV';

 var ENDPOINT_BASE_URL = RUNNING_ENV === 'TEST_ENV' ? 'http://test.api.myapp' : 'http://api.myapp';

 var settings = {
  'CUSTOMER_LIST' : ENDPOINT_BASE_URL + '/customers/',
  'ORDER_LIST' : ENDPOINT_BASE_URL + '/orders/'
 };

 return settings;
});

Il nostro scopo, come riportato anche nel commento del codice appena visto, è quello di creare un task grunt chiamato ‘distProd’ che una volta lanciato cambi il valore della variabile ‘RUNNING_ENV’ da ‘TEST_ENV’ a ‘PROD_ENV’ per poter utilizzare gli endpoint di produzione.

Struttura del nostro progetto

Di default la configurazione di Grunt che utiliziamo fornisce il task di build che crea una versione di distribuzione della nostra applicazione eseguendo tutte le operazioni preliminari di ottimizzazione (CSS minification, concatenazione dei file js in un unico file uglyfied, compressione dell’HTML, ecc.).

Il risultato di questo task viene posto nella sottocartella ‘dist’ che a sua volta contiene la cartella ‘scripts’ dove troviamo i due file js generati: uno contenente le librerie di terze parti (vendor_xxx.js) ed un altro contenente il codice della nostra applicazione (scripts_xxx.js).

Di seguito riportiamo l’organizazione dei file del nostro progetto:

.\myapp
 |   bower.json
 |   Gruntfile.js
 |   package.json
 |   README.md
 |
 \---app
 \---test
 \---dest
 +---scripts
     |   scripts_xxx.js
     |   vendor_xxx.js

Creazione dei nuovi task

Ciò che dobbiamo fare è creare un nuovo task grunt che si metta “a valle” del build di default e operi la sostituzione del valore ‘TEST_ENV’ con ‘PROD_ENV’. Per prima cosa seguendo la documentazione disponibile sul sito di string-replace impostiamo il task che cercherà i file JavaScript da scansionare nella sottocartella ‘dist/scripts/’ e che sostituira’ ‘TEST_ENV’ con ‘PROD_ENV’:

'string-replace': {
   dist: {
     files: [{
     expand: true,
     cwd: './dist/scripts/',
     src: '*.js',
     dest: './dist/scripts/'
   }],
   options: {
     replacements: [{
       pattern: 'TEST_ENV',
       replacement: 'PROD_ENV'
     }]
    }
   }
 }

Ora possiamo definire il task ‘distProd’ che semplicemente eseguirà ‘string-replace’ dopo aver effettuato il regolare build dell’applicazione:

grunt.registerTask('buildProd', [
   'build',
   'string-replace'
 ]);

Conclusioni

Con i due nuovi task creati sarà sufficiente eseguire ‘grunt buildProd’ dalla root del progetto per produrre una versione della nostra applicazione adatta alla pubblicazione in ambiente di produzione.

Loading Facebook Comments ...
0 commenti

Lascia un Commento

Vuoi partecipare alla discussione?
Fornisci il tuo contributo!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *