Ataskaitoje bus kalbama apie kai kurias „DevOps“ praktikas, tačiau kūrėjo požiūriu. Paprastai visi prie „DevOps“ prisijungę inžinieriai jau turi kelerių metų administravimo patirtį. Bet tai nereiškia, kad čia nėra vietos kūrėjui. Dažniausiai kūrėjai yra užsiėmę taisydami „kitą skubiai kritinę dienos klaidą“ ir neturi laiko net greitai pažvelgti į „DevOps“ lauką. Autoriaus supratimu, DevOps, pirma, yra sveikas protas. Antra, tai galimybė būti efektyvesniems. Jei esate kūrėjas, turite sveiko proto ir norite būti efektyvesnis kaip komandos žaidėjas, ši ataskaita skirta jums.
Leiskite prisistatyti, visiškai pripažįstu, kad kambaryje yra žmonių, kurie manęs nepažįsta. Mano vardas yra Anton Boyko, aš esu „Microsoft Azure“ MVP. Kas yra MVP? Tai Modelis-View-Presenter. Modelis-View-Presenter yra būtent aš.
Be to, šiuo metu „Ciklum“ užimu sprendimų architekto pareigas. Ir visai neseniai nusipirkau sau tokį gražų domeną ir atnaujinau savo el.paštą, kurį dažniausiai rodau pristatymuose. Galite parašyti man adresu: me [šuo] byokoant.pro. Kilus klausimams galite man el. Dažniausiai jiems atsakau. Vienintelis dalykas yra tai, kad nenorėčiau gauti el. paštu klausimų, susijusių su dviem temomis: politika ir religija. Apie visa kita galite man rašyti el. Praeis šiek tiek laiko, atsakysiu.
Keletas žodžių apie save:
- Šioje srityje dirbu jau 10 metų.
- Dirbau Microsoft.
- Esu Ukrainos Azure bendruomenės, kurią įkūrėme kažkur 2014 m., įkūrėjas. Ir mes jį vis dar turime ir kuriame.
- Taip pat esu „Azure“ konferencijos, kurią rengiame Ukrainoje, įkūrėjo tėvas.
- Taip pat padedu organizuoti „Global Azure Bootcamp“ Kijeve.
- Kaip sakiau, esu „Microsoft Azure“ MVP.
- Gana dažnai kalbu konferencijose. Man labai patinka kalbėti konferencijose. Per pastaruosius metus galėjau koncertuoti apie 40 kartų. Jei praeinate pro Ukrainą, Baltarusiją, Lenkiją, Bulgariją, Švediją, Daniją, Nyderlandus, Ispaniją arba duodate ar paimate kitą Europos šalį, gali būti, kad nuvykus į konferenciją, kurios sraute yra debesų tema, mane galite pamatyti kalbėtojų sąraše.
- Aš taip pat esu „Star Trek“ gerbėjas.
Pakalbėkime šiek tiek apie dienotvarkę. Mūsų darbotvarkė labai paprasta:
- Mes kalbėsime apie tai, kas yra „DevOps“. Pakalbėkime, kodėl tai svarbu. Anksčiau DevOps buvo raktinis žodis, kurį parašėte savo gyvenimo aprašyme ir iškart gavote +500 USD atlyginimo. Dabar į savo gyvenimo aprašymą reikia įrašyti, pavyzdžiui, blockchain, kad gautum +500 dolerių prie atlyginimo.
- Ir tada, kai šiek tiek suprasime, kas tai yra, pakalbėsime apie tai, kas yra „DevOps“ praktika. Bet ne tiek apskritai DevOps kontekste, kiek apie tas DevOps praktikas, kurios gali būti įdomios kūrėjams. Aš jums pasakysiu, kodėl jie gali jus sudominti. Aš jums pasakysiu, kodėl išvis turėtumėte tai daryti ir kaip tai gali padėti jums patirti mažiau skausmo.
Tradicinis paveikslas, kurį rodo daugelis žmonių. Taip nutinka daugelyje projektų. Tai yra tada, kai turime kūrimo ir operacijų skyrius, kurie palaiko mūsų programinę įrangą. Ir šie skyriai tarpusavyje nebendrauja.
Galbūt, jei negalėjote to taip aiškiai pajusti „DevOps“ ir operacijų skyriuose, galite padaryti analogiją su „DevOps“ ir „QA“ skyriais. Yra žmonių, kurie kuria programinę įrangą, ir yra kokybės užtikrinimo žmonių, kurie kūrėjų požiūriu yra blogi. Pavyzdžiui, aš įdedu savo nuostabų kodą į saugyklą, o ten sėdi koks niekšas, kuris grąžina man šį kodą ir sako, kad jūsų kodas yra blogas.
Visa tai nutinka todėl, kad žmonės nebendrauja vieni su kitais. O jie meta vienas kitam kažkokius paketus, kažkokias aplikacijas per kažkokią nesusipratimo sieną ir bando su jomis kažką daryti.
Būtent šią sieną DevOps kultūra ir skirta sunaikinti, t.y. priversti žmones bendrauti tarpusavyje ir bent jau suprasti, ką skirtingi projekte dalyvaujantys žmonės veikia ir kodėl jų darbas svarbus.
Ir kai mes kalbame apie DevOps, kažkas jums pasakys, kad DevOps yra tada, kai projektas yra nuolat integruojamas; kažkas pasakys, kad DevOps yra, jei projektas įgyvendina „infrastruktūros kaip kodo“ praktiką; kažkas pasakys, kad pirmas žingsnis į DevOps yra funkcijų išsišakojimas, funkcijų vėliavėlės.
Iš esmės visa tai savaip yra tiesa. Bet tai tik geriausi mūsų praktikos metodai. Prieš pereinant prie šių praktikų, siūlau pažiūrėti šią skaidrę, kurioje parodyti 3 Dev-Ops metodikos diegimo jūsų projekte, jūsų įmonėje etapai.
Ši skaidrė taip pat turi antrą neoficialų pavadinimą. Galite ieškoti internete, kad sužinotumėte, kas yra 3 DevOps muškietininkai. Gali būti, kad šį straipsnį rasite. Kodėl 3 muškietininkai? Žemiau parašyta: žmonės, procesai ir produktai, t.y. PPP – Porthos, Porthos ir Porthos. Štai 3 „DevOps“ muškietininkai. Šiame straipsnyje išsamiau aprašoma, kodėl tai svarbu ir ką tai reiškia.
Kai pradedate diegti DevOps kultūrą, labai svarbu, kad ji būtų įdiegta tokia tvarka.
Iš pradžių reikia kalbėtis su žmonėmis. Ir jūs turite paaiškinti žmonėms, kas tai yra ir kaip jie gali iš to gauti naudos.
Mūsų konferencija vadinasi DotNet Fest. Ir kaip man sakė organizatoriai, mes čia daugiausia kvietėme kūrėjų auditoriją, todėl tikiuosi, kad dauguma salėje esančių žmonių yra susiję su plėtra.
Kalbėsime apie žmones, kalbėsime apie tai, ką kūrėjai nori veikti kiekvieną dieną. Ko jie labiausiai nori? Jie nori parašyti naują kodą, naudoti naujas sistemas, kurti naujas funkcijas. Ko kūrėjai mažiausiai nori? Ištaisykite senas klaidas. Tikiuosi, kad sutinkate su manimi. To nori kūrėjai. Jie nori rašyti naujas funkcijas, nenori taisyti klaidų.
Klaidų, kurias sukuria konkretus kūrėjas, skaičius priklauso nuo to, kiek tiesios jo rankos ir kiek jos auga nuo pečių, o ne iš užpakalio kišenių. Tačiau, nepaisant to, kai turime didelį projektą, kartais nutinka taip, kad visko susekti neįmanoma, todėl būtų malonu panaudoti kokius nors būdus, kurie padėtų parašyti stabilesnį ir kokybiškesnį kodą.
Ko QA nori labiausiai? Nežinau, ar jie yra salėje. Man sunku pasakyti, kad noriu kokybės užtikrinimo, nes niekada juo nebuvau. Ir neįsižeiskite vaikinų, bus pasakyta, kad tikiuosi, kad niekada to nedarysiu. Bet ne dėl to, kad jų darbą laikau beprasmiu ir nenaudingu, o dėl to, kad nelaikau savęs žmogumi, kuris galėtų šį darbą atlikti efektyviai, todėl net nebandysiu to daryti. Bet, kaip suprantu, QA labiausiai nemėgsta dirbti ryte, nuolat atlikti kažkokius regresijos testus, žengti į tas pačias klaidas, apie kurias pranešė kūrėjams prieš 3 sprintus ir sakydamas: „Kada jūs , Pone D. Artanjanai, ištaisykite šią klaidą. Ponas D'Artanjanas jam atsako: „Taip, taip, taip, aš jau sutvarkiau“. Ir kaip atsitinka, kad ištaisiau vieną klaidą ir pakeliui padariau 5.
Žmonės, kurie palaiko šį sprendimą gamyboje, nori, kad šis sprendimas veiktų be klaidų, kad jiems nereikėtų kiekvieną penktadienį perkrauti serverio, kai visi normalūs žmonės eina į barą. Kūrėjai įdiegė penktadienį, administratoriai sėdi iki šeštadienio, bandydami sutvarkyti ir sutvarkyti šį diegimą.
O kai paaiškini žmonėms, kad jie yra skirti tų pačių problemų sprendimui, galima pereiti prie procesų formalizavimo. Tai labai svarbu. Kodėl? Nes kai sakome „formalizacija“, jums svarbu apibūdinti, kaip jūsų procesai vyksta bent kažkur ant servetėlės. Turite suprasti, kad jei, pavyzdžiui, diegiate į QA aplinką arba gamybos aplinką, tai visada vyksta tokia tvarka; šiais etapais vykdome, pavyzdžiui, automatinius vienetų testus ir vartotojo sąsajos testus. Po dislokavimo patikriname, ar diegimas vyko gerai, ar prastai. Tačiau jau turite aiškų veiksmų sąrašą, kurie turi būti kartojami vėl ir vėl, kai įdiegiate gamybą.
Ir tik tada, kai jūsų procesai yra formalizuoti, jūs pradedate rinktis produktus, kurie padės automatizuoti šiuos procesus.
Deja, labai dažnai matau, kad tai vyksta atvirkščiai. Kai tik kas nors išgirsta žodį „DevOps“, iš karto siūlo įdiegti „Jenkins“, nes tiki, kad kai tik įdiegs „Jenkins“, jie turės „DevOps“. Jie įdiegė „Jenkins“, perskaitė „Kaip“ straipsnius Jenkins svetainėje, bandė įterpti procesus į šiuos „How to“ straipsnius, o tada priėjo prie žmonių ir sulenkė žmones sakydami, kad knygoje parašyta, kad reikia tai padaryti taip, taigi mes darome taip.
Ne tai, kad Jenkinsas yra blogas įrankis. Jokiu būdu nenoriu to pasakyti. Bet tai tik vienas iš produktų. O kurį produktą naudosite, tai turėtų būti jūsų paskutinis sprendimas ir jokiu būdu ne pirmas. Jūsų produktas neturėtų būti varomas kultūros ir požiūrių įgyvendinimo. Tai labai svarbu suprasti, todėl tiek daug laiko praleidžiu prie šios skaidrės ir taip ilgai visa tai aiškinu.
Pakalbėkime apie „DevOps“ praktiką apskritai. Kas jie tokie? Koks skirtumas? Kaip juos pasimatuoti? Kodėl jie svarbūs?
Pirmoji praktika, apie kurią galbūt girdėjote, vadinama nuolatine integracija. Galbūt kas nors projekto dalyvis turi nuolatinę integraciją (CI).
Didžiausia problema yra ta, kad dažniausiai, kai klausiu žmogaus: „Ar projekte turite KI? ir jis sako: „Taip“, tada, kai paklausiu, ką jis daro, jis man apibūdina absoliučiai visą automatizavimo procesą. Tai nėra visiškai tiesa.
Tiesą sakant, CI praktika yra skirta tam, kad skirtingų žmonių rašomas kodas būtų integruotas į vieną kodų bazę. Tai viskas.
Kartu su CI paprastai yra ir kitų praktikų, tokių kaip nuolatinis diegimas, leidimų valdymas, bet apie tai pakalbėsime vėliau.
Pati CI mums sako, kad skirtingi žmonės rašo kodą ir šis kodas turi būti nuolat integruotas į vieną kodų bazę.
Ką tai mums duoda ir kodėl tai svarbu? Jei turime DotNet, tai gerai, tai yra kompiliuota kalba, galime kompiliuoti savo programą. Jei jis kompiliuoja, tai jau geras ženklas. Tai dar nieko nereiškia, bet tai pirmas geras ženklas, kurį galime bent jau surinkti.
Tada galime atlikti keletą testų, o tai taip pat yra atskira praktika. Visi testai žali – tai antras geras ženklas. Bet vėlgi, tai nieko nereiškia.
Bet kodėl tu tai darytum? Visos praktikos, apie kurias šiandien kalbėsiu, turi maždaug tokią pačią vertę, t.
Pirma, tai leidžia pagreitinti pristatymą. Kaip tai leidžia paspartinti pristatymą? Kai atliekame keletą naujų kodų bazės pakeitimų, galime nedelsdami pabandyti ką nors padaryti su šiuo kodu. Mes nelaukiame, kol ateis ketvirtadienis, nes ketvirtadienį išleidžiame jį į QA Environment, darome tai čia ir čia.
Papasakosiu vieną liūdną istoriją iš savo gyvenimo. Tai buvo seniai, kai dar buvau jaunas ir gražus. Dabar aš jau jauna, graži ir protinga, ir kukli. Prieš kurį laiką dalyvavau projekte. Turėjome didelę apie 30 kūrėjų komandą. Ir mes turėjome didelį, didelį įmonės projektą, kuris vystėsi apie 10 metų. Ir mes turėjome skirtingus filialus. Saugykloje turėjome filialą, kuriame vaikščiojo kūrėjai. Ir buvo filialas, kuriame buvo rodoma gaminamo kodo versija.
Gamybos šaka 3 mėnesiais atsiliko nuo kūrėjams prieinamos šakos. Ką tai reiškia? Tai reiškia, kad kai tik turiu kažkur klaidą, kuri paleidžiama į gamybą dėl kūrėjų kaltės, nes jie tai leido, ir dėl kokybės užtikrinimo kaltės, nes jie ją peržiūrėjo, tai reiškia, kad jei gaunu gamybos karštųjų pataisų užduotis, tada turiu atšaukti kodo pakeitimus prieš 3 mėnesius. Turiu prisiminti, ką turėjau prieš 3 mėnesius, ir pabandyti tai ištaisyti.
Jei dar neturėjote šios patirties, galite tai išbandyti savo namų projekte. Svarbiausia, nemėginkite to reklamuoti. Parašykite kelias kodo eilutes, pamirškite apie jas šešiems mėnesiams, o tada grįžkite ir pabandykite greitai paaiškinti, kas yra tos kodo eilutės ir kaip galite jas pataisyti ar optimizuoti. Tai labai, labai jaudinanti patirtis.
Jei turime nuolatinio integravimo praktiką, tai leidžia mums tai patikrinti naudojant daugybę automatinių įrankių čia ir dabar, kai tik parašysiu savo kodą. Galbūt tai nesuteiks man viso vaizdo, bet vis dėlto pašalins bent dalį rizikos. Ir jei yra kokių nors galimų klaidų, aš apie tai sužinosiu dabar, ty tiesiogine prasme po poros minučių. Man nereikės atsukti 3 mėnesių atgal. Man reikės tik 2 minutes atsukti atgal. Geras kavos aparatas net nespės išvirti kavos per 2 minutes, todėl tai gana puiku.
Tai turi tokią vertę, kad tai gali būti kartojama kartas nuo karto kiekviename projekte, t.y. ne tik tas, kurį nustatėte. Galite pakartoti ir pačią praktiką, ir pati CI bus pakartota kiekvieną kartą atlikus naują projekto pakeitimą. Tai leidžia optimizuoti išteklius, nes jūsų komanda dirba efektyviau. Nebeturėsite situacijos, kai klaidą aplankė kodas, su kuriuo dirbote prieš 3 mėnesius. Nebeturėsite konteksto perjungimo, kai sėdėsite ir praleisite pirmas dvi valandas bandydami suprasti, kas tada atsitiko, ir įsigilinti į konteksto esmę prieš pradėdami ką nors taisyti.
Kaip galime įvertinti šios praktikos sėkmę ar nesėkmę? Jei praneši didžiajam viršininkui, ką įgyvendinome CI projekte, jis išgirs bla bla bla. Įgyvendinome, gerai, bet kodėl, ką tai mums atnešė, kaip tai išmatuojame, kaip teisingai ar neteisingai tai įgyvendiname?
Pirma, CI dėka galime diegti vis dažniau ir dažniau būtent todėl, kad mūsų kodas yra potencialiai stabilesnis. Lygiai taip pat sutrumpėja mūsų laikas rasti klaidą, o laikas ištaisyti šią klaidą – būtent dėl to, kad mes čia ir dabar gauname atsakymą iš sistemos, kas negerai su mūsų kodu.
Kita mūsų praktika yra automatizavimo testavimo praktika, kuri dažniausiai ateina kartu su CI praktika. Jie eina kartu.
Ką čia svarbu suprasti? Svarbu suprasti, kad mūsų testai skiriasi. Ir kiekvienas automatizuotas testas yra skirtas išspręsti savo problemas. Turime, pavyzdžiui, vienetinius testus, kurie leidžia modulį testuoti atskirai, t.y. Kaip tai veikia vakuume? Tai yra gerai.
Taip pat turime integravimo testus, kurie leidžia suprasti, kaip skirtingi moduliai integruojasi vienas su kitu. Taip pat gerai.
Galime turėti UI automatizavimo testus, kurie leidžia patikrinti, kaip darbas su UI atitinka tam tikrus kliento keliamus reikalavimus ir pan.
Konkretūs jūsų vykdomi testai gali turėti įtakos jų vykdymo dažnumui. Vienetiniai testai dažniausiai rašomi trumpi ir nedideli. Ir juos galima paleisti reguliariai.
Jei mes kalbame apie vartotojo sąsajos automatizavimo testus, tada gerai, jei jūsų projektas yra mažas. Jūsų vartotojo sąsajos automatizavimo testai gali užtrukti pakankamai ilgai. Tačiau paprastai UI automatizavimo testas yra tai, kas dideliam projektui trunka kelias valandas. Ir gerai, jei tai kelios valandos. Vienintelis dalykas yra tai, kad nėra prasmės juos naudoti kiekvienai konstrukcijai. Prasminga juos paleisti naktį. O kai ryte visi atėjo į darbą: ir testuotojai, ir kūrėjai, gavo kažkokį pranešimą, kad naktį vykdėme UI autotestą ir gavome tokius rezultatus. O štai serverio, kuris patikrins, ar jūsų gaminys atitinka kokius nors reikalavimus, darbo valanda bus daug pigesnė nei to paties QA inžinieriaus darbo valanda, net jei jis yra Jaunesnysis QA inžinierius, dirbantis už maistą ir ačiū. Nepaisant to, mašinos darbo valanda bus pigesnė. Štai kodėl prasminga į tai investuoti.
Turiu dar vieną projektą, prie kurio dirbau. Turėjome dviejų savaičių šio projekto sprintus. Projektas buvo didelis, svarbus finansų sektoriui, todėl nebuvo galima padaryti klaidos. O po dviejų savaičių sprinto po kūrimo ciklo sekė testavimo procesas, kuris užtruko dar 4 savaites. Pabandykite įsivaizduoti tragedijos mastą. Dvi savaites rašome kodą, tada tai darome ala CodeFreeze, supakuojame jį į naują programos versiją ir pateikiame testuotojams. Testuotojai jį testuoja dar 4 savaites, t.y. Kol jie jį išbando, turime laiko jiems paruošti dar dvi versijas. Tai tikrai liūdnas atvejis.
Ir mes jiems pasakėme, kad jei norite būti produktyvesni, prasminga įdiegti automatinio testavimo praktiką, nes būtent tai jus skaudina čia, dabar.
Praktikuokite nuolatinį diegimą. Puiku, baigėte statyti. Tai jau gerai. Jūsų kodas sukompiliuotas. Dabar būtų puiku įdiegti šią versiją tam tikroje aplinkoje. Tarkime, kūrėjams skirtoje aplinkoje.
Kodėl tai svarbu? Pirmiausia galite pažiūrėti, kaip jums sekasi pats diegimo procesas. Esu sutikęs tokių projektų, kai paklausiu: „Kaip diegti naują programos versiją?“, vaikinai man atsako: „Surenkame ir supakuojame į ZIP archyvą. Išsiunčiame administratoriui paštu. Administratorius atsisiunčia ir išplečia šį archyvą. Ir visas biuras pradeda melstis, kad serveris pasiimtų naują versiją.
Pradėkime nuo kažko paprasto. Pavyzdžiui, jie pamiršo įdėti CSS į archyvą arba pamiršo pakeisti grotažymę java-script failo pavadinime. O kai pateikiame užklausą serveriui, naršyklė mano, kad jau turi šį java-script failą ir nusprendžia jo nesiųsti. Ir buvo sena versija, kažko trūko. Apskritai gali kilti daug problemų. Todėl nuolatinio diegimo praktika leidžia bent jau išbandyti, kas nutiktų, jei paimtumėte švarų nuorodos vaizdą ir įkeltumėte jį į visiškai švarią naują aplinką. Galite pamatyti, kur tai veda.
Taip pat, kai tarpusavyje integruojate kodą, t.y. tarp komandų, tai taip pat leidžia pamatyti, kaip ji atrodo vartotojo sąsajoje.
Viena iš problemų, kylančių, kai naudojamas daug vanilinio java scenarijaus, yra ta, kad du kūrėjai lango objekte neapgalvotai paskelbė kintamąjį tuo pačiu pavadinimu. Ir tada, priklausomai nuo jūsų sėkmės. Kieno java scenarijaus failas bus ištrauktas antras, perrašys kito pakeitimus. Tai taip pat labai jaudina. Įeini: vienam tinka vienas dalykas, kitam netinka kitas. Ir tai yra „nuostabu“, kai visa tai pasirodo gamyboje.
Kita praktika, kurią turime, yra automatinio atkūrimo praktika, ty grįžimas į ankstesnę programos versiją.
Kodėl tai svarbu kūrėjams? Dar yra tokių, kurie prisimena tolimus, tolimus 90-uosius, kai kompiuteriai buvo dideli, o programos – mažos. Ir vienintelis būdas kurti žiniatinklio svetainę buvo PHP. Tai nereiškia, kad PHP yra bloga kalba, nors taip yra.
Tačiau problema buvo kitokia. Kai įdiegėme naują php svetainės versiją, kaip ją įdiegėme? Dažniausiai atidarydavome Far Manager ar dar ką nors. Ir įkėlė šiuos failus į FTP. Ir staiga supratome, kad turime mažą, mažą klaidą, pavyzdžiui, pamiršome įdėti kabliataškį arba pamiršome pakeisti duomenų bazės slaptažodį, o yra duomenų bazės slaptažodis, kuris yra vietiniame kompiuteryje. Ir mes nusprendžiame greitai prisijungti prie FTP ir redaguoti failus ten pat. Tai tik ugnis! Tai buvo populiaru 90-aisiais.
Bet jei nežiūrėjote į kalendorių, 90-ieji buvo beveik prieš 30 metų. Dabar viskas vyksta šiek tiek kitaip. Ir pabandykite įsivaizduoti tragedijos mastą, kai jums pasakys: „Mes pradėjome gaminti, bet ten kažkas nutiko. Štai jūsų FTP prisijungimo vardas ir slaptažodis, prisijunkite prie gamybos ir greitai pataisykite. Jei esate Chuckas Norrisas, tai veiks. Jei ne, rizikuojate, kad ištaisę vieną klaidą padarysite dar 10. Būtent dėl to ši praktika grįžtant prie ankstesnės versijos leidžia pasiekti daug.
Net jei kažkas blogo kažkaip pateko į prod, tai yra blogai, bet ne mirtina. Galite grįžti į ankstesnę versiją. Vadinkite tai atsargine kopija, jei tai lengviau suvokti pagal tą terminiją. Galite grįžti prie šios ankstesnės versijos, o vartotojai vis tiek galės dirbti su jūsų produktu ir turėsite pakankamai buferio laiko. Galite ramiai, neskubėdami visa tai paimti ir išbandyti vietoje, pataisyti, o tada įkelti naują versiją. Tai daryti tikrai prasminga.
Dabar pabandykime kaip nors sujungti dvi ankstesnes praktikas. Gausime trečią, pavadintą Išleidimo valdymu.
Kai kalbame apie nuolatinį diegimą jo klasikine forma, sakome, kad turime paimti kodą iš kokios nors šakos iš saugyklos, jį sukompiliuoti ir įdiegti. Gerai, jei mūsų aplinka yra tokia pati. Jei turime kelias aplinkas, tai reiškia, kad kiekvieną kartą turime ištraukti kodą, net ir iš to paties įsipareigojimo. Kiekvieną kartą ištrauksime, kaskart pastatysime ir diegsime į naują aplinką. Pirma, atėjo laikas, nes sukurti projektą, jei turite didelį ir atėjote iš 90-ųjų, tai gali užtrukti kelias valandas.
Be to, yra dar vienas liūdesys. Kai kuriate, net ir toje pačioje mašinoje, kursite tuos pačius šaltinius, vis tiek neturite garantijos, kad ši mašina yra tokios pat būklės, kokia buvo paskutinio kūrimo metu.
Tarkime, kažkas atėjo ir atnaujino DotNet už jus arba, atvirkščiai, kažkas nusprendė ką nors ištrinti. Ir tada jūs turite kognityvinį disonansą, kad nuo šio įsipareigojimo prieš dvi savaites mes kūrėme pastatymą ir viskas buvo gerai, bet dabar atrodo, kad ta pati mašina, tas pats įsipareigojimas, tas pats kodas, kurį bandome sukurti, bet jis neveikia. . Su tuo susidursite ilgą laiką ir nėra faktas, kad tai išsiaiškinsite. Bent jau labai sugadinsite savo nervus.
Todėl leidimų valdymo praktika siūlo įvesti papildomą abstrakciją, vadinamą artefaktų saugykla, galerija ar biblioteka. Galite vadinti kaip tik norite.
Pagrindinė idėja yra ta, kad kai tik turime tam tikrą įsipareigojimą, tarkime, filiale, kurį esame pasirengę diegti skirtingose aplinkose, mes surenkame programas iš šio įsipareigojimo ir viską, ko reikia šiai programai, supakuojame. į ZIP archyvą ir išsaugokite patikimoje saugykloje. Ir iš šios saugyklos galime bet kada gauti šį ZIP archyvą.
Tada mes jį paimame ir automatiškai įdiegiame į dev aplinką. Ten lenktyniaujame, o jei viskas gerai, tada dislokuojamės į sceną. Jei viskas gerai, gamyboje diegiame tą patį archyvą, tuos pačius dvejetainius failus, sukompiliuotus tiksliai vieną kartą.
Be to, kai turime tokią galeriją, ji taip pat padeda spręsti riziką, kurią aptarėme paskutinėje skaidrėje, kai kalbėjome apie ankstesnės versijos grįžimą. Jei netyčia įdiegėte ką nors ne taip, visada galite paimti bet kurią kitą ankstesnę versiją iš šios galerijos ir atšaukti jos diegimą šiose aplinkose tokiu pačiu būdu. Tai leidžia lengvai grįžti į ankstesnę versiją, jei kas nors negerai.
Yra dar viena puiki praktika. Jūs ir aš visi suprantame, kad kai grąžiname savo programas į ankstesnę versiją, tai gali reikšti, kad mums taip pat reikia ankstesnės versijos infrastruktūros.
Kai kalbame apie virtualią infrastruktūrą, daugelis žmonių mano, kad tai yra kažkas, ką nustato administratoriai. Ir jei jums reikia, tarkime, gauti naują serverį, kuriame norite išbandyti naują programos versiją, tuomet turite parašyti bilietą administratoriams arba devops. Devops užtruks 3 savaites. Ir po 3 savaičių jie jums pasakys, kad mes įdiegėme jums virtualią mašiną su vienu branduoliu, dviem gigabaitais RAM ir „Windows“ serveriu be „DotNet“. Jūs sakote: „Bet aš norėjau DotNet“. Jie: „Gerai, grįžk po 3 savaičių“.
Idėja yra ta, kad naudodami infrastruktūrą kaip kodo praktiką, savo virtualią infrastruktūrą galite laikyti dar vienu ištekliu.
Galbūt, jei kas nors iš jūsų kuria programas „DotNet“, galbūt girdėjote apie biblioteką, pavadintą „Entity Framework“. Ir galbūt net girdėjote, kad „Entity Framework“ yra vienas iš metodų, kurį „Microsoft“ aktyviai skatina. Darbui su duomenų baze tai yra metodas, vadinamas Code First. Tai yra tada, kai kode aprašote, kaip norite, kad jūsų duomenų bazė atrodytų. Ir tada įdiegiate programą. Prisijungia prie duomenų bazės, pati nustato, kurios lentelės yra, o kurios ne, ir sukuria viską, ko reikia.
Tą patį galite padaryti su savo infrastruktūra. Nėra skirtumo, ar projektui reikia duomenų bazės, ar projektui reikia Windows serverio. Tai tik išteklius. Ir jūs galite automatizuoti šio šaltinio kūrimą, galite automatizuoti šio šaltinio konfigūraciją. Atitinkamai, kiekvieną kartą, kai norite išbandyti kokią nors naują koncepciją, naują požiūrį, jums nereikės rašyti bilieto į devops, galite tiesiog įdiegti izoliuotą infrastruktūrą sau iš paruoštų šablonų, iš paruoštų scenarijų ir ją įdiegti. ten visi tavo eksperimentai. Galite tai ištrinti, gauti rezultatų ir pranešti apie tai daugiau.
Kita praktika, kuri taip pat egzistuoja ir taip pat yra svarbi, tačiau kuria naudojasi tik nedaugelis, yra taikomųjų programų našumo stebėjimas.
Norėjau pasakyti tik vieną dalyką apie programos našumo stebėjimą. Kas svarbiausia šioje praktikoje? Tai yra tai, ką taikomosios programos veikimo stebėjimas yra maždaug tas pats, kas remontuoti butą. Tai nėra galutinė būsena, tai procesas. Jums reikia tai daryti reguliariai.
Gerąja prasme būtų gerai atlikti programos našumo stebėjimą beveik kiekvienoje versijoje, nors, kaip suprantate, tai ne visada įmanoma. Bet bent jau tai turi būti atlikta kiekvienam išleidimui.
Kodėl tai svarbu? Nes jei staiga pajuntate našumo sumažėjimą, turite aiškiai suprasti, kodėl. Jei jūsų komanda turi, tarkime, dviejų savaičių sprintus, tada bent kartą per dvi savaites turėtumėte įdiegti programą į atskirą serverį, kuriame turite aiškiai fiksuotą procesorių, RAM, diskus ir pan. Ir paleiskite tuos pačius našumo testus. . Jūs gaunate rezultatą. Pažiūrėkite, kaip jis pasikeitė nuo ankstesnio sprinto.
Ir jei sužinosite, kad skolinimasis kažkur smarkiai sumažėjo, tai reikš, kad tai įvyko tik dėl per pastarąsias dvi savaites įvykusių pokyčių. Tai leis jums daug greičiau nustatyti ir išspręsti problemą. Ir vėl, tai yra maždaug tos pačios metrikos, pagal kurias galite įvertinti, kaip sėkmingai tai padarėte.
Kita mūsų praktika yra konfigūracijos valdymo praktika. Tik nedaugelis į tai žiūri rimtai. Bet patikėkite manimi, tai iš tikrųjų labai rimtas dalykas.
Neseniai buvo juokinga istorija. Vaikinai priėjo prie manęs ir pasakė: „Padėkite mums atlikti mūsų programos saugos auditą“. Ilgai kartu žiūrėjome kodą, papasakojo apie aplikaciją, braižė diagramas. Ir plius minus viskas buvo logiška, suprantama, saugu, bet buvo vienas BET! Jie turėjo konfigūracijos failus savo šaltinio valdyme, įskaitant gamybinius su IP duomenų baze, su prisijungimo vardais ir slaptažodžiais, kad būtų galima prisijungti prie šių duomenų bazių ir kt.
Ir aš sakau: „Vaikinai, gerai, uždarėte gamybinę aplinką naudodami ugniasienę, bet tai, kad turite prisijungimo vardą ir slaptažodį gamybos duomenų bazei tiesiai šaltinio valdiklyje ir bet kuris kūrėjas gali jį perskaityti, jau yra didžiulė rizika saugumui. . Ir nesvarbu, kokia itin saugi jūsų programa yra kodo požiūriu, jei paliksite ją šaltinio valdymui, niekada niekur nepraleisite jokio audito. Štai apie ką aš kalbu.
Konfigūracijos valdymas. Skirtingose aplinkose galime turėti skirtingas konfigūracijas. Pavyzdžiui, galime turėti skirtingus prisijungimo vardus ir slaptažodžius duomenų bazėms, skirtoms kokybės užtikrinimui, demonstracijai, gamybos aplinkai ir kt.
Ši konfigūracija taip pat gali būti automatizuota. Jis visada turėtų būti atskirtas nuo pačios programos. Kodėl? Kadangi programą sukūrėte vieną kartą, o tada programai nesvarbu, ar jungiatės prie SQL serverio per tokį ir tokį IP, ar tokį ir tokį IP, ji turėtų veikti taip pat. Todėl, jei staiga vienas iš jūsų vis dar sunkiai koduoja ryšio eilutę kode, prisiminkite, kad aš jus surasiu ir nubausiu, jei atsidursite tame pačiame projekte su manimi. Tai visada dedama į atskirą konfigūraciją, pavyzdžiui, web.config.
Ir ši konfigūracija jau valdoma atskirai, t.y. būtent šiuo momentu kūrėjas ir administratorius gali ateiti ir sėdėti vienoje patalpoje. Ir kūrėjas gali pasakyti: „Žiūrėk, čia yra mano programos dvejetainiai failai. Jie dirba. Kad programa veiktų, reikalinga duomenų bazė. Čia šalia dvejetainių failų yra failas. Šiame faile šis laukas yra atsakingas už prisijungimą, tai yra už slaptažodį, tai už IP. Įdiekite jį bet kur“. Ir tai paprasta ir aišku administratoriui. Valdydamas šią konfigūraciją, jis gali ją įdiegti bet kur.
Ir paskutinė praktika, apie kurią norėčiau pakalbėti, yra praktika, kuri labai labai susijusi su debesimis. Ir tai suteikia maksimalų efektą, jei dirbate debesyje. Tai yra automatinis jūsų aplinkos pašalinimas.
Žinau, kad šioje konferencijoje dalyvauja keli žmonės iš komandų, su kuriomis dirbu. Ir su visomis komandomis, su kuriomis dirbu, naudojame šią praktiką.
Kodėl? Žinoma, būtų puiku, jei kiekvienas kūrėjas turėtų virtualią mašiną, kuri veiktų 24 valandas per parą. Bet galbūt tai jums naujiena, galbūt jūs neatkreipėte dėmesio, bet pats kūrėjas nedirba 7 valandas per parą. Kūrėjas paprastai dirba 24 valandas per dieną. Net jei į darbą ateina anksti, valgo didelius pietus, kurių metu eina į sporto salę. Tegul tai būna 7 valandų per dieną, kai kūrėjas iš tikrųjų naudoja šiuos išteklius. Pagal mūsų teisės aktus per savaitę turime 8 dienas iš 12, kurios laikomos darbo dienomis.
Atitinkamai, darbo dienomis ši mašina turėtų dirbti ne 24 valandas, o tik 12, o savaitgaliais išvis. Atrodytų, viskas labai paprasta, bet ką čia svarbu pasakyti? Įdiegę šią paprastą praktiką pagal šį pagrindinį tvarkaraštį, galite 70% sumažinti šių aplinkų priežiūros išlaidas, t. y. jūs paskaičiavote savo kūrėjo, kokybės užtikrinimo, demonstracinės versijos, aplinkos kainą ir padalinate ją iš 3.
Kyla klausimas, ką daryti su likusiais pinigais? Pavyzdžiui, kūrėjai turėtų nusipirkti „ReSharper“, jei dar to nepadarė. Arba surengti kokteilių vakarėlį. Jei anksčiau turėjote vieną aplinką, kurioje ganėsi ir dev, ir QA, ir viskas, dabar galite sukurti 3 skirtingas, kurios bus izoliuotos ir žmonės netrukdys vieni kitiems.
Kalbant apie skaidrę su nuolatiniu našumo matavimu, kaip galime palyginti našumą, jei projekto duomenų bazėje turėjome 1 įrašų, o po dviejų mėnesių yra milijonas? Kaip suprasti, kodėl ir kokia yra efektyvumo matavimo prasmė?
Tai geras klausimas, nes visada turėtumėte matuoti našumą naudodami tuos pačius išteklius. Tai reiškia, kad išleidžiate naują kodą, įvertinate naujo kodo našumą. Pavyzdžiui, reikia išbandyti skirtingus našumo scenarijus, tarkime, kad norite patikrinti, kaip programa veikia esant nedideliam apkrovimui, kai yra 1 vartotojų, o duomenų bazės dydis yra 000 gigabaitai. Jūs išmatavote ir gavote skaičius. Toliau imamės kito scenarijaus. Pavyzdžiui, 5 vartotojų, duomenų bazės dydis 5 terabaitas. Gavome rezultatus ir juos prisiminėme.
Kas čia svarbu? Čia svarbu tai, kad priklausomai nuo scenarijaus, duomenų apimties, vienu metu naudojamų vartotojų skaičiaus ir pan., galite susidurti su tam tikrais apribojimais. Pavyzdžiui, iki tinklo plokštės ribos arba iki standžiojo disko ribos, arba iki procesoriaus galimybių ribos. Štai ką jums svarbu suprasti. Įvairiuose scenarijuose jūs susiduriate su tam tikromis ribomis. Ir jūs turite suprasti skaičius, kai juos paspausite.
Ar mes kalbame apie našumo matavimą specialioje bandymo aplinkoje? Tai yra, tai nėra gamyba?
Taip, tai ne gamyba, tai yra bandomoji aplinka, kuri visada yra ta pati, kad galėtumėte palyginti ją su ankstesniais matavimais.
Supratau ačiū!
Jei nėra klausimų, manau, galime baigti. Ačiū!
Šaltinis: www.habr.com