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