Quando si spiega DevOps a qualcuno, succede che sorge una domanda come:
In che modo la gestione delle versioni utilizzando la metodologia Agile differisce da Waterfall?
Quindi, che tipo di criteri puoi usare per spiegare queste differenze a tale pubblico?
Risposte:
IMO DevOps è cultura, molto simile a Agile (senza scegliere una metodologia agile.) Pertanto non devi "fare" DevOps.
"Fai" una metodologia di rilascio chiamata Continuous Delivery come parte di una cultura DevOps. (divulgazione completa, non credo di aver mai fatto riferimento al CD come una metodologia di rilascio prima, ma nel mio stato jetlagged penso che funzioni)
Se lo acquisterai, ecco la definizione di consegna continua di una delle persone che hanno scritto il libro con lo stesso titolo, Jez Humble .
La consegna continua è la capacità di ottenere cambiamenti di tutti i tipi, incluse nuove funzionalità, modifiche alla configurazione, correzioni di errori ed esperimenti, nella produzione o nelle mani degli utenti, in modo sicuro e rapido in modo sostenibile.
Il nostro obiettivo è realizzare distribuzioni — che si tratti di un sistema distribuito su larga scala, un ambiente di produzione complesso, un sistema incorporato o un'app — affari di routine prevedibili che possono essere eseguiti su richiesta.
Raggiungiamo tutto ciò assicurando che il nostro codice sia sempre in uno stato distribuibile, anche di fronte a team di migliaia di sviluppatori che apportano modifiche su base giornaliera. In questo modo eliminiamo completamente le fasi di integrazione, test e indurimento che tradizionalmente seguivano "sviluppo completo", così come il blocco del codice.
Quindi, puoi lavorare in una metodologia Agile, avere un software che puoi dimostrare all'azienda, assicurandoti di eseguire test automatici adeguati, reagendo bene al cambiamento e a tutte le cose che lo rendono migliore della cascata. Troppo spesso ciò non significa che potresti effettivamente distribuirlo alla produzione.
Si finisce con qualcosa del genere:
Quindi il software sarà (probabilmente) migliore quando hai finito, se non avessi una sorta di approccio iterativo, ma non lo sai davvero perché gli utenti reali non l'hanno mai visto.
Quello che vuoi davvero è qualcosa che assomigli di più a questo:
Ogni iterazione, qualcosa viene distribuito alla produzione. Quindi, il software è distribuito . Se decidi di creare download, apri il server web o comunque ottieni il software nelle mani degli utenti che viene rilasciato .
Quindi cosa c'entra DevOps con questo?
È molto, molto difficile (quasi impossibile) avere veramente il tuo software in uno stato in cui puoi distribuirlo quando vuoi, a meno che quel team non stia lavorando in una cultura DevOps. Una cultura in cui amministratori di sistema, DBA, SRE, Security People, Devs, QAs, ecc. Ecc. Fanno tutti parte di un singolo team e non fanno parte di una organizzazione con limiti.
Nota :
Circa parte di un commento pubblicato a questa risposta, che era così:
Informazioni sul tuo "... software in uno stato in cui è possibile implementarlo quando vuoi ...": questo mi ricorda il software "pilota automatico" (su un aereo) ... La mia domanda preferita al riguardo: " Immagina un aggiornamento viene applicato a tale software ... Come ti sentiresti a farlo in volo ... Mentre sei a bordo? ".
Adoro quella domanda (in grassetto, nella citazione sopra)! L'idea di "è davvero pronta?" è qualcosa di cui vado in continuazione - blog . L'IMO è fondamentale per la sicurezza, le prestazioni e altri test "secondari" troppo frequenti per esercitarsi con il CD. Le funzionalità sono fatte quando hanno finito, ma gli hacker sono sempre lì.
Non sono sicuro se non ce ne sono altri, ma questi sono i criteri che utilizzo:
+-------------------+-----------+-----------+
! Criteria ! Agile ! Waterfall !
+-------------------+-----------+-----------+
! Release Events ! Frequent ! Rare !
! Risk ! Less ! High !
! Required Effort ! Smoother ! Peaks !
! Volume of changes ! Small ! Huge !
+-------------------+-----------+-----------+
E se vuoi davvero sperimentare la differenza da solo come utente di alcuni software, allora pensa a utilizzare alcuni software (come una distribuzione Linux), dove puoi scegliere tra utilizzare una di queste versioni:
una " Rolling" versione (==> Agile).
una versione " Long Term Support" (==> Cascata).