AES_5 2022

Primo piano 25 SCENARI Automazione e Strumentazione n Giugno - Luglio 2022 russo in Ucraina, insegnano anche al mondo indu- striale quanto le supply chain possano rivelarsi fragili e rapidamente perturbabili; e quanto, sia vitale, per conservare competitività sul mercato, e accelerare il time-to-market, aumentare la tra- sparenza, la flessibilità e l’efficienza del processo di sviluppo e distribuzione del software, che sta alla base del funzionamento dei dispositivi IIoT (industrial IoT), dei sistemi e delle applicazioni embedded industriali. Perché considerare il paradigma DevOps DevOps è soprattutto questione di cultura. Nel senso che, prima di fondarsi sull’utilizzo di nuovi strumenti software, DevOps si fonda su un profondo cambiamento culturale dei processi e delle modalità di lavoro nelle organizzazioni IT, tipicamente costi- tuite da due reparti di attività: i team di addetti allo sviluppo (Dev) del codice applicativo, e le squadre di esperti che, invece, si occupano di predisporre le infrastrutture IT (Ops) richieste per il funziona- mento dello stesso. L’obiettivo di DevOps è proprio superare le limitazioni tradizionalmente esistenti negli ambienti Dev e Ops , dove spesso il metodo di sviluppo adottato è quello a cascata (waterfall). Una procedura che prevede un ciclo di progettazione sequenziale (requirements, design, implementation, verification/testing, deployment, maintenance), rigido, in cui non sono ammesse iterazioni tra una fase e l’altra, per eseguire modifiche del codice in corso d’opera, ma è necessario prima completare tutto il ciclo. Seguendo questa metodologia, il com- mittente del progetto non viene coinvolto nelle fasi di progettazione e implementazione, e solo alla fine del ciclo ha la possibilità di verificare se il codice risponde alle sue aspettative e ai requisiti stabiliti inizialmente per quel dato tipo di prodotto, applica- zione, sistema. Con la metodologia waterfall è possibile applicare processi rigorosi di controllo, verifica e validazione del codice, ma i tempi e i costi di sviluppo, specie quando occorre intervenire per apportare modifiche al codice, possono rivelarsi elevati e non sostenibili. In aggiunta, nei tradizionali ambienti Dev e Ops, in particolar modo nei settori fortemente regolamen- tati da normative specifiche relative alla sicurezza, alla privacy, o alla safety, come possono essere l’in- dustria automotive, avionica, il settore manu- facturing o quello medicale , esiste una rigorosa politica di ‘segregation of duties’ (SoD), ossia di separazione dei compiti. In sostanza, le regole SoD fanno sì che chi ha la responsabilità di sviluppare codice, ed ha quindi la facoltà di apportare modi- fiche al software in ambiente di sviluppo, non ha il permesso di eseguire il deployment di tali cambia- menti in ambiente di produzione, cosa che, invece, DevOps punta a ottimizzare e velocizzare la progettazione del codice, ma senza comprometterne la qualità o aumentare i costi di sviluppo (fonte: Pixabay)