Best practice per la gestione di rilasci e modifiche Agile

Transcript

1 White paper Best practice per la gestione di rilasci e modifiche Agile di Ben Cody, Julian Fish e Amita Abraham Novembre 2012

2 Sommario pagina Una valanga di incidenti segnalati al service desk a causa di una cattiva gestione delle modifiche... 1 Il problema dello scollegamento DevOps Best practice per la gestione di rilasci e modifiche Agile In sintesi

3 Per rimanere competitiva, la vostra organizzazione IT deve continuamente offrire servizi e applicazioni innovativi che rappresentano, molto spesso, il volto della vostra azienda. Una valanga di incidenti segnalati al service desk a causa di una cattiva gestione delle modifiche Fig. 1 Fonte: Sondaggio online Forrester/ itsmf T USA ITSM Il problema dello scollegamento DevOps Sempre più spesso, le attività aziendali vengono svolte online. Per rimanere competitiva, la vostra organizzazione IT deve continuamente offrire servizi e applicazioni innovativi che rappresentano, molto spesso, il volto della vostra azienda. La capacità di apportare modifiche a queste applicazioni in tempi rapidi senza compromettere la stabilità dell infrastruttura non è più un gradito surplus, bensì una necessità. 1

4 White paper Best practice per la gestione di rilasci e modifiche Agile Le organizzazioni di sviluppo hanno risposto a questa esigenza adottando metodologie agili. Possono ora passare velocemente servizi e applicazioni nuovi o aggiornati direttamente al team addetto alle operazioni IT. Tuttavia, in questo modo i team addetti alle operazioni IT hanno difficoltà a implementare le modifiche senza introdurre rischi aggiuntivi a seguito di queste modifiche. Con passaggi delle consegne tutt altro che perfetti tra questi due team nella maggior parte delle organizzazioni, non sorprende che una ricerca recente* indichi che più del 40% degli incidenti segnalati al service desk derivano dall insuccesso di alcune modifiche ad applicazioni e alla rispettiva infrastruttura di supporto. Lo scollegamento dei processi tra team di sviluppo e team operativi può avere un impatto molto negativo sulla capacità dell organizzazione di generare profitti. Il 40% degli incidenti segnalati al service desk derivano dall insuccesso di alcune modifiche ad applicazioni e alla rispettiva infrastruttura di supporto. Ad accrescere ulteriormente i problemi legati ai processi vi è il fatto che la maggior parte dei team addetti alle operazioni IT continuano a utilizzare i propri sistemi per la gestione di incidenti, problemi e modifiche correlati all infrastruttura IT. Tali sistemi sono spesso diversi da quelli utilizzati dai team di sviluppo delle applicazioni per il monitoraggio di requisiti, incidenti, miglioramenti e richieste di modifica. I team addetti alle operazioni IT di solito non hanno accesso né possono visualizzare le correzioni e le modifiche apportate dai team di sviluppo delle applicazioni. Analogamente, i team di sviluppo raramente hanno accesso agli strumenti che i team addetti alle operazioni IT utilizzano per il monitoraggio di incidenti, problemi e modifiche. Questi sistemi isolati e specifici per funzione aggravano ulteriormente il problema. Le sfide poste dallo scollegamento di processi e strumenti risultano evidenti in questo esempio di rilascio di un nuovo portale per transazioni online da parte di un provider di servizi di telecomunicazione. Il team di sviluppo aveva informato il team addetto alle operazioni IT della necessità di una diversa versione del database Oracle nell ambiente di produzione soltanto pochi giorni prima del rilascio. Dato che il team addetto alle operazioni IT aveva una visibilità limitata dei dettagli del rilascio, non era a conoscenza delle procedure di distribuzione e dell esigenza di un aggiornamento del database. A complicare ulteriormente la situazione, le altre applicazioni che condividevano il database Oracle erano incompatibili con la versione più recente. Di conseguenza, il team addetto alle operazioni IT è stato costretto ad affrettarsi per procurarsi componenti hardware aggiuntivi e creare una nuova istanza del database. Ciò ha determinato l aumento dei costi e il ritardo nel rilascio dell applicazione, con un conseguente impatto sui ricavi e l ulteriore deterioramento dei rapporti tra le organizzazioni responsabili dello sviluppo e delle operazioni. L impatto sul business dell incapacità di coordinare persone, processi e sistemi all interno dei team di sviluppo e dei team operativi è evidente quando le applicazioni che rappresentano le colonne portanti di un azienda vacillano a causa di modifiche e rilasci non riusciti. * Sondaggio online Forrester/ itsmf T USA ITSM 2

