ProHoster > Blogs > Administrācija > Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Ziņojumā tiks runāts par dažām DevOps praksēm, taču no izstrādātāja viedokļa. Parasti visiem inženieriem, kas pievienojas DevOps, jau ir vairāku gadu administratÄ«vā pieredze. Bet tas nenozÄ«mē, ka Å”eit nav vietas izstrādātājam. Biežāk izstrādātāji ir aizņemti ar "nākamās steidzami kritiskās dienas kļūdas" novērÅ”anu, un viņiem nav laika pat ātri apskatÄ«t DevOps lauku. Autora izpratnē DevOps, pirmkārt, ir veselais saprāts. Otrkārt, tā ir iespēja bÅ«t efektÄ«vākam. Ja esat izstrādātājs, jums ir veselais saprāts un vēlaties bÅ«t efektÄ«vāks kā komandas spēlētājs, Å”is pārskats ir paredzēts jums.

Ä»aujiet man iepazÄ«stināt ar sevi, es pilnÄ«bā atzÄ«stu, ka telpā ir cilvēki, kas mani nepazÄ«st. Mani sauc Antons Boiko, es esmu Microsoft Azure MVP. Kas ir MVP? Å is ir modeļa skata prezentētājs. Model-View-Presenter esmu tieÅ”i es.

Turklāt Å”obrÄ«d uzņēmumā Ciklum ieņemu risinājumu arhitekta amatu. Un pavisam nesen nopirku sev tik skaistu domēnu un atjaunināju savu e-pastu, ko parasti rādu prezentācijās. Varat man rakstÄ«t uz: me [suns] byokoant.pro. Ar jautājumiem varat man sÅ«tÄ«t e-pastu. Es parasti viņiem atbildu. VienÄ«gais, es nevēlos saņemt pa e-pastu jautājumus, kas attiecas uz divām tēmām: politiku un reliÄ£iju. Par visu pārējo varat man rakstÄ«t pa e-pastu. Paies kāds laiks, atbildÄ“Å”u.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Daži vārdi par sevi:

  • Esmu Å”ajā jomā jau 10 gadus.
  • Es strādāju Microsoft.
  • Es esmu Ukrainas debeszils kopienas dibinātājs, kuru mēs nodibinājām kaut kur 2014. gadā. Un mums tas joprojām ir un mēs to attÄ«stām.
  • Es esmu arÄ« Azure konferences dibinātāja tēvs, kuru mēs rÄ«kojam Ukrainā.
  • Es arÄ« palÄ«dzu organizēt Global Azure Bootcamp Kijevā.
  • Kā jau teicu, es esmu Microsoft Azure MVP.
  • Es diezgan bieži uzstājos konferencēs. Man ļoti patÄ«k runāt konferencēs. Pēdējā gada laikā es varēju uzstāties apmēram 40 reizes. Ja jÅ«s ejat garām Ukrainai, Baltkrievijai, Polijai, Bulgārijai, Zviedrijai, Dānijai, NÄ«derlandei, Spānijai vai dodat vai paņemat kādu citu valsti Eiropā, tad ir pilnÄ«gi iespējams, ka, dodoties uz konferenci, kuras plÅ«smā ir mākoņa tēma, jÅ«s varat redzēt mani runātāju sarakstā.
  • Esmu arÄ« Star Trek fane.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Parunāsim nedaudz par darba kārtību. Mūsu darba kārtība ir ļoti vienkārŔa:

  • Mēs runāsim par to, kas ir DevOps. Parunāsim, kāpēc tas ir svarÄ«gi. IepriekÅ” DevOps bija atslēgvārds, kuru ierakstÄ«jāt savā CV un uzreiz saņēmāt algu +500$. Tagad CV jāieraksta, piemēram, blockchain, lai pie algas saņemtu +500 dolārus.
  • Un tad, kad mēs mazliet sapratÄ«sim, kas tas ir, mēs runāsim par to, kas ir DevOps prakse. Bet ne tik daudz DevOps kontekstā kopumā, bet gan par tām DevOps praksēm, kas varētu interesēt izstrādātājus. Es jums pastāstÄ«Å”u, kāpēc tie varētu jÅ«s interesēt. Es jums pastāstÄ«Å”u, kāpēc jums tas vispār jādara un kā tas var palÄ«dzēt jums izjust mazāk sāpju.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Tradicionāla bilde, ko rāda daudzi. Tā tas notiek daudzos projektos. Å ajā gadÄ«jumā mums ir izstrādes un darbÄ«bas nodaļas, kas atbalsta mÅ«su programmatÅ«ru. Un Ŕīs nodaļas savā starpā nekomunicē.

VarbÅ«t, ja jÅ«s to nevarējāt tik skaidri izjust DevOps un operāciju nodaļās, varat izdarÄ«t analoÄ£iju ar Dev un QA departamentiem. Ir cilvēki, kas izstrādā programmatÅ«ru, un ir QA cilvēki, kuri ir slikti no izstrādātāju viedokļa. Piemēram, es ievietoju savu brÄ«niŔķīgo kodu repozitorijā, un tur sēž kāds nelietis, kurÅ” atdod man Å”o kodu un saka, ka jÅ«su kods ir slikts.

Tas viss notiek tāpēc, ka cilvēki nesazinās viens ar otru. Un viņi izmet viens otram kaut kādas pakas, kādu aplikāciju cauri kaut kādai pārpratuma sienai un mēģina ar tām kaut ko darīt.

TieÅ”i Ŕīs sienas iznÄ«cināŔanai ir paredzēta DevOps kultÅ«ra, t.i. likt cilvēkiem sazināties vienam ar otru un vismaz saprast, ko dara dažādi cilvēki projektā un kāpēc viņu darbs ir svarÄ«gs.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Un, kad mēs runājam par DevOps, kāds jums pateiks, ka DevOps ir tad, kad projektā ir nepārtraukta integrācija; kāds teiks, ka DevOps ir, ja projektā tiek Ä«stenota ā€œinfrastruktÅ«ras kā kodaā€ prakse; kāds teiks, ka pirmais solis uz DevOps ir funkciju sazaroÅ”ana, funkciju karodziņi.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

