Kažkada viename objekte klientui tiekėme elektroninę dokumentų valdymo sistemą. Ir tada į kitą objektą. Ir dar vienas. Ir ketvirtą, ir penktą. Taip įsitraukėme, kad pasiekėme 10 paskirstytų objektų. Tai pasirodė galingai... ypač kai pradėjome įgyvendinti pakeitimus. Pristatant į gamybos grandinę, 5 testavimo sistemos scenarijus galiausiai pareikalavo 10 valandų ir 6–7 darbuotojų. Tokios išlaidos privertė mus pristatyti kuo rečiau. Po trejų veiklos metų neištvėrėme ir nusprendėme projektą pagardinti žiupsneliu DevOps.
Dabar visi bandymai vyksta per 3 valandas, juose dalyvauja 3 žmonės: inžinierius ir du testuotojai. Patobulinimai aiškiai išreikšti skaičiais ir sumažina taip mėgstamą TTM. Mūsų patirtis rodo, kad yra daug daugiau klientų, kurie gali gauti naudos iš „DevOps“, nei tų, kurie apie tai žino. Todėl norėdami priartinti DevOps prie žmonių, sukūrėme paprastą konstruktorių, apie kurį plačiau pakalbėsime šiame įraše.
Dabar papasakokime išsamiau. Viena energetikos įmonė diegia techninių dokumentų valdymo sistemą 10 didelių objektų. Nelengva naršyti tokio masto projektuose be „DevOps“, nes didelė dalis rankų darbo labai vilkina darbą ir taip pat sumažina kokybę - visas rankų darbas yra kupinas klaidų. Kita vertus, yra projektų, kur yra tik viena instaliacija, bet viskas turi veikti automatiškai, nuolat ir be gedimų – pavyzdžiui, tos pačios dokumentų srauto sistemos didelėse monolitinėse organizacijose. Priešingu atveju kas nors atliks nustatymus rankiniu būdu, pamirš diegimo instrukcijas - ir dėl to gamyboje nustatymai bus prarasti ir viskas sugrius.
Dažniausiai su klientu dirbame pagal sutartį, o šiuo atveju mūsų interesai šiek tiek išsiskiria. Klientas žiūri į projektą griežtai neviršydamas biudžeto ir techninių specifikacijų. Jam gali būti sunku paaiškinti įvairių DevOps praktikų, kurios nėra įtrauktos į technines specifikacijas, naudą. Ką daryti, jei jį domina greiti leidimai su pridėtine verslo verte arba automatizavimo vamzdyno kūrimas?
Deja, dirbant su iš anksto patvirtintomis išlaidomis, šis susidomėjimas ne visada randamas. Mūsų praktikoje buvo atvejis, kai teko pasiimti nesąžiningo ir nerūpestingo rangovo plėtrą. Tai buvo baisu: nebuvo naujausių šaltinio kodų, tos pačios sistemos kodų bazė skirtinguose įrenginiuose buvo skirtinga, dokumentacijos iš dalies nebuvo, o iš dalies siaubingos kokybės. Žinoma, klientas nekontroliavo šaltinio kodo, surinkimo, išleidimo ir kt.
Kol kas apie „DevOps“ žino ne visi, tačiau kai tik prakalbame apie jo privalumus, apie realų resursų taupymą, visų klientų akys nušvinta. Taigi užklausų, kuriose yra „DevOps“, skaičius laikui bėgant didėja. Čia, norėdami lengvai kalbėti ta pačia kalba su klientais, turime greitai susieti verslo problemas ir „DevOps“ praktiką, kuri padės sukurti tinkamą plėtros vamzdyną.
Taigi, viena vertus, turime problemų, kita vertus, turime „DevOps“ žinių, praktikos ir įrankių. Kodėl nepasidalinus patirtimi su visais?
„DevOps“ konstruktoriaus kūrimas
Agile turi savo manifestą. ITIL turi savo metodiką. „DevOps“ pasisekė mažiau – ji dar neįsigijo šablonų ir standartų. Nors nustatyti įmonių brandą, remiantis jų plėtros ir veiklos praktikos įvertinimu.
Laimei, gerai žinoma kompanija Gartner 2014 m ir išanalizavo pagrindines „DevOps“ praktikas ir ryšius tarp jų. Remdamasis tuo, išleidau infografiką:
Mes tai priėmėme kaip savo pagrindą . Kiekviena iš keturių sričių turi įrankių rinkinį – surinkome juos į duomenų bazę, nustatėme populiariausias, nustatėme integravimo taškus ir tinkamus optimizavimo mechanizmus. Iš viso paaiškėjo 36 praktikos ir 115 įrankių, iš kurių ketvirtadalis yra atvirojo kodo arba nemokama programinė įranga. Toliau kalbėsime apie tai, ko pasiekėme kiekvienoje srityje ir, kaip pavyzdį, apie tai, kaip tai buvo įgyvendinta techninių dokumentų valdymo kūrimo projekte, nuo kurio pradėjome įrašą.
Procesai
Liūdnai pagarsėjusiame EDMS projekte techninės dokumentacijos valdymo sistema buvo įdiegta pagal tą pačią schemą kiekviename iš 10 objektų. Įdiegimą sudaro 4 serveriai: duomenų bazės serveris, programų serveris, viso teksto indeksavimas ir turinio valdymas. Įrenginyje jie veikia viename mazge ir yra įrenginių duomenų centre. Visi objektai šiek tiek skiriasi infrastruktūra, tačiau tai netrukdo pasaulinei sąveikai.
Pirma, pagal „DevOps“ praktiką automatizavome infrastruktūrą lokaliai, tada pristatymą pristatėme į bandymo grandinę, o tada – į kliento produktą. Kiekvienas procesas buvo atliktas žingsnis po žingsnio. Aplinkos nustatymai fiksuojami šaltinio kodo sistemoje, atsižvelgiant į tai, kad paskirstymo rinkinys yra sudarytas automatiniam atnaujinimui. Konfigūracijos pakeitimų atveju inžinieriams tereikia atlikti atitinkamus versijų valdymo sistemos pakeitimus – tada automatinis atnaujinimas įvyks be problemų.
Dėl šio metodo testavimo procesas buvo labai supaprastintas. Anksčiau projekte buvo bandytojų, kurie nieko nedarė, tik rankiniu būdu atnaujino stendus. Dabar jie tiesiog ateina, pamato, kad viskas veikia, ir daro daugiau naudingų dalykų. Kiekvienas atnaujinimas tikrinamas automatiškai – nuo paviršiaus lygio iki verslo scenarijų automatizavimo. Rezultatai skelbiami kaip atskiros ataskaitos „TestRail“.
Культура
Nuolatinis eksperimentavimas geriausiai paaiškinamas bandymo dizaino pavyzdžiu. Dar neegzistuojančios sistemos testavimas yra kūrybinis darbas. Rašydami testavimo planą turite suprasti, kaip taisyklingai testuoti ir kokiomis šakomis vadovautis. Taip pat raskite laiko ir biudžeto balansą, kad nustatytumėte optimalų patikrinimų skaičių. Svarbu tiksliai parinkti reikiamus testus, apgalvoti, kaip vartotojas sąveikaus su sistema, atsižvelgti į aplinką ir galimus išorinius veiksnius. Neįmanoma išsiversti be nuolatinių eksperimentų.
Dabar apie sąveikos kultūrą. Anksčiau buvo dvi priešingos pusės – inžinieriai ir kūrėjai. Kūrėjai sakė: „Mums nerūpi, kaip jis bus paleistas. Jūs esate inžinieriai, esate protingi, pasirūpinkite, kad jis veiktų be gedimų". Inžinieriai atsakė: „Jūs, kūrėjai, esate per daug neatsargūs. Būkime atsargesni ir jūsų leidimus leisime rečiau. Nes kiekvieną kartą, kai pateikiate mums nutekėjusį kodą, mums neaišku, kaip bendrauti.. Tai kultūrinės sąveikos problema, kurios struktūra skiriasi DevOps požiūriu. Čia tiek inžinieriai, tiek kūrėjai yra vienos komandos dalis, kuri yra orientuota į nuolat besikeičiančią, bet kartu patikimą programinę įrangą.
Toje pačioje komandoje specialistai pasiryžę padėti vieni kitiems. Kaip buvo anksčiau? Pavyzdžiui, buvo ruošiama kažkokia stora dislokavimo instrukcija, apie 50 puslapių.. Inžinierius perskaitė, kažko nesuprato, keikėsi ir trečią valandą nakties paprašė kūrėjo pakomentuoti. Kūrėjas pakomentavo ir taip pat keikė – galiausiai niekas nebuvo patenkintas. Be to, žinoma, buvo keletas klaidų, nes negalite prisiminti visko, kas nurodyta instrukcijose. O dabar inžinierius kartu su kūrėju rašo scenarijų automatizuotam taikomosios programinės įrangos infrastruktūros diegimui. Ir jie tarpusavyje kalbasi praktiškai ta pačia kalba.
Žmonės
Komandos dydį lemia atnaujinimo apimtis. Komanda komplektuojama formuojant pristatymą, ją sudaro suinteresuotieji iš bendros projekto komandos. Tada su atsakingais už kiekvieną etapą surašomas atnaujinimo planas, o komanda praneša apie eigą. Visi komandos nariai yra keičiami. Kaip komandos dalis, mes taip pat turime atsarginį kūrėją, bet jam beveik niekada nereikia prisijungti.
Technologija
Technologijų diagramoje keli punktai išryškinti, bet po jais – krūva technologijų – galėtum išleisti visą knygą su jų aprašymais. Taigi išskirsime įdomiausius.
Infrastruktūra kaip kodas
Dabar ši koncepcija tikriausiai nieko nenustebins, tačiau anksčiau infrastruktūrų aprašymai paliko daug norimų rezultatų. , bandymų aplinkos buvo unikalios, jos buvo puoselėjamos ir branginamos, nuo jų buvo nupūstos dulkių dalelės.
Šiais laikais niekas nebijo eksperimentuoti. Yra pagrindiniai virtualių mašinų vaizdai ir paruošti aplinkų diegimo scenarijai. Visi šablonai ir scenarijai yra saugomi versijų valdymo sistemoje ir yra nedelsiant atnaujinami. Anksčiau, kai reikėdavo pristatyti pakuotę į stendą, atsirasdavo konfigūracijos spraga. Dabar tereikia pridėti eilutę prie šaltinio kodo.
Be infrastruktūros scenarijų ir vamzdynų, dokumentacijai taip pat naudojamas dokumentacijos kaip kodo metodas. Dėl to prie projekto lengva prijungti naujus žmones, supažindinti juos su sistema pagal funkcijas, aprašytas, pavyzdžiui, testavimo plane, taip pat pakartotinai panaudoti testavimo atvejus.
Nuolatinis pristatymas ir stebėjimas
apie „DevOps“ kalbėjome apie tai, kaip pasirinkome įrankius nuolatiniam pristatymui ir stebėjimui įgyvendinti. Dažnai nereikia nieko perrašyti – pakanka naudoti anksčiau parašytus scenarijus, teisingai sukurti integraciją tarp komponentų ir sukurti bendrą valdymo pultą. Ir visus procesus galima paleisti vienu mygtuku arba tvarkaraščiu.
Anglų kalba yra skirtingos sąvokos: Continuous Delivery ir Continuous Deployment. Abu gali būti išversti kaip „nuolatinis pristatymas“, tačiau iš tikrųjų tarp jų yra nedidelis skirtumas. Mūsų projekte paskirstytos energetikos įmonės techninių dokumentų srautui veikiau naudojamas Pristatymas – kai montavimas gamybai vyksta pagal komandą. Diegiant diegimas vyksta automatiškai. Nuolatinis pristatymas šiame projekte paprastai tapo centrinė DevOps dalis.
Apskritai, surinkę tam tikrus parametrus, galite aiškiai suprasti, kodėl DevOps praktika yra naudinga. Ir perduokite tai vadovybei, kuri tikrai mėgsta skaičius. Bendras paleidimų skaičius, scenarijaus etapų vykdymo laikas, sėkmingų paleidimų dalis – visa tai tiesiogiai įtakoja kiekvieno mėgstamą laiką patekti į rinką, ty laiką nuo įsipareigojimo versijos valdymo sistemai iki versijos išleidimo. gamybos aplinka. Įdiegę reikiamus įrankius, inžinieriai vertingus rodiklius gauna paštu, o projekto vadovas juos mato prietaisų skydelyje. Taip iš karto galite įvertinti naujų priemonių naudą. Ir jūs galite išbandyti juos savo infrastruktūroje naudodami „DevOps“ dizainerį.
Kam reikės mūsų ?
Neapsimetinėkime: pradžiai jis mums tapo naudingas. Kaip jau minėjome, su klientu reikia kalbėti ta pačia kalba, o su DevOps dizainerio pagalba galime greitai nubraižyti tokio pokalbio pagrindą. Verslo specialistai galės patys įvertinti, ko jiems reikia ir taip sparčiau tobulėti. Mes stengėmės, kad dizaineris būtų kuo išsamesnis, pridėdami daugybę aprašymų, kad bet kuris vartotojas suprastų, ką jis renkasi.
Dizainerio formatas leidžia atsižvelgti į esamus įmonės pokyčius statybos procesų ir automatizavimo srityse. Nereikia visko griauti ir statyti iš naujo, jei galite pasirinkti tik tokius sprendimus, kurie gerai integruojasi su esamais procesais ir gali tiesiog užpildyti spragas.
Galbūt jūsų tobulėjimas jau perėjo į aukštesnį lygį ir mūsų įrankis atrodys per daug „kapitono“. Bet mes manome, kad tai naudinga mums patiems ir tikimės, kad ji bus naudinga kai kuriems skaitytojams. Primename projektuotojui - jei kas, tai schemą gauni iškart po pirminių duomenų įvedimo. Būsime dėkingi už atsiliepimus ir papildymus.
Šaltinis: www.habr.com