Parimad DevOpsi tavad arendajatele. Anton Boyko (2017)

Aruandes räägitakse mõnest DevOpsi praktikast, kuid arendaja vaatenurgast. Tavaliselt on kõigil DevOpsiga liituvatel inseneridel juba mitmeaastane halduskogemus. Aga see ei tähenda, et siin poleks kohta arendajal. Enamasti tegelevad arendajad "päeva järgmise kiireloomulise kriitilise vea" parandamisega ja neil pole aega isegi DevOpsi väljale kiiret pilku heita. Autori arvates on DevOps esiteks terve mõistus. Teiseks on see võimalus olla efektiivsem. Kui olete arendaja, teil on tervet mõistust ja soovite olla meeskonnamängijana tõhusam, on see aruanne teie jaoks.

Lubage mul end tutvustada, tunnistan täielikult, et ruumis on inimesi, kes mind ei tunne. Minu nimi on Anton Boyko, ma olen Microsoft Azure'i MVP. Mis on MVP? See on Model-View-Esitleja. Model-View-Presenter olen täpselt mina.

Lisaks töötan hetkel Ciklumis lahendusarhitekti ametit. Ja just hiljuti ostsin endale nii ilusa domeeni ja uuendasin oma meili, mida tavaliselt esitlustel näitan. Võite mulle kirjutada aadressil: me [koer] byokoant.pro. Küsimustega võite saata mulle meili. Tavaliselt vastan neile. Ainus asi on see, et ma ei soovi saada meili teel küsimusi, mis on seotud kahe teemaga: poliitika ja religioon. Kõigest muust võid mulle kirjutada meili teel. Mingi aeg läheb, vastan.

Paar sõna endast:

• Olen sellel alal tegutsenud nüüdseks 10 aastat.
• Töötasin Microsoftis.
• Olen Ukraina Azure kogukonna asutaja, mille asutasime kuskil 2014. aastal. Ja see on meil siiani alles ja me arendame seda.
• Olen ka Ukrainas korraldatava Azure konverentsi asutaja isa.
• Aitan korraldada ka Global Azure Bootcamp'i Kiievis.
• Nagu ma ütlesin, olen Microsoft Azure'i MVP.
• Ma räägin konverentsidel üsna sageli. Mulle väga meeldib konverentsidel esineda. Viimase aasta jooksul sain esineda umbes 40 korda. Kui möödute Ukrainast, Valgevenest, Poolast, Bulgaariast, Rootsist, Taanist, Hollandist, Hispaaniast või annate või võtate mõne muu riigi Euroopas, siis on täiesti võimalik, et kui lähete konverentsile, mille voos on pilveteema, võite mind esinejate loendis näha.
• Olen ka Star Treki fänn.

Räägime natuke Agendast. Meie päevakava on väga lihtne:

• Räägime sellest, mis on DevOps. Räägime, miks see oluline on. Varem oli DevOps märksõna, mille kirjutasid oma CV-sse ja said kohe +500 dollarit palka. Nüüd tuleb oma CV-sse kirjutada näiteks blockchain, et palgale +500 dollarit saada.
• Ja siis, kui saame natuke aru, mis see on, räägime sellest, millised on DevOpsi tavad. Kuid mitte niivõrd DevOpsi kontekstis üldiselt, vaid nende DevOpsi tavade kohta, mis võiksid arendajatele huvi pakkuda. Ma ütlen teile, miks need võivad teile huvi pakkuda. Ma ütlen teile, miks peaksite seda üldse tegema ja kuidas see aitab teil valu vähem tunda.

Traditsiooniline pilt, mida paljud inimesed näitavad. Nii juhtub paljudes projektides. See on siis, kui meil on arendus- ja operatsiooniosakonnad, mis toetavad meie tarkvara. Ja need osakonnad ei suhtle omavahel.

Võib-olla, kui te ei suutnud seda DevOpsis ja operatsiooniosakondades nii selgelt tunda, võite tuua analoogia arendus- ja kvaliteedikontrolli osakondadega. On inimesi, kes arendavad tarkvara ja on QA inimesi, kes on arendajate seisukohalt halvad. Näiteks panen oma imelise koodi hoidlasse ja seal istub mingi kaabakat, kes tagastab mulle selle koodi ja ütleb, et su kood on halb.

See kõik juhtub seetõttu, et inimesed ei suhtle omavahel. Ja nad viskavad üksteisele mingeid pakendeid, rakendusi läbi mingi arusaamatuse seina ja üritavad nendega midagi peale hakata.

Just seda müüri DevOpsi kultuur on loodud hävitama, s.t. sundida inimesi omavahel suhtlema ja vähemalt mõistma, mida erinevad projektis osalevad inimesed teevad ja miks nende töö on oluline.

