Come posso incoraggiare le OP a partecipare a una squadra di devops?

La risposta sopra sulla ricerca di un terreno comune sarebbe il miglior consiglio, e in linea con lo spirito dei devops - ma personalmente, l'idea di avvicinare operazioni e sviluppo per me significa smettere di pensare al personale come "dev" o "operazioni", in primo luogo, e per mettere in evidenza i punti di forza di tutti in termini di miglioramento del prodotto complessivo. Suggerimenti pratici che hanno funzionato per me in passato, in termini di coinvolgimento di tutti in una discussione:

• Creazione di pipeline - Quanto tempo è necessario per creare, testare, distribuire e eseguire il rollback delle modifiche in vari ambienti? Perché non possiamo farlo automaticamente? Cosa si può fare per migliorare questo?
• Monitoraggio e osservabilità. Cosa sappiamo della salute dei nostri vari sistemi software? Quali funzionalità aziendali supportano? Se perdiamo un particolare servizio, quanto è critico per l'azienda? Questa è la tariffa Ops / ITIL tradizionale, ma concentrandosi su questo con persone tradizionalmente dev-minded a) rafforza l'importanza delle modifiche sicure, b) spesso porta intuizioni migliori in "possiamo completamente automatizzare questo"
• Sicurezza, prestazioni e gestione della vulnerabilità del software. A seconda del modo in cui la tua azienda struttura vari skillset, potrebbe essere necessario coinvolgere altri team / persone per dare una mano, ma stabilire test di penetrazione continui o test del fumo delle prestazioni che si svolgono all'inizio del pezzo (piuttosto che prima di andare al prod!) È fondamentale ottenere feedback rapidi e garantire la qualità attraverso il ciclo. Lo stesso vale per mantenere il team aggiornato sulle vulnerabilità della sicurezza o delle licenze del software che utilizzano ed evitare la dipendenza dal pacchetto npm. A:)
• 'The Pink Test' - Un esercizio per testare il tempo di sviluppo / distribuzione. Quanto tempo è necessario per implementare la più semplice delle modifiche, ad es. "trasforma questo schermo in rosa". Questo ha bisogno di input da parte di tutti (tradizionalmente) perché non è solo lo sforzo di sviluppo richiesto, ma anche l'analisi del processo di gestione delle modifiche e dei processi di infra / implementazione. Una volta misurato, decidere se questo è appropriato per le esigenze aziendali e vedere cosa si può fare per migliorare il tempo di ciclo.

Non sparare ... vengo in pace;)

Posso riguardare l'altro lato della medaglia visto che ero una di quelle persone delle operazioni.

Immagina solo che tu (il Dev) ti trovi nella riunione dell'operazione in cui non c'è nulla da dire o da cui tu possa parlare e devi sederti lì per un certo numero di ore. E l'unica cosa che puoi pensare è che hai dei biglietti BAU arretrati. Ho trovato questo incredibilmente noioso e una totale perdita di tempo per me e il mio team.

Comunque alla fine abbiamo (Dev + Ops) insieme abbiamo trovato un terreno comune .

Le Operazioni saranno incluse in riunioni retrospettive in una data fase, cioè all'inizio o alla fine. Dove discuteremo la parte dello sprint che in qualche modo si riferisce alle Ops, sia che si tratti di prestazioni, requisiti o quant'altro. Ci vorrebbe tutto il tempo necessario per assicurarsi di avere punti pronti per essere sollevati con le operazioni, in modo che l'incontro sia strutturato. In ogni caso, una volta che tutti sono soddisfatti, gli Ops possono abbandonare i loro compiti e il Dev può continuare con nuove funzionalità o altro.

Il mio messaggio sarebbe: trovare un terreno comune e magari qualcuno dall'altra parte (Ops) che capisca le tue preoccupazioni e abbia una mentalità aperta quando si tratta di DEV, cioè qualcuno che ha "DEVOPS" mentalità .

Non penso che ci sia un insieme di competenze (tm) ufficiali per "OPS" ogni azienda avrà responsabilità diverse per il ruolo.

Tuttavia, direi che normalmente DEVOPS non è qualcosa che fai come parte di uno sprint di stile "aggiungi una nuova funzionalità al nostro software".

Se fai "DEVOPS", allora il tuo ambiente operativo è a posto. Come è la tua build, prova e distribuisci pipeline.

Il team OPs farebbe le proprie cose assicurandosi che i server non si blocchino, monitorando il firewall, installando il nuovo hardware ecc. Il team di DEVOPS potrebbe lavorare su un progetto per "migrare verso il cloud" o somesuch