Automazione del rilascio delle business application e dell’ambiente operativo Comprendere la proposta di valore di entrambe le soluzionidi Julian Fish, Director of Product Management, Serena Software (ora parte di Micro Focus)

White paper

Sommario pagina

Panoramica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Perché automatizzare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Breve storia dell’automazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Il progresso non è sempre difficile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Che cos’è l’automazione dell’infrastruttura? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Che cos’è l’automazione del rilascio delle applicazioni? . . . . . . . . . . . . . . . . . . . 5

Tratti comuni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Deployment Automation e Puppet per l’automazione dell’infrastruttura . . . . . 8

Deployment Automation e Puppet per l’automazione del rilascio delle applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Il valore delle pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Distribuzioni guidate da modelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Un piccolo problema di estensibilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Il meglio dei due mondi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1www.microfocus.com

Panoramica

Le organizzazioni all’inizio del loro percorso di trasformazione verso il DevOps, o quelle

che semplicemente desiderano automatizzare l’impostazione e la configurazione dei loro

ambienti, sono spesso confuse sul valore degli strumenti per l’automazione dei rilasci delle

applicazioni in contrapposizione a quelli per l’automazione dell’infrastruttura . È disponibile

una ricchissima scelta di strumenti, con molti ruoli dalle prestazioni apparentemente

identiche . In questo white paper, vengono descritte due soluzioni leader del mercato:

Deployment Automation1 per l’automazione del rilascio delle applicazioni e Puppet2 per

l’automazione dell’infrastruttura di Micro Focus . Si parlerà anche delle proposte di valore

di ciascuna delle due soluzioni, della principale area di interesse di ogni strumento e dei

benefici che ciascuna di esse può fornire come parte di una toolchain DevOps integrata .

Perché automatizzare

Molte organizzazioni stanno cercando di semplificare e ridurre la complessità delle

distribuzioni delle applicazioni pur mantenendo la stabilità operativa, aderendo agli SLA e

garantendo che i tempi di risposta delle applicazioni siano soddisfatti . Una maggiore velocità

di risposta dell’azienda e un atteggiamento basato sul concetto di “lavorare velocemente

senza interruzioni” sono di fondamentale importanza per la sopravvivenza aziendale. Al fine

di sostenere tali obiettivi contrastanti, la necessità di automatizzare “l’intero gruppo” delle

applicazioni è diventata sempre più importante. Purtroppo, la definizione di “intero gruppo”

tende a variare a seconda della zona dell’organizzazione che la descrive .

Il team delle operazioni spesso considera l’“intero gruppo” come l’infrastruttura necessaria

per ospitare le applicazioni e i sistemi a supporto e vede l’applicazione come un piccolo

componente del gruppo, mentre le organizzazioni di sviluppo tendono a vedere l’“intero

gruppo” come tutti i livelli dell’applicazione che funzionano con successo l’uno insieme all’altro

e sono molto meno interessate all’infrastruttura sottostante . La realtà, soprattutto da un

punto di vista del DevOps, è che tutti i settori devono lavorare in piena sinergia per garantire

il supporto di quelle che sono diventate rapidamente le risorse critiche di un’organizzazione .

Negli ultimi dieci anni, la funzione dell’IT non è più vista come un fattore aziendale chiave;

semplicemente, il garantire il funzionamento ininterrotto dei sistemi aziendali non è più

visto come un valore aggiunto, ma piuttosto è considerato un requisito obbligatorio . Per le

aziende, contano soprattutto le applicazioni e sono proprio le modifiche delle applicazioni a

differenziare l’azienda e a garantirne il valore . Implementare quanti più cambiamenti aziendali

possibile, e nel più breve tempo possibile, pur mantenendo elevati livelli di qualità, stabilità

e funzioni, è di importanza critica . I processi manuali di distribuzione delle applicazioni non

supportano questi requisiti chiave . L’automazione è obbligatoria, non facoltativa .

In questo white paper, vengono descritte due soluzioni leader del mercato: Deployment Automation per l’automazione del rilascio delle applicazioni e Puppet per l’automazione dell’infrastruttura di Micro Focus. Si parlerà anche delle proposte di valore di ciascuna delle due soluzioni, della principale area di interesse di ogni strumento e dei benefici che ciascuna di esse può fornire come parte di una toolchain DevOps integrata.

__________

1 Deployment Automation (SDA) è uno strumento leader sul mercato per l’automazione delle applicazioni, in grado di integrarsi e di avviare gli strumenti di provisioning delle infrastrutture. www.serena.com/sda