BÅ«tÄ«bā tas viss ir taisnÄ«ba savā veidā. Bet tā ir tikai labākā prakse, kas mums ir. Pirms pāriet pie Ŕīm praksēm, iesaku apskatÄ«t Å”o slaidu, kurā parādÄ«ti 3 Dev-Ops metodoloÄ£ijas ievieÅ”anas posmi jÅ«su projektā, jÅ«su uzņēmumā.

Å im slaidam ir arÄ« otrs neoficiāls nosaukums. Varat meklēt tieÅ”saistē, lai uzzinātu, kas ir 3 DevOps musketieri. Iespējams, ka jÅ«s atradÄ«sit Å”o rakstu. Kāpēc 3 musketieri? Zemāk ir rakstÄ«ts: cilvēki, procesi un produkti, t.i. PPP ā€“ Portosa, Portosa un Portosa. Å eit ir 3 DevOps musketieri. Å ajā rakstā ir sÄ«kāk aprakstÄ«ts, kāpēc tas ir svarÄ«gi un ko tas ietver.

Kad sākat ieviest DevOps kultūru, ir ļoti svarīgi, lai tā tiktu ieviesta Ŕādā secībā.

Sākumā jums ir jārunā ar cilvēkiem. Un jums ir jāpaskaidro cilvēkiem, kas tas ir un kā viņi no tā var gūt labumu.

MÅ«su konferences nosaukums ir DotNet Fest. Un, kā man stāstÄ«ja organizatori, mēs Å”eit galvenokārt aicinājām izstrādātāju auditoriju, tāpēc es ceru, ka lielākā daļa zālē esoÅ”o cilvēku ir iesaistÄ«ti attÄ«stÄ«bā.

Mēs runāsim par cilvēkiem, mēs runāsim par to, ko izstrādātāji vēlas darīt katru dienu. Ko viņi visvairāk vēlas? Viņi vēlas uzrakstīt jaunu kodu, izmantot jaunus ietvarus, izveidot jaunas funkcijas. Ko izstrādātāji vēlas vismazāk? Izlabojiet vecās kļūdas. Es ceru, ka jūs man piekrītat. Tas ir tas, ko vēlas izstrādātāji. Viņi vēlas rakstīt jaunas funkcijas, viņi nevēlas labot kļūdas.

Konkrēta izstrādātāja radīto kļūdu skaits ir atkarīgs no tā, cik taisnas ir viņa rokas un cik tās izaug no pleciem, nevis no dibena kabatām. Taču, neskatoties uz to, kad mums ir liels projekts, dažreiz gadās, ka nav iespējams visam izsekot, tāpēc būtu jauki, ja mēs izmantotu dažas pieejas, kas palīdzēs mums uzrakstīt stabilāku un kvalitatīvāku kodu.

Ko QA vēlas visvairāk? Es nezinu, vai viņi ir zālē. Man ir grÅ«ti pateikt, ka es vēlos QA, jo nekad neesmu tāda bijusi. Un neapvainojiet puiÅ”us, teiks, ka es ceru, ka nekad. Bet ne tāpēc, ka uzskatu viņu darbu par bezjēdzÄ«gu un bezjēdzÄ«gu, bet gan tāpēc, ka neuzskatu sevi par cilvēku, kas Å”o darbu varētu paveikt efektÄ«vi, tāpēc pat nemēģināŔu to darÄ«t. Bet, kā es saprotu, QA visvairāk nepatÄ«k iet strādāt no rÄ«tiem, pastāvÄ«gi veikt kaut kādus regresijas testus, uzkāpt uz tām paŔām kļūdām, par kurām viņi ziņoja izstrādātājiem pirms 3 sprintiem un sakot: "Kad jÅ«s to darÄ«sit , Monsieur D 'Artanjan, izlabojiet Å”o kļūdu. Un Monsieur D'Artanjan viņam atbild: "Jā, jā, jā, es jau to izlaboju." Un kā tas notiek, ka es izlaboju vienu kļūdu un pa ceļam uztaisÄ«ju 5.

Cilvēki, kas atbalsta Å”o risinājumu ražoÅ”anā, vēlas, lai Å”is risinājums darbotos bez kļūdām, lai viņiem nebÅ«tu jāpārstartē serveris katru piektdienu, kad visi normāli cilvēki dodas uz bāru. Izstrādātāji izvietoja piektdien, administratori sēž lÄ«dz sestdienai, cenÅ”oties Å”o izvietoÅ”anu sakārtot un salabot.

Un, paskaidrojot cilvēkiem, ka viņi ir vērsti uz to paÅ”u problēmu risināŔanu, varat pāriet uz procesu formalizÄ“Å”anu. Tas ir ļoti svarÄ«gi. Kāpēc? Jo, kad mēs sakām ā€œformalizācijaā€, jums ir svarÄ«gi aprakstÄ«t, kā jÅ«su procesi notiek vismaz kaut kur uz salvetes. Jums jāsaprot, ka, piemēram, izvietojot QA vidē vai ražoÅ”anas vidē, tas vienmēr notiek Ŕādā secÄ«bā; Å”ajos posmos mēs veicam, piemēram, automātiskos vienÄ«bu testus un lietotāja saskarnes testus. Pēc izvietoÅ”anas mēs pārbaudām, vai izvietoÅ”ana noritēja labi vai slikti. Taču jums jau ir skaidrs darbÄ«bu saraksts, kuras ir jāatkārto atkal un atkal, kad izvietojat ražoÅ”anu.

Un tikai tad, kad jÅ«su procesi ir formalizēti, jÅ«s sākat izvēlēties produktus, kas palÄ«dzēs automatizēt Å”os procesus.