5 Un portale per le richieste unificato reindirizza gli incidenti ai team operativi e di sviluppo per risolvere rapidamente i problemi. E come si possono semplificare i processi che interessano i team di sviluppo e quelli operativi? Come si possono migliorare e velocizzare la gestione delle modifiche e dei rilasci senza compromettere la stabilità e il controllo dell ambiente? Best practice per la gestione di rilasci e modifiche Agile Creazione di un unico imbuto per tutti gli incidenti Quando i vostri clienti hanno problemi con un applicazione o sollevano richieste di nuove funzioni, in genere inviano un o segnalano le loro esigenze in un foglio di calcolo o in un documento di Microsoft Word. Il rischio di questo approccio è che tali richieste e problemi possano finire nel dimenticatoio. I vostri clienti non possono monitorare facilmente lo stato delle loro richieste. Un portale centralizzato con cui i vostri clienti possono interagire per inoltrare e monitorare lo stato dei loro ticket può migliorare notevolmente i livelli di soddisfazione. Ad esempio, in fase di preparazione di un rilascio, un responsabile dello sviluppo delle applicazioni potrebbe aver bisogno di richiedere che il team addetto alle infrastrutture aggiunga un nuovo livello Web a un cluster server esistente per gestire la riprogettazione di un applicazione. Fig. 2 Un portale centralizzato che instrada gli incidenti e consente di visualizzare gli SLA 3

6 White paper Best practice per la gestione di rilasci e modifiche Agile Un portale centrale che visualizza i relativi contratti di assistenza (SLA, Service Level Agreement) e che raccoglie le informazioni necessarie sul centro di costo per addebiti e approvazioni può semplificare ulteriormente il processo di implementazione delle modifiche da apportare alle applicazioni. Inoltre, un portale di richieste unificato che in seguito reindirizza automaticamente gli incidenti ai team giusti, all interno dei gruppi operativi o di sviluppo, li aiuta a rispondere e a risolvere rapidamente i problemi. La gestione dei rilasci e delle modifiche integrata accelera l applicazione delle modifiche alle applicazioni in fase di produzione. Integrazione dei processi di gestione di rilasci e modifiche L integrazione e automazione dei processi di gestione di rilasci e modifiche elimina la necessità di scrivere script di distribuzione complessi, nonché il rischio di errore umano durante il rilascio delle modifiche in fase di produzione. Per ottenere questi risultati, è fondamentale fornire ai team operativi e di sviluppo una visibilità completa delle modifiche pianificate e la distribuzione programmata di tali modifiche. Le richieste di modifiche e la correzione dei difetti vengono passate ai team di sviluppo. Per contribuire all implementazione delle modifiche in fase di produzione, questi team possono usufruire di una chiara visibilità delle finestre di modifica predefinite disponibili negli ambienti di produzione, denominate sequenze di rilascio. Le sequenze di rilascio aiutano a combinare le richieste sia per le modifiche operative sia per le modifiche alle applicazioni in una finestra programmata e quindi a implementarle in un momento che è adatto per entrambi i team. Quando entrambi i team, operativi e di sviluppo, possono chiaramente visualizzare le sequenze di rilascio disponibili, combinare facilmente le funzioni con le modifiche operative pianificate e quindi monitorare lo stato di avanzamento del rilascio attraverso gli ambienti di sviluppo, test e produzione, le possibilità di modifiche non riuscite vengono notevolmente ridotte. Per poter tracciare le modifiche apportate alla richiesta iniziale, le organizzazioni IT dispongono delle risorse migliori per fornire alle loro controparti commerciali aggiornamenti di stato accurati e dettagliati. 4

7 Permettere ai team operativi e di sviluppo di lavorare di concerto tramite processi integrati offre loro strumenti migliori per implementare rapidamente le modifiche apportate alle applicazioni a supporto del business, senza mettere a repentaglio la stabilità dell ambiente operativo. Fig. 3 Combinazione di modifiche operative e alle applicazioni in un unica sequenza di rilascio Grazie ai processi collegati, i team di sviluppo possono monitorare le modifiche associate a una richiesta al livello del codice sorgente man mano che ci si sposta dall ambiente di sviluppo all ambiente di test e infine di produzione. Una volta che un applicazione viene distribuita nell ambiente di produzione, gli aggiornamenti dovrebbero essere automaticamente effettuati alla voce DML (Definitive Media Library) dell applicazione. Quando i processi relativi alle applicazioni sono collegati a un Configuration Management Database (CMDB) per la gestione delle infrastrutture e gli elementi vengono automaticamente aggiornati al momento del rilascio delle modifiche, viene effettuato un record completo e coerente di ciò che è in produzione. Permettere ai team operativi e di sviluppo di lavorare di concerto tramite processi integrati offre loro strumenti migliori per implementare rapidamente le modifiche apportate alle applicazioni a supporto del business, senza mettere a repentaglio la stabilità dell ambiente operativo. 5