Ja kui me räägime DevOpsist, siis keegi ütleb teile, et DevOps on siis, kui projektil on pidev integreerimine; keegi ütleb, et DevOps on see, kui projektis rakendatakse tava „infrastruktuur kui kood”; keegi ütleb, et DevOpsi esimene samm on funktsioonide hargnemine, funktsioonilipud.

Põhimõtteliselt on see kõik omal moel tõsi. Kuid need on ainult meie parimad tavad. Enne nende tavade juurde asumist soovitan vaadata seda slaidi, mis näitab Dev-Opsi metoodika rakendamise kolme etappi teie projektis teie ettevõttes.

Sellel slaidil on ka teine ​​mitteametlik nimi. Saate veebist otsida, et teada saada, millised on DevOpsi kolm musketäri. Võimalik, et leiate selle artikli. Miks 3 musketäri? All on kirjas: inimesed, protsessid ja tooted, st. PPP – Porthos, Porthos ja Porthos. Siin on kolm DevOpsi musketäri. Selles artiklis kirjeldatakse üksikasjalikumalt, miks see on oluline ja mida see endast kujutab.

Kui alustate DevOpsi kultuuri juurutamist, on väga oluline, et seda rakendataks järgmises järjekorras.

Esialgu peate inimestega rääkima. Ja peate inimestele selgitama, mis see on ja kuidas nad saavad sellest kasu.

Meie konverentsi nimi on DotNet Fest. Ja nagu korraldajad mulle ütlesid, kutsusime siia peamiselt arendajate publiku, seega loodan, et suurem osa saalis viibijatest on arendusega seotud.

Räägime inimestest, räägime sellest, mida arendajad iga päev teha tahavad. Mida nad kõige rohkem tahavad? Nad tahavad kirjutada uut koodi, kasutada uusi raamistikke, luua uusi funktsioone. Mida arendajad kõige vähem tahavad? Parandage vanad vead. Loodan, et nõustute minuga. See on see, mida arendajad tahavad. Nad tahavad kirjutada uusi funktsioone, nad ei taha vigu parandada.

Konkreetse arendaja tekitatud vigade arv sõltub sellest, kui sirged on tema käed ja kui palju nad kasvavad õlgadest, mitte tagumikutaskutest. Kuid sellegipoolest, kui meil on suur projekt, juhtub mõnikord, et kõike on võimatu jälgida, mistõttu oleks tore, kui kasutaksime mõnda lähenemisviisi, mis aitaks meil kirjutada stabiilsemat ja kvaliteetsemat koodi.

Mida QA-d kõige rohkem tahavad? Ma ei tea, kas nad on saalis. Mul on raske öelda, et ma tahan kvaliteedikontrolli, sest ma pole seda kunagi olnud. Ja ärge pahandage poisse, öeldakse, et ma loodan, et ma ei tee seda kunagi. Aga mitte sel põhjusel, et ma nende tööd mõttetuks ja kasutuks pean, vaid sellepärast, et ma ei pea end inimeseks, kes suudaks seda tööd tõhusalt teha, nii et ma isegi ei püüa seda teha. Kuid nagu ma aru saan, on see, mis QA-le kõige rohkem ei meeldi hommikuti töötamine, pidev regressioonitestide tegemine, samade vigade astumine, millest nad 3 sprinti tagasi arendajatele teatasid, ja öelda: “Millal sa teed. , Monsieur D 'Artagnan, parandage see viga.' Ja monsieur D'Artagnan vastab talle: "Jah, jah, jah, ma olen selle juba parandanud." Ja kuidas see juhtub, et parandasin ühe vea ja tegin tee peal 5.

Inimesed, kes seda lahendust tootmises toetavad, soovivad, et see lahendus töötaks ilma vigadeta, et nad ei peaks igal reedel serverit taaskäivitama, kui kõik normaalsed inimesed baaris käivad. Arendajad juurutasid reedel, administraatorid istuvad kuni laupäevani ning üritavad seda juurutamist üles ehitada ja parandada.

Ja kui selgitate inimestele, et nad on suunatud samade probleemide lahendamisele, saate liikuda protsesside vormistamise juurde. See on väga tähtis. Miks? Sest kui me ütleme "formaliseerimine", on teil oluline kirjeldada, kuidas teie protsessid toimuvad vähemalt kuskil salvrätikul. Peate mõistma, et kui juurutate näiteks kvaliteedikontrolli keskkonda või tootmiskeskkonda, siis toimub see alati selles järjekorras; nendes etappides käivitame näiteks automaatsed ühikutestid ja kasutajaliidese testid. Pärast kasutuselevõttu kontrollime, kas kasutuselevõtt läks hästi või halvasti. Kuid teil on juba selge toimingute loend, mida tuleb tootmisse juurutamisel ikka ja jälle korrata.