Diemžēl es ļoti bieži redzu, ka tas notiek otrādi. TiklÄ«dz kāds dzird vārdu ā€œDevOpsā€, viņŔ nekavējoties iesaka instalēt Jenkins, jo uzskata, ka, tiklÄ«dz viņi instalēs Jenkins, viņiem bÅ«s DevOps. Viņi instalēja Dženkinsu, izlasÄ«ja rakstus ā€œKāā€ Dženkinsa vietnē, mēģināja iebāzt procesus Å”ajos ā€œKāā€ rakstos, un tad nāca pie cilvēkiem un salieca cilvēkus, sakot, ka grāmatā teikts, ka tas jādara Ŕādi. tāpēc mēs to darām Ŕādā veidā.

Nav tā, ka Dženkinss ir slikts instruments. Es to nekādā veidā nedomāju teikt. Bet tas ir tikai viens no produktiem. Un kuru produktu izmantot, tam vajadzētu bÅ«t jÅ«su pēdējam lēmumam un nekādā gadÄ«jumā ne pirmajam. JÅ«su produktu nedrÄ«kst virzÄ«t kultÅ«ras un pieeju Ä«stenoÅ”ana. To ir ļoti svarÄ«gi saprast, tāpēc es pavadu tik daudz laika pie Ŕī slaida un tik ilgi to visu skaidroju.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Parunāsim par DevOps praksi kopumā. Kas viņi ir? Kāda ir atŔķirÄ«ba? Kā tās pielaikot? Kāpēc tie ir svarÄ«gi?

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Pirmā prakse, par kuru jūs, iespējams, dzirdējāt, tiek saukta par nepārtrauktu integrāciju. Varbūt kādam projekta dalībniekam ir nepārtraukta integrācija (CI).

Lielākā problēma ir tā, ka visbiežāk, kad es jautāju cilvēkam: "Vai jums projektā ir CI?" un viņŔ saka: ā€œJāā€, tad, kad es jautāju, ko viņŔ dara, viņŔ man apraksta pilnÄ«gi visu automatizācijas procesu. Tā nav gluži taisnÄ«ba.

Faktiski CI prakse ir tikai vērsta uz dažādu cilvēku rakstÄ«tā koda integrÄ“Å”anu kaut kādā vienotā koda bāzē. Tas ir viss.

Kopā ar CI parasti tiek izmantotas arÄ« citas metodes, piemēram, nepārtraukta izvietoÅ”ana, izlaiÅ”anas pārvaldÄ«ba, taču mēs par to runāsim vēlāk.

Pati CI mums saka, ka kodu raksta dažādi cilvēki, un Å”is kods ir nepārtraukti jāintegrē vienā koda bāzē.

Ko tas mums dod un kāpēc tas ir svarīgi? Ja mums ir DotNet, tad tas ir labi, tā ir kompilēta valoda, mēs varam apkopot savu lietojumprogrammu. Ja tas apkopo, tad tā jau ir laba zīme. Tas vēl neko nenozīmē, bet tā ir pirmā labā zīme, ko varam vismaz apkopot.

Pēc tam mēs varam veikt dažus testus, kas arÄ« ir atseviŔķa prakse. Pārbaudes ir zaļas ā€“ tā ir otrā labā zÄ«me. Bet atkal tas neko nenozÄ«mē.

Bet kāpēc jÅ«s to darÄ«tu? Visām praksēm, par kurām es Å”odien runāŔu, ir aptuveni tāda pati vērtÄ«ba, t.i., aptuveni vienādas priekÅ”rocÄ«bas, un tās arÄ« tiek mērÄ«tas aptuveni vienādi.

Pirmkārt, tas ļauj paātrināt piegādi. Kā tas ļauj paātrināt piegādi? Kad mēs veicam dažas jaunas izmaiņas mÅ«su kodu bāzē, mēs varam nekavējoties mēģināt kaut ko darÄ«t ar Å”o kodu. Mēs negaidām, lÄ«dz pienāks ceturtdiena, jo ceturtdien mēs to izlaižam QA Environment, mēs to darām tieÅ”i Å”eit un tieÅ”i Å”eit.

Es jums pastāstÄ«Å”u vienu skumju stāstu no savas dzÄ«ves. Tas bija sen, kad es vēl biju jauna un izskatÄ«ga. Tagad esmu jau jauna, skaista un gudra, un pieticÄ«ga. Pirms kāda laika es piedalÄ«jos projektā. Mums bija aptuveni 30 izstrādātāju liela komanda. Un mums bija liels, liels uzņēmuma projekts, kas attÄ«stÄ«jās apmēram 10 gadus. Un mums bija dažādas filiāles. Repozitorijā mums bija filiāle, kurā staigāja izstrādātāji. Un tur bija filiāle, kurā tika parādÄ«ta koda versija, kas tiek ražota.

RažoÅ”anas nozare par 3 mēneÅ”iem atpalika no izstrādātājiem pieejamās nozares. Ko tas nozÄ«mē? Tas nozÄ«mē, ka tiklÄ«dz man kaut kur ir kļūda, kas nonāk ražoÅ”anā izstrādātāju vainas dēļ, jo viņi to atļāva, un QA vainas dēļ, jo viņi to apskatÄ«ja, tad tas nozÄ«mē, ka, ja es saņemÅ”u uzdevums labojumfailam ražoÅ”anai, tad man ir jāatceļ pirms 3 mēneÅ”iem veiktās koda izmaiņas. Man jāatceras, kas man bija pirms 3 mēneÅ”iem, un jāmēģina to tur salabot.

Ja jums vēl nav Ŕādas pieredzes, varat to izmēģināt savā mājas projektā. Galvenais ir nemēģināt to komerciālā veidā. Uzrakstiet pāris koda rindiņas, aizmirstiet par tām uz seÅ”iem mēneÅ”iem un pēc tam atgriezieties un mēģiniet ātri izskaidrot, kas ir Ŕīs koda rindiņas un kā tās varat labot vai optimizēt. Tā ir ļoti, ļoti aizraujoÅ”a pieredze.