2 Puppet è uno strumento leader sul mercato per l’automazione dell’infrastruttura che, con un certo livello di investimento e codifica, può essere utilizzato per l’automazione del rilascio delle applicazioni. https://puppetlabs.com/

2

White paperAutomazione del rilascio delle applicazioni e automazione dell'infrastruttura

Breve storia dell’automazione

Negli ultimi quindici anni, si è assistito ad un incremento del tasso di cambiamento nel

settore dei software, che, come ha affermato Glenn O’Donnell di Forrester, sta portando

all’“industrializzazione dell’IT”3 . Inizialmente trainati da una riduzione della spesa IT

in seguito al Millennium Bug e allo scoppio della bolla speculativa delle dotcom, per poi

espandersi in seguito all’adozione di massa di Internet e ad un approccio alle attività

aziendali sempre attivo, questi cambiamenti hanno avuto un enorme impatto sul mondo

dell’IT imprenditoriale e aziendale . Le aziende che 15 anni fa non avevano bisogno di un

sito Web aziendale, per non parlare dell’idea della continua accessibilità dei clienti 24 ore

su 24, hanno dovuto adattarsi a un modo completamente nuovo di lavorare . La riduzione

della spesa IT ha costretto le organizzazioni a ottenere maggiori risultati con minori risorse,

riducendo il numero di dipendenti e aumentando le richieste al reparto IT aziendale .

L’adozione dell’approccio dell’“Internet ovunque” richiede un livello di efficienza operativa,

tempi di attività del sistema e tempi di risposta mai richiesti finora. Il livello di complessità

insita in molte applicazioni aziendali indica che la consegna efficiente e ripetibile dei

cambiamenti aziendali non è più un compito semplice . I rischi dell’esposizione delle

applicazioni a terze parti, che potrebbero essere alla ricerca di punti deboli o di un accesso

backdoor ai sistemi di back office critici per l’azienda, implicano che il semplice aumento

della velocità di consegna non è sufficiente; le applicazioni devono essere distribuite

rapidamente, pur mantenendo un elevato livello di qualità e di sicurezza, e devono includere

le funzioni future più interessanti. Non è più possibile fare affidamento su processi

manuali per garantire l’affidabilità, la tracciabilità e la ripetibilità. Continuare a distribuire

applicazioni in maniera manuale comporta il rischio che un’organizzazione resti molto

indietro rispetto alla concorrenza .

Il progresso non è sempre difficile

I team di sviluppo hanno tradizionalmente accettato il cambiamento, per esempio la

transizione da linguaggi di programmazione “tradizionali”, come COBOL e C, a linguaggi

più recenti come Java e .Net. I team di sviluppo hanno modificato le loro applicazioni e i

loro processi per supportare il cambiamento, anche quando i vantaggi iniziali avrebbero

potuto essere controbilanciati dai costi di transizione . La transizione dalle discipline

di gestione dei progetti Waterfall alle discipline Agile, l’adozione di pratiche LEAN e la

prevalenza dell’adozione di software open source sono tutti ottimi esempi della volontà

del team di sviluppo di supportare il cambiamento . La capacità delle organizzazioni di

sviluppo di diventare più efficienti e di offrire funzionalità aziendali in modo più efficace e

rapido ha aumentato la pressione sui team operativi per consegnare queste nuove funzioni

efficacemente e rapidamente.

Le aziende che 15 anni fa non avevano bisogno di un sito Web aziendale, per non parlare dell’idea della continua accessibilità dei clienti 24 ore su 24, hanno dovuto adattarsi a un modo completamente nuovo di lavorare.

__________

3 O’Donnell, Glenn. 2010, IT Is Industrializing—What Does That Mean To Me? (IT = industrializzazione: cosa significa per me?), blog di Glenn O’Donnell, visualizzato il 24 febbraio 2015, http://blogs.forrester.com/glenn_odonnell/10-04-21-it_industrializing_%E2%80%93_what_does_mean_me

3www.microfocus.com

I team operativi hanno storicamente avuto un approccio “a rischio zero” alla gestione degli

ambienti operativi o produttivi, come generalmente è stato imposto dalle loro aziende . Le

aziende richiedono un livello elevato di stabilità del sistema e tempi di attività, rendendo

questo approccio del tutto comprensibile . La responsabilità di mantenere operativo un

sistema di trading, di fare funzionare correttamente un sistema di ordinazioni o di fare in

modo che un sistema bancario fornisca informazioni precise ai consumatori non deve essere

presa alla leggera . L’investimento e l’adozione di pratiche, processi e procedure basati su

ITIL da parte di molte organizzazioni dimostrano che i sistemi operativi sono tenuti in