Ja alles siis, kui teie protsessid on vormistatud, hakkate valima tooteid, mis aitavad teil neid protsesse automatiseerida.

Kahjuks näen ma väga sageli, et see juhtub vastupidiselt. Niipea kui keegi kuuleb sõna "DevOps", soovitab ta kohe Jenkinsi installida, sest nad usuvad, et niipea, kui nad Jenkinsi installivad, on neil DevOps. Nad installisid Jenkinsi, lugesid Jenkinsi veebisaidil artikleid "Kuidas teha", proovisid neisse How to artiklitesse protsesse toppida ja tulid siis inimeste juurde ja kummardasid inimesi, öeldes, et raamatus öeldakse, et peate seda tegema nii. nii et me teeme seda nii.

Asi pole selles, et Jenkins on halb tööriist. Ma ei taha seda kuidagi öelda. Kuid see on vaid üks toodetest. Ja millist toodet te kasutate, peaks see olema teie viimane otsus ja mitte mingil juhul esimene. Teie toodet ei tohiks juhtida kultuuri ja lähenemisviiside rakendamine. Seda on väga oluline mõista, mistõttu veedan sellel slaidil nii palju aega ja seletan seda kõike nii kaua.

Räägime DevOpsi tavadest üldiselt. Mis need on? Mis vahe on? Kuidas neid selga proovida? Miks need olulised on?

Esimene praktika, millest olete kuulnud, on pidev integreerimine. Võib-olla on kellelgi projektis osalejal pidev integratsioon (CI).

Suurim probleem on see, et kui küsin inimeselt kõige sagedamini: "Kas teil on projektis CI?" ja ta ütleb: "Jah," siis kui ma küsin, mida ta teeb, kirjeldab ta mulle absoluutselt kogu automatiseerimisprotsessi. See pole täiesti tõsi.

Tegelikult on CI praktika suunatud lihtsalt erinevate inimeste kirjutatud koodi integreerimisele mingisse ühtsesse koodibaasi. See on kõik.

Lisaks CI-le on tavaliselt ka teisi tavasid – näiteks pidev juurutamine, väljalaskehaldus, kuid sellest räägime hiljem.

CI ise ütleb meile, et koodi kirjutavad erinevad inimesed ja seda koodi tuleb pidevalt integreerida ühtsesse koodibaasi.

Mida see meile annab ja miks see oluline on? Kui meil on DotNet, siis see on hea, see on kompileeritud keel, saame oma rakenduse koostada. Kui see kompileerub, on see juba hea märk. See ei tähenda veel midagi, kuid see on esimene hea märk, mille saame vähemalt koostada.

Seejärel saame teha mõned testid, mis on samuti eraldi praktika. Testid on kõik rohelised – see on teine ​​hea märk. Aga jällegi, see ei tähenda midagi.

Aga miks sa seda teeksid? Kõik tavad, millest ma täna räägin, kannavad ligikaudu sama väärtust, st ligikaudu sama kasu ja neid mõõdetakse samuti ligikaudu samamoodi.

Esiteks võimaldab see tarnimist kiirendada. Kuidas see võimaldab teil kohaletoimetamist kiirendada? Kui teeme oma koodibaasi uusi muudatusi, saame kohe proovida selle koodiga midagi teha. Me ei oota neljapäevani, sest neljapäeval avaldame selle QA Environmentile, teeme seda just siin ja siin.

Ma räägin teile ühe kurva loo oma elust. See oli ammu, kui ma olin veel noor ja ilus. Nüüd olen juba noor, ilus ja tark ja tagasihoidlik. Mõni aeg tagasi osalesin ühes projektis. Meil oli suur umbes 30 arendajast koosnev meeskond. Ja meil oli suur, suur ettevõtte projekt, mis arenes umbes 10 aastat. Ja meil olid erinevad filiaalid. Hoidlas oli meil filiaal, kus arendajad kõndisid. Ja seal oli filiaal, mis kuvas tootmises oleva koodi versiooni.

Tootmisharu oli arendajatele kättesaadavast harust 3 kuud maas. Mida see tähendab? See tähendab, et niipea kui mul on kuskil viga, mis läheb tootmisse arendajate süül, kuna nad seda lubasid, ja QA süül, kuna nad seda vaatasid, siis see tähendab, et kui ma saan Tootmise käigultparanduse ülesanne, siis pean 3 kuud tagasi tehtud koodimuudatused tagasi tõmbama. Pean meenutama, mis mul 3 kuud tagasi oli, ja proovima seda seal parandada.