Ja mums ir nepārtrauktas integrācijas prakse, tad tas ļauj mums to pārbaudÄ«t ar vairākiem automatizētiem rÄ«kiem tieÅ”i Å”eit un tÅ«lÄ«t, tiklÄ«dz esmu uzrakstÄ«jis savu kodu. Tas var nesniegt man pilnÄ«gu priekÅ”statu, bet tomēr tas novērsÄ«s vismaz dažus riskus. Un, ja ir kāda potenciāla kļūda, es par to uzzināŔu tÅ«lÄ«t, tas ir, burtiski pēc pāris minÅ«tēm. Man nebÅ«s jāatgriež 3 mēneÅ”i. Man bÅ«s jāatgriež tikai 2 minÅ«tes. Labam kafijas automātam pat nebÅ«s laika pagatavot kafiju 2 minÅ«tēs, tāpēc tas ir diezgan forÅ”i.

Tam ir tāda vērtÄ«ba, ka to var atkārtot katru reizi katrā projektā, t.i. ne tikai tas, kurā to iestatÄ«jāt. Varat atkārtot gan paÅ”u praksi, gan arÄ« pati CI tiks atkārtota katrā jaunajā projektā veiktajā izmaiņā. Tas ļauj optimizēt resursus, jo jÅ«su komanda strādā efektÄ«vāk. Jums vairs nebÅ«s situācijas, kad kļūda rodas no koda, ar kuru strādājāt pirms 3 mēneÅ”iem. Jums vairs nebÅ«s konteksta maiņas, kad sēdēsit un pavadÄ«sit pirmās divas stundas, mēģinot saprast, kas tad notika, un iedziļināties konteksta bÅ«tÄ«bā, pirms sākat kaut ko labot.

Kā mēs varam novērtēt Ŕīs prakses panākumus vai neveiksmes? Ja jÅ«s ziņojat lielajam priekÅ”niekam, ko mēs Ä«stenojām CI projektā, viņŔ dzird bla bla bla. Mēs to ieviesām, labi, bet kāpēc, ko tas mums deva, kā mēs to izmērām, cik pareizi vai nepareizi mēs to Ä«stenojam?

Pirmais ir tas, ka, pateicoties CI, mēs varam izvietot arvien biežāk un biežāk tieÅ”i tāpēc, ka mÅ«su kods ir potenciāli stabilāks. Tādā paŔā veidā tiek samazināts mÅ«su laiks kļūdas atraÅ”anai un laiks Ŕīs kļūdas laboÅ”anai tiek samazināts tieÅ”i tāpēc, ka mēs saņemam atbildi no sistēmas tieÅ”i Å”eit un tÅ«lÄ«t, kas ir nepareizi ar mÅ«su kodu.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Vēl viena mÅ«su prakse ir automatizācijas testÄ“Å”anas prakse, kas visbiežāk nāk kopā ar CI praksi. Viņi iet roku rokā.

Kas Å”eit ir svarÄ«gi saprast? Ir svarÄ«gi saprast, ka mÅ«su testi ir atŔķirÄ«gi. Un katra automatizētā pārbaude ir vērsta uz savu problēmu risināŔanu. Mums ir, piemēram, vienÄ«bu testi, kas ļauj testēt moduli atseviŔķi, t.i. Kā tas darbojas vakuumā? Tas ir labi.

Mums ir arī integrācijas testi, kas ļauj saprast, kā dažādi moduļi integrējas viens ar otru. Tas ir arī labi.

Mums var būt UI automatizācijas testi, kas ļauj pārbaudīt, cik labi darbs ar UI atbilst noteiktām klienta izvirzītajām prasībām utt.

Konkrētie testi, kurus veicat, var ietekmēt to izpildes biežumu. Vienības testi parasti tiek rakstīti īsi un mazi. Un tos var palaist regulāri.

Ja mēs runājam par lietotāja interfeisa automatizācijas testiem, tad ir labi, ja jÅ«su projekts ir mazs. JÅ«su lietotāja interfeisa automatizācijas testi var aizņemt pietiekami daudz laika. Taču parasti lietotāja interfeisa automatizācijas pārbaude liela projekta Ä«stenoÅ”anai aizņem vairākas stundas. Un tas ir labi, ja tas ir dažas stundas. VienÄ«gais ir tas, ka nav jēgas tos palaist katrai bÅ«vei. Ir jēga tos palaist naktÄ«. Un, kad visi no rÄ«ta ieradās darbā: gan testētāji, gan izstrādātāji, viņi saņēma kaut kādu ziņojumu, ka mēs naktÄ« veicām lietotāja interfeisa automātisko testu un saņēmām Å”os rezultātus. Un Å”eit stunda servera, kurÅ” pārbaudÄ«s, vai jÅ«su produkts atbilst kaut kādām prasÄ«bām, bÅ«s daudz lētāks nekā tā paÅ”a QA inženiera darba stunda, pat ja tas ir Junior QA inženieris, kurÅ” strādā par pārtiku un paldies. Tomēr maŔīnas darbÄ«bas stunda bÅ«s lētāka. Tāpēc ir jēga tajā ieguldÄ«t.

Man ir vēl viens projekts, pie kura esmu strādājis. Mums bija divu nedēļu sprints Å”ajā projektā. Projekts bija liels, svarÄ«gs finanÅ”u sektoram, un kļūdu nevarēja pieļaut. Un pēc divu nedēļu sprinta izstrādes ciklam sekoja testÄ“Å”anas process, kas aizņēma vēl 4 nedēļas. Mēģiniet iedomāties traģēdijas mērogu. Mēs rakstām kodu divas nedēļas, pēc tam darām to Ala CodeFreeze, iepakojam to jaunā lietojumprogrammas versijā un izlaižam testētājiem. Testētāji to testē vēl 4 nedēļas, t.i. Kamēr viņi to testē, mums ir laiks sagatavot viņiem vēl divas versijas. Å is ir patieŔām bēdÄ«gs gadÄ«jums.