grande considerazione . Assicurare che tutti siano d’accordo è fondamentale per consentire

che vengano seguite pratiche e procedure comuni .

Nel tentativo di fornire la miglior esperienza cliente possibile e nuove e interessanti

funzionalità o di acquisire un vantaggio competitivo, le aziende si concentrano sulla

consegna di un numero sempre maggiore di modifiche alle applicazioni, il più rapidamente

ed efficacemente possibile. Il punto è: come risolvere queste due esigenze apparentemente

contrastanti? È possibile garantire la maggiore velocità di consegna delle applicazioni,

richiesta dal team di sviluppo, e i livelli di stabilità, rintracciabilità, controllo e rigore

richiesti dal team operativo, riuscendo a soddisfare, nel contempo, tutti i requisiti di

conformità normativa, settoriale o aziendale?

_______________________________________________________________

Nel tentativo di fornire la miglior esperienza cliente possibile e nuove e interessanti funzionalità o di acquisire un vantaggio competitivo, le aziende si concentrano sulla consegna di un numero sempre maggiore di modifiche alle applicazioni, il più rapidamente ed efficacemente possibile.

Fig. 1

Sfide del team di sviluppo e del team operativo

_______________________________________________________________

4

White paperAutomazione del rilascio delle applicazioni e automazione dell'infrastruttura

L’automazione delle distribuzioni delle applicazioni, l’installazione delle applicazioni e le configurazioni del sistema assicurano che si raggiunga la coerenza in tutto l’ambiente; che le distribuzioni possano essere ripetute come richiesto; e che sia possibile effettuare e tracciare revisioni complete, per vedere esattamente quale versione di quali elementi è stata distribuita, in quale ambiente in un determinato momento.

Grazie ai progressi tecnologici, oggi è molto più facile automatizzare la consegna delle

applicazioni e di tutte le infrastrutture di supporto . Il movimento DevOps, che si sforza

di affrontare le sfide relative a persone, processi e comunicazioni prevalenti in due

diverse unità organizzative (sviluppo e operazioni), può certamente trarre beneficio

dall’uso dell’automazione . Allo stesso modo in cui le organizzazioni hanno scoperto che la

ricompilazione del codice in diversi ambienti porta a diversi output di build e a numerosi

problemi in ambienti successivi, vi è una crescente consapevolezza che la mancanza di

coerenza nella distribuzione in diversi ambienti porterà anche a importanti problemi e

sfide. L’automazione delle distribuzioni delle applicazioni, l’installazione delle applicazioni

e le configurazioni del sistema assicurano che si raggiunga la coerenza in tutto l’ambiente;

che le distribuzioni possano essere ripetute come richiesto; e che sia possibile effettuare

e tracciare revisioni complete, per vedere esattamente quale versione di quali elementi è

stata distribuita, in quale ambiente in un determinato momento . L’automazione, in genere,

porta anche ad una riduzione del tempo trascorso nell’esecuzione delle distribuzioni, a una

maggiore fiducia nella qualità della consegna (le macchine non commettono errori o non

si dimenticano di eseguire i comandi) e alla possibilità di dimostrare esattamente che si è

verificato ciò che era stato pianificato, assicurando di aver soddisfatto importanti conformità

di revisioni .

La distribuzione di un’applicazione non è generalmente facile come spostare i file da una

posizione ad un’altra. Può comportare la creazione o l’estensione dell’infrastruttura per

supportare nuove funzioni, una maggiore capacità di storage o l’implementazione di nuove

funzionalità dell’applicazione, richiedendo complesse routine di installazione . L’automazione

delle infrastrutture e quella delle applicazioni sono funzionalità leggermente differenti che

richiedono un’ulteriore definizione.

Che cos’è l’automazione dell’infrastruttura?

L’automazione di un’infrastruttura consiste nella creazione e nella gestione degli ambienti,

fino ad includere l’installazione dei sistemi operativi, l’installazione e la configurazione

di server su istanze fisiche virtuali o cloud e la configurazione del modo in cui le istanze

e i software comunicano fra loro . È anche comunemente denominata provisioning,

infrastruttura basata su script, infrastruttura come codice o, ingannevolmente, gestione

della configurazione (un termine che assume molti significati diversi a seconda della parte

del ciclo di vita in corso di discussione). Il principio è semplice: consente di definire la

configurazione di un sistema tramite uno script o un set di script per consentire agli utenti di

creare o ricreare gli ambienti il più semplicemente e rapidamente possibile, pur garantendo

un minor numero di errori e rapidi tempi di produzione .

5www.microfocus.com

Che cos’è l’automazione del rilascio delle applicazioni?