Kui teil pole seda kogemust veel olnud, saate seda oma koduprojektis proovida. Peaasi, et ärge proovige seda kaubanduslikul kujul. Kirjutage paar koodirida, unustage need kuueks kuuks ja tulge seejärel tagasi ja proovige kiiresti selgitada, mida need koodiread endast kujutavad ja kuidas saate neid parandada või optimeerida. See on väga-väga põnev kogemus.

Kui meil on pideva integreerimise tava, siis see võimaldab meil seda mitmete automatiseeritud tööriistadega kontrollida just siin ja kohe, niipea kui olen oma koodi kirjutanud. See ei pruugi anda mulle täit pilti, kuid sellegipoolest eemaldab see vähemalt osa riskidest. Ja kui on võimalik viga, siis ma saan sellest kohe teada, see tähendab sõna otseses mõttes paari minuti pärast. Ma ei pea 3 kuud tagasi kerima. Mul on vaja ainult 2 minutit tagasi kerida. Hea kohvimasin ei jõua isegi 2 minutiga kohvi keeta, nii et see on päris lahe.

Sellel on väärtus, et seda saab iga projekti puhul korrata, s.t. mitte ainult see, mille seadistasite. Saate korrata nii praktikat ennast kui ka CI-d korratakse iga uue projekti muudatuse korral. See võimaldab teil ressursse optimeerida, kuna teie meeskond töötab tõhusamalt. Teil ei ole enam olukorda, kus viga tuleb teile koodist, millega töötasite 3 kuud tagasi. Te ei pea enam konteksti vahetama, kui istud ja veedad esimesed kaks tundi, püüdes mõista, mis siis juhtus, ja enne kui midagi parandama hakkad konteksti olemusse jõudma.

Kuidas me saame mõõta selle praktika edu või ebaõnnestumist? Kui annate suurele bossile aru, mida me CI projektis rakendasime, kuuleb ta bla-bla-bla. Me rakendasime selle, OK, aga miks, mida see meile tõi, kuidas me seda mõõdame, kui õigesti või valesti me seda rakendame?

Esimene on see, et tänu CI-le saame juurutada üha sagedamini ja sagedamini just seetõttu, et meie kood on potentsiaalselt stabiilsem. Samamoodi väheneb meie aeg vea leidmiseks ja selle vea parandamise aeg just sel põhjusel, et saame just siin ja praegu süsteemist vastuse, mis meie koodiga valesti on.

Veel üks meie tava on automatiseerimise testimise tava, mis enamasti kaasneb CI praktikaga. Need käivad käsikäes.

Mida on siin oluline mõista? Oluline on mõista, et meie testid on erinevad. Ja iga automatiseeritud test on suunatud oma probleemide lahendamisele. Meil on näiteks ühiktestid, mis võimaldavad testida moodulit eraldi, s.t. Kuidas see vaakumis töötab? See on hea.

Meil on ka integratsioonitestid, mis võimaldavad meil mõista, kuidas erinevad moodulid omavahel integreeruvad. See on ka hea.

Meil võivad olla kasutajaliidese automatiseerimise testid, mis võimaldavad kontrollida, kui hästi töö kasutajaliidesega vastab teatud kliendi poolt seatud nõuetele jne.

Teie käivitatavad konkreetsed testid võivad mõjutada nende käitamise sagedust. Ühiktestid on tavaliselt kirjutatud lühikesed ja väikesed. Ja neid saab regulaarselt käivitada.

Kui me räägime kasutajaliidese automatiseerimise testidest, siis on kõik korras, kui teie projekt on väike. Teie kasutajaliidese automatiseerimise testid võivad toimuda mõistliku aja jooksul. Tavaliselt võtab aga suure projekti kasutajaliidese automatiseerimise test mitu tundi. Ja see on okei, kui see võtab vaid paar tundi. Ainuke asi on see, et nende käivitamine igal versioonil pole mõttekas. Mõistlik on neid käivitada öösel. Ja kui kõik hommikul tööle tulevad – nii testijad kui ka arendajad –, saavad nad mingi aruande, mis ütleb, et me käivitasime kasutajaliidese automatiseerimise testi öösel ja saime need tulemused. See on tunni töö. serverKvaliteedikontrolli inseneri palkamine, kes kontrollib teie toote vastavust teatud nõuetele, on palju odavam kui tunniajaline kvaliteedikontrolli inseneri töö, isegi kui tegemist on tasuta töötava noorema kvaliteedikontrolli inseneriga. Tund masinatööd on ikkagi odavam. Seetõttu on sellesse investeerimine mõistlik.

