Ambienti

Per abilitare lo sviluppo dei progetti software, sono stati messi a disposizione una serie di ambienti di programmazione che permettono di implementare le fasi del Software Lifecycle, che vedremo nel paragrafo successivo.

Ciascun ambiente è caratterizzato da:

- gli utenti che lo utilizzano;

- chi richiede il rilascio del pacchetto nell’ambiente;

- chi esegue il rilascio nell’ambiente;

- chi effettua la manutenzione dell’infrastruttura.

79

Figure 24 - Ambienti

Nello schema in figura è rappresentata una mappa degli ambienti forniti; essi possono essre suddivisi in tre categorie: sviluppo, quality assurance e produzione.

8.1.1 Sviluppo

Con ambiente di sviluppo viene indicato l’insieme di infrastrutture e middleware che la banca mette a disposizione ai gruppi di sviluppo per supportare l’implementazione dei progetti software.

Esistono tre differenti ambienti di sviluppo: macchina di sviluppo, sviluppo di team e architetture.

Macchina di sviluppo

Per facilitare lo sviluppatore nel velocizzare il processo di setup dei tool di sviluppo, sono state predisposte delle virtual machine contenenti tutte le applicazioni e configurazioni necessarie allo sviluppo delle componenti di frontend e backend.

80 Sviluppo di Team

Lo scopo di questo ambiente è fornire la possibilità ai gruppi di sviluppo di provare e testare il software implementato in un ambiente centralizzato, dove è disponibile tutto il middleware che viene utilizzato anche in ambiente di produzione.

Questo è un ambiente centralizzato completamente gestito da gruppi di sviluppo (a parte l’infrastruttura, gestita dal gruppo di erogazione), che si occupano di decidere quali pacchetti installarvi ed effettuarne il deploy.

Risulta molto utile nel caso di sviluppo di un’applicazione fra diversi gruppi di lavoro:

qui si possono installare i vari pacchetti forniti dai vari gruppi e verificare che tutto stia procedendo correttamente; oppure effettuare un test “verticale” di pacchetti appartenenti a differenti elementi dell’architettura che si sta sviluppando (JBus, OSB, Backend).

Architetture

Lo scopo è di fornire sia al gruppo di sviluppo che al gruppo di architetture un ambiente il più possibile allineato con la produzione, in cui anche l’installazione dei pacchetti viene gestita centralmente: se un gruppo id sviluppo vuole effettuare il deploy di un pacchetto, deve richiederlo ai responsabili DevOps, che si occuperanno di portare il pacchetto nell’ambiente.

Oltre che ai gruppi di sviluppo, questo ambiente è a disposizione del gruppo di architetture per la fase di progettazione, per studi di fattibilità o per analisi tecniche.

8.1.2 Quality Assurance

Con quality assurance andiamo ad indicare quegli ambienti creati allo scopo quello di verificare la qualità del codice del pacchetto di cui viene richiesto il rilascio in

produzione, eseguendone i test per individuare eventuali defect.

Ambiente di integrazione

L’ambiente di integrazione viene principalmente utilizzato dal gruppo di sviluppo per effettuare i test di integrazione fra i pacchetti software sviluppati ed il resto del

sistema in cui verranno inseriti; inoltre viene utilizzato per effettuare eventuali long running test sui pacchetti implementati.

In questo ambiente l’installazione dei pacchetti viene fatta dai responsabili DevOps, su richiesta del gruppo di sviluppo.

La differenza principale di questo ambiente di integrazione rispetto agli ambienti centralizzati forniti per lo sviluppo sono i dati: l’ambiente di integrazione non

81

contiene dati allineati alla produzione, ma a differenza dell’ambiente di sviluppo, risultano essere più consistenti e forniscono test più attendibili.

Ambiente di System test

L’ambiente di System test viene utilizzato dal gruppo di test per eseguire le verifiche sui pacchetti di cui è stato richiesto il rilascio, con lo scopo di individuare eventuali defect presenti nel codice ed ottenere una certificazione dei pacchetti che andranno a far parte della release. Il rilascio del pacchetto nell’ambiente di System Test avviene da parte del gruppo di Release Management solamente dopo che il gruppo di sviluppo ha effettuato una richiesta formale (attraverso una RFC, Request For Change) per il rilascio del pacchetto in questione; per poter essere installato in system test, il software deve superare alcuni Quality Gates.

Gli artefatti restano in questo ambiente per un tempo ben determinato (1/2

settimane), necessario al gruppo di test per creare, sulla base dei requisiti funzionali utilizzati per lo sviluppo, i test ed successivamente applicarli al codice da certificare.

Ambiente UAT (User Acceptance Test)

Per i pacchetti che superano il system test devops può richiedere il loro rilascio nell’area dedicata agli User Acceptance Test; questo ambiente viene utilizzato dal gruppo di demand e di business per verificare che il software implementato sia funzionale per l’utente finale, controllando che soddisfi tutti i requisiti e gli use case iniziali, individuati in fase di progettazione. La gestione dell’infrastruttura ed il rilascio dei pacchetti viene gestito dal gruppo erogazione.

8.1.3 Produzione

Dopo aver superato la fase di quality assurance, i pacchetti sono pronti per essere portati in produzione ed utilizzati dagli utenti finali. Oltre all’ambiente di produzione.

che permette agli utenti finali di fruire dei servizi messi a disposizione, è stato creato un ambiente per agevolare il passaggio dei pacchetti in produzione e diminuire il rischio di malfunzionamenti.

Ambiente Pre Produzione

Questo ambiente contiene gli stessi dati e le stesse versioni del software di

produzione; dopo aver selezionato quali pacchetti dovranno far parte del pacchetto di release, è DevOps a richiederne l’installazione in quest’area al gruppo di erogazione;

sarà compito del gruppo di test effettuare una serie di verifiche per certificare la

82

release. A questo punto il pacchetto di release viene bloccato nell’ambiente per due giorni, e dopo questio periodo, la produzione viene riallineata. Questa permette di rendere meno traumatica la transizione in produzione del pacchetto di rilascio ed avere una maggiore reattività nell’analisi di anomalie critiche. Inoltre si riesce a dare maggiore continuità all’ambiente di System Test, rendendo più semplice il passaggio dei pacchetti da testare.

Se vengono trovati errori o elementi non in linea con quanto richiesto durante il testing nell’ambiente di Pre Produzione, vengono aperti dei defect (segnalazioni) che generano branch di hot-fixing; queste correzioni devono però riuscire ad arrivare entro un certo tempo limite, quando il codice viene bloccato: se i defect non sono stati risolti, il rilascio in produzione non verrà effettuato.

Ambiente di produzione

È ’ l’ambiente dove sono installati tutti i pacchetti software utilizzati dagli utilizzatori finali; anche questo ambiente, come in pre produzione, il rilascio dei pacchetti viene gestito dal gruppo di erogazione.

8.1.4 Transizioni tra gli ambienti

In accordo con il software lifecycle, nello schema seguente vengono rappresentati i passaggi fra i vari ambienti che un artefatto esegue passando dalla fase di sviluppo fino alla produzione.

Figure 25 - Schema di rilascio

83