L’automazione del rilascio delle applicazioni consiste nella gestione di applicazioni

basata su script all’interno degli ambienti, che include l’installazione, la configurazione e

la distribuzione delle applicazioni in ambienti fisici, virtuali o cloud. Questi ambienti di

destinazione possono, in effetti, essere stati creati attraverso l’utilizzo dell’automazione

dell’infrastruttura. L’automazione del rilascio delle applicazioni include la configurazione

della modalità con cui le applicazioni vengono installate e distribuite e con cui i diversi livelli

di un’applicazione interagiscono tra loro in fase di runtime. Viene comunemente definita

anche automazione delle applicazioni (AA), automazione delle distribuzioni, distribuzione

Agile o, perfino, gestione dei rilasci. Il termine “script” è comunemente impiegato per

definire strumenti di pacchetti dichiarativi, personalizzati e incentrati sui processi, con o

L’automazione del rilascio delle applicazioni include la configurazione della modalità con cui le applicazioni vengono installate e distribuite e con cui i diversi livelli di un’applicazione interagiscono tra loro in fase di runtime.

Fig. 2

Automazione dell’infrastruttura

_______________________________________________________________

6

White paperAutomazione del rilascio delle applicazioni e automazione dell'infrastruttura

senza funzionalità di definizione dell’interfaccia utente. Il principio è semplice: definire un

modello tramite uno script o un set di script per consentire agli utenti di creare o distribuire

le applicazioni il più semplicemente e rapidamente possibile, pur garantendo un minor

numero di errori e rapidi tempi di produzione .

_______________________________________________________________

L’automazione del rilascio delle applicazioni viene comunemente definita anche automazione delle applicazioni (AA), automazione delle distribuzioni, distribuzione Agile o, perfino, gestione dei rilasci.

Fig. 3

Automazione del rilascio delle applicazioni

_______________________________________________________________

7www.microfocus.com

L’automazione delle applicazioni e l’automazione delle infrastrutture possono essere considerate complementari nel più ampio mondo del DevOps e nel mondo della consegna continua o distribuzione continua.

__________

4 La consegna continua (CD) consiste nel mantenere l’applicazione in uno stato in cui è sempre in grado di passare dalla distribuzione alla produzione. Martin Fowler, visualizzato il 24 febbraio 2015, http://martinfowler.com/delivery.html

5 La distribuzione continua consiste, in realtà, nella distribuzione di ogni modifica alla produzione, ogni giorno o più frequentemente. Martin Fowler, visualizzato il 24 febbraio 2015, http://martinfowler.com/delivery.html

Tratti comuni

L’automazione delle applicazioni e l’automazione delle infrastrutture possono essere

considerate complementari nel più ampio mondo del DevOps (i processi e le pratiche di

allineamento dei team di sviluppo e operazioni) e nel mondo della consegna continua4 o

distribuzione continua5 . La comunanza di obiettivi tra questi due tipi di strumenti, vale a

dire maggiore reattività, errori ridotti, revisioni migliorate, responsabilità, rintracciabilità

e l’intenzione di “eseguire lo script di tutto”, porta a considerare questi due set di strumenti

come diretti concorrenti oppure come potenziale sostituto uno dell’altro . La realtà è che

entrambi i set di strumenti presentano un obiettivo ben definito e un “punto di incontro”.

Anche se è sicuramente possibile utilizzarne uno per eseguire determinate funzioni dell’altro,

è preferibile scegliere lo strumento giusto per il lavoro .

_______________________________________________________________

Automazione del rilascio delle applicazioni

Automazione dell’infrastruttura

Distribuzioni incentrate sui processi ● ● Distribuzione delle applicazioni ● ● Installazione delle applicazioni ● ● Supporto della pipeline ● ● Gestione ambientale ● ● Provisioning dell’infrastruttura ● ● Modifica all’infrastruttura ● ● Provisioning hardware ● ● Automazione di un intero gruppo (basata sulla toolchain)

● ●

Fig. 4

Automazione del rilascio delle applicazioni e automazione dell’infrastruttura

_______________________________________________________________

8

White paperAutomazione del rilascio delle applicazioni e automazione dell'infrastruttura

Deployment Automation e Puppet per l’automazione dell’infrastruttura

L’automazione della distribuzione può essere utilizzata per eseguire un sottoinsieme di

attività di automazione dell’infrastruttura tramite script o plugin esistenti su strumenti di

terze parti, che, in determinate circostanze, potrebbe essere tutto ciò che viene richiesto

tramite l’automazione dell’infrastruttura . Esempi di tali attività possono includere il