Un mēs viņiem teicām, ka, ja vēlaties bÅ«t produktÄ«vāks, ir lietderÄ«gi ieviest automatizētās testÄ“Å”anas praksi, jo tieÅ”i tas jums sāp tieÅ”i Å”eit, tieÅ”i tagad.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Praktizējiet nepārtrauktu izvietoÅ”anu. Lieliski, jÅ«s esat pabeidzis bÅ«vniecÄ«bu. Tas jau ir labi. JÅ«su kods ir apkopots. Tagad bÅ«tu jauki izvietot Å”o bÅ«vējumu kādā vidē. Teiksim izstrādātāju vidē.

Kāpēc tas ir svarÄ«gi? Pirmkārt, varat apskatÄ«t, cik veiksmÄ«gs jums ir pats izvietoÅ”anas process. Esmu sastapis Ŕādus projektus, kad jautāju: ā€œKā jÅ«s izvietojat jaunu aplikācijas versiju?ā€, puiÅ”i man saka: ā€œMēs to samontējam un iesaiņojam zip arhÄ«vā. NosÅ«tām adminam pa pastu. Administrators lejupielādē un izvērÅ” Å”o arhÄ«vu. Un viss birojs sāk lÅ«gties, lai serveris uzņemtu jauno versiju.

Sāksim ar kaut ko vienkārÅ”u. Piemēram, viņi aizmirsa arhÄ«vā ievietot CSS vai aizmirsa mainÄ«t tēmturi java-script faila nosaukumā. Un, kad mēs iesniedzam pieprasÄ«jumu serverim, pārlÅ«kprogramma uzskata, ka tai jau ir Å”is java-script fails, un nolemj to nelejupielādēt. Un bija veca versija, kaut kā pietrÅ«ka. Kopumā var bÅ«t daudz problēmu. Tāpēc nepārtrauktās izvietoÅ”anas prakse ļauj vismaz pārbaudÄ«t, kas notiktu, ja uzņemtu tÄ«ru atsauces attēlu un augÅ”upielādētu to pilnÄ«gi tÄ«rā jaunā vidē. JÅ«s varat redzēt, kur tas noved.

Tāpat, integrējot kodu savā starpā, t.i. starp komandu, tas ļauj arī redzēt, kā tā izskatās lietotāja saskarnē.

Viena no problēmām, kas rodas, ja tiek izmantots daudz vaniļas java skriptu, ir tas, ka divi izstrādātāji loga objektā nepārdomāti deklarēja mainÄ«go ar tādu paÅ”u nosaukumu. Un tad, atkarÄ«bā no jÅ«su veiksmes. Kura java skripta fails tiek izvilkts otrais, tas pārrakstÄ«s otra faila izmaiņas. Tas ir arÄ« ļoti aizraujoÅ”i. Tu ienāc: viena lieta der vienam, cita neder citam. Un tas ir ā€œbrÄ«niŔķīgiā€, kad tas viss tiek izdots ražoÅ”anā.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Nākamā mÅ«su prakse ir automātiskās atjaunoÅ”anas prakse, proti, atgrieÅ”anās pie iepriekŔējās lietojumprogrammas versijas.

Kāpēc tas ir svarīgi izstrādātājiem? Joprojām ir tādi, kas atceras tālos, tālos 90. gadus, kad datori bija lieli un programmas mazas. Un vienīgais veids, kā izstrādāt tīmekļa vietni, bija PHP. Nav tā, ka PHP ir slikta valoda, lai gan tā ir.

Bet problēma bija cita. Kad mēs izvietojām jaunu php vietnes versiju, kā mēs to izvietojām? Visbiežāk mēs atvērām Far Manager vai ko citu. Un augÅ”upielādēja Å”os failus FTP. Un mēs pēkŔņi sapratām, ka mums ir kāda maza, maza kļūda, piemēram, mēs aizmirsām ievietot semikolu vai aizmirsām nomainÄ«t datu bāzes paroli, un ir datu bāzes parole, kas atrodas vietējā resursdatorā. Un mēs nolemjam ātri izveidot savienojumu ar FTP un rediģēt failus tieÅ”i tur. Å Ä« ir tikai uguns! Tas bija populārs 90. gados.

Bet, ja neesat skatÄ«jies kalendārā, 90. gadi bija gandrÄ«z pirms 30 gadiem. Tagad viss notiek mazliet savādāk. Un mēģiniet iztēloties traģēdijas mērogu, kad viņi jums saka: ā€œMēs izvērsām ražoÅ”anu, taču tur kaut kas nogāja greizi. Å eit ir jÅ«su FTP pieteikumvārds un parole, izveidojiet savienojumu ar ražoÅ”anu un ātri izlabojiet to. Ja jÅ«s esat Čaks Noriss, tas darbosies. Ja nē, tad jÅ«s riskējat, ka, izlabojot vienu kļūdu, jÅ«s izveidosit vēl 10. TieÅ”i tāpēc Ŕī prakse atgriezties pie iepriekŔējās versijas ļauj sasniegt daudz.

Pat ja kaut kas slikts kaut kur ir iekļuvis prod, tad tas ir slikti, bet ne letāli. Varat atgriezties pie iepriekŔējās versijas. Sauciet to par rezerves kopiju, ja to ir vieglāk uztvert Å”ajā terminoloÄ£ijā. Varat atgriezties pie Ŕīs iepriekŔējās versijas, un lietotāji joprojām varēs strādāt ar jÅ«su produktu, un jums bÅ«s pietiekams bufera laiks. Varat to visu mierÄ«gi, bez steigas paņemt un pārbaudÄ«t lokāli, salabot un pēc tam augÅ”upielādēt jaunu versiju. Tas patieŔām ir jēga to darÄ«t.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Tagad mēģināsim kaut kā apvienot abas iepriekŔējās prakses kopā. Mēs iegÅ«sim treÅ”o ar nosaukumu Release Management.

