Processo di rilascio del team

Completato

Il primo passaggio per configurare una procedura DevOps consiste nel valutare il processo corrente. Ciò significa analizzare:

  • Gli artefatti esistenti, ad esempio i pacchetti di distribuzione e NuGet, nonché i repository del contenitore.
  • Gli strumenti di gestione test esistenti.
  • Gli strumenti di gestione del lavoro esistenti.
  • Raccomandazione di strategie di migrazione e integrazione.

A questo scopo, è possibile usare il team di Tailspin e vedere come DevOps può essere utile.

Dopo che Irwin il product manager lascia, Amita dice: "Abbiamo bisogno di aiuto. Non so quando queste correzioni sono dovute, ma so che è presto. Non siamo configurati per un rapido turnaround. Inoltre, il nuovo sito Web di Space Game dovrà attendere fino a quando non avremo risolto questo pasticcio, e quel gioco sta per arrivare velocemente".

Andy guarda Mara. "Questo è molto da prendere durante le prime settimane."

"Va bene", risponde Mara. "Forse puoi spiegarmi come funzionano le cose qui. In che modo un gioco passa dallo sviluppo all'ambiente di produzione?

"Questa è una grande domanda", dice Andy. "Sarà difficile trovare una risposta semplice, ma vale la pena provare."

Il team decide di andare in un bar per rilassarsi e avere una discussione informale. Insieme, cercheranno di capire perché stanno avendo così tanti problemi.

Oltre il caffè, Mara ascolta e cerca di prendere appunti. C'è un sacco di informazioni e non è organizzato. I suoi pensieri generali sul team sono:

  • Usano un approccio a cascata. La gestione imposta le priorità. Gli sviluppatori scrivono codice e consegnano la compilazione al controllo di qualità. I test di controllo di qualità e quindi passano alle operazioni per la distribuzione.
  • L'approccio a cascata potrebbe essere accettabile per un piccolo team, ma in questo caso gli obiettivi non sono sempre chiari e sembra che cambino frequentemente.
  • Il test viene ritardato fino alla fine del processo. Ciò significa che è più difficile e più costoso correggere i bug e apportare modifiche.
  • Non esiste alcuna definizione chiara di cosa significhi Fine. Ogni membro del team ha una propria idea. Non c'è alcun obiettivo aziendale complessivo su cui tutti sono d'accordo.
  • Alcuni codici si trovano in un sistema centralizzato di controllo della versione. Molti strumenti e script esistono solo nelle condivisioni file di rete.
  • Esistono molti processi manuali.
  • La comunicazione è afazard e dipende dalla posta elettronica, dalla documentazione di Word e dai fogli di calcolo.
  • Il feedback è anche poco frequente e incoerente.
  • Sul lato più, la squadra sembra andare avanti, e vogliono migliorare le cose.

Quando guarda il suo mucchio di note, Mara sa che ha bisogno di organizzare tutte queste informazioni. L'organizzazione renderà più semplice valutare i processi. È convinto che un approccio DevOps risolverà molti dei problemi del team, ma ha bisogno di un modo per presentare il suo caso al team.

Una pratica DevOps inizia spesso con la comprensione dei processi esistenti. Da qui, è possibile valutare cosa funziona bene, cosa non è e concentrarsi su cosa correggere per primo.

Screenshot of a person taking notes on their tablet device.

Mara chiede "Qualcuno di voi ha mai eseguito un esercizio di mapping di flusso del valore?"

Andy rotola gli occhi, Amita sospiri, e Tim dice: "Non abbiamo bisogno di più documenti".

Mara dice: "Lo capisco. Lascialo a me."

Contento di lasciare che il newbie lo gestisca, tutti tornano al lavoro.