provisioning virtuale o basato sul cloud, in cui un’immagine esistente predefinita e

configurata viene utilizzata per fornire ulteriori funzionalità virtuali o cloud. La pratica

di creare infrastrutture basate su un’immagine predefinita e configurata è comunemente

denominata provisioning di un’immagine “gold”, in quanto, una volta creata la nuova

infrastruttura, c’è poco da configurare. Questo modello di provisioning delle infrastrutture

è adatto quando le organizzazioni intendono scalare la loro infrastruttura di applicazioni

esistente orizzontalmente o verticalmente per fornire ulteriori funzioni o capacità . In questo

esempio, il provisioning di un’infrastruttura virtuale viene eseguito usando i plugin VMware

ESX, ESXi o Workstation, con il provisioning di nuove immagini virtuali . Dopo la creazione

dell’istanza, le nuove immagini aggiorneranno le impostazioni di proprietà dell’agente,

consentendo ai nuovi agenti di registrarsi automaticamente nel corretto gruppo del pool di

agenti sul server di automazione della distribuzione . Il provisioning di un’infrastruttura cloud

viene eseguito tramite plugin Amazon, Azure o vCloud, con il provisioning di nuove immagini

cloud . Dopo la creazione dell’istanza, le nuove immagini aggiorneranno le impostazioni di

proprietà dell’agente, consentendo ai nuovi agenti di registrarsi automaticamente nel corretto

gruppo del pool di agenti sul server di automazione della distribuzione .

L’automazione delle infrastrutture a livello “hardware” o di macchina fisica richiede

capacità molto più approfondite e, in quanto strumento di automazione delle applicazioni,

questo non è il bersaglio dell’automazione della distribuzione . In queste circostanze, si

consiglia l’uso di uno strumento di terze parti, come ad esempio Puppet, in cui il processo

di provisioning dell’infrastruttura viene controllato dallo strumento di automazione della

distribuzione . L’uso di uno strumento per il provisioning dell’infrastruttura, come Puppet,

richiede un set di competenze specialistiche . Anche se nella comunità dello sviluppo

esiste un numero predefinito di manifesti e moduli, le competenze necessarie per creare,

modificare e aggiornare tali manifesti si trovano comunemente in individui che vantano

un background nel team operativo . Sapere quali parametri kernel, di memoria, di sistema

e di configurazione impostare al momento della creazione di un’istanza, come distribuire

correttamente un sistema operativo con parametri di sicurezza e di rete e comprendere

i requisiti dell’operazione di I/O del disco dei set di storage di dati allegati durante la

creazione di istanze di una nuova infrastruttura nel contesto di un data center più grande,

è di importanza fondamentale per fornire adeguate infrastrutture di base sulle quali

distribuire le applicazioni .

L’uso di uno strumento per il provisioning dell’infrastruttura, come Puppet, richiede un set di competenze specialistiche. Anche se nella comunità dello sviluppo esiste un numero predefinito di manifesti e moduli, le competenze necessarie per creare, modificare e aggiornare tali manifesti si trovano comunemente in individui che vantano un background nel team operativo.

9www.microfocus.com

I modelli, le guide di riferimento e altri script di questo tipo sono scritti generalmente in

un linguaggio specifico per il dominio, ed è necessaria una certa esperienza di scripting per

impostare e configurare le distribuzioni dell’infrastruttura. La distribuzione di applicazioni

in questo “gruppo” creato in modo predefinito o personalizzato è la logica estensione del

provisioning dell’infrastruttura: d’altro canto, c’è sempre un valido motivo alla base della

distribuzione di un bellissimo hardware innovativo. Gli obiettivi finali consistono nell’essere

in grado di definire il processo di distribuzione per il provisioning dell’infrastruttura,

richiamare i manifesti e i moduli corretti per creare la nuova infrastruttura fisica,

distribuire una nuova infrastruttura virtuale, distribuire le applicazioni e garantire che

tutte le applicazioni del nuovo gruppo appena creato siano configurate correttamente.

Tramite l’uso di plugin per il provisioning di strumenti quali Puppet, le aziende possono

ottenere i vantaggi di uno strumento ottimale per creare l’infrastruttura, di funzionalità di

elaborazione per lo strumento di automazione, oltre alla possibilità di distribuire facilmente

le applicazioni nel nuovo ambiente appena creato utilizzando un processo facile da usare e

definito graficamente, con un livello completo di controllo e tracciabilità .

_______________________________________________________________

