A proposito di DevOps

L’esplorazione del continente del setup continua e giungiamo nella città delle meccaniche di base.

In questo meetup, Ferdinando ha voluto sperimentare un format diverso dal solito. Anziché esporre o raccontare qualcosa di preconfezionato, la serata ha preso forma attraverso un dibattito aperto al pubblico, dove ognuno ha portato il proprio contributo.

Tutto è iniziato dalla domanda fondamentale:

Cos’è DevOps?

A questa prima domanda sono nati già i primi spunti:

• Chimera: un mito, una forma strana, un ibrido tra Dev e Sistemista
• L’evoluzione naturale dell’agilità, per comprendere le operations al suo interno
• E’ la risposta alla domanda: “come posso consegnare valore al mio cliente?”, dopo aver capito come crearlo
• Metodologia di buone pratiche per il rilascio del software
• Implementazione di T-Shaped people: persona che non è verticale solo in una cosa ma che amplia il raggio d’azione, riuscendo dunque a vedere un end-to-end più ampio, come ad esempio un’integrazione di sistemi e applicazioni.
• Team misto di persone con competenze variegate che si aiutano a vicenda
• Non si tratta di solo software

A seguito di questo primo confronto abbiamo provato insieme a cercare una “risposta ufficiale”, ma nemmeno Wikipedia è stata in grado di offrirla:

Academics and practitioners have not developed a universal definition for the term “DevOps”.

Nel secondo passaggio abbiamo quindi iniziato a formulare delle ipotesi.
Sfruttando la celebre fiaba indiana dell’elefante, Ferdinando ha guidato la discussione su tre delle definizioni che si sentono normalmente “nei corridoi”.

1.1 DevOps è un mindset

Non si fa DevOps, si è DevOps,

In questo frangente del dibattito si è parlato di questa sorta di “reductio ad mindset” che permea il mondo di DevOps e di altre declinazioni dell’agilità. Il mindset è sicuramente importante, ma dire che “serve il mindset” porta rapidamente alla domanda conseguente: “come lo ottengo questo mindset?”.

Il pubblico ha offerto interessanti punti di vista:

Il DevOps è quella persona che non si ferma di sviluppare quando funziona la sua macchina, ma si assicura che funzioni anche in altri contesti.

Le pratiche DevOps facilitano l’agilità.

Ma tali pratiche esistevano già prima che DevOps nascesse, sotto altre forme e nomenclature (Extreme Programming, Lean, e il Manifesto per lo sviluppo agile del software, ad esempio).

Quindi, in concreto?
Che differenza c’è con la cultura e quindi il mindset di altri approcci come quelli di Lean, XP o del Manifesto?

Una riflessione interessante è stata notare come in Extreme Programming si sia parlato poco delle Operations. Ferdinando ha fatto qualche domanda agli attori protagonisti di quel tempo, scoprendo qualcosa in più dalla viva testimonianza di Ron Jeffries.

In un frangente della discussione, qualcuno dal pubblico ha evidenziato come oggi “I team hanno iniziato a fare Ops”: DevOps abbatte esplicitamente i silos fra Dev e Ops. Mischiando i team nasce il concetto di responsabilità condivisa e con essa il fatto di lavorare su e per più contesti e di creare ulteriori nuovi team.

1.2 DevOps è un approccio

Abbiamo quindi provato ad argomentare l’affermazione “DevOps è un approccio”.

Sì, bene, ma un approccio a cosa? E’ un processo? Un metodo? Un framework?
Ferdinando ha continuato ad alimentare la discussione con frasi che ha sentito o letto in proposito.

C’è chi ad esempio dice:

Faccio DevOps e non Scrum.

Ma come gestisco i processi, allora, in DevOps? Esistono dei PM in DevOps?

Agile e DevOps non sono comparabili, ma DevOps è un’estensione dell’Agile in ambito di gestione dello sviluppo software e dell’infrastruttura (in operations)

DevOps è un’aggiunta, un plugin; può applicarsi anche al waterfall, ma Agile e DevOps sono cose distinte.

Un’altro argomento emerso è scaturito da una testimonianza:

Conosco sviluppatori che hanno rifiutato lavori in aziende che facevano Agile o Scrum.

DevOps sembra quindi in alcuni casi raccogliere anche una fetta dei delusi dall’agilità, anche se si è convenuto che in sé e per sé DevOps non è sostitutivo di un altro metodo/framework.

2.2 DevOps è mantenere scorrevole il flusso, da backlog a produzione

In un secondo “lato dell’elefante DevOps” si vedono riferimenti al flusso del valore, o Value Stream. Ferdinando riporta quanto letto e sentito, e l’attenzione che spesso si percepisce su questo tema quando si parla di DevOps.

Ma anche in questo caso sorge un dubbio: non si tratta semplicemente di Lean?

In questo frangente non c’è stato bisogno di dibattere un granché, visto che ci si è trovati da subito d’accordo sull’importante influenza che Lean ha dato a DevOps (e non solo).

3.1 DevOps è un set di tools e pratiche

L’ultimo aspetto sintetizzato da Ferdinando riguarda il forte riferimento di DevOps a tool e pratiche. Di seguito alcune delle frasi emerse nel confronto.

Spesso CI/CD e DevOps vengono usati come sinonimi, erroneamente. In realtà le radici di DevOps affondano nella cultura aziendale; è un ciclo che non si ferma mai

Tutti d’accordo, ma anche qui nulla di nuovo: sviluppo iterativo e incrementale si conosceva già da tempo.

Sono Dev che fanno Ops, o Ops che fanno Dev?

Sistemisti che programmano o programmatori che fanno i sistemisti? Bella domanda!

3.2 E’ trattare le operations come fossero sviluppo (Ops come Dev)

Sono pratiche di sviluppo adeguate e adottate da operations.

Questa è una delle definizioni che più ci è piaciuta. DevOps è diventato oggi un contenitore di tutte le tecnologie e le pratiche sviluppate che negli ultimi anni ci hanno permesso di passare, ad esempio, da sistemi on-premise a “gestione manuale” a infrastrutture cloud ad elevata complessità.

3.3 DevOps è un ruolo?

Nell’ultimo blocco ci siamo interrogati su un’altro punto di vista abbastanza comune, ovvero che DevOps sia un ruolo.

Nel corso del tempo sono nate tante nuove competenze in ambito Ops (pensate alla moltitudine di cloud provider, orchestrator, etc.). Ha quindi iniziato a diffondersi la necessità di dare un nome al tutto, e DevOps sembra sia diventato il termine cappello adatto a racchiuderle tutte, seppure alcune sono fondamentali e sarebbe bene riconoscerne il ruolo (come quello di Cloud Engineer o di SRE, ad esempio).

Conclusioni

Al termine della serata, il gruppo è giunto a conclusione che in effetti le Operations sono state sottovalutate e non prese bene in considerazione per moltissimo tempo. L’avvento di DevOps ha permesso di metterci l’attenzione necessaria, e di questo siamo tutti grati.

Infine ci siamo lasciati con la definizione che dà Patrick Debois, colui a cui si adduce l’invenzione del termine DevOps:

Risorse

• Mirò Board del meetup: https://miro.com/app/board/uXjVOkboSI8=/