Kad mēs runājam par nepārtrauktu izvietoÅ”anu tās klasiskajā formā, mēs sakām, ka mums ir jāizvelk kods no kādas filiāles no repozitorija, tas jāapkopo un jāizvieto. Ir labi, ja mums ir vienāda vide. Ja mums ir vairākas vides, tas nozÄ«mē, ka mums katru reizi ir jāizvelk kods, pat no vienas un tās paÅ”as darbÄ«bas. Mēs to izvilksim katru reizi, mēs to uzbÅ«vēsim katru reizi un izvietosim jaunā vidē. Pirmkārt, Å”is ir laiks, jo, lai izveidotu projektu, ja jums ir liels un nācis no 90. gadiem, tas var aizņemt vairākas stundas.

Turklāt ir vēl viens skumjas. Kad veidosiet pat tajā paŔā maŔīnā, veidosiet tos paÅ”us avotus, jums joprojām nav garantijas, ka Ŕī iekārta ir tādā paŔā stāvoklÄ«, kādā tā bija pēdējās bÅ«ves laikā.

Pieņemsim, ka kāds ieradās un atjaunināja DotNet jÅ«su vietā vai, gluži pretēji, kāds nolēma kaut ko izdzēst. Un tad jums ir kognitÄ«vā disonanse, ka no Ŕīs saistÄ«bas pirms divām nedēļām mēs veidojām bÅ«vniecÄ«bu un viss bija kārtÄ«bā, bet tagad Ŕķiet, ka tā pati maŔīna, tā pati commit, tas pats kods, ko mēs cenÅ”amies izveidot, bet tas nedarbojas. . JÅ«s ar to saskarsities ilgu laiku, un tas nav fakts, ka jÅ«s to izdomāsit. Vismaz jÅ«s ļoti sabojāsit savus nervus.

Tāpēc laidienu pārvaldības prakse iesaka ieviest papildu abstrakciju, ko sauc par artefaktu krātuvi vai galeriju vai bibliotēku. Jūs varat to saukt, kā vēlaties.

Galvenā ideja ir tāda, ka, tiklÄ«dz mums ir kaut kāda veida commit tur, teiksim, filiālē, kuru mēs esam gatavi izvietot savās dažādās vidēs, mēs apkopojam lietojumprogrammas no Ŕīs saistÄ«bas un visu, kas nepiecieÅ”ams Å”ai lietojumprogrammai, mēs to iesaiņojam. zip arhÄ«vā un saglabājiet to uzticamā krātuvē. Un no Ŕīs krātuves mēs varam iegÅ«t Å”o zip arhÄ«vu jebkurā laikā.

Pēc tam mēs to ņemam un automātiski izvietojam izstrādātāja vidē. Mēs tur braucam, un, ja viss ir labi, tad izvietojamies uz skatuves. Ja viss ir kārtÄ«bā, tad mēs izvietojam to paÅ”u arhÄ«vu ražoÅ”anā, tos paÅ”us bināros failus, kas apkopoti tieÅ”i vienu reizi.

Turklāt, ja mums ir Ŕāda galerija, tā arÄ« palÄ«dz mums novērst riskus, par kuriem mēs runājām pēdējā slaidā, kad runājām par atgrieÅ”anu uz iepriekŔējo versiju. Ja nejauÅ”i izvietojāt kaut ko nepareizi, vienmēr varat paņemt jebkuru citu iepriekŔējo versiju no Ŕīs galerijas un atsaukt to Å”ajās vidēs tādā paŔā veidā. Tas ļauj viegli atgriezties pie iepriekŔējās versijas, ja kaut kas noiet greizi.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Ir vēl viena lieliska prakse. Mēs visi saprotam, ka, atgriežot savas lietojumprogrammas uz iepriekŔējo versiju, tas var nozÄ«mēt, ka mums ir nepiecieÅ”ama arÄ« iepriekŔējās versijas infrastruktÅ«ra.

Kad mēs runājam par virtuālo infrastruktÅ«ru, daudzi cilvēki domā, ka tas ir kaut kas tāds, ko iestata administratori. Un, ja jums ir nepiecieÅ”ams, teiksim, iegÅ«t jaunu serveri, kurā vēlaties pārbaudÄ«t jaunu savas lietojumprogrammas versiju, jums ir jāuzraksta biļete administratoriem vai devops. Devops tam bÅ«s nepiecieÅ”amas 3 nedēļas. Un pēc 3 nedēļām viņi jums pateiks, ka esam jums instalējuÅ”i virtuālo maŔīnu ar vienu kodolu, diviem gigabaitiem RAM un Windows serveri bez DotNet. JÅ«s sakāt: "Bet es gribēju DotNet." Viņi: "Labi, atgriezieties pēc 3 nedēļām."

Ideja ir tāda, ka, izmantojot infrastruktūru kā kodu, jūs varat uzskatīt savu virtuālo infrastruktūru tikai par citu resursu.

Iespējams, ja kāds no jums izstrādā lietojumprogrammas vietnē DotNet, iespējams, esat dzirdējis par bibliotēku ar nosaukumu Entity Framework. Un jÅ«s, iespējams, pat esat dzirdējuÅ”i, ka Entity Framework ir viena no pieejām, ko Microsoft aktÄ«vi virza. Darbam ar datu bāzi Ŕī ir pieeja, ko sauc par Code First. Tas ir tad, kad kodā aprakstāt, kā vēlaties izskatÄ«ties jÅ«su datu bāzei. Un tad jÅ«s izvietojat lietojumprogrammu. Tas pieslēdzas datu bāzei, pats nosaka, kuras tabulas ir un kuras nav, un izveido visu nepiecieÅ”amo.