Tramite l’uso di plugin per il provisioning di strumenti quali Puppet, le aziende possono ottenere i vantaggi di uno strumento ottimale per creare l’infrastruttura, di funzionalità di elaborazione per lo strumento di automazione, oltre alla possibilità di distribuire facilmente le applicazioni nel nuovo ambiente appena creato utilizzando un processo facile da usare e definito graficamente, con un livello completo di controllo e tracciabilità.

Fig. 5

Provisioning di un intero gruppo

_______________________________________________________________

10

White paperAutomazione del rilascio delle applicazioni e automazione dell'infrastruttura

Deployment Automation e Puppet per l’automazione del rilascio delle applicazioni

Come abbiamo visto nel trattare l’automazione dell’infrastruttura, le aree di automazione

congiunte forniscono le funzionalità necessarie per implementare i principi DevOps

all’interno di un’organizzazione . Tuttavia, come abbiamo visto con l’automazione

dell’infrastruttura, vi sono alcune aree chiave e specifiche sulle quali ci si potrebbe

concentrare per l’automazione delle applicazioni . Se la distribuzione delle applicazioni

è semplice come l’esecuzione di uno script shell o batch per copiare i file nella posizione

corretta, gli strumenti di automazione dell’infrastruttura possono offrirvi la capacità (se non

la tracciabilità) richiesta. Queste semplici distribuzioni delle applicazioni sono purtroppo

incredibilmente rare nel mondo del software aziendale . Generalmente, il semplice approccio

basato sulla copia di un file e sull’esecuzione di uno script non è sufficiente per distribuire

un’applicazione su più livelli, che possono contenere dipendenze tra diverse aree dei

componenti dell’applicazione, avere diversi sistemi operativi utilizzati in ambienti diversi

e richiedere operazioni manuali da eseguire per completare gli script . Nel caso in cui sia

necessario distribuire più componenti di un’applicazione o applicazioni con eventi multipli

in serie o in parallelo, le funzionalità degli strumenti di automazione delle infrastrutture

diventano oberati di lavoro e si finisce per usare script concatenati incredibilmente

complicati, che diventano difficili da gestire e da comprendere. Anche l’esecuzione di

semplici distribuzioni delle applicazioni comunemente utilizzate sui server per applicazioni,

come Tomcat, richiede script dettagliati e complessi; una semplice distribuzione di file

war su Tomcat tramite Puppet, ad esempio, richiede oltre 800 righe di codice . Mantenere

questi script correnti o modificarli per adattarli ai requisiti organizzativi può diventare

una responsabilità a tempo pieno per una risorsa ben pagata e altamente qualificata. Al

confronto, la semplice distribuzione di un file war su un server applicativo Tomcat tramite

l’automazione della distribuzione è un processo ad un singolo passaggio, visualizzato

graficamente all’utente finale. Eventuali adattamenti o modifiche di configurazione tra

gli ambienti vengono passati come parametri di questo passaggio, garantendo la piena

ripetibilità del processo dagli ambienti di sviluppo a quelli di produzione .

Il valore delle pipeline

Uno dei principi fondamentali di qualsiasi tipo di automazione è che lo stato finale è noto

e può essere raggiunto in modo ripetibile. La coerenza in tutti gli ambienti è la chiave per

evitare errori durante le distribuzioni . Non è insolito per i responsabili dei rilasci e per gli

ingegneri addetti alla qualità e all’ambiente sforzarsi di distribuire le applicazioni nei loro

ambienti preferiti, solo per essere oggetto di derisione dai loro omologhi ingegneri, che

Generalmente, il semplice approccio basato sulla copia di un file e sull’esecuzione di uno script non è sufficiente per distribuire un’applicazione su più livelli, che possono contenere dipendenze tra diverse aree dei componenti dell’applicazione, avere diversi sistemi operativi utilizzati in ambienti diversi e richiedere operazioni manuali da eseguire per completare gli script.

11www.microfocus.com

affermano, semplicemente, “funzionava bene nel mio ambiente” . Senza un obiettivo o uno

stato finale di destinazione coerenti, l’automazione diventa un compito banale e non riesce

a fornire alcun valore vitale. Naturalmente, lo stato finale di destinazione per qualsiasi

iniziativa DevOps o di consegna continua è quello di distribuire le applicazioni in un ambiente

di produzione, in qualsiasi momento e in modo semplice, ripetibile, conforme alle revisioni

e automatizzato. Tuttavia, proprio come le attività di pianificazione iniziali assicurano il

successo e il completamento tempestivo, la conoscenza dei meccanismi, delle fasi e dei livelli

di convalida richiesti per offrire la nostra applicazione alla produzione è di importanza critica .

Se si ci aspetta semplicemente che il codice generato in ambienti di sviluppo funzioni senza