Mul on veel üks projekt, millega olen tegelenud. Meil oli selle projektiga kaks nädalat spurti. Projekt oli suur, finantssektori jaoks oluline ja viga ei saanud teha. Ja pärast kahenädalast spurti järgnes arendustsüklile testimisprotsess, mis võttis veel 4 nädalat. Proovige ette kujutada tragöödia ulatust. Kirjutame koodi kaks nädalat, seejärel teeme seda CodeFreeze'iga, pakendame selle rakenduse uude versiooni ja avaldame testijatele. Testijad testivad seda veel 4 nädalat, st. Kuni nad seda testivad, on meil aega neile veel kaks versiooni ette valmistada. See on tõesti kurb juhtum.

Ja me ütlesime neile, et kui soovite olla produktiivsem, on mõistlik rakendada automatiseeritud testimise tavasid, sest just see teeb teile haiget just siin ja praegu.

Harjutage pidevat juurutamist. Suurepärane, olete ehitamise lõpetanud. See on juba hea. Teie kood on koostatud. Nüüd oleks tore juurutada see ehitus mõnes keskkonnas. Oletame, et arendajatele mõeldud keskkonnas.

Miks see oluline on? Esiteks saate vaadata, kui edukas olete juurutamisprotsessiga ise. Olen kohanud selliseid projekte, kui küsin: “Kuidas te rakenduse uut versiooni juurutate?”, ütlevad poisid mulle: “Me paneme selle kokku ja pakime ZIP-arhiivi. Saadame selle adminnile posti teel. Administraator laadib selle arhiivi alla ja laiendab. Ja kogu kontor hakkab palvetama, et server uue versiooni üles võtaks.

Alustame millegi lihtsaga. Näiteks unustasid nad arhiivi CSS-i lisada või JavaScripti faili nimes räsimärki muuta. Ja kui me esitame päringu server, arvab brauser, et tal on JavaScripti fail juba olemas ja otsustab seda mitte alla laadida. Aga vanas versioonis oli midagi puudu. Lühidalt öeldes võib probleeme olla palju. Seetõttu võimaldab pideva juurutamise praktika teil vähemalt testida, mis juhtub, kui võtta puhas võrdluskujutis ja lükata see täiesti puhtasse uude keskkonda. Näete, mis juhtub.

Samuti, kui integreerite omavahel koodi, st. käsu vahel, see võimaldab teil ka näha, kuidas see kasutajaliideses välja näeb.

Üks probleem, mis ilmneb, kui kasutatakse palju vanilje java-skripti, on see, et kaks arendajat deklareerisid aknaobjektis tormakalt sama nimega muutuja. Ja siis, sõltuvalt teie õnnest. Kelle java-scripti fail teisena välja tõmmatakse, kirjutab teise faili muudatused üle. See on ka väga põnev. Sa tuled sisse: üks asi töötab ühe inimese jaoks, teine ​​ei tööta teise jaoks. Ja see on "imeline", kui see kõik tootmises välja tuleb.

Järgmine praktika, mis meil on, on automaatse taastamise tava, nimelt rakenduse eelmisele versioonile tagasipöördumine.

Miks on see arendajatele oluline? Veel on neid, kes mäletavad kaugeid-kaugeid 90ndaid, mil arvutid olid suured ja programmid väikesed. Ja ainus viis veebiarenduseks oli PHP. Asi pole selles, et PHP on halb keel, kuigi see on nii.

Kuid probleem oli erinev. Kui juurutasime oma php saidi uue versiooni, kuidas me selle juurutasime? Kõige sagedamini avasime Far Manageri või midagi muud. Ja laadis need failid üles FTP-sse. Ja järsku saime aru, et meil on mingi väike väike viga, näiteks unustasime panna semikooloni või unustasime andmebaasi parooli muuta ja andmebaasi parool on olemas, mis asub kohalikus hostis. Ja otsustame kiiresti FTP-ga ühenduse luua ja faile seal redigeerida. See on lihtsalt tuli! See oli 90ndatel populaarne.

Aga kui te pole kalendrit vaadanud, siis 90ndad olid peaaegu 30 aastat tagasi. Nüüd toimub kõik veidi teisiti. Ja proovige ette kujutada tragöödia ulatust, kui teile öeldakse: "Me kasutasime tootmist, kuid seal läks midagi valesti. Siin on teie FTP sisselogimine ja parool, looge ühendus tootmisvõrguga ja parandage see seal kiiresti. Kui sa oled Chuck Norris, siis see toimib. Kui ei, siis on oht, et kui parandate ühe vea, saate veel 10. Just seetõttu võimaldab see eelmisele versioonile tagasipöördumine palju saavutada.

