Una volta abbiamo fornito un sistema di gestione elettronica dei documenti a un cliente presso una struttura. E poi ad un altro oggetto. E un altro ancora. E il quarto e il quinto. Ci siamo lasciati così trasportare che abbiamo raggiunto 10 oggetti distribuiti. Si è rivelato potente... soprattutto quando siamo riusciti a realizzare i cambiamenti. Nell'ambito della consegna al circuito produttivo, 5 scenari del sistema di test hanno richiesto in definitiva 10 ore e 6-7 dipendenti. Tali costi ci hanno costretto a effettuare le consegne il più raramente possibile. Dopo tre anni di attività, non riuscivamo più a sopportarlo e abbiamo deciso di ravvivare il progetto con un pizzico di DevOps.
Ora tutti i test si svolgono in 3 ore e vi partecipano 3 persone: un ingegnere e due tester. I miglioramenti si esprimono chiaramente in numeri e portano ad una riduzione del tanto amato TTM. Secondo la nostra esperienza, sono molti di più i clienti che possono trarre vantaggio da DevOps rispetto a quelli che ne sono a conoscenza. Pertanto, per avvicinare DevOps alle persone, abbiamo sviluppato un semplice costruttore, di cui parleremo più in dettaglio in questo post.
Ora te lo raccontiamo più nel dettaglio. Una società energetica sta implementando un sistema di gestione dei documenti tecnici in 10 grandi strutture. Non è facile gestire progetti di questa portata senza DevOps, perché gran parte del lavoro manuale ritarda notevolmente il lavoro e riduce anche la qualità: tutto il lavoro manuale è pieno di errori. D'altra parte, ci sono progetti in cui esiste una sola installazione, ma tutto deve funzionare automaticamente, costantemente e senza guasti, ad esempio gli stessi sistemi di flusso di documenti nelle grandi organizzazioni monolitiche. Altrimenti, qualcuno effettuerà le impostazioni manualmente, dimenticherà le istruzioni di distribuzione e, di conseguenza, in produzione le impostazioni andranno perse e tutto crollerà.
Di solito lavoriamo con il cliente attraverso un contratto e in questo caso i nostri interessi divergono leggermente. Il cliente esamina il progetto rispettando rigorosamente il budget e le specifiche tecniche. Può essere difficile spiegargli i vantaggi delle varie pratiche DevOps che non sono incluse nelle specifiche tecniche. E se fosse interessato a rilasci rapidi con valore aziendale aggiunto o alla creazione di una pipeline di automazione?
Purtroppo, quando si lavora con un costo pre-approvato, questo interesse non sempre si riscontra. Nella nostra pratica, si è verificato un caso in cui abbiamo dovuto riprendere lo sviluppo di un appaltatore senza scrupoli e negligente. Era terribile: non c'erano codici sorgente aggiornati, il codice base dello stesso sistema era diverso su installazioni diverse, la documentazione era in parte assente e in parte di pessima qualità. Naturalmente, il cliente non aveva il controllo sul codice sorgente, sull'assemblaggio, sui rilasci, ecc.
Finora non tutti conoscono DevOps, ma non appena si parla dei suoi vantaggi, del reale risparmio di risorse, gli occhi di tutti i clienti si illuminano. Pertanto, il numero di richieste che includono DevOps aumenta nel tempo. In questo caso, per poter parlare facilmente la stessa lingua con i clienti, dobbiamo collegare rapidamente i problemi aziendali e le pratiche DevOps che aiuteranno a costruire una pipeline di sviluppo adeguata.
Quindi, da un lato abbiamo una serie di problemi, dall’altro abbiamo conoscenze, pratiche e strumenti DevOps. Perché non condividere l'esperienza con tutti?
Creazione di un costruttore DevOps
Agile ha il suo manifesto. ITIL ha una propria metodologia. DevOps è meno fortunato: non ha ancora acquisito modelli e standard. Sebbene determinare la maturità delle aziende sulla base di una valutazione del loro sviluppo e delle pratiche operative.
Fortunatamente, la nota azienda Gartner nel 2014 e analizzato le principali pratiche DevOps e le relazioni tra di loro. Sulla base di questo, ho pubblicato un’infografica:
L'abbiamo preso come base per il nostro . Ognuna delle quattro aree ha una serie di strumenti: li abbiamo raccolti in un database, identificato quelli più popolari, identificato punti di integrazione e meccanismi di ottimizzazione adeguati. In totale si è scoperto 36 pratiche e 115 strumenti, un quarto dei quali sono software open source o gratuiti. Successivamente parleremo di ciò che abbiamo realizzato in ciascuna area e, ad esempio, di come questo è stato implementato nel progetto per creare una gestione tecnica dei documenti, con cui abbiamo iniziato il post.
processi
Nel famigerato progetto EDMS, il sistema di gestione della documentazione tecnica è stato implementato secondo lo stesso schema in ciascuno dei 10 oggetti. L'installazione include 4 server: server database, server applicazioni, indicizzazione full-text e gestione dei contenuti. Nell'installazione operano all'interno di un singolo nodo e si trovano nel data center delle strutture. Tutti gli oggetti differiscono leggermente nell'infrastruttura, ma ciò non interferisce con l'interazione globale.
Innanzitutto, secondo le pratiche DevOps, abbiamo automatizzato l’infrastruttura localmente, poi abbiamo portato la consegna al circuito di test e infine al prodotto del cliente. Ogni processo è stato elaborato passo dopo passo. Le impostazioni dell'ambiente sono fisse nel sistema del codice sorgente, tenendo conto del quale il kit di distribuzione è compilato per l'aggiornamento automatico. In caso di modifiche alla configurazione, gli ingegneri devono semplicemente apportare le modifiche appropriate al sistema di controllo della versione e l'aggiornamento automatico avverrà senza problemi.
Grazie a questo approccio, il processo di test è stato notevolmente semplificato. In precedenza, il progetto aveva tester che non facevano altro che aggiornare manualmente i supporti. Adesso vengono e basta, vedono che tutto funziona e fanno cose più utili. Ogni aggiornamento viene testato automaticamente, dal livello superficiale all'automazione dello scenario aziendale. I risultati vengono pubblicati come report separati in TestRail.
La Cultura
La sperimentazione continua è meglio spiegata attraverso l'esempio della progettazione del test. Testare un sistema che ancora non esiste è un lavoro creativo. Quando si scrive un piano di test, è necessario capire come testare correttamente e quali rami seguire. E trova anche un equilibrio tra tempo e budget per determinare il numero ottimale di controlli. È importante scegliere esattamente i test necessari, pensare a come l'utente interagirà con il sistema, tenere conto dell'ambiente e dei possibili fattori esterni. È impossibile fare a meno della sperimentazione continua.
Ora parliamo della cultura dell'interazione. In precedenza c'erano due lati opposti: ingegneri e sviluppatori. Gli sviluppatori hanno detto: “Non ci interessa come verrà lanciato. Siete ingegneri, siete intelligenti, assicuratevi che funzioni senza guasti". Gli ingegneri hanno risposto: “Voi sviluppatori siete troppo imprudenti. Stiamo più attenti e suoneremo le tue uscite meno spesso. Perché ogni volta che ci dai un codice che perde, non ci è chiaro come interagire”.. Si tratta di un problema di interazione culturale strutturato in modo diverso dal punto di vista DevOps. Qui, sia gli ingegneri che gli sviluppatori fanno parte di un unico team che si concentra su un software in continua evoluzione, ma allo stesso tempo affidabile.
All'interno dello stesso team, gli specialisti sono determinati ad aiutarsi a vicenda. Com'era prima? Ad esempio, stavano preparando delle spesse istruzioni per l'implementazione, lunghe circa 50 pagine. L'ingegnere le ha lette, non ha capito qualcosa, ha imprecato e alle tre del mattino ha chiesto allo sviluppatore di commentare. Lo sviluppatore ha commentato e anche imprecato: alla fine nessuno è stato contento. Inoltre, naturalmente, ci sono stati degli errori, perché non puoi ricordare tutto nelle istruzioni. E ora l'ingegnere, insieme allo sviluppatore, sta scrivendo uno script per la distribuzione automatizzata dell'infrastruttura del software applicativo. E si parlano praticamente nella stessa lingua.
Persone
La dimensione del team è determinata dall'ambito dell'aggiornamento. Il team viene reclutato durante la formazione della consegna e comprende gli interessati dal team generale del progetto. Quindi viene scritto un piano di aggiornamento con i responsabili di ciascuna fase e il team riferisce man mano che procede. Tutti i membri del team sono intercambiabili. Come parte del team abbiamo anche uno sviluppatore di backup, ma non deve quasi mai connettersi.
Tecnologia
Nel diagramma della tecnologia sono evidenziati alcuni punti, ma sotto di essi ci sono un sacco di tecnologie: potresti pubblicare un intero libro con le loro descrizioni. Quindi metteremo in evidenza i più interessanti.
Infrastruttura come codice
Ora, probabilmente, questo concetto non sorprenderà nessuno, ma prima le descrizioni delle infrastrutture lasciavano molto a desiderare. , gli ambienti di prova erano unici, erano amati e amati, le particelle di polvere venivano spazzate via.
Al giorno d'oggi nessuno ha paura di sperimentare. Sono disponibili immagini di base di macchine virtuali e scenari già pronti per la distribuzione degli ambienti. Tutti i modelli e gli script sono archiviati in un sistema di controllo della versione e vengono tempestivamente aggiornati. In precedenza, quando era necessario consegnare un pacco allo stand, si verificava una lacuna nella configurazione. Ora devi solo aggiungere una riga al codice sorgente.
Oltre agli script e alle pipeline dell'infrastruttura, per la documentazione viene utilizzato anche l'approccio Documentation as a Code. Grazie a ciò, è facile connettere nuove persone al progetto, introdurle al sistema in base alle funzioni descritte, ad esempio, nel piano di test e anche riutilizzare i casi di test.
Consegna e monitoraggio continui
riguardo a DevOps, abbiamo parlato di come abbiamo selezionato gli strumenti per implementare la distribuzione e il monitoraggio continui. Spesso non è necessario riscrivere nulla: è sufficiente utilizzare script scritti in precedenza, creare correttamente l'integrazione tra i componenti e creare una console di gestione comune. E tutti i processi possono essere avviati utilizzando un pulsante o una pianificazione.
In inglese esistono diversi concetti, Continuous Delivery e Continuous Deployment. Entrambi possono essere tradotti come “consegna continua”, ma in realtà c’è una leggera differenza tra loro. Nel nostro progetto per il flusso dei documenti tecnici di un'azienda di energia distribuita, viene invece utilizzata la consegna, quando l'installazione per la produzione avviene su comando. In Distribuzione, l'installazione avviene automaticamente. La consegna continua in questo progetto è generalmente diventata parte centrale di DevOps.
In generale, raccogliendo determinati parametri, puoi capire chiaramente perché le pratiche DevOps sono utili. E comunicalo al management, che ama davvero i numeri. Il numero totale di lanci, il tempo di esecuzione delle fasi dello script, la quota di lanci riusciti: tutto ciò influisce direttamente sul time to market preferito da tutti, ovvero il tempo che intercorre tra l'impegno nel sistema di controllo della versione e il rilascio di una versione su un ambiente di produzione. Con l'implementazione degli strumenti necessari, gli ingegneri ricevono preziosi indicatori via e-mail e il project manager li vede sulla dashboard. In questo modo potrai valutare immediatamente i vantaggi dei nuovi strumenti. E puoi provarli sulla tua infrastruttura utilizzando il designer DevOps.
Chi avrà bisogno del nostro ?
Non fingiamo: tanto per cominciare ci è diventato utile. Come abbiamo già detto, è necessario parlare la stessa lingua con il cliente e con l'aiuto del designer DevOps possiamo rapidamente abbozzare le basi per tale conversazione. Gli specialisti aziendali saranno in grado di valutare da soli ciò di cui hanno bisogno e quindi svilupparsi più rapidamente. Abbiamo cercato di rendere il designer il più dettagliato possibile, aggiungendo una serie di descrizioni in modo che ogni utente capisca cosa sta scegliendo.
Il formato del progettista consente di tenere conto degli sviluppi esistenti dell’azienda nei processi di costruzione e nell’automazione. Non è necessario demolire tutto e ricostruirlo se si possono solo scegliere soluzioni che si integrino bene con i processi esistenti e che possano semplicemente colmare le lacune.
Forse il tuo sviluppo è già passato a un livello superiore e il nostro strumento sembrerà troppo “del capitano”. Ma lo troviamo utile per noi stessi e speriamo che possa essere utile ad alcuni lettori. Te lo ricordiamo al progettista: semmai riceverai lo schema subito dopo aver inserito i dati iniziali. Saremo grati per il vostro feedback e le vostre aggiunte.
Fonte: habr.com