problemi in un ambiente di produzione, con configurazioni e parametri di runtime diversi,

l’installazione dell’infrastruttura e dei set di dati diventa sempre meno realistica, soprattutto

se ci si scontra con la complessità dell’applicazione e con le dipendenze tra le applicazioni

durante le distribuzioni. Per molti clienti aziendali, già la sola definizione delle dipendenze

tra le applicazioni, con la consapevolezza dell’impatto della modifica di un’applicazione su

un’altra, è un’attività altamente complessa e dispendiosa in termini di tempo . Il solo garantire

la distribuzione corretta al momento giusto e nell’ambiente corretto è l’obiettivo finale di

molte organizzazioni di consegna delle applicazioni .

Per aiutare ad assicurare il raggiungimento di tale obiettivo, la chiave è il concetto di

pipeline di distribuzione o percorso di produzione . Le pipeline di distribuzione sono sempre

esistite negli anni, sotto forme diverse, dal tradizionale SDLC, in cui lo sviluppo è seguito

dai test e poi dalla produzione, ai percorsi di produzione dinamici e visivamente definiti che

possono variare a seconda dell’applicazione e del potenziale rischio di distribuzione di tale

applicazione .

Una delle molte domande che i clienti pongono quando si definiscono una o più pipeline è:

“Tutte le mie applicazioni richiedono la stessa pipeline”? Per fornire una semplice risposta,

occorre esaminare le applicazioni in questione e definire i requisiti di conformità e revisione

di ciascuna di esse . Un sito intranet richiede lo stesso livello di rigore e di convalida di

un sistema di banking online o di trading orientato ai clienti? Per la maggior parte delle

organizzazioni, la risposta è un sonoro “no”: è necessario applicare rigore e controllo per

applicazioni orientate ai clienti, ampiamente utilizzate e ad alta visibilità; applicare gli stessi

approcci alle applicazioni per test interni, ai siti intranet o ad applicazioni con bassa priorità

è eccessivo . Applicare diverse pipeline a diverse applicazioni è un fattore critico di successo

per l’adozione dell’automazione .

Se si ci aspetta semplicemente che il codice generato in ambienti di sviluppo funzioni senza problemi in un ambiente di produzione, con configurazioni e parametri di runtime diversi, l’installazione dell’infrastruttura e dei set di dati diventa sempre meno realistica, soprattutto se ci si scontra con la complessità dell’applicazione e con le dipendenze tra le applicazioni durante le distribuzioni.

12

White paperAutomazione del rilascio delle applicazioni e automazione dell'infrastruttura

Le pipeline sono il componente critico quando si definisce la ripetibilità delle

implementazioni in ambienti multipli, fornendo la conformità e l’aderenza agli standard .

La distribuzione delle stesse applicazioni, utilizzando gli stessi processi in ambienti multipli,

può essere facilmente raggiunta tramite la definizione e l’applicazione di una pipeline.

Le pipeline permettono anche di identificare le discrepanze tra gli ambienti.

L’automazione delle distribuzioni fornisce una funzionalità di pipeline grafiche ricche di

funzioni, con l’opzione di richiedere alla pipeline di usare e di promuovere automaticamente

le applicazioni da un ambiente a un altro (supponendo che la precedente installazione sia

stata completata correttamente) . Puppet non ha alcuna nozione di pipeline . Anche se tramite

l’uso di script concatenati, è possibile collegare i lavori di automazione . In questo scenario,

il consiglio potrebbe essere quello di guidare graficamente i lavori Puppet attraverso un

processo grafico in SDA e seguire il processo grafico definito per la pipeline di distribuzione .

Distribuzioni guidate da modelli

La comprensione della modalità di distribuzione effettiva delle applicazioni di destinazione

è un fattore chiave per l’adozione di qualsiasi strumento di automazione . È impossibile

automatizzare la distribuzione delle applicazioni se non si conoscono i passaggi necessari

per eseguire una tale distribuzione . Con le distribuzioni basate su modelli, come ad esempio

quelle utilizzate dall’automazione della distribuzione, gli utenti finali possono definire

graficamente l’intero processo di distribuzione delle applicazioni, comprese le dipendenze

tra applicazioni e le interazioni tra sistemi . La possibilità di modellare i processi e le pipeline

di distribuzione in modo grafico offre un vantaggio significativo rispetto alle applicazioni

di tipo dichiarativo, in cui la conoscenza e la comprensione dei processi deriva da una

comprensione implicita del codice utilizzato per eseguire una qualsiasi delle distribuzioni .

Si consideri un semplice caso utente, ad esempio la distribuzione di un’applicazione su un