Isegi kui midagi halba sattus kuskil prodisse, on see halb, kuid mitte saatuslik. Saate naasta eelmisele versioonile. Nimetage seda varukoopiaks, kui seda on selles terminoloogias lihtsam tajuda. Saate naasta sellele eelmisele versioonile ja kasutajad saavad endiselt teie tootega töötada ja teil on piisavalt puhveraega. Saate seda kõike rahulikult, kiirustamata ette võtta ja kohapeal testida, parandada ja seejärel uue versiooni üles laadida. Seda on tõesti mõistlik teha.

Proovime nüüd kahte eelnevat praktikat kuidagi omavahel kombineerida. Saame kolmanda nimega Release Management.

Kui me räägime pidevast juurutamisest selle klassikalisel kujul, siis ütleme, et peame hoidlast mõnest harust koodi tõmbama, selle kompileerima ja juurutama. Hea, kui meil on sama keskkond. Kui meil on mitu keskkonda, tähendab see, et peame koodi tõmbama iga kord, isegi samast sissekandmisest. Tõmbame selle iga kord välja, ehitame iga kord ja juurutame selle uude keskkonda. Esiteks on käes aeg, sest kui teil on suur projekt ja see on pärit 90ndatest, võib see võtta mitu tundi.

Peale selle on veel üks kurbus. Kui ehitate, isegi samale masinale, ehitate samu allikaid, kuid teil pole endiselt garantiid, et see masin on samas olekus, nagu see oli viimase ehitamise ajal.

Oletame, et keegi tuli sisse ja värskendas DotNeti teie jaoks või vastupidi, keegi otsustas midagi kustutada. Ja siis on teil kognitiivne dissonants, et sellest kahe nädala tagusest commitist ehitasime ehitamist ja kõik oli korras, aga nüüd tundub, et see on sama masin, sama commit, sama kood, mida me üritame luua, kuid see ei tööta . Te tegelete sellega pikka aega ja pole tõsi, et te sellest aru saate. Vähemalt rikute palju oma närve.

Seetõttu soovitab väljalaskehalduse tava kasutusele võtta täiendava abstraktsiooni, mida nimetatakse artefaktihoidlaks või galeriiks või raamatukoguks. Sa võid seda nimetada kuidas tahad.

Põhiidee seisneb selles, et niipea, kui meil on seal mingisugune commit, näiteks filiaalis, mida oleme valmis oma erinevatesse keskkondadesse juurutama, kogume sellelt commitilt rakendused ja kõik, mida selle rakenduse jaoks vajame, pakkime selle. ZIP-arhiivi ja salvestage see mõnda usaldusväärsesse salvestusruumi. Ja sellelt salvestusruumilt saame selle ZIP-arhiivi igal ajal hankida.

Seejärel võtame selle ja juurutame selle automaatselt arenduskeskkonda. Võisteldakse seal ja kui kõik on hästi, siis läheme lavale. Kui kõik on korras, juurutame tootmisse sama arhiivi, samad binaarfailid, mis on kompileeritud täpselt üks kord.

Lisaks, kui meil on selline galerii, aitab see meil käsitleda riske, mida käsitlesime eelmisel slaidil, kui rääkisime eelmisele versioonile tagasipööramisest. Kui juurutasite kogemata midagi valesti, saate alati sellest galeriist võtta mis tahes muu eelmise versiooni ja eemaldada selle nendes keskkondades samal viisil. See võimaldab teil hõlpsasti naasta eelmisele versioonile, kui midagi läheb valesti.

On veel üks suurepärane praktika. Teie ja mina mõistame kõik, et kui me oma rakendusi ennistame eelmisele versioonile, võib see tähendada, et vajame ka eelmise versiooni infrastruktuuri.

Virtuaalsest infrastruktuurist rääkides arvavad paljud, et see on midagi, mille administraatorid seadistavad. Seega, kui teil on vaja näiteks uut serverit oma rakenduse uue versiooni testimiseks, peate esitama administraatoritele või DevOpsile pileti. DevOpsil kulub selleks kolm nädalat. Ja kolme nädala pärast ütlevad nad teile, et oleme installinud teile virtuaalmasina ühe tuuma, kahe gigabaidise muutmälu ja... Windows- server ilma DotNetita. Sa ütled: "Aga ma tahtsin DotNeti." Nad ütlevad: "Olgu, tule kolme nädala pärast tagasi."

Idee seisneb selles, et kui kasutate infrastruktuuri koodi tavadena, saate oma virtuaalset infrastruktuuri käsitleda lihtsalt ühe ressursina.

