Skýrslan mun fjalla um nokkur DevOps starfshætti, en frá sjónarhóli þróunaraðila. Venjulega hafa allir verkfræðingar sem ganga til liðs við DevOps þegar margra ára stjórnunarreynslu á bakinu. En þetta þýðir ekki að það sé enginn staður fyrir framkvæmdaraðila hér. Oftar en ekki eru verktaki uppteknir við að laga „næstu brýnt mikilvæga villu dagsins“ og þeir hafa ekki tíma til að skoða DevOps sviðið. Í skilningi höfundar er DevOps í fyrsta lagi heilbrigð skynsemi. Í öðru lagi er það tækifæri til að vera áhrifaríkari. Ef þú ert verktaki, hefur skynsemi og vilt vera skilvirkari sem liðsmaður, þá er þessi skýrsla fyrir þig.
Leyfðu mér að kynna mig, ég viðurkenni alveg að það er fólk í herberginu sem þekkir mig ekki. Mitt nafn er Anton Boyko, ég er Microsoft Azure MVP. Hvað er MVP? Þetta er Model-View-Presenter. Model-View-Presenter er nákvæmlega ég.
Auk þess gegni ég nú stöðu lausnaarkitekts hjá Ciklum. Og nýlega keypti ég mér svo fallegt lén og uppfærði tölvupóstinn minn, sem ég sýni venjulega á kynningum. Þú getur skrifað mér á: me [hundur] byokoant.pro. Þú getur sent mér tölvupóst með spurningum. Ég svara þeim yfirleitt. Málið er bara að ég myndi ekki vilja fá spurningar í tölvupósti sem tengjast tvennu: stjórnmálum og trúarbrögðum. Þú getur skrifað mér um allt annað með tölvupósti. Það mun líða nokkur tími, mun ég svara.
Nokkur orð um sjálfan mig:
- Ég hef verið á þessu sviði í 10 ár núna.
- Ég vann hjá Microsoft.
- Ég er stofnandi úkraínska Azure samfélagsins, sem við stofnuðum einhvers staðar árið 2014. Og við höfum það enn og erum að þróa það.
- Ég er líka faðir stofnanda Azure ráðstefnunnar sem við höldum í Úkraínu.
- Ég aðstoða líka við að skipuleggja Global Azure Bootcamp í Kyiv.
- Eins og ég sagði, ég er Microsoft Azure MVP.
- Ég tala nokkuð oft á ráðstefnum. Ég elska virkilega að tala á ráðstefnum. Undanfarið ár gat ég komið fram um 40 sinnum. Ef þú ferð framhjá Úkraínu, Hvíta-Rússlandi, Póllandi, Búlgaríu, Svíþjóð, Danmörku, Hollandi, Spáni eða gefur eða tekur annað land í Evrópu, þá er alveg mögulegt að þegar þú ferð á ráðstefnu sem er með skýjaþema í straumnum, þú gætir séð mig á mælendalistanum.
- Ég er líka Star Trek aðdáandi.
Við skulum tala aðeins um Dagskrá. Dagskráin okkar er mjög einföld:
- Við munum tala um hvað DevOps er. Við skulum tala um hvers vegna þetta er mikilvægt. Áður fyrr var DevOps lykilorð sem þú skrifaðir á ferilskrána þína og fékkst strax +$500 í laun. Nú þarftu að skrifa til dæmis blockchain í ferilskrána þína til að fá +500 dollara í launin þín.
- Og svo, þegar við skiljum aðeins hvað þetta er, munum við tala um hvað DevOps venjur eru. En ekki svo mikið í samhengi við DevOps almennt, heldur um þá DevOps venjur sem gætu verið áhugaverðar fyrir þróunaraðila. Ég skal segja þér hvers vegna þeir gætu haft áhuga á þér. Ég skal segja þér hvers vegna þú ættir að gera þetta yfirleitt og hvernig það getur hjálpað þér að upplifa minni sársauka.
Hefðbundin mynd sem margir sýna. Þetta er það sem gerist í mörgum verkefnum. Þetta er þegar við erum með þróunar- og rekstrardeildir sem styðja hugbúnaðinn okkar. Og þessar deildir hafa ekki samskipti sín á milli.
Kannski, ef þú varst ekki fær um að finna það svo greinilega í DevOps og rekstrardeildum, geturðu dregið upp hliðstæðu við Dev og QA deildirnar. Það er fólk sem þróar hugbúnað og það er QA fólk sem er slæmt frá sjónarhóli þróunaraðila. Til dæmis sendi ég dásamlega kóðann minn í geymsluna og þar situr einhver skúrkur sem skilar þessum kóða til mín og segir að kóðinn þinn sé slæmur.
Þetta gerist allt vegna þess að fólk hefur ekki samskipti sín á milli. Og þeir kasta sumum pökkum, einhverri umsókn hver á annan í gegnum einhvern vegg misskilnings og reyna að gera eitthvað með þá.
Það er einmitt þessi veggur sem DevOps menningin er hönnuð til að eyðileggja, þ.e. neyða fólk til að eiga samskipti sín á milli og skilja að minnsta kosti hvað mismunandi fólk í verkefninu gerir og hvers vegna starf þeirra er mikilvægt.
Og þegar við tölum um DevOps mun einhver segja þér að DevOps er þegar verkefnið hefur stöðuga samþættingu; einhver mun segja að DevOps sé ef verkefnið útfærir „innviði sem kóða“ venju; einhver mun segja að fyrsta skrefið í DevOps sé eiginleikagrein, eiginleikafánar.
Í meginatriðum er þetta allt satt á sinn hátt. En þetta eru bara æðstu vinnubrögðin sem við höfum. Áður en haldið er áfram að þessum aðferðum legg ég til að þú skoðir þessa glæru, sem sýnir þrjú stig innleiðingar Dev-Ops aðferðafræðinnar í verkefninu þínu, í fyrirtækinu þínu.
Þessi glæra hefur einnig annað óopinbert nafn. Þú getur leitað á netinu til að komast að því hvað 3 Musketeers of DevOps eru. Það er mögulegt að þú finnir þessa grein. Af hverju 3 musketeers? Hér að neðan segir: fólk, ferlar og vörur, þ.e. PPP - Porthos, Porthos og Porthos. Hér eru 3 Musketeers of DevOps. Þessi grein lýsir nánar hvers vegna þetta er mikilvægt og hvað það felur í sér.
Þegar þú byrjar að innleiða DevOps menningu er mjög mikilvægt að hún sé innleidd í eftirfarandi röð.
Í upphafi þarftu að tala við fólk. Og þú þarft að útskýra fyrir fólki hvað það er og hvernig það getur fengið einhvern ávinning af því.
Ráðstefnan okkar heitir DotNet Fest. Og eins og skipuleggjendurnir sögðu mér þá buðum við aðallega áhorfendum þróunaraðila hingað, svo ég vona að flestir í salnum taki þátt í þróuninni.
Við munum tala um fólk, við munum tala um hvað forritarar vilja gera á hverjum degi. Hvað vilja þeir helst? Þeir vilja skrifa nýjan kóða, nota nýmóðins ramma, búa til nýja eiginleika. Hvað vilja verktaki síst? Lagfærðu gamlar villur. Ég vona að þú sért sammála mér. Þetta er það sem verktaki vilja. Þeir vilja skrifa nýja eiginleika, þeir vilja ekki laga villur.
Fjöldi galla sem tiltekinn verktaki framleiðir fer eftir því hversu beinir handleggir hans eru og hversu mikið þeir vaxa úr öxlum hans, en ekki frá rassvösum hans. En engu að síður, þegar við erum með stórt verkefni, gerist það stundum að það er ómögulegt að fylgjast með öllu, svo það væri gaman fyrir okkur að nota nokkrar aðferðir sem munu hjálpa okkur að skrifa stöðugri og hágæða kóða.
Hvað vilja QAs helst? Ég veit ekki hvort þeir eru í salnum. Það er erfitt fyrir mig að segja að ég vilji QA, því ég hef aldrei verið það. Og ekki móðgast við strákana, það verður sagt að ég vona að ég geri það aldrei. En ekki af þeirri ástæðu að ég tel starf þeirra tilgangslaust og gagnslaust, heldur vegna þess að ég tel mig ekki vera manneskju sem gæti unnið þetta verk á skilvirkan hátt, svo ég mun ekki einu sinni reyna að vinna það. En eftir því sem ég skil, það sem QA líkar ekki best við er að fara að vinna á morgnana, keyra stöðugt einhverskonar aðhvarfspróf, stíga á sömu villurnar og þeir tilkynntu þróunaraðilum fyrir þremur spretti síðan og segja: „Hvenær ætlarðu að , Monsieur D 'Artagnan, lagaðu þessa villu.' Og Monsieur D'Artagnan svarar honum: "Já, já, já, ég er búinn að laga það." Og hvernig það gerist að ég lagaði eina villu og gerði 3 í leiðinni.
Fólkið sem styður þessa lausn í framleiðslu vill að þessi lausn virki án galla, svo að þeir þurfi ekki að endurræsa þjóninn á hverjum föstudegi, þegar allt venjulegt fólk fer á barinn. Þróunaraðilarnir komu á föstudeginum, stjórnendurnir sitja fram á laugardag og reyna að koma þessari uppsetningu upp og laga.
Og þegar þú útskýrir fyrir fólki að þeir miði að því að leysa sömu vandamálin, geturðu haldið áfram að formfesta ferlana. Það er mjög mikilvægt. Hvers vegna? Vegna þess að þegar við segjum „formfestingu“ er mikilvægt fyrir þig að lýsa því hvernig ferlar þínir eiga sér stað að minnsta kosti einhvers staðar á servíettu. Þú þarft að skilja að ef þú, til dæmis, dreifir í QA umhverfi eða framleiðsluumhverfi, þá gerist það alltaf í þessari röð; á þessum stigum keyrum við til dæmis sjálfvirk einingapróf og UI próf. Eftir útsetningu athugum við hvort uppsetningin hafi gengið vel eða illa. En þú ert nú þegar með skýran lista yfir aðgerðir sem verður að endurtaka aftur og aftur þegar þú sendir til framleiðslu.
Og aðeins þegar ferlar þínir eru formbundnir, byrjarðu að velja vörur sem munu hjálpa þér að gera þessi ferla sjálfvirkan.
Því miður sé ég þetta mjög oft gerast öfugt. Um leið og einhver heyrir orðið „DevOps“ stinga þeir strax upp á því að setja upp Jenkins, því þeir trúa því að um leið og þeir setja upp Jenkins muni þeir hafa DevOps. Þeir settu Jenkins upp, lásu „Hvernig á“ greinarnar á Jenkins vefsíðunni, reyndu að troða ferlum inn í þessar Hvernig á að greinar, og komu svo til fólks og beygðu fólk niður og sögðu að bókin segði að þú þyrftir að gera þetta á þennan hátt, þannig að við gerum þetta svona.
Það er ekki það að Jenkins sé slæmt tæki. Ég ætla ekki að segja það á nokkurn hátt. En þetta er bara ein af vörum. Og hvaða vara þú notar ætti að vera síðasta ákvörðun þín og alls ekki sú fyrsta. Varan þín ætti ekki að vera knúin áfram af innleiðingu menningar og aðferða. Þetta er mjög mikilvægt að skilja og þess vegna eyði ég svo miklum tíma í þessa glæru og útskýri allt þetta svo lengi.
Við skulum tala um DevOps venjur almennt. Hvað eru þeir? Hver er munurinn? Hvernig á að prófa þá? Hvers vegna eru þau mikilvæg?
Fyrsta æfingin sem þú gætir hafa heyrt um heitir Stöðug samþætting. Kannski hefur einhver í verkefninu stöðuga samþættingu (CI).
Stærsta vandamálið er að oftast þegar ég spyr mann: "Ertu með CI í verkefninu?" og hann segir: „Já,“ svo þegar ég spyr hvað hann geri, lýsir hann fyrir mér algjörlega öllu sjálfvirkniferlinu. Þetta er ekki alveg satt.
Reyndar miðar iðkun CI bara að því að samþætta kóðann sem mismunandi fólk skrifar í einhvers konar einn kóðagrunn. Það er allt og sumt.
Samhliða CI eru venjulega aðrar venjur á leiðinni - eins og stöðug dreifing, útgáfustjórnun, en við munum tala um það síðar.
CI sjálft segir okkur að mismunandi fólk skrifar kóða og þessi kóða verður að vera stöðugt samþættur í einn kóðagrunn.
Hvað gefur þetta okkur og hvers vegna er það mikilvægt? Ef við erum með DotNet, þá er það gott, það er samsett tungumál, við getum sett saman forritið okkar. Ef það er sett saman, þá er þetta nú þegar gott merki. Þetta þýðir ekki neitt ennþá, en þetta er fyrsta góða merkið sem við getum að minnsta kosti sett saman.
Síðan getum við keyrt nokkur próf, sem er líka sérstök æfing. Prófin eru öll græn - þetta er annað góða merkið. En aftur, þetta þýðir ekkert.
En hvers vegna myndirðu gera þetta? Allar aðferðir sem ég mun tala um í dag bera um það bil sama gildi, þ.e.a.s. um það bil sömu ávinning og eru einnig mældar um það bil á sama hátt.
Í fyrsta lagi gerir það þér kleift að flýta fyrir afhendingu. Hvernig gerir þetta þér kleift að flýta fyrir afhendingu? Þegar við gerum nýjar breytingar á kóðagrunninum okkar getum við strax reynt að gera eitthvað með þennan kóða. Við bíðum ekki þangað til fimmtudagurinn kemur því á fimmtudaginn gefum við það út til QA Environment, við gerum það hér og hér.
Ég skal segja þér eina sorgarsögu úr lífi mínu. Það var langt síðan ég var enn ungur og myndarlegur. Nú er ég þegar ungur, fallegur og klár og hógvær. Fyrir nokkru síðan var ég í verkefni. Við vorum með stórt teymi um 30 þróunaraðila. Og við vorum með stórt, stórt Enterprise verkefni sem þróaðist í um það bil 10 ár. Og við vorum með mismunandi útibú. Í geymslunni vorum við með útibú sem framkvæmdaraðilar gengu í. Og það var útibú sem sýndi útgáfu kóðans sem er í framleiðslu.
Framleiðsluútibúið var 3 mánuðum á eftir útibúinu sem var í boði fyrir þróunaraðila. Hvað þýðir þetta? Þetta þýðir að um leið og ég er með galla einhvers staðar sem fer í framleiðslu vegna sök þróunaraðila, vegna þess að þeir leyfðu það, og vegna galla QA, vegna þess að þeir horfðu á það, þá þýðir þetta að ef ég fæ a verkefni fyrir flýtileiðréttingu fyrir framleiðslu, þá þarf ég að afturkalla kóðabreytingarnar mínar fyrir 3 mánuðum síðan. Ég verð að muna hvað ég átti fyrir 3 mánuðum og reyna að laga það þar.
Ef þú hefur ekki fengið þessa reynslu ennþá geturðu prófað hana í heimaverkefninu þínu. Aðalatriðið er, ekki reyna það í auglýsingum. Skrifaðu nokkrar línur af kóða, gleymdu þeim í sex mánuði og komdu svo aftur og reyndu að útskýra fljótt um hvað þessar kóðalínur snúast og hvernig þú getur lagað eða fínstillt þær. Þetta er mjög, mjög spennandi reynsla.
Ef við erum með stöðuga samþættingu, þá gerir þetta okkur kleift að athuga það með fjölda sjálfvirkra verkfæra hér og núna, um leið og ég hef skrifað kóðann minn. Þetta gefur mér kannski ekki heildarmyndina, en engu að síður mun það fjarlægja að minnsta kosti hluta áhættunnar. Og ef það er einhver hugsanleg villa, mun ég vita um það núna, það er bókstaflega eftir nokkrar mínútur. Ég þarf ekki að fara aftur 3 mánuði. Ég þarf aðeins að snúa aftur 2 mínútur. Góð kaffivél mun ekki einu sinni hafa tíma til að brugga kaffi á 2 mínútum, svo það er frekar flott.
Þetta hefur það gildi að hægt er að endurtaka það aftur og aftur á hverju verkefni, þ.e. ekki bara þann sem þú setur það upp á. Þú getur endurtekið bæði æfinguna sjálfa og CI sjálft verður endurtekið fyrir hverja nýja breytingu sem þú gerir á verkefninu. Þetta gerir þér kleift að hámarka auðlindir vegna þess að teymið þitt vinnur skilvirkari. Þú munt ekki lengur búa við aðstæður þar sem galla kemur til þín frá kóðanum sem þú vannst með fyrir 3 mánuðum síðan. Þú munt ekki lengur hafa samhengisskipti þegar þú situr og eyðir fyrstu tveimur tímunum í að reyna að skilja hvað gerðist þá og komast inn í kjarna samhengisins áður en þú byrjar að leiðrétta eitthvað.
Hvernig getum við mælt árangur eða mistök þessarar framkvæmdar? Ef þú tilkynnir stóra yfirmanninum hvað við innleiddum á CI verkefninu, þá heyrir hann bla bla bla. Við innleiddum það, allt í lagi, en hvers vegna, hvað leiddi það til okkar, hvernig mælum við það, hversu rétt eða rangt erum við að innleiða það?
Hið fyrsta er að, þökk sé CI, getum við dreift oftar og oftar og oftar einmitt vegna þess að kóðinn okkar er hugsanlega stöðugri. Á sama hátt styttist tími okkar til að finna villu og tíminn til að leiðrétta þessa villu minnkar einmitt vegna þess að við fáum svar frá kerfinu hér og núna, hvað er að kóðanum okkar.
Önnur æfing sem við höfum er sjálfvirkniprófunaraðferðin, sem oftast fylgir CI æfingunni. Þeir haldast í hendur.
Hvað er mikilvægt að skilja hér? Það er mikilvægt að skilja að prófin okkar eru mismunandi. Og hvert sjálfvirkt próf miðar að því að leysa eigin vandamál. Við erum til dæmis með einingapróf sem gera okkur kleift að prófa einingu sérstaklega, þ.e. Hvernig virkar það í lofttæmi? Þetta er gott.
Við erum líka með samþættingarpróf sem gera okkur kleift að skilja hvernig mismunandi einingar sameinast hver öðrum. Það er líka gott.
Við gætum verið með HÍ sjálfvirknipróf sem gera okkur kleift að athuga hversu vel vinnan með HÍ uppfyllir ákveðnar kröfur sem viðskiptavinurinn setur o.s.frv.
Sértækar prófanir sem þú keyrir geta haft áhrif á hversu oft þú keyrir þau. Einingapróf eru venjulega skrifuð stutt og lítil. Og hægt er að hleypa þeim af stað reglulega.
Ef við erum að tala um sjálfvirknipróf í HÍ, þá er gott ef verkefnið þitt er lítið. Sjálfvirkniprófin þín við HÍ geta tekið nægan tíma. En venjulega er sjálfvirknipróf í HÍ eitthvað sem tekur nokkrar klukkustundir í stóru verkefni. Og það er gott ef það eru nokkrar klukkustundir. Málið er bara að það þýðir ekkert að keyra þá fyrir hverja byggingu. Það er skynsamlegt að keyra þá á kvöldin. Og þegar allir mættu til vinnu á morgnana: bæði prófunaraðilar og forritarar, fengu þeir einhvers konar tilkynningu um að við keyrðum HÍ sjálfvirka prófun á kvöldin og fengum þessar niðurstöður. Og hér, klukkutími af vinnu netþjóns sem mun athuga hvort varan þín uppfylli einhverjar kröfur verður mun ódýrari en klukkutími af vinnu sama QA verkfræðings, jafnvel þótt það sé Junior QA verkfræðingur sem vinnur fyrir mat og þakkir. Samt sem áður, klukkutími í notkun vél verður ódýrari. Þess vegna er skynsamlegt að fjárfesta í því.
Ég er með annað verkefni sem ég hef verið að vinna að. Við áttum tveggja vikna spretti í þessu verkefni. Verkefnið var stórt, mikilvægt fyrir fjármálageirann og mistök urðu ekki. Og eftir tveggja vikna sprett, var þróunarlotunni fylgt eftir með prófunarferli sem tók 4 vikur í viðbót. Reyndu að ímynda þér umfang harmleiksins. Við skrifum kóða í tvær vikur, síðan gerum við það ala CodeFreeze, pökkum honum inn í nýja útgáfu af forritinu og rúllum honum út til prófunaraðila. Prófendur prófa það í 4 vikur í viðbót, þ.e. Á meðan þeir eru að prófa það höfum við tíma til að undirbúa tvær útgáfur í viðbót fyrir þá. Þetta er virkilega sorglegt mál.
Og við sögðum þeim að ef þú vilt vera afkastameiri, þá er skynsamlegt fyrir þig að innleiða sjálfvirkar prófanir, því þetta er það sem særir þig hérna, núna.
Æfðu stöðuga dreifingu. Frábært, þú ert búinn að smíða. Þetta er nú þegar gott. Kóðinn þinn hefur safnað saman. Nú væri gaman að setja þessa byggingu á einhverju umhverfi. Segjum í umhverfi fyrir þróunaraðila.
Hvers vegna er það mikilvægt? Í fyrsta lagi geturðu skoðað hversu vel þú ert með dreifingarferlið sjálft. Ég hef kynnst svona verkefnum, þegar ég spyr: „Hvernig seturðu upp nýja útgáfu af forritinu?“ segja krakkar mér: „Við setjum það saman og pökkum því inn í zip-skjalasafn. Við sendum það til stjórnanda í pósti. Stjórnandinn hleður niður og stækkar þetta skjalasafn. Og öll skrifstofan byrjar að biðja um að þjónninn taki upp nýju útgáfuna.“
Byrjum á einhverju einföldu. Til dæmis gleymdu þeir að setja CSS í skjalasafnið eða gleymdu að breyta myllumerkinu í java-script skráarnafninu. Og þegar við gerum beiðni til netþjónsins, heldur vafrinn að hann hafi nú þegar þessa java-script skrá og ákveður að hlaða henni ekki niður. Og það var gömul útgáfa, eitthvað vantaði. Almennt séð geta verið mörg vandamál. Þess vegna gerir æfingin á stöðugri dreifingu þér kleift að prófa að minnsta kosti hvað myndi gerast ef þú myndir taka hreina tilvísunarmynd og hlaða henni upp í alveg hreint nýtt umhverfi. Þú getur séð hvert þetta leiðir.
Einnig, þegar þú samþættir kóða sín á milli, þ.e. milli skipunarinnar, þetta gerir þér kleift að sjá hvernig það lítur út í notendaviðmótinu.
Eitt af vandamálunum sem koma upp þar sem mikið af vanillu java-scripti er notað er að tveir forritarar lýstu í skyndi yfir breytu með sama nafni í gluggahlutnum. Og svo, allt eftir heppni þinni. Java-script skrá sem er dregin út í öðru sæti mun skrifa yfir breytingar á hinni. Það er líka mjög spennandi. Þú kemur inn: eitt virkar fyrir einn mann, annað virkar ekki fyrir annan. Og það er „dásamlegt“ þegar allt kemur út í framleiðslu.
Næsta æfing sem við höfum er æfingin á sjálfvirkri endurheimt, nefnilega að snúa aftur í fyrri útgáfu forritsins.
Af hverju er þetta mikilvægt fyrir forritara? Enn eru þeir sem muna eftir hinni fjarlægu, fjarlægu tíunda áratug, þegar tölvur voru stórar og forrit lítil. Og eina leiðin til vefþróunar var í gegnum PHP. Það er ekki það að PHP sé slæmt tungumál, þó það sé það.
En vandamálið var allt annað. Þegar við settum upp nýja útgáfu af php síðunni okkar, hvernig settum við hana upp? Oftast opnuðum við Far Manager eða eitthvað annað. Og hlóð þessum skrám upp á FTP. Og við áttuðum okkur allt í einu á því að við vorum með litla, litla galla, til dæmis gleymdum við að setja semíkommu eða gleymdum að breyta lykilorðinu fyrir gagnagrunninn og það er lykilorð fyrir gagnagrunninn, sem er á staðbundnum hýsil. Og við ákveðum að tengjast fljótt við FTP og breyta skránum þar. Þetta er bara eldur! Þetta var það sem var vinsælt á tíunda áratugnum.
En ef þú hefur ekki skoðað dagatalið, þá voru 90s fyrir næstum 30 árum síðan. Nú er allt að gerast aðeins öðruvísi. Og reyndu að ímynda þér umfang harmleiksins þegar þeir segja þér: „Við fórum í framleiðslu, en eitthvað fór úrskeiðis þar. Hér er FTP innskráningin þín og lykilorðið þitt, tengdu við framleiðslu og lagaðu það fljótt þar. Ef þú ert Chuck Norris, þá mun þetta virka. Ef ekki, þá er hætta á því að ef þú lagar eina villu muntu fá 10 í viðbót. Þetta er einmitt ástæðan fyrir því að þessi venja að snúa aftur í fyrri útgáfu gerir þér kleift að ná miklu.
Jafnvel þó að eitthvað slæmt hafi einhvern veginn lent í árekstri einhvers staðar, þá er það slæmt, en ekki banvænt. Þú getur snúið aftur í fyrri útgáfu sem þú hefur. Kallaðu það öryggisafrit, ef það er auðveldara að skynja það í þeim hugtökum. Þú getur snúið aftur í þessa fyrri útgáfu og notendur munu enn geta unnið með vöruna þína og þú munt hafa nægan biðtíma. Þú getur rólega, án flýti, tekið allt þetta og prófað það á staðnum, lagað það og síðan hlaðið upp nýrri útgáfu. Það er virkilega skynsamlegt að gera þetta.
Nú skulum við reyna að sameina á einhvern hátt fyrri vinnubrögðin saman. Við fáum þann þriðja sem heitir Release Management.
Þegar við tölum um Continuous Deployment í sinni klassísku mynd segjum við að við verðum að draga kóða úr einhverri grein úr geymslunni, setja hann saman og dreifa honum. Það er gott ef við höfum sama umhverfi. Ef við erum með mörg umhverfi þýðir þetta að við verðum að draga kóðann í hvert skipti, jafnvel úr sama commit. Við munum draga það út í hvert skipti, við munum byggja það í hvert skipti og við munum dreifa því í nýtt umhverfi. Í fyrsta lagi er þetta kominn tími, vegna þess að til að byggja upp verkefni, ef þú ert með stórt og kom frá 90s, þá getur það tekið nokkrar klukkustundir.
Að auki er önnur sorg. Þegar þú byggir, jafnvel á sömu vél, muntu byggja sömu heimildir, þú hefur samt enga tryggingu fyrir því að þessi vél sé í sama ástandi og hún var við síðustu smíði.
Segjum að einhver hafi komið inn og uppfært DotNet fyrir þig eða öfugt hafi einhver ákveðið að eyða einhverju. Og svo ertu með vitsmunalega mismunun að frá þessari commit fyrir tveimur vikum síðan vorum við að byggja byggingu og allt var í lagi, en núna virðist það vera sama vél, sama commit, sami kóðann og við erum að reyna að byggja, en það virkar ekki . Þú munt takast á við þetta í langan tíma og það er ekki staðreynd að þú munt komast að því. Að minnsta kosti muntu spilla taugum þínum mikið.
Þess vegna benda útgáfustjórnunarvenjur til að kynna viðbótar abstrakt sem kallast gripageymslu eða gallerí eða bókasafn. Þú mátt kalla það hvað sem þú vilt.
Meginhugmyndin er sú að um leið og við höfum einhvers konar skuldbindingu þarna, segjum, í útibúi sem við erum tilbúin til að dreifa í mismunandi umhverfi okkar, söfnum við umsóknum frá þessari skuldbindingu og öllu sem við þurfum fyrir þessa umsókn, pökkum við því. inn í zip skjalasafn og vistaðu það í áreiðanlegri geymslu. Og frá þessari geymslu getum við fengið þetta zip skjalasafn hvenær sem er.
Síðan tökum við það og sendum það sjálfkrafa í þróunarumhverfið. Við keppum þarna og ef allt er í lagi þá leggjum við okkur á svið. Ef allt er í lagi, þá sendum við sama skjalasafnið til framleiðslu, sömu tvíþættir, settir nákvæmlega saman einu sinni.
Þar að auki, þegar við erum með gallerí eins og þetta, hjálpar það okkur líka að takast á við áhættuna sem við tókum á síðustu glærunni þegar við ræddum um afturköllun í fyrri útgáfu. Ef þú notaðir óvart eitthvað rangt geturðu alltaf tekið hvaða fyrri útgáfu sem er úr þessu myndasafni og tekið hana upp í þessi umhverfi á sama hátt. Þetta gerir þér kleift að snúa aftur í fyrri útgáfu auðveldlega ef eitthvað fer úrskeiðis.
Það er önnur frábær æfing. Þú og ég skiljum öll að þegar við endurnýjum forritin okkar í fyrri útgáfu gæti þetta þýtt að við þurfum líka innviði fyrri útgáfunnar.
Þegar við tölum um sýndarinnviði halda margir að þetta sé eitthvað sem stjórnendur setja upp. Og ef þú þarft, segjum, að fá nýjan netþjón sem þú vilt prófa nýja útgáfu af forritinu þínu, þá verður þú að skrifa miða til admins eða devops. Devops mun taka 3 vikur í þetta. Og eftir 3 vikur munu þeir segja þér að við höfum sett upp sýndarvél fyrir þig, með einum kjarna, tveimur gígabætum af vinnsluminni og Windows netþjóni án DotNet. Þú segir: "En ég vildi DotNet." Þeir: "Allt í lagi, komdu aftur eftir 3 vikur."
Hugmyndin er sú að með því að nota innviði sem kóðaaðferðir geturðu meðhöndlað sýndarinnviði þína sem bara aðra auðlind.
Kannski, ef einhver ykkar er að þróa forrit á DotNet, gætirðu hafa heyrt um bókasafn sem heitir Entity Framework. Og þú gætir jafnvel hafa heyrt að Entity Framework er ein af þeim aðferðum sem Microsoft er virkur að ýta undir. Til að vinna með gagnagrunn er þetta aðferð sem kallast Code First. Þetta er þegar þú lýsir í kóða hvernig þú vilt að gagnagrunnurinn þinn líti út. Og svo seturðu forritið í notkun. Hann tengist gagnagrunninum, hann ákvarðar sjálfur hvaða töflur eru til staðar og hvaða töflur eru ekki, og býr til allt sem þú þarft.
Þú getur gert það sama með innviðina þína. Það er enginn munur á því hvort þú þarft gagnagrunn fyrir verkefni eða hvort þú þarft Windows netþjón fyrir verkefni. Þetta er bara auðlind. Og þú getur sjálfvirkt stofnun þessarar auðlindar, þú getur gert sjálfvirkan uppsetningu á þessari auðlind. Í samræmi við það, í hvert skipti sem þú vilt prófa eitthvað nýtt hugtak, einhverja nýja nálgun, þarftu ekki að skrifa miða á devops, þú getur einfaldlega sett upp einangraðan innviði fyrir sjálfan þig frá tilbúnum sniðmátum, frá tilbúnum skriftum og útfært það þar allar tilraunir þínar. Þú getur eytt þessu, fengið nokkrar niðurstöður og tilkynnt frekar um það.
Næsta æfing, sem er líka til og er líka mikilvæg, en sem fæstir nota, er eftirlit með frammistöðu forrita.
Mig langaði að segja aðeins eitt um eftirlit með frammistöðu forrita. Hvað er mikilvægast við þessa vinnu? Þetta er það sem Umsókn árangurseftirlit er um það sama og að gera við íbúð. Þetta er ekki endanlegt ástand, þetta er ferli. Þú þarft að gera það reglulega.
Á góðan hátt væri gott að framkvæma vöktun á frammistöðu forrita á næstum hverri byggingu, þó, eins og þú skilur, það sé ekki alltaf mögulegt. En að minnsta kosti þarf að framkvæma það fyrir hverja útgáfu.
Hvers vegna er það mikilvægt? Vegna þess að ef þú finnur skyndilega fyrir lækkun á frammistöðu, þá þarftu að skilja skýrt hvers vegna. Ef liðið þitt hefur td tveggja vikna spretti, þá ættirðu að minnsta kosti einu sinni á tveggja vikna fresti að senda forritið þitt á einhvern sérstakan netþjón, þar sem þú ert með greinilega fastan örgjörva, vinnsluminni, diska osfrv. Og keyra sömu frammistöðuprófin . Þú færð niðurstöðuna. Sjáðu hvernig það hefur breyst frá fyrri spretti.
Og ef þú kemst að því að niðurfellingin hafi lækkað verulega einhvers staðar þýðir það að það hafi bara verið vegna breytinganna sem áttu sér stað undanfarnar tvær vikur. Þetta gerir þér kleift að bera kennsl á og laga vandamálið mun hraðar. Og aftur, þetta eru nokkurn veginn sömu mælingar sem þú getur mælt með hversu vel þú tókst það.
Næsta æfing sem við höfum er stillingarstjórnun æfing. Það eru mjög fáir sem taka þetta alvarlega. En trúðu mér, þetta er í rauninni mjög alvarlegur hlutur.
Það var skemmtileg saga nýlega. Strákarnir komu til mín og sögðu: „Hjálpaðu okkur að gera öryggisúttekt á umsókninni okkar. Við skoðuðum kóðann saman í langan tíma, þeir sögðu mér frá forritinu, teiknuðu skýringarmyndir. Og plús eða mínus allt var rökrétt, skiljanlegt, öruggt, en það var eitt EN! Þeir voru með stillingarskrár í upprunastýringu sinni, þar á meðal þær frá framleiðslu með IP gagnagrunninum, með innskráningum og lykilorðum til að tengjast þessum gagnagrunnum o.s.frv.
Og ég segi: „Krakkar, allt í lagi, þið hafið lokað framleiðsluumhverfinu ykkar með eldvegg, en sú staðreynd að þið hafið notandanafnið og lykilorðið fyrir framleiðslugagnagrunninn beint í frumstýringunni og hvaða verktaki sem er getur lesið það er nú þegar mikil öryggisáhætta . Og sama hversu ofuröruggt forritið þitt er frá sjónarhóli kóðans, ef þú skilur það eftir í frumstýringu, þá muntu aldrei standast neina endurskoðun neins staðar. Þetta er það sem ég er að tala um.
Stillingarstjórnun. Við gætum haft mismunandi stillingar í mismunandi umhverfi. Til dæmis gætum við haft mismunandi innskráningar og lykilorð fyrir gagnagrunna fyrir QA, kynningu, framleiðsluumhverfi o.s.frv.
Þessa stillingu er einnig hægt að gera sjálfvirkt. Það ætti alltaf að vera aðskilið frá forritinu sjálfu. Hvers vegna? Vegna þess að þú smíðaðir forritið einu sinni, og þá er forritinu sama hvort þú tengist SQL þjóninum í gegnum svona og svona IP eða svona og svona IP, þá ætti það að virka eins. Þess vegna, ef allt í einu er einhver ykkar enn að harðkóða tengistrenginn í kóðanum, mundu að ég mun finna þig og refsa þér ef þú lendir í sama verkefni og mig. Þetta er alltaf sett í sérstaka stillingu, til dæmis í web.config.
Og þessari uppsetningu er nú þegar stjórnað sérstaklega, þ.e. þetta er einmitt augnablikið þegar verktaki og stjórnandi geta komið og setið í sama herbergi. Og verktaki getur sagt: „Sjáðu, hér eru tvöfaldir forritsins míns. Þeir vinna. Forritið þarf gagnagrunn til að virka. Hér við hliðina á tvístirnunum er skrá. Í þessari skrá er þessi reitur ábyrgur fyrir innskráningu, þetta er fyrir lykilorðið, þetta er fyrir IP. Settu það hvar sem er." Og það er einfalt og skýrt fyrir stjórnandann. Hann getur sett það í raun hvar sem er með því að stjórna þessari uppsetningu.
Og síðasta æfingin sem mig langar að tala um er æfing sem er mjög, mjög tengd skýjum. Og það hefur hámarksáhrif ef þú vinnur í skýinu. Þetta er sjálfvirk fjarlæging á umhverfi þínu.
Ég veit að það eru nokkrir á þessari ráðstefnu úr teymunum sem ég vinn með. Og með öllum liðunum sem ég vinn með notum við þessa æfingu.
Hvers vegna? Auðvitað væri frábært ef hver þróunaraðili ætti sýndarvél sem myndi vinna 24/7. En kannski eru þetta fréttir fyrir þig, kannski tókstu ekki eftir, en verktaki sjálfur vinnur ekki 24/7. Verktaki vinnur venjulega 8 tíma á dag. Jafnvel þótt hann komi snemma í vinnuna, þá borðar hann stóran hádegisverð þar sem hann fer í ræktina. Láttu það vera 12 klukkustundir á dag þegar verktaki notar þessar auðlindir í raun. Samkvæmt lögum okkar höfum við 5 af 7 dögum í viku sem teljast virkir dagar.
Samkvæmt því ætti þessi vél ekki að virka 24 tíma á virkum dögum, heldur aðeins 12, og um helgar ætti þessi vél alls ekki að virka. Það virðist sem allt sé mjög einfalt, en hvað er mikilvægt að segja hér? Með því að innleiða þessa einföldu æfingu á þessari grunnáætlun gerir það þér kleift að draga úr kostnaði við að viðhalda þessu umhverfi um 70%, þ.e.a.s. þú tókst verðið á dev, QA, kynningu, umhverfi og deildir því með 3.
Spurningin er, hvað á að gera við afganginn af peningunum? Til dæmis ættu verktaki að kaupa ReSharper ef þeir hafa ekki gert það nú þegar. Eða halda kokteilboð. Ef þú varst áður með eitt umhverfi þar sem bæði dev og QA beit, og það er það, núna geturðu búið til 3 mismunandi sem verða einangruð og fólk mun ekki trufla hvert annað.
Varðandi glæruna með stöðugri frammistöðumælingu, hvernig getum við borið saman árangur ef við værum með 1 færslur í gagnagrunninum í verkefninu, tveimur mánuðum síðar eru þær milljón? Hvernig á að skilja hvers vegna og hvað er tilgangurinn með því að mæla árangur?
Þetta er góð spurning, því þú ættir alltaf að mæla árangur á sömu auðlindum. Það er, þú rúllar út nýjum kóða, þú mælir frammistöðu á nýja kóðanum. Til dæmis þarftu að prófa mismunandi frammistöðusviðsmyndir, segjum að þú viljir prófa hvernig forritið virkar á léttu álagi, þar sem notendur eru 1 og stærð gagnagrunnsins er 000 gígabæt. Þú mældir það og fékkst tölurnar. Næst tökum við aðra atburðarás. Til dæmis, 5 notendur, gagnagrunnsstærð 5 terabæti. Við fengum niðurstöðurnar og minntumst þeirra.
Hvað er mikilvægt hér? Það sem skiptir máli hér er að eftir atburðarásinni, gagnamagninu, fjölda notenda samtímis osfrv., gætirðu lent í ákveðnum mörkum. Til dæmis, að mörkum netkorts, eða að mörkum harða disksins, eða að mörkum örgjörva. Þetta er það sem er mikilvægt fyrir þig að skilja. Í mismunandi atburðarás lendir þú á ákveðnum mörkum. Og þú þarft að skilja tölurnar þegar þú smellir á þær.
Erum við að tala um að mæla árangur í sérstöku prófunarumhverfi? Semsagt, þetta er ekki framleiðsla?
Já, þetta er ekki framleiðsla, þetta er prófunarumhverfi, sem er alltaf það sama svo hægt sé að bera það saman við fyrri mælingar.
Skil þig takk!
Ef það eru engar spurningar held ég að við getum klárað. Þakka þér fyrir!
Heimild: www.habr.com