server per applicazioni, come Tomcat. Con un sistema basato su modelli, la definizione

dell’attività da eseguire viene graficamente tracciata su una tela, ad indicare il passaggio e il

processo da eseguire. In un sistema dichiarativo, questa stessa attività richiederà la modifica

del codice, in questo caso deve essere modificato un elemento contenente circa 1.000 linee

di codice. Naturalmente, è molto più facile per i nuovi utenti comprendere una definizione

di processo grafica piuttosto che capire un nuovo linguaggio di programmazione con molte

centinaia di righe di codice. Anche le modifiche future sono semplificate, in quanto eventuali

personalizzazioni possono essere visualizzate facilmente nel processo di distribuzione

anziché dover rivedere basi di codice complesso .

È impossibile automatizzare la distribuzione delle applicazioni se non si conoscono i passaggi necessari per eseguire una tale distribuzione.

13www.microfocus.com

Un piccolo problema di estensibilità

Le aziende sono ambienti complessi . Non si tratta mai di eseguire semplicemente le ultime e

più aggiornate versioni del software sulla più recente e migliore infrastruttura . Nella maggior

parte delle organizzazioni aziendali più longeve, le applicazioni esistenti devono coesistere

con nuove applicazioni, varie versioni di linguaggi di programmazione, componenti runtime

e livelli di astrazione . Per molte organizzazioni, la migrazione verso nuove versioni delle

applicazioni comporta anche la migrazione dell’infrastruttura e dei desktop per gli utenti

finali, nonché l’aggiornamento delle interfacce di dati esistenti. La variazione nelle versioni

delle applicazioni che devono essere aggiornate al momento della distribuzione implica che il

disporre di un’interfaccia complessa e difficile da aggiornare tra la tecnologia di automazione

e il sistema di terze parti pone l’azienda in un grande svantaggio . L’automazione della

distribuzione fornisce un gran numero di integrazioni pronte all’uso per molti dei comuni

sistemi di terze parti, dal database al middleware ai server per applicazioni e, perfino, agli

strumenti di test . Il modello di plugin estensibile utilizzato dall’applicazione consente la

creazione rapida di nuovi plugin per i sistemi di terze parti, aumentando la capacità della

piattaforma di automazione di estendersi a tutti i settori dell’azienda . I manifesti Puppet

sono un ottimo modo per definire l’infrastruttura come codice e promuovere la creazione,

l’aggiornamento e la distruzione di infrastrutture come parte del processo di provisioning o

distribuzione di un “intero gruppo” predefinito .

Il meglio dei due mondi

Come è già stato discusso, il provisioning di un “intero gruppo” può coinvolgere l’intero

gruppo di infrastrutture e applicazioni . La distribuzione delle applicazioni, il provisioning

delle infrastrutture e i processi per mantenerle tutte sincronizzate sono componenti

chiave per le organizzazioni che desiderano sfruttare i vantaggi della consegna continua

e della tecnologia di transizione, nonché le persone e il processo verso il DevOps . Gli

strumenti di provisioning dell’infrastruttura svolgono un ruolo di enorme valore nel

garantire che l’infrastruttura di base sia al suo posto per le distribuzioni successive delle

applicazioni . L’uso di processi coerenti per la distribuzione delle infrastrutture e delle

applicazioni consente di ottenere la conformità, il controllo, la ripetibilità e la conoscenza

delle distribuzioni, riducendo anche i tempi di distribuzione e rimuovendo i rischi delle

distribuzioni manuali . Promuovere l’automazione dell’infrastruttura tramite l’automazione

della distribuzione è il primo passo verso la trasformazione organizzativa, la semplificazione

dei processi e tempi di introduzione sul mercato più rapidi . Lavorare velocemente senza

interruzioni .

La distribuzione delle applicazioni, il provisioning delle infrastrutture e i processi per mantenerle tutte sincronizzate sono componenti chiave per le organizzazioni che desiderano sfruttare i vantaggi della consegna continua e della tecnologia di transizione, nonché le persone e il processo verso il DevOps.

162-IT0085-002 | S | 04/17 | © 2017 Micro Focus. Tutti i diritti riservati. Micro Focus e il logo Micro Focus, tra gli altri, sono marchi di fabbrica o marchi registrati di Micro Focus o delle sue controllate o consociate nel Regno Unito, negli Stati Uniti e in altri Paesi. Tutti gli altri marchi appartengono ai rispettivi proprietari.

www.microfocus.com

Micro FocusItalia+39 02 366 349 00

Micro FocusSede centraleRegno Unito+44 (0) 1635 565200

www.microfocus.com