Una volta avemu furnitu un sistema di gestione di documenti elettronicu à un cliente in una facilità. È dopu à un altru ughjettu. È unu di più. È à u quartu, è à u quintu. Avemu cusì purtatu chì avemu ghjuntu à 10 oggetti distribuiti. Hè risultatu putente ... soprattuttu quandu avemu avutu à furnisce i cambiamenti. Cum'è parte di a consegna à u circuitu di pruduzzione, 5 scenarii di u sistema di teste necessitanu ultimamente 10 ore è 6-7 impiegati. Tali costi ci anu obligatu à fà spedizioni u più raramente pussibule. Dopu à trè anni di funziunamentu, ùn pudemu micca suppurtà è decisu di spice up the project with a pinch of DevOps.
Avà tutte e teste sò in 3 ore, è 3 persone participanu à questu: un ingegnere è dui testatori. I megliurenze sò chjaramente espressi in numeri è portanu à una riduzzione in u TTM assai amatu. In a nostra sperienza, ci sò assai più clienti chì ponu prufittà di DevOps cà quelli chì ancu cunnoscenu. Dunque, per avvicinassi DevOps à e persone, avemu sviluppatu un custruttore simplice, di quale parlemu in più detail in questu post.
Avà vi dicemu in più detail. Una cumpagnia energetica implementa un sistema di gestione di documenti tecnichi in 10 grandi strutture. Ùn hè micca faciule di navigà in prughjetti di questa scala senza DevOps, perchè una grande parte di u travagliu manuale ritarda assai u travagliu è riduce ancu a qualità - tuttu u travagliu manuale hè pienu di errore. Per d 'altra banda, ci sò prughjetti induve ci hè una sola installazione, ma tuttu deve travaglià automaticamente, constantemente è senza fallimentu - per esempiu, i stessi sistemi di flussu di documentu in grandi urganisazioni monolitiche. Altrimenti, qualcunu hà da fà i paràmetri manualmente, scurdate di l'istruzzioni di implementazione - è in u risultatu, in a pruduzzione, i paràmetri seranu persi è tuttu colapserà.
Di solitu avemu travagliatu cù u cliente attraversu un cuntrattu, è in questu casu i nostri interessi divergenu pocu. U cliente vede u prugettu strettamente in u budgetu è e specificazioni tecniche. Pò esse difficiuli di spiegà à ellu i benefici di e diverse pratiche DevOps chì ùn sò micca incluse in e specificazioni tecniche. E s'ellu hè interessatu in versioni veloci cù un valore cummerciale aghjuntu, o à custruisce un pipeline d'automatizazione?
Alas, quandu u travagliu cù un costu pre-appruvatu, questu interessu ùn hè micca sempre truvatu. In a nostra pratica, ci era un casu quandu avemu avutu à ripiglià u sviluppu di un cuntrattu senza scrupulous è senza cura. Era terribili: ùn ci era micca codici fonte aghjurnati, a basa di codice di u stessu sistema era diversa in diverse installazioni, a documentazione era parzialmente assente, è in parte di qualità terribili. Di sicuru, u cliente ùn avia micca u cuntrollu di u codice fonte, assemblea, liberazioni, etc.
Finu a ora, ùn tutti ùn sanu micca di DevOps, ma appena parlemu di i so vantaghji, di u risparmiu di risorse reale, l'ochji di tutti i clienti s'illuminanu. Dunque, u numeru di richieste chì includenu DevOps aumenta cù u tempu. Quì, per parlà facilmente a stessa lingua cù i clienti, avemu bisognu di cunnette rapidamente i prublemi di cummerciale è e pratiche DevOps chì aiutanu à custruisce un pipeline di sviluppu adattatu.
Dunque, avemu un inseme di prublemi da una banda, è cunniscenze DevOps, pratiche è arnesi da l'altru. Perchè ùn sparte micca a sperienza cù tutti?
Creazione di un constructore DevOps
Agile hà u so propiu manifestu. ITIL hà a so propria metodulugia. DevOps hè menu furtunatu - ùn hà ancu acquistatu mudelli è standard. Eppuru determina a maturità di l'imprese nantu à una valutazione di u so sviluppu è e pratiche operative.
Fortunatamente, a famosa cumpagnia Gartner in 2014 è analizà e pratiche chjave DevOps è e relazioni trà elli. Basatu annantu à questu, aghju publicatu una infografica:
Avemu pigliatu cum'è a basa per u nostru . Ciascuna di e quattru spazii hà un inseme di strumenti - l'avemu cullucatu in una basa di dati, identificà i più populari, identificanu punti d'integrazione è miccanismi di ottimisazione adattati. In u tutale hè risultatu 36 pratiche è 115 arnesi, un quartu di i quali sò open source o software liberu. In seguitu, parlemu di ciò chì avemu ottinutu in ogni spaziu è, per esempiu, cumu si hè stata implementata in u prugettu per creà a gestione di documentu tecnicu, cù quale avemu principiatu u postu.
I prucessi
In u famosu prughjettu EDMS, u sistema di gestione di documentazioni tecniche hè statu implementatu secondu u listessu schema à ognunu di l'uggetti 10. A stallazione include 4 servitori: servitore di basa di dati, servitore d'applicazioni, indexing full-text è gestione di cuntenutu. In a stallazione, operanu in un unicu node è si trovanu in u centru di dati à e facilità. Tutti l'uggetti sò pocu diffirenti in l'infrastruttura, ma questu ùn interferiscenu micca cù l'interazzione glubale.
Prima, secondu e pratiche DevOps, avemu automatizatu l'infrastruttura in u locu, dopu avemu purtatu a consegna à u circuitu di prova, è dopu à u pruduttu di u cliente. Ogni prucessu hè statu travagliatu passu à passu. I paràmetri di l'ambiente sò fissati in u sistema di codice fonte, tenendu in contu chì u kit di distribuzione hè compilatu per l'aghjurnamentu automaticu. In casu di cambiamenti di cunfigurazione, l'ingegneri solu bisognu di fà i cambiamenti adatti à u sistema di cuntrollu di versione - è dopu l'aghjurnamentu automaticu si farà senza prublemi.
Grazie à questu approcciu, u prucessu di prova hè statu assai simplificatu. Nanzu, u prughjettu avia teste chì ùn anu fattu nunda, ma aghjurnà manualmente i stands. Avà venenu solu, vede chì tuttu funziona è fà cose più utili. Ogni aghjurnamentu hè pruvatu automaticamente - da u livellu di a superficia à l'automatizazione di u scenariu cummerciale. I risultati sò publicati cum'è rapporti separati in TestRail.
Cultura
L'esperimentu cuntinuu hè megliu spiegatu per l'esempiu di cuncepimentu di teste. Pruvà un sistema chì ùn esiste ancu hè un travagliu creativo. Quandu scrivite un pianu di teste, avete bisognu di capiscenu cumu pruvà currettamente è chì rami seguitanu. È ancu truvà un equilibriu trà u tempu è u budgetu per determinà u numeru ottimali di cuntrolli. Hè impurtante di sceglie esattamente i testi necessarii, pensate cumu l'utilizatore interagisce cù u sistema, piglià in contu l'ambiente è i pussibuli fatturi esterni. Hè impussibile di fà senza sperimentazione cuntinua.
Avà nantu à a cultura di l'interazzione. Nanzu, ci eranu dui lati opposti - ingegneri è sviluppatori. I sviluppatori anu dettu: "Ùn ci importa micca cumu serà lanciatu. Siete ingegneri, site intelligente, assicuratevi chì funziona senza fallimenti ". L'ingegneri anu rispostu: "Voi sviluppatori sò troppu trascurati. Semu più attenti, è ghjucheremu e vostre versioni menu spessu. Perchè ogni volta chì ci dà un codice leaky, ùn ci hè micca chjaru cumu interagisce ".. Questa hè una questione di interazione culturale chì hè strutturata in modu diversu da una perspettiva DevOps. Quì, l'ingegneri è i sviluppatori sò parte di una sola squadra chì hè focu annantu à u cambiamentu constantemente, ma à u listessu tempu un software affidabile.
In u stessu squadra, i specialisti sò decisu à aiutà l'altri. Cume era prima? Per esempiu, alcune struzzioni di dispiegamentu grossu sò stati preparati, nantu à e pagine 50. L'ingegnere hà lettu, ùn hà micca capitu qualcosa, malediziu è dumandò à u sviluppatore à trè ore di a matina per cummentà. U sviluppatore hà cummentatu è ancu malediziu - à a fine nimu era felice. In più, naturalmente, ci sò stati parechji sbagli, perchè ùn pudete micca ricurdà tuttu in l'istruzzioni. È avà l'ingegnere, inseme cù u sviluppatore, scrive un script per a implementazione automatizata di l'infrastruttura di u software di l'applicazione. È si parlanu l'un l'altru praticamente in a listessa lingua.
populu
A dimensione di a squadra hè determinata da u scopu di l'aghjurnamentu. A squadra hè reclutata durante a furmazione di a consegna; include quelli interessati da a squadra generale di u prugettu. Allora un pianu di aghjurnamentu hè scrittu cù i rispunsevuli di ogni tappa, è a squadra informa mentre avanza. Tutti i membri di a squadra sò intercambiabili. Cum'è parte di a squadra, avemu ancu un sviluppatore di salvezza, ma ùn hà quasi mai à cunnette.
di tecnulugia
In u diagramma di a tecnulugia, uni pochi di punti sò evidenziati, ma sottu à elli ci hè una mansa di tecnulugia - pudete pubblicà un libru sanu cù e so descrizzioni. Allora avemu da mette in risaltu i più interessanti.
Infrastruttura cum'è Codice
Avà, prubabilmente, stu cuncettu ùn sorprenderà à nimu, ma prima i discrizzioni di l'infrastrutture lasciavanu assai à desiderate. , L'ambienti di prova eranu unichi, sò stati amati è cari, particeddi di polvera sò stati sbulicati.
Avà nimu ùn hà paura di sperimentà. Ci sò imaghjini basi di macchine virtuali, ci sò scenarii pronti per implementà ambienti. Tutti i mudelli è i scripts sò almacenati in un sistema di cuntrollu di versione è sò prontamente aghjurnati. Prima, quandu era necessariu di furnisce un pacchettu à un stand, apparsu una lacuna di cunfigurazione. Avà vi basta à aghjunghje una linea à u codice fonte.
In più di script di infrastruttura è pipeline, l'approcciu di Documentazione cum'è Codice hè ancu utilizatu per a documentazione. Grazie à questu, hè faciule per cunnette persone novi à u prugettu, intruduce à u sistema basatu nantu à e funzioni descritte, per esempiu, in u pianu di prova, è ancu reutilizà casi di teste.
Cunsigliu cuntinuu è monitoraghju
circa DevOps, avemu parlatu di cumu avemu sceltu arnesi per implementà a consegna è u monitoraghju cuntinuu. Spessu ùn ci hè micca bisognu di riscrive qualcosa - hè abbastanza per utilizà scripts scritti prima, custruisce currettamente integrazione trà cumpunenti è creà una cunsola di gestione cumuni. È tutti i prucessi ponu esse lanciati usendu un buttone o pianificazione.
In inglese ci sò cuncetti diffirenti, Consegna Cuntinuu è Impiegazione Continua. I dui ponu esse tradutti cum'è "consegna cuntinuu", ma in fattu ci hè una ligera differenza trà elli. In u nostru prughjettu per u flussu di documentu tecnicu di una cumpagnia di energia distribuita, piuttostu, Delivery hè utilizatu - quandu a stallazione per a pruduzzione si faci nantu à u cumandimu. In Deployment, a stallazione si faci automaticamente. A Consegna Continua in stu prughjettu hè diventata in generale parte centrale di DevOps.
In generale, cullendu certi parametri, pudete capisce chjaramente perchè e pratiche DevOps sò utili. È trasmette questu à a gestione, chì ama veramente i numeri. U numeru tutale di lanciamenti, u tempu d'esekzione di e tappe di scrittura, a parte di i lanciamenti successi - tuttu questu affetta direttamente u tempu favuritu di tutti à u mercatu, vale à dì u tempu da un impegnu à u sistema di cuntrollu di versione à a liberazione di una versione in un ambiente di pruduzzione. Cù l'implementazione di l'arnesi necessarii, l'ingegneri ricevenu indicatori preziosi per mail, è u capu di prughjettu li vede nantu à u dashboard. Questu modu pudete valutà immediatamente i benefici di novi strumenti. È pudete pruvà à a vostra infrastruttura cù u designer DevOps.
Quale sarà bisognu di u nostru ?
Ùn fintemu micca : per un principiu, ci hè diventatu utile. Comu avemu digià dettu, avete bisognu di parlà a listessa lingua cù u cliente, è cù l'aiutu di u designer DevOps pudemu abbozzà rapidamente a basa per una tale conversazione. I spezialisti di l'imprese seranu capaci di valutà per elli stessi ciò chì anu bisognu è cusì sviluppà più veloce. Avemu pruvatu à fà u designer u più detallatu pussibule, aghjunghjendu una mansa di descrizzioni per chì ogni utilizatore capisce ciò chì ellu sceglie.
U furmatu di u designer permette di piglià in contu i sviluppi esistenti di a cumpagnia in i prucessi di custruzzione è l'automatizazione. Ùn ci hè bisognu di sfondà tuttu è di ricustruisce, se pudete sceglie solu suluzioni chì si integranu bè cù i prucessi esistenti è chì ponu simplificà i lacune.
Forsi u vostru sviluppu hà digià spustatu à un livellu più altu è u nostru strumentu vi pare troppu "capitanu". Ma a truvamu utile per noi stessi è spergu chì serà utile à alcuni di i lettori. Vi ricurdemu à u designer - se qualcosa, riceve u diagramma immediatamente dopu avè inseritu i dati iniziali. Saremu grati per i vostri feedback è aghjunte.
Source: www.habr.com