Home
topics
DevOps
DevOps è una metodologia di sviluppo software che accelera la fornitura di applicazioni e servizi di qualità superiore combinando e automatizzando il lavoro dei team di sviluppo software e delle operazioni IT.
Con strumenti e pratiche condivise, inclusi aggiornamenti piccoli ma frequenti, lo sviluppo del software diventa più efficiente, più veloce e più affidabile.
Per definizione, il DevOps, ovvero le operazioni di sviluppo, delinea sia un processo di sviluppo software che un cambiamento della cultura organizzativa volto a promuovere il coordinamento e la collaborazione tra i team di sviluppo e di operazioni IT, due gruppi che, tradizionalmente, sono separati l'uno dall'altro, o in silo.
Nella pratica, i migliori processi e culture DevOps si estendono oltre le pratiche di sviluppo e le operazioni e incorporano gli input di tutti gli stakeholder delle applicazioni nel ciclo di vita dello sviluppo software. Ciò include gli ingegneri di piattaforma e infrastruttura, i team di sicurezza, conformità, governance, gestione del rischio e line of business, gli utenti e i clienti.
I principi di DevOps rappresentano lo stato attuale dell'evoluzione del processo di distribuzione del software negli ultimi 20 anni. Il processo di distribuzione è passato da enormi rilasci di codice a livello di applicazione a intervalli di svariati mesi o addirittura anni, a aggiornamenti iterativi di funzionalità o funzionalità più piccoli, rilasciati con una frequenza giornaliera o più volte al giorno.
In definitiva, DevOps mira a soddisfare la domanda sempre crescente da parte degli utenti di software di nuove funzionalità frequenti e innovative e di prestazioni e disponibilità ininterrotte.
Se il software è importante, lo è anche l'efficienza della sua distribuzione. Leggi il report per conoscere insight dettagliati su come migliorare l'efficienza complessiva del ciclo di vita di DevOps.
Prima del 2000, la maggior parte dei software veniva sviluppata e aggiornata utilizzando la metodologia a cascata, un approccio lineare ai progetti di sviluppo su larga scala. I team di sviluppo del software impiegavano mesi a sviluppare grandi quantità di nuovo codice, che avevano un impatto sulla maggior parte o sulla totalità del ciclo di vita dell'applicazione. Poiché le modifiche erano così estese, hanno impiegato diversi mesi in più per integrare il nuovo codice nella base di codice.
Successivamente, i team addetti al controllo della qualità (QA), alla sicurezza e alle operazioni hanno impiegato ancora più mesi a testare il codice. Il risultato è stato che tra un versione e l'altra passavano mesi o addirittura anni, e spesso vi erano anche diverse patch o correzioni di bug significative. Questo approccio "big bang" alla distribuzione delle funzionalità era spesso caratterizzato da piani di distribuzione complessi e rischiosi, da interblocchi difficili da programmare con i sistemi a monte e a valle e dalla grande speranza dell'IT che i requisiti aziendali non fossero cambiati drasticamente nei mesi che precedevano la messa in produzione o la versione a disponibilità generale (GA).
Per accelerare lo sviluppo e migliorare la qualità, nei primi anni 2000 i team di sviluppo hanno iniziato ad adottare le metodologie di sviluppo di software agile. Queste metodologie sono iterative anziché che lineari e si concentrano sull'esecuzione di aggiornamenti più piccoli e più frequenti alla base di codice dell'applicazione. La maggior parte di queste metodologie di DevOps sono di integrazione continua e fornitura continua, o CI/CD.
Nella CI/CD, i frammenti più piccoli del nuovo codice vengono uniti alla base di codice a intervalli frequenti, per poi essere integrati, testati e preparati automaticamente per l'implementazione nell'ambiente di produzione. La modalità agile ha modificato l'approccio "big bang" trasformandolo in una serie di scatti più piccoli, che hanno anche compartimentato i rischi.
Quanto più efficacemente queste pratiche di sviluppo agile acceleravano lo sviluppo e la consegna del software, tanto più esponevano le operazioni IT ancora in silo, come il provisioning del sistema, la configurazione, i test di accettazione, la gestione e il monitoraggio, ad esempio, come ulteriori colli di bottiglia nel ciclo di vita della consegna del software.
Si può dire, quindi, che il DevOps è nato dall'approccio agile. Ha aggiunto nuovi processi e strumenti che estendono l'iterazione continua e l'automazione di CI/CD al resto del ciclo di vita della distribuzione del software, e ha implementato una stretta collaborazione tra sviluppo e operazioni in ogni fase del processo.
Il ciclo di vita DevOps (a volte chiamato continuous delivery pipeline, se rappresentato in modo lineare) è una serie di processi di sviluppo iterativi e automatizzati, o flussi di lavoro, eseguiti all'interno di un ciclo di vita di sviluppo più ampio, automatizzato e iterativo, progettato per ottimizzare la distribuzione rapida di software di alta qualità. I nomi e il numero dei workflow variano da persona a persona, ma spesso includono questi otto passaggi.
In questo workflow, i team individuano nuove caratteristiche e funzioni per la prossima versione, attingendo al feedback degli utenti e ai casi di studio prioritari, nonché agli input di tutti gli stakeholder interni. L'obiettivo della fase di pianificazione è massimizzare il valore aziendale del prodotto producendo un backlog di funzionalità che migliorano il valore del prodotto.
Si tratta della fase di programmazione, in cui gli sviluppatori codificano e creano funzionalità nuove e migliorate in base alle storie degli utenti e agli elementi di lavoro nel backlog. Sono piuttosto comuni una combinazione di pratiche come sviluppo basato su test (TDD), pair programming e peer code reviews. Gli sviluppatori usano spesso le workstation locali per eseguire il ciclo interno di scrittura e test del codice prima di inviarlo alla pipeline di distribuzione continua.
In questo workflow, il nuovo codice viene integrato nella base di codice esistente, quindi testato e inserito in un pacchetto per il rilascio e la distribuzione. Le attività di automazione comuni includono l'unione delle modifiche al codice in una copia master, il controllo del codice da un repository di codice sorgente e l'automazione della compilazione, dei test di unità e della creazione di pacchetti in un file eseguibile. La best practice consiste nel memorizzare l'output della fase CI in un repository binario per la fase successiva.
I team utilizzano i test, spesso automatizzati, per assicurarsi che l'applicazione soddisfi determinati standard e requisiti. L'approccio DevOps classico include una fase di test discreta che si verifica tra la creazione e il rilascio.
Tuttavia, DevOps è progredito tanto che alcuni elementi di test possono verificarsi nella pianificazione (sviluppo guidato dal comportamento), nello sviluppo (test unitari, test a contratto), nell'integrazione (scansioni di codice statico, scansioni CVE, linting), nella distribuzione (smoke test, test di penetrazione, test di configurazione), nelle operazioni (test di caos, test di conformità) e nell'apprendimento (test A/B).
I test continui sono una forma efficace di identificazione dei rischi e delle vulnerabilità, e offrono all'IT l'opportunità di accettare, mitigare o correggere i rischi. Inoltre, il test shift-left è un approccio nello sviluppo software che enfatizza le attività di test in movimento prima del processo di sviluppo. Questo approccio consente di migliorare la qualità del prodotto, offre una migliore copertura dei test, cicli di feedback continui e un time-to-market più rapido.
La prima delle fasi operative, cioè la fase di rilascio, è l'ultima che avviene dietro le quinte, prima che gli utenti accedano all'applicazione. In questo workflow, l'output di tempo di esecuzione della build (dall'integrazione) viene distribuito in un ambiente di esecuzione, in genere uno di sviluppo in cui vengono eseguiti i test di runtime per verificare qualità, conformità e sicurezza.
Se vengono rilevati errori o difetti, gli sviluppatori hanno la possibilità di intercettare e risolvere eventuali problemi prima che gli utenti li vedano. In genere esistono ambienti per lo sviluppo, il test e la produzione, ognuno dei quali richiede controlli di qualità progressivamente più rigorosi. Quando gli sviluppatori hanno risolto tutti i problemi individuati e l'applicazione soddisfa tutti i requisiti, il team operativo conferma che è pronta per la distribuzione e la costruisce nell'ambiente di produzione.
La distribuzione avviene quando il progetto si sposta in un ambiente di produzione in cui gli utenti possono accedere alle modifiche effettuate all'applicazione. L'infrastruttura è impostata e configurata (spesso utilizzando l'infrastruttura come codice) e viene distribuito il codice dell'applicazione. Una buona pratica per l'implementazione in un ambiente di produzione è quella di distribuire prima a un sottoinsieme di utenti finali e poi eventualmente a tutti gli utenti una volta raggiunta la stabilità.
Se la distribuzione delle funzioni a un ambiente di produzione è caratterizzata come "Giorno 1", una volta che le funzionalità sono in esecuzione nell'ambiente di produzione, iniziano le operazioni "Giorno 2". Il monitoraggio delle prestazioni, del comportamento e della disponibilità consente di garantire che le funzioni forniscano valore agli utenti.
In questa fase, i team verificano che le funzioni lavorino senza problemi e che non vi siano interruzioni del servizio, assicurandosi che la rete, lo storage, la piattaforma, l'elaborazione e i livelli di sicurezza siano integri. Se si verificano problemi, i team operativi identificano l'incidente, avvisano il personale appropriato, risolvono i problemi e applicano le correzioni.
Questo avviene mediante raccolta di feedback da parte di utenti e clienti su caratteristiche, funzioni, prestazioni e valore aziendale da riportare per pianificare miglioramenti e funzionalità nella prossima versione. Ciò include anche eventuali elementi di apprendimento e di backlog derivanti dalle attività operative che possono aiutare gli sviluppatori a prevenire in modo proattivo il ripetersi di incidenti noti. È questo il punto in cui avviene la "conclusione" della fase di pianificazione che guida il miglioramento continuo.
Ci sono altri due importanti workflow continui nel ciclo di vita:
Mentre le metodologie a cascata e le implementazioni agili si aggiungono ai workflow di sicurezza dopo la distribuzione o l'implementazione, DevOps si impegna a incorporare la sicurezza fin dall'inizio (pianificazione), quando i problemi di sicurezza sono più facili e meno costosi da affrontare, e funziona continuamente per tutto il resto del ciclo di sviluppo. Questo approccio alla sicurezza viene definito spostamento a sinistra. Alcune organizzazioni hanno avuto meno successo spostandosi a sinistra rispetto ad altre, il che ha portato alla crescita di DevSecOps (sviluppo, sicurezza e operazioni).
Inoltre, è consigliabile affrontare le normative di governance, risk and compliance (GRC) in modo preventivo e lungo l'intero ciclo di vita dello sviluppo. I settori regolamentati sono spesso obbligati a fornire un certo livello di osservabilità, tracciabilità e accesso alle modalità di fornitura e gestione delle funzioni nel loro ambiente di runtime operativo.
Ciò richiede pianificazione, sviluppo, collaudo e applicazione di politiche nella pipeline di consegna continua e nello stesso ambiente di runtime. La verificabilità delle misure di compliance è importante per dimostrare la conformità a revisori terzi.
I leader aziendali sono generalmente concordi sul fatto che i metodi DevOps non possono funzionare senza un impegno nella cultura DevOps, ossia un approccio organizzativo e tecnico diverso allo sviluppo del software.
A livello organizzativo, DevOps richiede una comunicazione continua, collaborazione e responsabilità condivisa tra tutti gli stakeholder della distribuzione del software. Ciò include i team di sviluppo del software e delle operazioni IT, sicuramente, ma anche i team di sicurezza, conformità, governance, rischio e linea di business, per innovare rapidamente e continuamente e concentrarsi sulla qualità sin dall'inizio.
Solitamente, il modo migliore per raggiungere questo obiettivo è abbattere i silo e riorganizzare il personale in team DevOps interfunzionali e autonomi, in grado di lavorare sui progetti dall'inizio alla fine (dalla pianificazione al feedback) senza passare il testimone o attendere l'approvazione di altri team. Nel contesto dello sviluppo agile, la responsabilità e la collaborazione condivise sono il fondamento di un focus condiviso sul prodotto che porta risultati preziosi.
A livello tecnico, DevOps richiede un impegno verso l’automazione che mantiene i progetti in movimento all'interno dei workflow e tra l'uno e l'altro. Richiede anche feedback e misurazione per consentire ai team di accelerare continuamente i cicli e migliorare la qualità e le prestazioni del software.
Promuovere una cultura della collaborazione e rimuovere i silos avvicina il lavoro degli sviluppatori e dei team operativi, il che aumenta l'efficienza e riduce i carichi di lavoro grazie alla combinazione di workflow. Poiché gli sviluppatori e i team operativi condividono molte responsabilità, ci sono meno sorprese man mano che i progetti avanzano. I team DevOps sanno esattamente in quale ambiente viene eseguito il codice mentre lo sviluppano.
I team DevOps creano nuovo codice più rapidamente grazie all'aumento della collaborazione e alla creazione di rilasci più mirati (e più frequenti) utilizzando un'architettura di microservizi. In questo modo, i miglioramenti, le innovazioni e le correzioni dei bug possono arrivare prima sul mercato.
Consente inoltre alle organizzazioni di adattarsi più rapidamente ai cambiamenti del mercato e di soddisfare meglio le esigenze dei clienti, con conseguente aumento della soddisfazione dei clienti e vantaggio competitivo. Il processo di rilascio del software può essere automatizzato con la consegna continua e l'integrazione continua.
La fornitura continua e l'integrazione continua includono test automatici per garantire la qualità e l'affidabilità degli aggiornamenti del software e dell'infrastruttura. Il monitoraggio e la registrazione verificano le prestazioni in tempo reale.
L'automazione, inclusa l'infrastruttura come il codice, può aiutare a gestire lo sviluppo, i test e la produzione, e consentire una scalabilità più rapida con una maggiore efficienza.
DevSecOps unisce l'integrazione, la distribuzione e l'implementazione continue nel processo di sviluppo, in modo che la sicurezza sia integrata fin dall'inizio, anziché applicata in un secondo momento. I team integrano test e audit di sicurezza nei workflow usando l'infrastruttura come codice per mantenere il controllo e tenere traccia della conformità.
Un approccio DevOps migliora la soddisfazione sul lavoro automatizzando le attività semplici e ripetitive e consentendo ai dipendenti di concentrarsi su un lavoro più gratificante che genera valore aziendale.
Le esigenze della cultura DevOps e DevOps privilegiano gli strumenti che supportano la collaborazione asincrona, integrano perfettamente i workflow DevOps e automatizzano l'intero ciclo di vita DevOps il più possibile.
Le categorie di strumenti DevOps includono:
Gli strumenti di gestione dei progetti consentono ai team di creare un backlog di storie degli utenti (requisiti) che formano progetti di codifica, suddividerli in attività più piccole e tenere traccia delle attività fino al completamento. Molti strumenti supportano pratiche di gestione agile dei progetti, come Scrum, Lean e Kanban, che gli sviluppatori portano a DevOps. Le opzioni open source più popolari includono GitHub Issues e Jira.
Si tratta di ambienti di codifica controllati dalla versione che consentono a più sviluppatori di lavorare sulla stessa base di codice. I repository di codice devono integrarsi con CI/CD, strumenti di test e sicurezza, in modo che quando viene eseguito il commit del codice nel repository possa passare automaticamente al passaggio successivo. I repository di codice open source includono GitHub e GitLab.
Si tratta di strumenti che automatizzano il checkout, la costruzione, il test e la distribuzione del codice. Jenkins è lo strumento open source più popolare di questa categoria; molte precedenti alternative open source, come CircleCI, sono ora disponibili solo in versione commerciale.
Per gli strumenti di distribuzione continua (CD), Spinnaker si allinea tra applicazione e infrastruttura come layer di codice. ArgoCD è un'altra scelta open source popolare per la CI/CD nativa di Kubernetes.
Questi includono strumenti software, librerie e best practice per l'automazione di test unitari, contrattuali, funzionali, di prestazioni, di usabilità, di penetrazione e di sicurezza. I migliori strumenti supportano più lingue. Alcuni utilizzano l'intelligenza artificiale (AI) per riconfigurare automaticamente i test in risposta alle modifiche del codice. La portata degli strumenti e dei framework di test è estremamente ampia. I più popolari framework di automazione dei test open source includono Selenium, Appium, Katalon, Robot Framework e Serenity (precedentemente noti come Thucydides).
Gli strumenti di gestione della configurazione (noti anche come strumenti di codice per l'infrastruttura) consentono agli ingegneri DevOps di configurare e fornire un'infrastruttura con versioni completamente controllate e documentate eseguendo uno script. Le opzioni open source includono Ansible (Red Hat), Chef, Puppet e Terraform. Kubernetes esegue la stessa funzione per le applicazioni containerizzate.
Gli strumenti di monitoraggio aiutano i team DevOps a identificare e risolvere i problemi del sistema. Inoltre, raccolgono e analizzano i dati in tempo reale per rivelare in che modo le modifiche al codice influiscono sulle prestazioni delle applicazioni. Gli strumenti di monitoraggio open source includono Datadog, Nagios, Prometheus e Splunk.
Questi strumenti raccolgono il feedback degli utenti, tramite mappe di calore (registrazione delle azioni degli utenti sullo schermo), sondaggi o emissione di ticket self-service.
Il cloud-native è un approccio alla creazione di applicazioni che utilizzano tecnologie fondamentali di cloud computing. Le piattaforme cloud consentono lo sviluppo, l'implementazione, la gestione e le prestazioni delle applicazioni in modo coerente e ottimale in ambienti pubblici, privati e multicloud.
Oggi, le applicazioni cloud-native sono, in genere:
- Costruite utilizzando i microservizi: componenti liberamente accoppiati e indipendenti che dispongono di uno stack autonomo e comunicano tra di loro tramite API REST, streaming di eventi o broker di messaggi.
- Distribuite in container: unità di codice eseguibili contenenti tutto il codice, i tempi di esecuzione e le dipendenze del sistema operativo necessarie per eseguire l'applicazione. Per molte organizzazioni, i container sono sinonimi di container Docker, ma sono disponibili altre tipologie.
- Operato (su larga scala) utilizzando Kubernetes: una piattaforma di orchestrazione dei contenitori open source per pianificare e automatizzare la distribuzione, la gestione e la scalabilità delle applicazioni containerizzate.
In molti modi, lo sviluppo cloud-native e quello DevOps sono fatti l'uno per l'altro. Ad esempio, lo sviluppo e l'aggiornamento dei microservizi, ovvero la distribuzione iterativa di piccole unità di codice a una piccola base di codice, sono perfetti per i cicli di rilascio e gestione rapidi di DevOps. Gestire la complessità di un'architettura di microservizi senza l'implementazione e le operazioni di DevOps sarebbe difficile.
Un recente sondaggio condotto da IBM tra sviluppatori e dirigenti IT ha rilevato che il 78% degli attuali utenti di microservizi prevede di aumentare il tempo, i costi e gli sforzi investiti nell'architettura, e il 56% delle persone che ancora non sono utenti probabilmente adotterà questi microservizi nei prossimi due anni.
Creando pacchetti e correggendo in modo permanente tutte le dipendenze del sistema operativo, i container consentono cicli rapidi di CI/CD e distribuzione, poiché tutte le integrazioni, i test e la distribuzione avvengono nello stesso ambiente. L'orchestrazione Kubernetes esegue le stesse attività di configurazione continua per le applicazioni containerizzate che Ansible, Puppet e Chef eseguono per le applicazioni non containerizzate.
La maggior parte dei principali provider di cloud computing tra cui AWS, Google, Microsoft Azure e IBM® Cloud, offrono una qualche tipologia di soluzione gestita di pipeline DevOps.
DevSecOps è DevOps che integra e automatizza continuamente la sicurezza in tutto il ciclo di vita di DevOps, dall'inizio alla fine, dalla pianificazione al feedback e di nuovo alla pianificazione.
Si può anche spiegare dicendo che DevSecOps è ciò che DevOps avrebbe dovuto essere fin dall'inizio. Ma due delle prime, significative (e per un certo periodo insormontabili) sfide legate all’adozione di DevOps sono state l’integrazione delle competenze in materia di sicurezza nei team interfunzionali (un problema culturale) e l’implementazione dell’automazione della sicurezza nel ciclo di vita DevOps (un problema tecnico). La sicurezza è stata percepita come una sorta di ostacolo e come un costoso collo di bottiglia in molte pratiche DevOps.
DevSecOps è emerso come uno sforzo specifico per integrare e automatizzare la sicurezza come originariamente previsto. In DevSecOps, la sicurezza è un cittadino e uno stakeholder di prima classe insieme allo sviluppo e alle operazioni e introduce la sicurezza nel processo di sviluppo con un focus sul prodotto.
L'ingegneria dell'affidabilità del sito (SRE) utilizza tecniche di ingegneria del software per automatizzare le attività operative IT, come la gestione dei sistemi di produzione, la gestione delle modifiche, la risposta agli incidenti e persino la risposta alle emergenze, che gli amministratori di sistema potrebbero altrimenti eseguire manualmente. La SRE cerca di trasformare il classico amministratore di sistema in un ingegnere.
L'obiettivo dell'SRE è simile a quello del DevOps, ma è più specifico: l'SRE bilancia il desiderio di un'organizzazione di sviluppare rapidamente le applicazioni con la necessità di soddisfare i livelli di prestazioni e disponibilità specificati negli accordi sul livello di servizio (SLA) stabiliti con i clienti.
I tecnici dell'affidabilità del sito raggiungono questo equilibrio determinando un livello accettabile di rischio operativo causato dalle applicazioni, chiamato budget di errore, e automatizzando le operazioni per soddisfarlo.
In un team DevOps interfunzionale, la SRE può fungere da ponte tra lo sviluppo e le operazioni. La SRE fornisce le metriche e gli strumenti di automazione di cui i team hanno bisogno per spingere le modifiche al codice e le nuove funzionalità attraverso la pipeline DevOps il più rapidamente possibile, senza violare i termini degli SLA dell'organizzazione.
Con l'aumento della portata delle attività che possono essere automatizzate, vengono aggiunte più funzioni a DevOps, generando più varianti di DevOps. E, man mano che DevOps dimostra i suoi numerosi vantaggi, gli investimenti aziendali aumentano.
Secondo Verified Market Research, il mercato DevOps è stato valutato a 10,96 miliardi di dollari nel 2023 e si prevede che raggiungerà 21,13 miliardi di dollari entro il 2031, raggiungendo un CAGR del 21,23% dal 2024 al 2031.
Per garantire il successo di DevOps, le aziende stanno adottando sempre più:
L'intelligenza artificiale per le operazioni IT porta l'AI e il machine learning per automatizzare e semplificare le operazioni IT, consentendo una rapida analisi di enormi quantità di dati.
BizDevOps porta le unità di business a collaborare al processo di sviluppo software insieme allo sviluppo e alle operazioni. Noto anche come DevOps 2,0, questo cambiamento culturale accelera il processo e porta a soluzioni più forti in linea con gli obiettivi dell'unità aziendale.
Un altro modo per creare nuove efficienze è la containerizzazione, dove un'app e le sue dipendenze sono incapsulate in un pacchetto semplificato e portatile eseguito su quasi tutte le piattaforme.
L'aggiunta di altre funzioni di sicurezza all'inizio dello sviluppo ha dato impulso a DevSecOps. La sicurezza non è più un aspetto secondario.
GitOps si concentra sull'archiviazione del codice dell'applicazione in un repository Git in modo che sia controllato dalla versione, disponibile per più membri del team e completamente tracciabile e verificabile. Queste misure aiutano ad aumentare efficienza, affidabilità e scalabilità.
Mentre gli strumenti di monitoraggio tradizionali offrono visibilità, le piattaforme di observability offrono una comprensione più approfondita delle prestazioni di un sistema e, soprattutto, del contesto, ovvero del perché delle prestazioni. Oltre a fornire questa comprensione completa, l'osservabilità consente a tutte le parti interessate di accedere ai dati di cui hanno bisogno per creare soluzioni e applicazioni migliori.
Il serverless computing è un modello di sviluppo ed esecuzione di applicazioni che consente agli sviluppatori di creare ed eseguire il codice delle applicazioni senza eseguire il provisioning o gestire server o infrastrutture di backend. Nelle architetture serverless, gli sviluppatori scrivono il codice delle applicazioni e lo distribuiscono in container gestiti da un provider di servizi cloud.
Usa un potente software DevOps per creare, distribuire e gestire app cloud-native sicure su più dispositivi, ambienti e cloud.
Automatizza il processo di distribuzione del software per aumentare la produttività e l'efficienza operativa.
Trasforma le applicazioni mission-critical per ambienti cloud ibridi con stabilità, sicurezza e agilità.
Realizza più velocemente l'innovazione, riduci i costi operativi e trasforma le operazioni IT (ITOps) in un panorama in continua evoluzione con una piattaforma AIOps che rende pienamente visibili i dati sulle prestazioni e le dipendenze tra gli ambienti.
Scopri in che modo la modernizzazione degli ambienti applicativi mainframe fornirà maggiori risultati di business.
Accedi a un esclusivo report degli analisti di Gartner e scopri come l'AI per l'IT migliora i risultati aziendali, aumenta i ricavi e riduce sia i costi che i rischi per le organizzazioni.
Questo documento di IBM Redpaper illustra strategie e soluzioni architetturali in grado di accelerare la modernizzazione delle applicazioni mainframe sfruttando gli ambienti ibridi di cloud. In particolare, consultare il capitolo 5 per informazioni sulla modernizzazione del DevOps aziendale.
Scopri di più su Wazi Deploy, che aggiunge un'opzione di distribuzione di applicazioni basate su script open source all'ampio set di strumenti di sviluppo IBM Developer for z/OS Enterprise Edition.
Esplora un programma di adozione anticipata a valore aggiunto progettato per collaborare con i clienti durante le fasi distinte che riteniamo necessarie per qualsiasi trasformazione DevOps.
Unisciti alla community DevSecOps per restare al passo con le ultime tendenze e argomenti di Z.