<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1267344923293614&amp;ev=PageView&amp;noscript=1">

Blog

Come cambia il lavoro per i Dev e gli Ops con l'introduzione di Openshift

Davide Costanza

Davide Costanza, 19 luglio 2019 | Red Hat Openshift DevOps

In altri articoli, già pubblicati sul blog di Extra Red, abbiamo approfondito i temi dell’approccio DevOps, delle metodologie e degli strumenti necessari per poterlo implementare, fino a descrivere come OpenShift possa essere utilizzato come Container Platform per implementare le pipeline di produzione del software all’interno di una organizzazione. In questo articolo invece voglio mettere l’enfasi sul come i ruoli dello sviluppatore software (Dev) e quello del sistemista (Ops) cambierebbero con l’introduzione del DevOps attraverso l’automazione spinta, il self-service e la replicabilità delle pipeline.

Scopri come velocizzare il Time-To-Market delle applicazioni con OpenShift!

Rispetto alle mansioni classiche a cui siamo abituati, l’approccio DevOps porta naturalmente, ma nello stesso tempo necessariamente, a far diventare "più Ops i Dev e più Dev gli Ops"! Un'operazione non banale ovviamente, che passa dall'avere in azienda personale totalmente autonomo o, come si usa definire con un job-title in voga, un Full-stack Developer.

Chi sono gli addetti all'introduzione del DevOps?

Prima di arrivare ad introdurre workflow condivisi implementati su Openshift, la nostra metodologia di introduzione al DevOps in una azienda prevede l’individuazione di due o più persone che fungano da apri pista, delle figure chiave insomma che consentano di accelerare il periodo di “contaminazione”, figure che ci piace indicare col nome Dev++ e Ops++.

Quali caratteristiche devono avere queste figure addette a introdurre il DevOps?

Dev++

  • Conosce bene i container
  • Se la cava bene con gli script di shell
  • Conosce bene Git
  • Conosce bene Jenkins
  • È un automatore compulsivo
  • Ha competenze di networking
  • È un buon architetto
  • È disciplinato e pretende disciplina
  • Non è detto che sia una persona sola

Ops++

  • Conosce bene Docker e i container
  • Conosce bene Ansible
  • Conosce bene Git
  • Gli piace programmare (non solo in bash)
  • È un fanatico dell’automazione
  • Gli piace costruire strumenti
  • È un documentatore compulsivo
  • Vuole strumenti di monitoraggio evoluti
  • Non è detto che sia una persona sola

Queste figure avranno il compito di rendere più chiara la cultura DevOps al resto del team attraverso attività di mentoring, meglio ancora se supportata da aziende esterne specializzate nel settore che renderebbero più veloce e certa la trasformazione del modello di sviluppo.

Introdurre un attore terzo ha diversi vantaggi, che vanno da delegare l’oneroso Change Management, sfruttare l’esperienza altrui nell’evitare errori noti e farsi accompagnare nell’introduzione di nuove tecnologie.

Gli step successivi all'introduzione del metodo

L’azienda esterna, fornitrice del servizio, lavorerà quindi su tre aspetti chiave:

1. Diffusione della Cultura DevOps

La diffusione della Cultura DevOps, attraverso diversi interventi di condivisione col team che dovrà avere necessariamente un forte commitment da parte del management aziendale.

2. Ridefinizione dei processi

Naturalmente, nel corso dell'introduzione del metodo i processi dovranno essere, almeno in una prima fase, continuamente verificati e controllati.

3. Introduzione nuovi strumenti

Introduzione di determinati strumenti che consentano di implementare i processi nel modo più facile e sicuro possibile.

Dall'introduzione alla delivery del progetto

Gli step che comunemente proponiamo alle aziende che si rivolgono a Extra Red per essere supportate in un percorso di DevOps sono i seguenti:

  1. Discovery Session: tutti insieme Dev e Ops per un incontro esplorativo atto a identificare le sfide aziendali e gli approcci più adatti a superarle. In questa fase vengono identificati gli attori che gestiranno le fasi successive
  2. Assessment: approfondimento sulle modalità di sviluppo del software presso il cliente, strumenti e processi
  3. Design: la proposta di cambiamento con attività di dettaglio, identificazione di strumenti, tempi e costi

A seguito di queste tre fasi, si passa alla delivery del progetto vero e proprio, che sarà un giusto mix di diversi interventi di Installazione, Configurazione, Manutenzione e Training sugli strumenti che sono stati individuati, sviluppo di PoC o Progetti Pilota, Training on the job, Mentoring e Supporto al management per individuare modalità di valutazione del successo del cambiamento.

La ridefinizione del ruoli di Dev e Ops con l'introduzione di OpenShift

Una delle attività critiche è quella della ridefinizione dei ruoli tra Dev e Ops. Chi fa cosa con l’introduzione di OpenShift come strumento di gestione delle pipeline di sviluppo applicativo in azienda?

Di seguito, la nostra proposta:

Dev

  • Utilizzano le risorse all’interno dei progetti per lo sviluppo del software
  • Creano le pipeline Jenkins (build) (Jenkins è integrato in Openshift)
  • Gestiscono il deployment in ambienti non di produzione
  • Gestiscono service e route in ambienti non di produzione
  • Producono informazioni per il logging e il monitoring applicativo

Ops

  • Installano la piattaforma
  • Amministrano la piattaforma
  • Gestiscono la quota delle risorse
  • Gestiscono le utenze e i ruoli
  • Creano e mantengono le immagini base
  • Amministrano il catalogo dei template (applicazioni in self-service)
  • Gestiscono i deployment e le route in produzione
  • Utilizzano gli strumenti di monitoring

Insieme all'approccio DevOps e agli strumenti per l'automazione del rilascio software, Openshift è la piattaforma migliore per velocizzare il Time-To-Market delle applicazioni. Se vuoi approfondire l'argomento, ti invito a scaricare il nostro eBook gratuito dedicato, cliccando sul pulsante qui sotto:

Velocizzare Time-To-Market applicazioni con OpenShift

Lascia un commento