Introduzione del DevOps
Cambiare il modo in cui il software arriva in produzione: modifiche più piccole, rilasciate più spesso, con un ripristino invece che una speranza.
Panoramica
Il DevOps è un modo di lavorare, non una cassetta di attrezzi. Installare gli strumenti senza cambiare il modo di lavorare produce gli stessi grandi rilasci mensili con registri migliori, il che cambia poco per chi la notte è al telefono con un guasto.
Il cambiamento è semplice da enunciare e scomodo da realizzare: modifiche più piccole, rilasciate più spesso, testate automaticamente, con un ripristino che qualcuno ha già eseguito davvero. Questo riduce il rischio per rilascio, perché c'è meno roba in volo alla volta.
A chi è rivolto
- Squadre che rilasciano di rado e con rischio alto
- Aziende i cui rilasci richiedono passaggi manuali e una lista di controllo
- Organizzazioni senza un percorso di ripristino provato
Il nostro approccio a Introduzione del DevOps
Le attività concrete che comprende un incarico tipo. Il perimetro si concorda prima: nulla di quanto elencato ricompare più avanti come voce a sorpresa.
Ricognizione
Come si rilascia oggi, quanto tempo richiede, cosa si fa a mano e cosa è andato storto di recente.
Rilascio automatizzato
Il rilascio come operazione ripetibile invece di una sequenza di passaggi che una persona ha in testa.
Infrastruttura come codice
Ambienti definiti invece che configurati a mano, perché test e produzione si assomiglino davvero.
Ambienti
Ambienti separati con dati realistici, perché un test su una base vuota insegna poco.
Ripristino
Un percorso di ritorno provato. Un ripristino mai eseguito è un'ipotesi, non un piano.
Reperibilità e passaggio
Chi viene chiamato in caso di guasto, in quale ordine, e cosa trova quando entra.
Dal primo contatto al risultato misurato
Sempre la stessa sequenza, così sapete cosa viene dopo.
Rilevare
Descrivere il percorso attuale dal commit alla produzione, con tempi e gesti reali.
Automatizzare
Sostituire i passaggi manuali, partendo da quelli che producono più errori.
Aumentare il ritmo
Passare a rilasci più piccoli e frequenti, il che riduce il rischio per rilascio invece di aumentarlo.
Provare
Eseguire ripristino e procedura di guasto prima che servano sotto pressione.
Risultati, non pile di documenti
Un cumulo di deliverable non è progresso. Questi sono i cambiamenti che il lavoro deve produrre.
Meno rischio per rilascio
Quando parte poco alla volta, la causa di un guasto si trova in minuti invece che in ore.
Un ripristino che funziona
Aver provato il ritorno separa una breve interruzione da una lunga serata.
Ambienti confrontabili
Un'infrastruttura descritta chiude la classe di errori che compaiono solo in produzione.
Meno dipendenza dalle persone
Un processo automatizzato significa che rilasciare non dipende da chi è in ferie.
Domande frequenti su Introduzione del DevOps
Quello che ci chiedono prima di contattarci. Se la vostra domanda non c'è, fatecela direttamente.
Rilasciare più spesso non aumenta il rischio?
È il contrario. Il rischio cresce con la quantità di modifiche per rilascio, non con il numero di rilasci. Dieci piccoli rilasci si verificano e si ritirano uno a uno, mentre un grande rilascio mensile contiene decine di modifiche di cui nessuna è identificabile come causa in caso di guasto.
Servono figure DevOps dedicate?
Non necessariamente, e per una squadra piccola è spesso la risposta sbagliata. Serve un processo automatizzato che gli sviluppatori usino da soli. Un ruolo dedicato si giustifica da una dimensione in cui il lavoro di piattaforma è un'attività permanente.
Quanto dura la transizione?
Miglioramenti sensibili in quattro o otto settimane, in genere automazione del rilascio e un ripristino affidabile. Il passaggio a rilasci davvero piccoli richiede più tempo, perché tocca abitudini e non strumenti.
E se siamo fortemente regolamentati?
La regolamentazione richiede tracciabilità e approvazioni, non rilasci rari. Un processo automatizzato con approvazioni registrate soddisfa in genere i requisiti di audit meglio di un processo manuale, perché ogni passaggio è documentato e ripetibile.
State pensando a Introduzione del DevOps?
Diteci che cosa volete cambiare. Se non siamo i partner giusti ve lo diciamo e vi indichiamo di meglio.
Vi interessa il quadro completo?
Introduzione del DevOps di solito si affianca ad altre attività in DevOps, infrastruttura ed esercizio tecnico. Sfogliate l'intera area per vedere i collegamenti.