JÅ«s varat darÄ«t to paÅ”u ar savu infrastruktÅ«ru. Nav atŔķirÄ«bas starp to, vai projektam ir nepiecieÅ”ama datu bāze vai projektam ir nepiecieÅ”ams Windows serveris. Tas ir tikai resurss. Un jÅ«s varat automatizēt Ŕī resursa izveidi, jÅ«s varat automatizēt Ŕī resursa konfigurāciju. AttiecÄ«gi katru reizi, kad vēlaties pārbaudÄ«t kādu jaunu koncepciju, jaunu pieeju, jums nebÅ«s jāraksta biļete uz devops, jÅ«s varat vienkārÅ”i izvietot izolētu infrastruktÅ«ru sev no gatavām veidnēm, no gataviem skriptiem un to ieviest. tur ir visi jÅ«su eksperimenti. Varat to izdzēst, iegÅ«t dažus rezultātus un ziņot par to tālāk.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Nākamā prakse, kas arī pastāv un ir arī svarīga, bet kuru izmanto tikai daži cilvēki, ir lietojumprogrammu veiktspējas uzraudzība.

Es gribēju teikt tikai vienu lietu par lietojumprogrammu veiktspējas uzraudzÄ«bu. Kas Å”ajā praksē ir vissvarÄ«gākais? Lietojumprogrammu veiktspējas uzraudzÄ«ba ir aptuveni tas pats, kas dzÄ«vokļa remonts. Tas nav galÄ«gais stāvoklis, tas ir process. Jums tas jādara regulāri.

Labā nozÄ«mē bÅ«tu labi veikt lietojumprogrammu veiktspējas uzraudzÄ«bu gandrÄ«z katrā versijā, lai gan, kā jÅ«s saprotat, tas ne vienmēr ir iespējams. Bet vismaz tas ir jāveic katrai izlaiÅ”anai.

Kāpēc tas ir svarÄ«gi? Jo, ja pēkŔņi rodas veiktspējas kritums, tad jums ir skaidri jāsaprot, kāpēc. Ja jÅ«su komandai ir, teiksim, divu nedēļu sprints, tad vismaz reizi divās nedēļās jums vajadzētu izvietot savu lietojumprogrammu kādā atseviŔķā serverÄ«, kur jums ir skaidri fiksēts procesors, RAM, diski utt. Un palaist tos paÅ”us veiktspējas testus. . JÅ«s saņemat rezultātu. Skatiet, kā tas ir mainÄ«jies salÄ«dzinājumā ar iepriekŔējo sprinta laiku.

Un, ja uzzināsiet, ka izņemÅ”ana kaut kur strauji samazinājās, tas nozÄ«mēs, ka tas notika tikai pēdējo divu nedēļu laikā notikuÅ”o izmaiņu dēļ. Tas ļaus jums daudz ātrāk noteikt un novērst problēmu. Un atkal Å”ie ir aptuveni tie paÅ”i rādÄ«tāji, pēc kuriem varat novērtēt, cik veiksmÄ«gi jÅ«s to paveicāt.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Nākamā mūsu prakse ir konfigurācijas pārvaldības prakse. Ir ļoti maz tādu, kas to uztver nopietni. Bet ticiet man, tā patiesībā ir ļoti nopietna lieta.

Nesen bija smieklÄ«gs stāsts. PuiÅ”i pienāca pie manis un teica: "PalÄ«dziet mums veikt mÅ«su lietojumprogrammas droŔības auditu." Kopā ilgi skatÄ«jāmies kodu, stāstÄ«ja par aplikāciju, zÄ«mēja diagrammas. Un plus mÄ«nus viss bija loÄ£iski, saprotami, droÅ”i, bet bija viens BET! Viņu avota kontrolē bija konfigurācijas faili, tostarp tie, kas iegÅ«ti no ražoÅ”anas ar IP datu bāzi, ar pieteikumvārdiem un parolēm, lai izveidotu savienojumu ar Ŕīm datu bāzēm utt.

Un es saku: ā€œPuiÅ”i, labi, jÅ«s esat aizvēris savu ražoÅ”anas vidi ar ugunsmÅ«ri, bet tas, ka jums ir tieÅ”i avota vadÄ«klā un jebkurÅ” izstrādātājs var to izlasÄ«t, jau ir milzÄ«gs droŔības risks. . Un neatkarÄ«gi no tā, cik ļoti droÅ”a ir jÅ«su lietojumprogramma no koda viedokļa, ja atstājat to avota kontrolē, jÅ«s nekad nekur neizturēsit auditu. Tas ir tas par ko es runāju.

Konfigurācijas pārvaldÄ«ba. Mums var bÅ«t dažādas konfigurācijas dažādās vidēs. Piemēram, mums var bÅ«t dažādi pieteikumvārdi un paroles datu bāzēm kvalitātes nodroÅ”ināŔanai, demonstrācijai, ražoÅ”anas videi utt.

Å o konfigurāciju var arÄ« automatizēt. Tam vienmēr jābÅ«t atseviŔķi no paÅ”as lietojumprogrammas. Kāpēc? Tā kā lietojumprogrammu veidojāt vienreiz, un tad lietojumprogrammai ir vienalga, vai izveidojat savienojumu ar SQL serveri, izmantojot Ŕādu un tādu IP vai tādu un tādu IP, tai vajadzētu darboties tāpat. Tāpēc, ja pēkŔņi kāds no jums joprojām stingri iekodē savienojuma virkni kodā, atcerieties, ka es jÅ«s atradÄ«Å”u un sodÄ«Å”u, ja jÅ«s atradÄ«sities vienā projektā ar mani. Tas vienmēr tiek ievietots atseviŔķā konfigurācijā, piemēram, Web.config.

