MÄs savulaik klientam vienÄ objektÄ piegÄdÄjÄm elektronisko dokumentu pÄrvaldÄ«bas sistÄmu. Un tad uz citu objektu. Un vÄl vienu. Un ceturtajÄ, un piektajÄ. MÄs tÄ aizrÄvÄmies, ka tikÄm lÄ«dz 10 izdalÄ«tiem objektiem. Tas izrÄdÄ«jÄs spÄcÄ«gi... it Ä«paÅ”i, kad nonÄcÄm pie izmaiÅu ievieÅ”anas. KÄ daļu no piegÄdes uz ražoÅ”anas Ä·Ädi 5 testÄÅ”anas sistÄmas scenÄrijiem galu galÄ bija vajadzÄ«gas 10 stundas un 6ā7 darbinieki. Å Ädas izmaksas lika mums veikt piegÄdes pÄc iespÄjas retÄk. PÄc trÄ«s darbÄ«bas gadiem mÄs to neizturÄjÄm un nolÄmÄm papildinÄt projektu ar ŔķipsniÅu DevOps.
Tagad visa testÄÅ”ana notiek 3 stundu laikÄ, un tajÄ piedalÄs 3 cilvÄki: inženieris un divi testÄtÄji. Uzlabojumi ir skaidri izteikti skaitļos un noved pie tik iemīļotÄ TTM samazinÄÅ”anÄs. MÅ«su pieredze liecina, ka ir daudz vairÄk klientu, kuri var gÅ«t labumu no DevOps, nekÄ tie, kas par to pat zina. TÄpÄc, lai DevOps tuvinÄtu cilvÄkiem, esam izstrÄdÄjuÅ”i vienkÄrÅ”u konstruktoru, par kuru sÄ«kÄk pastÄstÄ«sim Å”ajÄ ierakstÄ.
Tagad pastÄstÄ«sim jums sÄ«kÄk. Viens enerÄ£Ätikas uzÅÄmums 10 lielos objektos ievieÅ” tehnisko dokumentu pÄrvaldÄ«bas sistÄmu. Nav viegli orientÄties Å”Äda mÄroga projektos bez DevOps, jo liela daļa roku darba ievÄrojami aizkavÄ darbu un arÄ« samazina kvalitÄti - viss roku darbs ir pilns ar kļūdÄm. No otras puses, ir projekti, kur ir tikai viena instalÄcija, bet visam jÄdarbojas automÄtiski, pastÄvÄ«gi un bez kļūmÄm - piemÄram, vienas un tÄs paÅ”as dokumentu plÅ«smas sistÄmas lielÄs monolÄ«tÄs organizÄcijÄs. PretÄjÄ gadÄ«jumÄ kÄds veiks iestatÄ«jumus manuÄli, aizmirsÄ«s par izvietoÅ”anas instrukcijÄm - un rezultÄtÄ ražoÅ”anÄ iestatÄ«jumi tiks zaudÄti un viss sabruks.
Parasti mÄs strÄdÄjam ar klientu, pamatojoties uz lÄ«gumu, un Å”ajÄ gadÄ«jumÄ mÅ«su intereses nedaudz atŔķiras. PasÅ«tÄ«tÄjs projektu aplÅ«ko stingri budžeta un tehnisko specifikÄciju ietvaros. ViÅam var bÅ«t grÅ«ti izskaidrot dažÄdu DevOps prakÅ”u priekÅ”rocÄ«bas, kas nav iekļautas tehniskajÄs specifikÄcijÄs. Ko darÄ«t, ja viÅu interesÄ Ätrie izlaidumi ar pievienoto biznesa vÄrtÄ«bu vai automatizÄcijas cauruļvada izveide?
DiemžÄl, strÄdÄjot ar iepriekÅ” apstiprinÄtÄm izmaksÄm, Ŕī interese ne vienmÄr tiek atrasta. MÅ«su praksÄ bija gadÄ«jums, kad nÄcÄs uzÅemties negodprÄtÄ«ga un neuzmanÄ«ga bÅ«vuzÅÄmÄja izstrÄdi. Tas bija briesmÄ«gi: nebija atjauninÄtu pirmkodu, vienas un tÄs paÅ”as sistÄmas kodu bÄze dažÄdÄs instalÄcijÄs bija atŔķirÄ«ga, dokumentÄcijas daļÄji trÅ«ka un daļÄji drausmÄ«gas kvalitÄtes. Protams, klientam nebija kontroles pÄr pirmkodu, montÄžu, izlaidumiem utt.
PagaidÄm ne visi zina par DevOps, taÄu, tiklÄ«dz mÄs runÄjam par tÄ priekÅ”rocÄ«bÄm, par reÄlu resursu ietaupÄ«jumu, visiem klientiem iemirdzas acis. TÄdÄjÄdi pieprasÄ«jumu skaits, kas ietver DevOps, laika gaitÄ palielinÄs. Å eit, lai viegli runÄtu vienÄ valodÄ ar klientiem, mums Ätri jÄsavieno biznesa problÄmas un DevOps prakse, kas palÄ«dzÄs izveidot piemÄrotu izstrÄdes cauruļvadu.
TÄtad, no vienas puses, mums ir problÄmu kopums, no otras puses, mums ir DevOps zinÄÅ”anas, prakse un rÄ«ki. KÄpÄc gan nepadalÄ«ties pieredzÄ ar visiem?
DevOps konstruktora izveide
Agilei ir savs manifests. ITIL ir sava metodoloÄ£ija. DevOps ir mazÄk paveicies - tas vÄl nav ieguvis veidnes un standartus. Lai gan noteikt uzÅÄmumu briedumu, pamatojoties uz to attÄ«stÄ«bas un darbÄ«bas prakses novÄrtÄjumu.
Par laimi, labi pazÄ«stamÄ kompÄnija Gartner 2014.g un analizÄja galvenÄs DevOps prakses un attiecÄ«bas starp tÄm. Pamatojoties uz to, es izlaidu infografiku:
MÄs to ÅÄmÄm par pamatu mÅ«su . Katrai no ÄetrÄm jomÄm ir noteikts rÄ«ku komplekts - mÄs tos apkopojÄm datu bÄzÄ, noteicÄm populÄrÄkos, identificÄjÄm integrÄcijas punktus un piemÄrotus optimizÄcijas mehÄnismus. KopumÄ izrÄdÄ«jÄs 36 prakses un 115 rÄ«ki, no kuriem ceturtÄ daļa ir atvÄrtÄ pirmkoda vai bezmaksas programmatÅ«ra. TÄlÄk runÄsim par to, ko esam sasnieguÅ”i katrÄ jomÄ un, piemÄram, par to, kÄ tas tika Ä«stenots tehnisko dokumentu pÄrvaldÄ«bas izveides projektÄ, ar kuru sÄkÄm ierakstu.
Procesi
BÄdÄ«gi slavenajÄ EDMS projektÄ tehniskÄs dokumentÄcijas pÄrvaldÄ«bas sistÄma tika izvietota pÄc vienas shÄmas katrÄ no 10 objektiem. InstalÄcija ietver 4 serverus: datu bÄzes serveri, lietojumprogrammu serveri, pilna teksta indeksÄÅ”anu un satura pÄrvaldÄ«bu. InstalÄcijÄ tie darbojas vienÄ mezglÄ un atrodas iekÄrtu datu centrÄ. Visi objekti infrastruktÅ«rÄ nedaudz atŔķiras, taÄu tas netraucÄ globÄlai mijiedarbÄ«bai.
PirmkÄrt, saskaÅÄ ar DevOps praksi mÄs automatizÄjÄm infrastruktÅ«ru lokÄli, pÄc tam nogÄdÄjÄm piegÄdi testa Ä·ÄdÄ un pÄc tam klienta produktam. Katrs process tika izstrÄdÄts soli pa solim. Vides iestatÄ«jumi tiek fiksÄti pirmkoda sistÄmÄ, Åemot vÄrÄ to, ka izplatÄ«Å”anas komplekts tiek sastÄdÄ«ts automÄtiskai atjauninÄÅ”anai. KonfigurÄcijas izmaiÅu gadÄ«jumÄ inženieriem vienkÄrÅ”i ir jÄveic atbilstoÅ”as āāizmaiÅas versiju kontroles sistÄmÄ ā un tad automÄtiskÄ atjauninÄÅ”ana notiks bez problÄmÄm.
Pateicoties Å”ai pieejai, testÄÅ”anas process ir ievÄrojami vienkÄrÅ”ots. IepriekÅ” projektÄ bija testÄtÄji, kuri nedarÄ«ja neko citu kÄ tikai manuÄli atjauninÄja stendus. Tagad viÅi vienkÄrÅ”i atnÄk, redz, ka viss darbojas, un dara vairÄk noderÄ«gas lietas. Katrs atjauninÄjums tiek pÄrbaudÄ«ts automÄtiski ā no virsmas lÄ«meÅa lÄ«dz biznesa scenÄriju automatizÄcijai. RezultÄti tiek publicÄti kÄ atseviŔķi ziÅojumi pakalpojumÄ TestRail.
Kultūra
NepÄrtrauktu eksperimentÄÅ”anu vislabÄk var izskaidrot ar testa dizaina piemÄru. VÄl neeksistÄjoÅ”as sistÄmas testÄÅ”ana ir radoÅ”s darbs. Rakstot pÄrbaudes plÄnu, ir jÄsaprot, kÄ pareizi testÄt un kuras filiÄles ievÄrot. Un arÄ« atrodiet lÄ«dzsvaru starp laiku un budžetu, lai noteiktu optimÄlo pÄrbaužu skaitu. Ir svarÄ«gi izvÄlÄties tieÅ”i nepiecieÅ”amos testus, pÄrdomÄt, kÄ lietotÄjs mijiedarbosies ar sistÄmu, Åemt vÄrÄ vidi un iespÄjamos ÄrÄjos faktorus. Bez nepÄrtrauktiem eksperimentiem nav iespÄjams iztikt.
Tagad par mijiedarbÄ«bas kultÅ«ru. IepriekÅ” bija divas pretÄjÄs puses ā inženieri un izstrÄdÄtÄji. IzstrÄdÄtÄji teica: "Mums ir vienalga, kÄ tas tiks palaists. JÅ«s esat inženieri, jÅ«s esat gudri, pÄrliecinieties, ka tas darbojas bez kļūmÄm". Inženieri atbildÄja: "JÅ«s, izstrÄdÄtÄji, esat pÄrÄk neuzmanÄ«gi. BÅ«sim uzmanÄ«gÄki, un jÅ«su laidienus atskaÅosim retÄk. Jo katru reizi, kad jÅ«s sniedzat mums noplÅ«duÅ”o kodu, mums nav skaidrs, kÄ mijiedarboties.. Å Ä« ir kultÅ«ras mijiedarbÄ«bas problÄma, kas ir strukturÄta atŔķirÄ«gi no DevOps perspektÄ«vas. Å eit gan inženieri, gan izstrÄdÄtÄji ir daļa no vienas komandas, kas ir vÄrsta uz pastÄvÄ«gi mainÄ«gu, bet tajÄ paÅ”Ä laikÄ uzticamu programmatÅ«ru.
Vienas komandas ietvaros speciÄlisti ir apÅÄmÄ«bas pilni palÄ«dzÄt viens otram. KÄ tas bija agrÄk? PiemÄram, tika sagatavotas kÄdas biezas izvietoÅ”anas instrukcijas, apmÄram 50 lappuÅ”u garumÄ.Inženieris izlasÄ«ja, kaut ko nesaprata, lamÄjÄs un trijos naktÄ« lÅ«dza izstrÄdÄtÄju komentÄt. IzstrÄdÄtÄjs komentÄja un arÄ« nolamÄja - galu galÄ neviens nebija laimÄ«gs. TurklÄt, protams, bija dažas kļūdas, jo jÅ«s nevarat atcerÄties visu instrukcijÄs. Un tagad inženieris kopÄ ar izstrÄdÄtÄju raksta skriptu lietojumprogrammatÅ«ras infrastruktÅ«ras automatizÄtai izvietoÅ”anai. Un viÅi runÄ viens ar otru praktiski vienÄ valodÄ.
CilvÄki
Komandas lielumu nosaka atjauninÄjuma apjoms. Komanda tiek komplektÄta piegÄdes veidoÅ”anas laikÄ, tajÄ ietilpst interesenti no vispÄrÄjÄs projekta komandas. PÄc tam tiek uzrakstÄ«ts atjauninÄÅ”anas plÄns ar atbildÄ«gajiem par katru posmu, un komanda ziÅo par tÄ gaitu. Visi komandas locekļi ir savstarpÄji aizvietojami. KÄ daļai no komandas mums ir arÄ« rezerves izstrÄdÄtÄjs, taÄu viÅam gandrÄ«z nekad nav jÄpieslÄdzas.
Tehnoloģija
TehnoloÄ£iju diagrammÄ daži punkti ir izcelti, bet zem tiem ir tehnoloÄ£iju kaudze - jÅ«s varÄtu izdot veselu grÄmatu ar to aprakstiem. TÄpÄc mÄs izcelsim interesantÄko.
InfrastruktÅ«ra kÄ kods
Tagad, iespÄjams, Ŕī koncepcija nevienu nepÄrsteigs, taÄu iepriekÅ” infrastruktÅ«ru apraksti atstÄja daudz vÄlamo. , testa vides bija unikÄlas, tÄs tika lolotas un lolotas, no tÄm tika izpÅ«stas putekļu daļiÅas.
MÅ«sdienÄs neviens nebaidÄs eksperimentÄt. Ir virtuÄlo maŔīnu pamata attÄli, ir gatavi vides izvietoÅ”anas scenÄriji. Visas veidnes un skripti tiek glabÄti versiju kontroles sistÄmÄ un tiek nekavÄjoties atjauninÄti. IepriekÅ”, kad bija nepiecieÅ”ams nogÄdÄt paku uz stendu, parÄdÄ«jÄs konfigurÄcijas sprauga. Tagad jums vienkÄrÅ”i jÄpievieno avota kodam rinda.
Papildus infrastruktÅ«ras skriptiem un konveijeriem dokumentÄcijai tiek izmantota arÄ« dokumentÄcijas kÄ koda pieeja. Pateicoties tam, ir viegli pieslÄgt projektam jaunus cilvÄkus, iepazÄ«stinÄt viÅus ar sistÄmu, pamatojoties uz funkcijÄm, kas aprakstÄ«tas, piemÄram, testa plÄnÄ, kÄ arÄ« atkÄrtoti izmantot testa gadÄ«jumus.
NepÄrtraukta piegÄde un uzraudzÄ«ba
par DevOps mÄs runÄjÄm par to, kÄ mÄs atlasÄ«jÄm rÄ«kus nepÄrtrauktas piegÄdes un uzraudzÄ«bas ievieÅ”anai. Bieži vien nekas nav jÄpÄrraksta - pietiek ar iepriekÅ” rakstÄ«tu skriptu izmantoÅ”anu, pareizi izveidot integrÄciju starp komponentiem un izveidot kopÄju pÄrvaldÄ«bas konsoli. Un visus procesus var palaist, izmantojot vienu pogu vai grafiku.
Angļu valodÄ ir dažÄdi jÄdzieni Continuous Delivery un Continuous Deployment. Abus var tulkot kÄ ānepÄrtraukta piegÄdeā, taÄu patiesÄ«bÄ starp tiem ir neliela atŔķirÄ«ba. MÅ«su projektÄ izplatÄ«tÄ energokompÄnijas tehnisko dokumentu plÅ«smai drÄ«zÄk tiek izmantota PiegÄde - kad uzstÄdÄ«Å”ana ražoÅ”anai notiek pÄc komandas. IzvietoÅ”anÄ instalÄÅ”ana notiek automÄtiski. NepÄrtraukta piegÄde Å”ajÄ projektÄ kopumÄ ir kļuvusi DevOps centrÄlÄ daļa.
KopumÄ, apkopojot noteiktus parametrus, jÅ«s varat skaidri saprast, kÄpÄc DevOps prakse ir noderÄ«ga. Un nodod to vadÄ«bai, kurai ļoti patÄ«k skaitļi. KopÄjais palaiÅ”anas reižu skaits, skripta posmu izpildes laiks, veiksmÄ«go palaiÅ”anas gadÄ«jumu Ä«patsvars ā tas viss tieÅ”i ietekmÄ ikviena iecienÄ«tÄko laiku, lai nonÄktu tirgÅ«, tas ir, laiku no apÅemÅ”anÄs izmantot versiju kontroles sistÄmu lÄ«dz versijas izlaiÅ”anai ražoÅ”anas vide. IevieÅ”ot nepiecieÅ”amos rÄ«kus, inženieri pa pastu saÅem vÄrtÄ«gus rÄdÄ«tÄjus, un projekta vadÄ«tÄjs tos redz informÄcijas panelÄ«. TÄdÄ veidÄ jÅ«s varat nekavÄjoties novÄrtÄt jauno rÄ«ku priekÅ”rocÄ«bas. Un jÅ«s varat tos izmÄÄ£inÄt savÄ infrastruktÅ«rÄ, izmantojot DevOps dizaineru.
Kam būs vajadzīgi mūsu ?
Neizliksimies: sÄkumÄ viÅÅ” mums kļuva noderÄ«gs. KÄ jau teicÄm, ar klientu jÄrunÄ vienÄ valodÄ, un ar DevOps dizainera palÄ«dzÄ«bu varam Ätri ieskicÄt Å”Ädas sarunas pamatu. UzÅÄmÄjdarbÄ«bas speciÄlisti varÄs paÅ”i novÄrtÄt, kas viÅiem nepiecieÅ”ams, un tÄdÄjÄdi ÄtrÄk attÄ«stÄ«ties. MÄs centÄmies dizaineru padarÄ«t pÄc iespÄjas detalizÄtÄku, pievienojot virkni aprakstu, lai jebkurÅ” lietotÄjs saprastu, ko viÅÅ” izvÄlas.
ProjektÄtÄja formÄts ļauj Åemt vÄrÄ uzÅÄmuma esoÅ”Äs norises bÅ«vniecÄ«bas procesos un automatizÄcijÄ. Nav nepiecieÅ”ams visu nojaukt un atjaunot, ja varat izvÄlÄties tikai tÄdus risinÄjumus, kas labi integrÄjas esoÅ”ajos procesos, kas var vienkÄrÅ”i aizpildÄ«t nepilnÄ«bas.
IespÄjams, jÅ«su attÄ«stÄ«ba jau ir pÄrgÄjusi uz augstÄku lÄ«meni, un mÅ«su rÄ«ks ŔķitÄ«s pÄrÄk "kapteiÅa". Bet mÄs to uzskatÄm par noderÄ«gu sev un ceram, ka noderÄs kÄdam no lasÄ«tÄjiem. MÄs jums atgÄdinÄm projektÄtÄjam - ja kas, tad diagrammu saÅem uzreiz pÄc sÄkotnÄjo datu ievadÄ«Å”anas. BÅ«sim pateicÄ«gi par jÅ«su atsauksmÄm un papildinÄjumiem.
Avots: www.habr.com