Qual è lo scopo di un team DevOps?

Stai attento! Senza un'adeguata guida da parte della leadership tecnica, i "team" DevOps possono finire per essere bidelli, responsabili di default per qualsiasi / tutto ciò che non è esplicitamente responsabilità di qualcun altro già.

Poiché Jez Humble ha dichiarato , DevOps "è una pratica, non una strumento. ", con una delle motivazioni alla base della riduzione dei silos tra i team di progettazione, controllo qualità e operatori.

Che ci sia o meno essere un team DevOps è discutibile, poiché reintroduce efficacemente un team silente responsabile di build, automazione, schieramenti e altre attività simili, con lo svantaggio significativo che questi oneri vengono rimossi da altri team che sono quindi meno incentivati a preoccuparsi delle considerazioni build / deploy / runtime del loro prodotto.

Quindi, con l'avvertimento che questo può variare molto tra le organizzazioni, ci sono due potenziali modelli da seguire per le organizzazioni:

• Nessun team DevOps: i team di progettazione hanno la responsabilità di assicurarsi che i componenti vengano compilati nel sistema di configurazione, vengano distribuiti in ambienti di test e siano impacchettati / containerizzati in modo da essere consumabili dal team ops per l'implementazione finale in ambienti di produzione. (Nelle piccole organizzazioni senza un team operativo, l'implementazione della produzione può essere eseguita anche da un tecnico).

• DevOps Team come Facilitatore: se un team DevOps separato (o persona) esiste in un ruolo autonomo, un approccio è quello di rendere questo team responsabile della fornitura di gap di automazione o tooling che consente un approccio più self-service dal resto del organizzazione, ovvero:

  • Non creare macchine di prova / VM per le persone, creare (o acquistare) un servizio per farlo (abbiamo fatto il nostro, ma MS SystemCenter è un esempio).
  • Automatizza fino a zero o un clic la distribuzione dei candidati e delle versioni di produzione in modo che chiunque possa essere l'iniziatore di un ciclo di build e test, e non ricade sul team DevOps per essere coinvolto in ogni singola iterazione.
  • Promuovi l'uso di contenitori o altri meccanismi di imballaggio in modo che i team possano consegnare pacchetti completi alle operazioni che sono pronti per essere distribuiti.

In questo modello, è importante definire il ruolo del team come automi e facilitatori, altrimenti è del tutto possibile finire come "la gente dell'installatore", a questo punto i benefici della pratica DevOps sono già andati persi.