Võib-olla, kui keegi teist arendab DotNetis rakendusi, olete ehk kuulnud teegist nimega Entity Framework. Võib-olla olete isegi kuulnud, et Entity Framework on üks lähenemisviisidest, mida Microsoft aktiivselt edendab. Andmebaasiga töötamiseks on see lähenemine nimega Code First. See on siis, kui kirjeldate koodis, kuidas soovite oma andmebaasi välja näha. Ja siis juurutate rakenduse. See ühendub andmebaasiga, määrab ise, millised tabelid on olemas ja millised mitte, ning loob kõik vajaliku.

Sama saad teha ka oma infrastruktuuriga. Pole vahet, kas vajad andmebaasi projekti või projekti jaoks. Windows-server. See on lihtsalt ressurss. Ja selle ressursi loomise, selle ressursi konfigureerimise saab automatiseerida. Seega ei pea te iga kord, kui soovite uut kontseptsiooni või lähenemisviisi testida, DevOps-i piletit esitama. Saate lihtsalt juurutada isoleeritud infrastruktuuri valmismallide ja skriptide abil ning käivitada kõik oma katsed seal. Saate selle kustutada, tulemusi hankida ja neist aru anda.

Järgmine praktika, mis on samuti olemas ja samuti oluline, kuid mida vähesed kasutavad, on rakenduste toimivuse jälgimine.

Tahtsin rakenduse jõudluse jälgimise kohta öelda ainult üht. Mis on selle praktika juures kõige olulisem? See on rakenduse jõudluse jälgimine umbes sama, mis korteri remont. See ei ole lõplik seisund, see on protsess. Peate seda regulaarselt tegema.

Hea mõte oleks rakenduse jõudluse jälgimine peaaegu igas järgus läbi viia, kuigi, nagu te aru saate, pole see alati võimalik. Kuid seda tuleb teha vähemalt iga väljalaske puhul.

Miks see oluline on? Sest kui kogete järsku jõudluse langust, peate selgelt mõistma, miks. Kui teie meeskonnal on näiteks kahenädalased sprintid, siis peaksite vähemalt kord kahe nädala jooksul juurutama oma rakenduse mõnda eraldi serverisse, kus teil on selgelt fikseeritud protsessor, RAM, kettad jne. Ja käivitage need samad jõudlustestid. . Sa saad tulemuse. Vaata, kuidas see eelmisest sprindist muutunud on.

Ja kui avastate, et väljamakse langes kuskil järsult, tähendab see, et see oli lihtsalt viimase kahe nädala jooksul toimunud muutuste tõttu. See võimaldab teil probleemi palju kiiremini tuvastada ja lahendada. Ja jällegi on need ligikaudu samad mõõdikud, mille abil saate mõõta, kui edukalt te seda tegite.

Järgmine praktika on konfiguratsioonihaldus. Väga vähe on neid, kes seda tõsiselt võtavad. Aga uskuge mind, see on tegelikult väga tõsine asi.

Hiljuti oli üks naljakas lugu. Poisid tulid minu juurde ja ütlesid: "Aidake meil läbi viia meie rakenduse turvaaudit." Vaatasime koos pikalt koodi, nad rääkisid rakendusest, joonistasid skeeme. Ja pluss-miinus oli kõik loogiline, arusaadav, turvaline, aga oli üks AGA! Nende allikajuhtimises olid konfiguratsioonifailid, sealhulgas IP-andmebaasiga tootmisfailid, nende andmebaasidega ühenduse loomiseks vajalikud sisselogimised ja paroolid jne.

Ja ma ütlen: "Poisid, okei, sulgesite oma tootmiskeskkonna tulemüüriga, kuid see, et teil on tootmisandmebaasi sisselogimine ja parool otse lähtekoodi kontrolli all ja iga arendaja saab seda lugeda, on juba tohutu turvarisk. . Ja olenemata sellest, kui üliturvaline teie rakendus koodi seisukohast on, kui jätate selle allika juhtimise alla, ei läbi te kunagi ühtegi auditit. Sellest ma räägingi.

Konfiguratsiooni juhtimine. Meil võivad erinevates keskkondades olla erinevad konfiguratsioonid. Näiteks võivad meil olla erinevad sisselogimised ja paroolid andmebaaside jaoks QA, demo, tootmiskeskkonna jne jaoks.

Seda konfiguratsiooni saab ka automatiseerida. See peaks alati olema rakendusest eraldi. Miks? Kuna lõite rakenduse ühe korra ja siis pole rakendusel vahet, kas loote ühenduse SQL-serveriga sellise ja sellise IP või sellise ja sellise IP kaudu, peaks see töötama samamoodi. Seega, kui äkki keegi teist ikka veel kõvasti kodeerib koodis olevat ühendusstringi, siis pidage meeles, et ma leian teid üles ja karistan teid, kui leiate end minuga samast projektist. See paigutatakse alati eraldi konfiguratsiooni, näiteks failis web.config.