8 White paper Best practice per la gestione di rilasci e modifiche Agile Un calendario unificato per una visibilità completa Un calendario integrato accessibile dai team operativi e di sviluppo che riporta tutte le modifiche pianificate per settimana o per mese aiuta ad avvisare i team degli aggiornamenti pianificati per le applicazioni. Un calendario unificato consente di visualizzare le finestre disponibili per il rilascio delle modifiche. Fig. 4 Un calendario unificato per una visibilità completa all interno dei team operativi e di sviluppo La capacità di esaminare le diverse applicazioni influenzate da una sequenza di rilasci e di eseguire il drill-down dei dettagli di una richiesta di modifica può essere di grande valore per i team di sviluppo, così come per quelli operativi. Dovrebbero essere inclusi i dettagli delle modifiche alle applicazioni fino agli elementi da distribuire, nonché le informazioni sulle modifiche all infrastruttura. Un calendario unificato delle modifiche fornisce ai team di sviluppo, ai responsabili del rilascio e ai team operativi una vista consolidata di tutti i software pianificati, nonché delle modifiche all infrastruttura. 6

9 Il collegamento dei processi all interno dei team operativi e di sviluppo migliora la soddisfazione aziendale con l IT in quanto gli incidenti e i problemi vengono monitorati e risolti, le modifiche alle applicazioni vengono apportate prima e agli utenti aziendali viene inviata una notifica in modo proattivo quando vengono risolti i problemi. Sfruttando un calendario unificato, i team addetti ai rilasci e allo sviluppo sono pienamente consapevoli delle finestre disponibili per le modifiche, nonché dei tempi di inattività della produzione pianificati. In questo modo, i team possono scegliere il momento opportuno per richiedere una modifica all infrastruttura, ad esempio, per risolvere i recenti problemi relativi alle prestazioni delle applicazioni. Una volta che la modifica operativa viene associata a una sequenza di rilascio, il controllo della modifica dovrebbe passare a quella sequenza. Quando la sequenza viene approvata e contrassegnata come pronta per l implementazione, i team operativi dovrebbero ricevere una notifica automatica per apportare le necessarie modifiche all infrastruttura, attenendosi agli SLA. Il processo dovrebbe continuare finché non vengono implementate tutte le modifiche alla sequenza di rilascio. In seguito alla revisione post implementazione, è necessario effettuare gli aggiornamenti al sistema di gestione delle configurazioni, che comprende il CMDB, come pure il DML. Collegando i rilasci di sviluppo approvati alle finestre di manutenzione operativa esistenti, i team possono evitare ritardi nei rilasci e confusione a livello di distribuzione. In sintesi Le organizzazioni svolgono sempre più spesso le loro attività online e la necessità di velocizzare la gestione delle modifiche è cruciale. Le aziende potranno usufruire del fatto che i team DevOps o di gestione dei rilasci fungano da collante tra i team operativi e di sviluppo. Gli strumenti e i sistemi che collegano le persone e i processi all interno dei team operativi e di sviluppo possono contribuire notevolmente a fornire a questi team la visibilità necessaria per raccogliere e velocizzare le richieste di modifica alle applicazioni. Una strategia di gestione dei rilasci e delle modifiche integrata può inoltre ridurre il volume degli incidenti. Una ricerca rileva che il 40% di tutti gli incidenti segnalati sono il risultato di modifiche non riuscite. Il collegamento dei processi all interno dei team operativi e di sviluppo migliora la soddisfazione aziendale con l IT in quanto gli incidenti e i problemi vengono monitorati e risolti, le modifiche alle applicazioni vengono apportate prima e agli utenti aziendali viene inviata una notifica in modo proattivo quando vengono risolti i problemi. 7

10 Micro Focus Italia Micro Focus Sede centrale Regno Unito +44 (0) IT S 04/ 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.