Un Ŕī konfigurācija jau tiek pārvaldÄ«ta atseviŔķi, t.i., tas ir tieÅ”i tas brÄ«dis, kad izstrādātājs un administrators var nākt un sēdēt vienā telpā. Un izstrādātājs var teikt: ā€œLÅ«k, Å”eit ir manas lietojumprogrammas binārie faili. Viņi strādā. Lai lietojumprogramma darbotos, nepiecieÅ”ama datu bāze. Å eit blakus binārajiem failiem ir fails. Å ajā failā Å”is lauks ir atbildÄ«gs par pieteikÅ”anos, tas ir par paroli, tas ir par IP. Izvietojiet to jebkur." Un tas ir vienkārÅ”i un skaidrs administratoram. Pārvaldot Å”o konfigurāciju, viņŔ to var izvietot jebkur.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Un pēdējā prakse, par kuru es vēlētos runāt, ir prakse, kas ir ļoti, ļoti saistÄ«ta ar mākoņiem. Un tas sniedz maksimālu efektu, ja strādājat mākonÄ«. Å Ä« ir jÅ«su vides automātiska noņemÅ”ana.

Es zinu, ka Å”ajā konferencē ir vairāki cilvēki no komandām, ar kurām es strādāju. Un ar visām komandām, ar kurām es strādāju, mēs izmantojam Å”o praksi.

Kāpēc? Protams, bÅ«tu lieliski, ja katram izstrādātājam bÅ«tu virtuālā maŔīna, kas strādātu 24/7. Bet varbÅ«t tas jums ir jaunums, iespējams, jÅ«s nepievērsāt uzmanÄ«bu, bet pats izstrādātājs nestrādā 24/7. Izstrādātājs parasti strādā 8 stundas dienā. Pat ja viņŔ nāk uz darbu agri, viņam ir lielas pusdienas, kuru laikā viņŔ dodas uz sporta zāli. Lai tās bÅ«tu 12 stundas dienā, kad izstrādātājs faktiski izmanto Å”os resursus. Saskaņā ar mÅ«su likumdoÅ”anu mums ir 5 no 7 dienām nedēļā, kas tiek uzskatÄ«tas par darba dienām.

AttiecÄ«gi darba dienās Å”ai maŔīnai nevajadzētu strādāt 24 stundas, bet tikai 12, un brÄ«vdienās Å”ai iekārtai nevajadzētu strādāt vispār. Å Ä·iet, ka viss ir ļoti vienkārÅ”i, bet ko Å”eit ir svarÄ«gi pateikt? IevieÅ”ot Å”o vienkārÅ”o praksi Å”ajā pamata grafikā, tas ļauj samazināt Å”o vidi uzturÄ“Å”anas izmaksas par 70%, t.i., jÅ«s paņēmāt sava izstrādātāja, kvalitātes nodroÅ”ināŔanas, demonstrācijas, vides cenu un dalÄ«jāt to ar 3.

Jautājums, ko darÄ«t ar atlikuÅ”o naudu? Piemēram, izstrādātājiem vajadzētu iegādāties ReSharper, ja viņi to vēl nav izdarÄ«juÅ”i. Vai arÄ« sarÄ«ko kokteiļu ballÄ«ti. Ja jums iepriekÅ” bija viena vide, kurā ganÄ«jās gan izstrādātājs, gan QA, un tas arÄ« viss, tagad varat izveidot 3 dažādas, kas bÅ«s izolētas un cilvēki netraucēs viens otram.

Labākā DevOps prakse izstrādātājiem. Antons Boiko (2017)

Runājot par slaidu ar nepārtrauktu veiktspējas mērÄ«Å”anu, kā mēs varam salÄ«dzināt veiktspēju, ja projektā datu bāzē bija 1 ierakstu, bet divus mēneÅ”us vēlāk ir miljons? Kā saprast, kāpēc un kāda ir veiktspējas mērÄ«Å”anas jēga?

Tas ir labs jautājums, jo vienmēr ir jāmēra veiktspēja ar tiem paÅ”iem resursiem. Tas nozÄ«mē, ka jÅ«s izlaižat jaunu kodu, novērtējat jaunā koda veiktspēju. Piemēram, jums ir jāpārbauda dažādi veiktspējas scenāriji, pieņemsim, ka vēlaties pārbaudÄ«t, kā lietojumprogramma darbojas ar nelielu slodzi, kur ir 1 lietotāju un datu bāzes izmērs ir 000 gigabaiti. JÅ«s to izmērÄ«jāt un saņēmāt skaitļus. Tālāk mēs pieņemam citu scenāriju. Piemēram, 5 lietotāju, datu bāzes izmērs 5 terabaits. Mēs saņēmām rezultātus un atcerējāmies tos.

Kas Å”eit ir svarÄ«gs? Å eit svarÄ«gi ir tas, ka atkarÄ«bā no scenārija, datu apjoma, vienlaicÄ«go lietotāju skaita utt. var rasties noteikti ierobežojumi. Piemēram, lÄ«dz tÄ«kla kartes ierobežojumam, vai lÄ«dz cietā diska ierobežojumam, vai lÄ«dz procesora iespēju robežai. Tas ir tas, kas jums ir svarÄ«gi saprast. Dažādos scenārijos jÅ«s saskaraties ar noteiktiem ierobežojumiem. Un jums ir jāsaprot skaitļi, kad tos trāpÄ«jat.

Vai mēs runājam par veiktspējas mērÄ«Å”anu Ä«paŔā testa vidē? Tas ir, tā nav ražoÅ”ana?

Jā, Ŕī nav ražoÅ”ana, tā ir testa vide, kas vienmēr ir vienāda, lai jÅ«s varētu to salÄ«dzināt ar iepriekŔējiem mērÄ«jumiem.

Sapratu paldies!

Ja nav jautājumu, es domāju, ka varam pabeigt. Paldies!

Avots: www.habr.com

Pievieno komentāru