Ja seda konfiguratsiooni hallatakse juba eraldi, st see on täpselt see hetk, mil arendaja ja administraator saavad tulla ja ühes ruumis istuda. Ja arendaja võib öelda: "Vaata, siin on minu rakenduse binaarfailid. Nad töötavad. Rakendus vajab töötamiseks andmebaasi. Siin on kahendfailide kõrval fail. Selles failis vastutab see väli sisselogimise eest, see on parooli ja IP-aadressi eest. Kasutage seda kõikjal." Ja see on administraatorile lihtne ja selge. Seda konfiguratsiooni haldades saab ta selle kasutusele võtta kõikjal.

Ja viimane praktika, millest tahaksin rääkida, on praktika, mis on väga-väga seotud pilvedega. Ja see annab maksimaalse efekti, kui töötate pilves. See on teie keskkonna automaatne eemaldamine.

Ma tean, et sellel konverentsil on mitu inimest tiimidest, kellega ma töötan. Ja kõigi meeskondadega, kellega ma töötan, kasutame seda praktikat.

Miks? Muidugi oleks tore, kui igal arendajal oleks virtuaalne masin, mis töötaks 24/7. Kuid võib-olla on see teile uudis, võib-olla ei pööranud te tähelepanu, kuid arendaja ise ei tööta 24/7. Arendaja töötab tavaliselt 8 tundi päevas. Isegi kui ta tuleb varakult tööle, on tal suur lõunasöök, mille jooksul ta läheb jõusaali. Olgu see siis 12 tundi päevas, mil arendaja neid ressursse reaalselt kasutab. Meie seadusandluse kohaselt on meil nädalas 5 päeva seitsmest, mida loetakse tööpäevadeks.

Sellest lähtuvalt ei tohiks see masin tööpäeviti töötada 24 tundi, vaid ainult 12 ja nädalavahetustel ei tohiks see masin üldse töötada. Näib, et kõik on väga lihtne, kuid mida on siin oluline öelda? Rakendades seda lihtsat tava selles põhigraafikus, võimaldab see vähendada nende keskkondade ülalpidamiskulusid 70%, st võtsite oma arendaja, kvaliteedikontrolli, demo, keskkonna hinna ja jagasite selle 3-ga.

Küsimus on selles, mida teha ülejäänud rahaga? Näiteks peaksid arendajad ostma ReSharperi, kui nad pole seda veel teinud. Või korraldage kokteilipidu. Kui teil oli varem üks keskkond, kus nii dev kui ka QA karjatasid, ja kõik, siis nüüd saate teha 3 erinevat, mis on isoleeritud ja inimesed ei sega üksteist.

Mis puutub pideva jõudlusmõõtmisega slaidi, siis kuidas saame võrrelda jõudlust, kui meil oli projektis andmebaasis 1 kirjet, kaks kuud hiljem on neid miljon? Kuidas aru saada, miks ja mis on tulemuslikkuse mõõtmise mõte?

See on hea küsimus, sest tulemuslikkust tuleks alati mõõta samade ressurssidega. See tähendab, et võtate kasutusele uue koodi, mõõdate uue koodi toimivust. Näiteks peate testima erinevaid jõudlusstsenaariume, oletame, et soovite testida, kuidas rakendus töötab väikese koormuse korral, kus on 1 kasutajat ja andmebaasi suurus on 000 gigabaiti. Sa mõõtsid selle ja said numbrid. Järgmisena võtame teise stsenaariumi. Näiteks 5 kasutajat, andmebaasi suurus 5 terabait. Saime tulemused kätte ja jätsime need meelde.

Mis siin olulist on? Siin on oluline see, et olenevalt stsenaariumist, andmemahust, samaaegsete kasutajate arvust jne võivad teil tekkida teatud piirangud. Näiteks võrgukaardi piirini või kõvaketta piirini või protsessori võimaluste piirini. Seda on teie jaoks oluline mõista. Erinevate stsenaariumide korral satute teatud piiridesse. Ja te peate numbreid mõistma, kui neid tabate.

Kas me räägime jõudluse mõõtmisest spetsiaalses testkeskkonnas? See tähendab, et see pole tootmine?

Jah, see ei ole tootmine, see on testkeskkond, mis on alati sama, et saaksite seda võrrelda varasemate mõõtmistega.

Sai aru aitäh!

Kui küsimusi pole, arvan, et võime lõpetada. Aitäh!

Allikas: www.habr.com