Tatalakayin ng ulat ang ilang mga kasanayan sa DevOps, ngunit mula sa pananaw ng isang developer. Karaniwan, ang lahat ng mga inhinyero na sumali sa DevOps ay mayroon nang ilang taon ng karanasang pang-administratibo sa ilalim ng kanilang sinturon. Ngunit hindi ito nangangahulugan na walang lugar para sa developer dito. Mas madalas kaysa sa hindi, ang mga developer ay abala sa pag-aayos ng "susunod na agarang kritikal na bug ng araw," at wala silang oras upang tingnan ang field ng DevOps. Sa pang-unawa ng may-akda, ang DevOps ay, una, ang sentido komun. Pangalawa, ito ay isang pagkakataon upang maging mas epektibo. Kung ikaw ay isang developer, may sentido komun at gustong maging mas epektibo bilang isang team player, ang ulat na ito ay para sa iyo.
Let me introduce myself, I fully admit na may mga tao sa room na hindi ako kilala. Ang pangalan ko ay Anton Boyko, ako ay isang Microsoft Azure MVP. Ano ang MVP? Ito ay Model-View-Presenter. Eksaktong ako ang Model-View-Presenter.
Bilang karagdagan, kasalukuyang hawak ko ang posisyon ng arkitekto ng solusyon sa Ciklum. At kamakailan lang ay binili ko ang aking sarili ng napakagandang domain, at na-update ko ang aking email, na karaniwan kong ipinapakita sa mga presentasyon. Maaari kang sumulat sa akin sa: me [dog] byokoant.pro. Maaari mo akong i-email na may mga katanungan. Karaniwang sinasagot ko sila. Ang tanging bagay ay hindi ko gustong makatanggap ng mga tanong sa pamamagitan ng email na nauugnay sa dalawang paksa: pulitika at relihiyon. Maaari kang sumulat sa akin tungkol sa lahat ng iba pa sa pamamagitan ng email. Lumipas ang ilang oras, sasagutin ko.
Ang ilang mga salita tungkol sa aking sarili:
- 10 taon na ako sa larangang ito.
- Nagtrabaho ako sa Microsoft.
- Ako ang founding father ng Ukrainian Azure community, na itinatag namin sa isang lugar noong 2014. At mayroon pa rin tayo nito at pinapaunlad ito.
- Ako rin ang ama ng tagapagtatag ng kumperensya ng Azure, kung saan kami ay nagho-host sa Ukraine.
- Tumutulong din ako sa pag-aayos ng Global Azure Bootcamp sa Kyiv.
- Gaya ng sinabi ko, isa akong Microsoft Azure MVP.
- Madalas akong nagsasalita sa mga kumperensya. Gustung-gusto kong magsalita sa mga kumperensya. Sa nakalipas na taon nakapagtanghal ako ng halos 40 beses. Kung dumaan ka sa Ukraine, Belarus, Poland, Bulgaria, Sweden, Denmark, Netherlands, Spain o magbibigay o kumuha ng ibang bansa sa Europa, posible na kapag pumunta ka sa isang kumperensya na may paksa ng mga ulap sa stream nito , maaari mo akong makita sa listahan ng mga nagsasalita.
- Star Trek fan din ako.
Pag-usapan natin ng kaunti ang tungkol sa Agenda. Ang aming Agenda ay napaka-simple:
- Pag-uusapan natin kung ano ang DevOps. Pag-usapan natin kung bakit ito mahalaga. Dati, ang DevOps ay isang keyword na isinulat mo sa iyong resume at agad na nakatanggap ng +$500 na suweldo. Ngayon ay kailangan mong magsulat, halimbawa, blockchain sa iyong resume upang makakuha ng +500 dolyar sa iyong suweldo.
- At pagkatapos, kapag naunawaan natin nang kaunti kung ano ito, pag-uusapan natin kung ano ang mga kasanayan sa DevOps. Ngunit hindi gaanong sa konteksto ng DevOps sa pangkalahatan, ngunit tungkol sa mga kasanayan sa DevOps na maaaring interesado sa mga developer. Sasabihin ko sa iyo kung bakit maaari silang maging interesado sa iyo. Sasabihin ko sa iyo kung bakit mo dapat gawin ito at kung paano ito makakatulong sa iyong makaranas ng mas kaunting sakit.
Isang tradisyonal na larawan na ipinapakita ng maraming tao. Ito ang nangyayari sa maraming proyekto. Ito ay kapag mayroon kaming mga departamento ng pagpapaunlad at pagpapatakbo na sumusuporta sa aming software. At ang mga departamentong ito ay hindi nakikipag-usap sa isa't isa.
Marahil, kung hindi mo ito naramdaman nang malinaw sa mga departamento ng DevOps at pagpapatakbo, maaari kang gumuhit ng pagkakatulad sa mga departamento ng Dev at QA. May mga taong gumagawa ng software at may mga taong QA na masama sa pananaw ng mga developer. Halimbawa, ibinibigay ko ang aking kahanga-hangang code sa repositoryo, at mayroong ilang hamak na nakaupo doon na nagbabalik ng code na ito sa akin at nagsasabing masama ang iyong code.
Nangyayari ang lahat ng ito dahil ang mga tao ay hindi nakikipag-usap sa isa't isa. At itinapon nila ang ilang mga pakete, ilang aplikasyon sa isa't isa sa pamamagitan ng ilang pader ng hindi pagkakaunawaan at subukang gumawa ng isang bagay sa kanila.
Ito ay tiyak na pader na DevOps kultura ay dinisenyo upang sirain, i.e. pilitin ang mga tao na makipag-usap sa isa't isa at hindi bababa sa maunawaan kung ano ang ginagawa ng iba't ibang tao sa proyekto at kung bakit mahalaga ang kanilang trabaho.
At kapag pinag-uusapan natin ang tungkol sa DevOps, may magsasabi sa iyo na ang DevOps ay kapag ang proyekto ay may tuluy-tuloy na pagsasama; may magsasabi na ang DevOps ay kung ang proyekto ay nagpapatupad ng "imprastraktura bilang code" na kasanayan; may magsasabi na ang unang hakbang sa DevOps ay feature branching, feature flags.
Mahalaga, lahat ito ay totoo sa sarili nitong paraan. Ngunit ito lamang ang pinakahuling mga kasanayan na mayroon tayo. Bago magpatuloy sa mga kasanayang ito, iminumungkahi kong tingnan ang slide na ito, na nagpapakita ng 3 yugto ng pagpapatupad ng pamamaraan ng Dev-Ops sa iyong proyekto, sa iyong kumpanya.
Ang slide na ito ay mayroon ding pangalawang hindi opisyal na pangalan. Maaari kang maghanap online upang malaman kung ano ang 3 Musketeer ng DevOps. Posibleng mahanap mo ang artikulong ito. Bakit 3 Musketeers? Sa ibaba ay sinasabi nito: mga tao, proseso at produkto, i.e. PPP β Porthos, Porthos at Porthos. Narito ang 3 Musketeer ng DevOps. Inilalarawan ng artikulong ito nang mas detalyado kung bakit ito mahalaga at kung ano ang kasama nito.
Kapag sinimulan mong ipatupad ang isang kultura ng DevOps, napakahalaga na ipatupad ito sa sumusunod na pagkakasunud-sunod.
Sa una kailangan mong makipag-usap sa mga tao. At kailangan mong ipaliwanag sa mga tao kung ano ito at kung paano sila makakakuha ng ilang mga benepisyo mula dito.
Ang aming kumperensya ay tinatawag na DotNet Fest. At gaya ng sinabi sa akin ng mga tagapag-ayos, pangunahing nag-imbita kami ng madla ng mga developer dito, kaya umaasa ako na karamihan sa mga tao sa bulwagan ay kasangkot sa pag-unlad.
Pag-uusapan natin ang tungkol sa mga tao, pag-uusapan natin kung ano ang gustong gawin ng mga developer araw-araw. Ano ang pinaka gusto nila? Nais nilang magsulat ng ilang bagong code, gumamit ng mga bagong balangkas, lumikha ng mga bagong tampok. Ano ang gusto ng mga developer? Ayusin ang mga lumang bug. Sana sumang-ayon ka sa akin. Ito ang gusto ng mga developer. Gusto nilang magsulat ng mga bagong feature, ayaw nilang ayusin ang mga bug.
Ang bilang ng mga bug na nagagawa ng isang partikular na developer ay depende sa kung gaano katuwid ang kanyang mga braso at kung gaano kalaki ang mga ito mula sa kanyang mga balikat, at hindi mula sa kanyang mga bulsa sa puwitan. Ngunit gayunpaman, kapag mayroon kaming isang malaking proyekto, kung minsan ay nangyayari na imposibleng masubaybayan ang lahat, kaya't mas maganda para sa amin na gumamit ng ilang mga diskarte na makakatulong sa amin na magsulat ng mas matatag at mas mataas na kalidad ng code.
Ano ang pinaka gusto ng mga QA? Hindi ko alam kung nasa hall sila. Mahirap para sa akin na sabihin na gusto ko ng QA, dahil hindi pa ako naging isa. And no offense to the guys, sasabihin na sana hindi na lang. Ngunit hindi sa kadahilanang itinuturing kong walang kabuluhan at walang silbi ang kanilang gawain, ngunit dahil hindi ko itinuturing ang aking sarili na isang taong kayang gawin ang gawaing ito nang mahusay, kaya hindi ko na subukang gawin ito. Ngunit mula sa naiintindihan ko, ang pinaka ayaw ng QA ay gagana sa umaga, na patuloy na nagpapatakbo ng ilang uri ng mga pagsubok sa regression, na tinatapakan ang parehong mga bug na iniulat nila sa mga developer 3 sprint ang nakalipas at nagsasabing: βKailan ka , Monsieur D 'Artagnan, ayusin ang bug na ito.' At sinagot siya ni Monsieur D'Artagnan: "Oo, oo, oo, naayos ko na ito." At kung paano nangyari na naayos ko ang isang bug at gumawa ng 5 kasama ang paraan.
Gusto ng mga taong sumusuporta sa solusyong ito sa produksyon na gumana ang solusyong ito nang walang mga bug, nang sa gayon ay hindi nila kailangang i-reboot ang server tuwing Biyernes, kapag ang lahat ng normal na tao ay pumunta sa bar. Ang mga developer ay nag-deploy noong Biyernes, ang mga admin ay umupo hanggang Sabado, sinusubukang ayusin ang deployment na ito at ayusin.
At kapag ipinaliwanag mo sa mga tao na nilalayon nilang lutasin ang parehong mga problema, maaari kang magpatuloy sa pag-formalize ng mga proseso. Napakahalaga nito. Bakit? Dahil kapag sinabi nating "formalization," mahalagang ilarawan mo kung paano nangyayari ang iyong mga proseso kahit saan man lang sa isang napkin. Kailangan mong maunawaan na kung ikaw, halimbawa, ay nagde-deploy sa isang QA environment o isang production environment, palaging nangyayari ito sa ganitong pagkakasunud-sunod; sa mga yugtong ito ay tumatakbo kami, halimbawa, mga awtomatikong unit test at UI test. Pagkatapos ng deployment, tinitingnan namin kung naging maayos o hindi maganda ang deployment. Ngunit mayroon ka nang malinaw na listahan ng mga aksyon na dapat ulitin nang paulit-ulit kapag nag-deploy ka sa produksyon.
At kapag ang iyong mga proseso ay pormal na, magsisimula kang pumili ng mga produkto na makakatulong sa iyong i-automate ang mga prosesong ito.
Sa kasamaang palad, madalas kong nakikita itong nangyayari sa kabaligtaran. Sa sandaling may makarinig ng salitang "DevOps", agad nilang iminumungkahi ang pag-install ng Jenkins, dahil naniniwala sila na sa sandaling mag-install sila ng Jenkins, magkakaroon sila ng DevOps. Nag-install sila ng Jenkins, binasa ang mga artikulong "Paano" sa website ng Jenkins, sinubukang ilagay ang mga proseso sa mga artikulong ito na How to, at pagkatapos ay lumapit sa mga tao at yumuko ang mga tao, na nagsasabi na sinasabi ng aklat na kailangan mong gawin ito sa ganitong paraan, kaya ginagawa namin ito sa ganitong paraan.
Hindi naman masamang kasangkapan si Jenkins. Hindi ko ibig sabihin na sa anumang paraan. Ngunit ito ay isa lamang sa mga produkto. At kung aling produkto ang iyong gagamitin ang dapat mong huling desisyon, at hindi ito ang una mo. Ang iyong produkto ay hindi dapat hinihimok ng pagpapatupad ng kultura at mga diskarte. Napakahalagang maunawaan ito, kaya naman gumugugol ako ng napakaraming oras sa slide na ito at ipinapaliwanag ang lahat ng ito nang napakatagal.
Pag-usapan natin ang tungkol sa mga kasanayan sa DevOps sa pangkalahatan. Ano sila? Ano ang pagkakaiba? Paano subukan ang mga ito? Bakit sila mahalaga?
Ang unang kasanayan na maaaring narinig mo ay tinatawag na Continuous Integration. Marahil ang isang tao sa proyekto ay may Continuous Integration (CI).
Ang pinakamalaking problema ay madalas kapag tinatanong ko ang isang tao: "May CI ka ba sa proyekto?" at sinabi niya: "Oo," pagkatapos kapag tinanong ko kung ano ang ginagawa niya, inilalarawan niya sa akin ang buong proseso ng automation. Ito ay hindi ganap na totoo.
Sa katunayan, ang pagsasanay ng CI ay naglalayong isama lamang ang code na isinusulat ng iba't ibang tao sa ilang uri ng solong base ng code. Iyon lang.
Kasama ng CI, kadalasan ay may iba pang mga kasanayan sa daan - gaya ng Continuous Deployment, Release Management, ngunit pag-uusapan natin iyon mamaya.
Ang CI mismo ay nagsasabi sa amin na ang iba't ibang tao ay sumulat ng code at ang code na ito ay dapat na patuloy na isinama sa isang solong code base.
Ano ang ibinibigay nito sa atin at bakit ito mahalaga? Kung mayroon tayong DotNet, mabuti iyon, ito ay isang pinagsama-samang wika, maaari nating i-compile ang ating aplikasyon. Kung ito ay nag-compile, kung gayon ito ay isang magandang senyales. Wala pa itong ibig sabihin, ngunit ito ang unang magandang senyales na maaari tayong mag-compile.
Pagkatapos ay maaari tayong magpatakbo ng ilang mga pagsubok, na isa ring hiwalay na kasanayan. Ang mga pagsubok ay berde lahat - ito ang pangalawang magandang senyales. Ngunit muli, wala itong ibig sabihin.
Ngunit bakit mo ito gagawin? Ang lahat ng mga kasanayan na tatalakayin ko ngayon ay nagtataglay ng humigit-kumulang sa parehong halaga, ibig sabihin, humigit-kumulang sa parehong mga benepisyo at sinusukat din nang humigit-kumulang sa parehong paraan.
Una, pinapayagan ka nitong mapabilis ang paghahatid. Paano ka nito binibigyang-daan na mapabilis ang paghahatid? Kapag gumawa kami ng ilang bagong pagbabago sa aming code base, maaari naming agad na subukang gumawa ng isang bagay gamit ang code na ito. Hindi namin hinintay na dumating ang Huwebes dahil sa Huwebes ay inilalabas namin ito sa QA Environment, ginagawa namin ito dito mismo at dito mismo.
Sasabihin ko sa iyo ang isang malungkot na kuwento mula sa aking buhay. Matagal na ang nakalipas, noong bata pa ako at gwapo. Ngayon ako ay bata pa, maganda at matalino, at mahinhin. Noong nakaraan, nasa isang proyekto ako. Nagkaroon kami ng malaking team na may humigit-kumulang 30 developer. At nagkaroon kami ng malaki at malaking proyekto ng Enterprise na binuo ng humigit-kumulang 10 taon. At magkaiba kami ng branch. Sa repository ay mayroon kaming sangay kung saan lumakad ang mga developer. At mayroong isang sangay na nagpakita ng bersyon ng code na nasa produksyon.
Ang sangay ng produksyon ay 3 buwan sa likod ng sangay na magagamit sa mga developer. Ano ang ibig sabihin nito? Nangangahulugan ito na sa sandaling mayroon akong isang bug sa isang lugar na napupunta sa produksyon dahil sa kasalanan ng mga developer, dahil pinayagan nila ito, at dahil sa kasalanan ng QA, dahil tiningnan nila ito, nangangahulugan ito na kung makakatanggap ako ng isang gawain para sa hotfix para sa produksyon, pagkatapos ay kailangan kong ibalik ang aking mga pagbabago sa code 3 buwan na ang nakakaraan. Kailangan kong tandaan kung ano ang mayroon ako 3 buwan na ang nakakaraan at subukang ayusin ito doon.
Kung hindi ka pa nakakaranas ng ganitong karanasan, maaari mo itong subukan sa iyong proyekto sa bahay. Ang pangunahing bagay ay, huwag subukan ito sa isang komersyal. Sumulat ng ilang linya ng code, kalimutan ang tungkol sa mga ito sa loob ng anim na buwan, at pagkatapos ay bumalik at subukang mabilis na ipaliwanag kung tungkol saan ang mga linya ng code na iyon at kung paano mo maaayos o ma-optimize ang mga ito. Ito ay isang napaka, napaka kapana-panabik na karanasan.
Kung mayroon kaming Continuous Integration na kasanayan, binibigyang-daan kami nitong suriin ito gamit ang ilang automated na tool dito mismo at ngayon, sa sandaling naisulat ko na ang aking code. Maaaring hindi nito ibigay sa akin ang buong larawan, ngunit gayunpaman, aalisin nito ang kahit ilan sa mga panganib. At kung mayroong anumang potensyal na bug, malalaman ko ang tungkol dito ngayon, iyon ay, literal sa loob ng ilang minuto. Hindi ko na kailangang ibalik ang 3 buwan. Kakailanganin ko lang mag-roll back ng 2 minuto. Ang isang mahusay na makina ng kape ay hindi magkakaroon ng oras upang magtimpla ng kape sa loob ng 2 minuto, kaya maganda iyon.
Ito ay may halaga na maaari itong ulitin sa bawat oras sa bawat proyekto, i.e. hindi lang yung set up mo. Maaari mong ulitin ang pagsasanay mismo at ang CI mismo ay uulitin para sa bawat bagong pagbabagong gagawin mo sa proyekto. Nagbibigay-daan ito sa iyong i-optimize ang mga mapagkukunan dahil mas mahusay na gumagana ang iyong koponan. Hindi ka na magkakaroon ng sitwasyon kung saan may darating na bug sa iyo mula sa code na ginamit mo 3 buwan na ang nakakaraan. Hindi ka na magkakaroon ng paglipat ng konteksto kapag umupo ka at gumugol ng unang dalawang oras sa pagsubok na unawain kung ano ang nangyari noon at pumasok sa esensya ng konteksto bago mo simulan ang pagwawasto ng isang bagay.
Paano natin masusukat ang tagumpay o kabiguan ng pagsasanay na ito? Kung isusumbong mo sa big boss ang ipinatupad namin sa CI project, naririnig niya blah blah blah. Ipinatupad natin ito, OK, ngunit bakit, ano ang naidulot nito sa atin, paano natin ito sinusukat, gaano ba tayo tama o mali ang pagpapatupad nito?
Ang una ay na, salamat sa CI, maaari kaming mag-deploy nang mas madalas, at mas madalas na tiyak dahil ang aming code ay potensyal na mas matatag. Sa parehong paraan, ang aming oras upang makahanap ng isang error ay nabawasan at ang oras upang itama ang error na ito ay nabawasan nang eksakto sa kadahilanang nakatanggap kami ng sagot mula sa system dito mismo at ngayon, kung ano ang mali sa aming code.
Ang isa pang kasanayan na mayroon kami ay ang kasanayan sa Pagsusuri ng Automation, na kadalasang kasama ng pagsasanay sa CI. Magkahawak-kamay sila.
Ano ang mahalagang maunawaan dito? Mahalagang maunawaan na magkaiba ang ating mga pagsubok. At ang bawat awtomatikong pagsubok ay naglalayong lutasin ang sarili nitong mga problema. Mayroon kaming, halimbawa, mga unit test na nagpapahintulot sa amin na subukan ang isang module nang hiwalay, i.e. Paano ito gumagana sa isang vacuum? Mabuti ito.
Mayroon din kaming mga pagsubok sa pagsasama na nagbibigay-daan sa amin na maunawaan kung paano nagsasama ang iba't ibang mga module sa isa't isa. Magaling din ito.
Maaaring mayroon kaming mga pagsubok sa automation ng UI na nagbibigay-daan sa aming suriin kung gaano kahusay natutugunan ng trabaho sa UI ang ilang partikular na kinakailangan na itinakda ng customer, atbp.
Ang mga partikular na pagsubok na iyong pinapatakbo ay maaaring makaapekto sa kung gaano mo kadalas pinapatakbo ang mga ito. Ang mga pagsusulit sa yunit ay karaniwang nakasulat na maikli at maliit. At maaari silang ilunsad nang regular.
Kung pinag-uusapan natin ang mga pagsubok sa automation ng UI, mabuti kung maliit ang iyong proyekto. Maaaring tumagal ng ilang sapat na oras ang iyong mga pagsubok sa automation ng UI. Ngunit kadalasan ang isang UI automation test ay isang bagay na tumatagal ng ilang oras sa isang malaking proyekto. At mabuti kung ito ay ilang oras. Ang tanging bagay ay walang saysay na patakbuhin ang mga ito para sa bawat build. Makatuwirang patakbuhin ang mga ito sa gabi. At nang magtrabaho ang lahat sa umaga: parehong mga tester at developer, nakatanggap sila ng ilang uri ng ulat na pinatakbo namin ang UI autotest sa gabi at nakuha namin ang mga resultang ito. At dito, ang isang oras ng trabaho ng isang server na titingnan kung ang iyong produkto ay nakakatugon sa ilang mga kinakailangan ay magiging mas mura kaysa sa isang oras ng trabaho ng parehong QA engineer, kahit na ito ay isang Junior QA engineer na nagtatrabaho para sa pagkain at salamat. Gayunpaman, ang isang oras ng pagpapatakbo ng makina ay magiging mas mura. Ito ang dahilan kung bakit makatuwirang mamuhunan dito.
May isa pa akong project na ginagawa ko. Nagkaroon kami ng dalawang linggong sprint sa proyektong ito. Malaki ang proyekto, mahalaga para sa sektor ng pananalapi, at hindi maaaring magkamali. At pagkatapos ng dalawang linggong sprint, ang development cycle ay sinundan ng isang proseso ng pagsubok, na tumagal ng isa pang 4 na linggo. Subukang isipin ang laki ng trahedya. Nagsusulat kami ng code sa loob ng dalawang linggo, pagkatapos ay ginagawa namin ito bilang CodeFreeze, i-package ito sa isang bagong bersyon ng application, at ilalabas ito sa mga tester. Sinusubukan ito ng mga tagasubok para sa isa pang 4 na linggo, i.e. Habang sinusubok nila ito, mayroon kaming oras upang maghanda ng dalawa pang bersyon para sa kanila. Ito ay isang talagang malungkot na kaso.
At sinabi namin sa kanila na kung gusto mong maging mas produktibo, makatuwiran para sa iyo na ipatupad ang mga kasanayan sa Automated Testing, dahil ito ang masakit sa iyo dito, ngayon.
Magsanay ng Tuloy-tuloy na Deployment. Mahusay, nakagawa ka na. Ito ay mabuti na. Naipon na ang iyong code. Ngayon ay mainam na i-deploy ang build na ito sa ilang kapaligiran. Sabihin natin sa isang kapaligiran para sa mga developer.
Bakit ito mahalaga? Una, maaari mong tingnan kung gaano ka matagumpay sa mismong proseso ng pag-deploy. Nakilala ko ang mga proyektong tulad nito, kapag tinanong ko: "Paano ka mag-deploy ng isang bagong bersyon ng application?", Ang mga lalaki ay nagsasabi sa akin: "Ginagawa namin ito at inilalagay ito sa isang zip archive. Ipinapadala namin ito sa admin sa pamamagitan ng koreo. Dina-download at pinalawak ng admin ang archive na ito. At nagsimulang magdasal ang buong opisina na kunin ng server ang bagong bersyon.β
Magsimula tayo sa isang bagay na simple. Halimbawa, nakalimutan nilang ilagay ang CSS sa archive o nakalimutang baguhin ang hashtag sa java-script file name. At kapag humiling kami sa server, iniisip ng browser na mayroon na itong java-script file at nagpasyang huwag itong i-download. At may lumang bersyon, may kulang. Sa pangkalahatan, maaaring magkaroon ng maraming problema. Samakatuwid, ang pagsasagawa ng Continuous Deployment ay nagbibigay-daan sa iyo na subukan man lang kung ano ang mangyayari kung kumuha ka ng malinis na reference na larawan at na-upload ito sa isang ganap na malinis na bagong kapaligiran. Makikita mo kung saan ito patungo.
Gayundin, kapag isinama mo ang code sa pagitan ng isa't isa, i.e. sa pagitan ng command, binibigyang-daan ka nitong makita kung ano ang hitsura nito sa UI.
Isa sa mga problemang nangyayari kung saan maraming vanilla java-script ang ginagamit ay ang dalawang developer na padalus-dalos na nagdeklara ng variable na may parehong pangalan sa window object. At pagkatapos, depende sa iyong kapalaran. Kung kaninong java-script file ang na-pull out sa pangalawa, o-overwrite ang mga pagbabago ng isa pa. Sobrang exciting din. Pumasok ka: isang bagay ang gumagana para sa isang tao, ang isa ay hindi gumagana para sa isa pa. At ito ay "kahanga-hanga" kapag ang lahat ay lumabas sa produksyon.
Ang susunod na kasanayan na mayroon kami ay ang pagsasanay ng Awtomatikong Pagpapanumbalik, katulad ng pagbabalik sa nakaraang bersyon ng application.
Bakit ito mahalaga para sa mga developer? May mga nakaalala pa rin sa malayo, malayong dekada 90, noong malalaki ang kompyuter at maliliit pa ang mga programa. At ang tanging paraan sa web development ay sa pamamagitan ng PHP. Ito ay hindi na PHP ay isang masamang wika, bagaman ito ay.
Ngunit iba ang problema. Noong nag-deploy kami ng bagong bersyon ng aming php site, paano namin ito na-deploy? Kadalasan ay binuksan namin ang Far Manager o iba pa. At na-upload ang mga file na ito sa FTP. At bigla naming napagtanto na mayroon kaming maliit, maliit na bug, halimbawa, nakalimutan naming maglagay ng semicolon o nakalimutan naming baguhin ang password para sa database, at mayroong isang password para sa database, na nasa lokal na host. At nagpasya kaming mabilis na kumonekta sa FTP at i-edit ang mga file doon mismo. Ito ay sunog lamang! Ito ang sikat noong 90s.
Ngunit, kung hindi mo pa tinitingnan ang kalendaryo, ang dekada 90 ay halos 30 taon na ang nakakaraan. Ngayon ang lahat ng bagay ay nangyayari na medyo naiiba. At subukang isipin ang laki ng trahedya kapag sinabi nila sa iyo: "Nag-deploy kami sa produksyon, ngunit may nangyaring mali doon. Narito ang iyong FTP login at password, kumonekta sa produksyon at mabilis na ayusin ito doon." Kung ikaw si Chuck Norris, gagana ito. Kung hindi, nanganganib ka na kung aayusin mo ang isang bug, gagawa ka pa ng 10. Ito ang dahilan kung bakit ang kasanayang ito ng pagbabalik sa nakaraang bersyon ay nagpapahintulot sa iyo na makamit ang marami.
Kahit na ang isang bagay na masama sa paanuman ay napunta sa prod sa isang lugar, kung gayon ito ay masama, ngunit hindi nakamamatay. Maaari kang bumalik sa nakaraang bersyon na mayroon ka. Tawagan itong backup, kung mas madaling makita ito sa terminolohiya na iyon. Maaari kang bumalik sa nakaraang bersyong ito, at magagawa pa rin ng mga user na magtrabaho kasama ang iyong produkto, at magkakaroon ka ng sapat na buffer time. Maaari mong mahinahon, nang walang pagmamadali, kunin ang lahat ng ito at subukan ito nang lokal, ayusin ito, at pagkatapos ay mag-upload ng bagong bersyon. Makatuwirang gawin ito.
Ngayon subukan nating pagsamahin kahit papaano ang dalawang nakaraang mga kasanayan nang magkasama. Makakakuha kami ng pangatlo na tinatawag na Release Management.
Kapag pinag-uusapan natin ang tungkol sa Continuous Deployment sa klasikal nitong anyo, sinasabi natin na dapat nating hilahin ang code mula sa ilang sangay mula sa repository, i-compile ito at i-deploy ito. Mabuti kung pareho tayo ng kapaligiran. Kung mayroon kaming ilang mga kapaligiran, nangangahulugan ito na kailangan naming hilahin ang code sa bawat oras, kahit na mula sa parehong commit. Bubunutin namin ito sa bawat oras, itatayo namin ito sa bawat oras at ipapakalat namin ito sa isang bagong kapaligiran. Una, ito ang oras, dahil upang bumuo ng isang proyekto, kung mayroon kang malaki at nagmula sa 90s, pagkatapos ay maaaring tumagal ng ilang oras.
Tsaka may isa pang lungkot. Kapag nagtayo ka, kahit na sa parehong makina, gagawa ka ng parehong mga mapagkukunan, wala ka pa ring garantiya na ang makinang ito ay nasa parehong estado tulad noong huling build.
Sabihin nating may pumasok at nag-update ng DotNet para sa iyo o, sa kabilang banda, may nagpasya na magtanggal ng isang bagay. At pagkatapos ay mayroon kang cognitive dissonance na mula sa commit na ito dalawang linggo na ang nakakaraan ay nagtatayo kami ng isang build at lahat ay maayos, ngunit ngayon ay parang ang parehong makina, ang parehong commit, ang parehong code na sinusubukan naming buuin, ngunit hindi ito gumagana . Haharapin mo ito nang mahabang panahon at hindi ito isang katotohanan na malalaman mo ito. Sa pinakakaunti, masisira mo ang iyong mga ugat.
Samakatuwid, ang kasanayan sa Pamamahala ng Paglabas ay nagmumungkahi ng pagpapakilala ng karagdagang abstraction na tinatawag na artifact repository o gallery o library. Maaari mo itong tawaging kahit anong gusto mo.
Ang pangunahing ideya ay na sa sandaling mayroon kaming ilang uri ng commit doon, sabihin nating, sa isang sangay na handa na naming i-deploy sa aming iba't ibang mga kapaligiran, kinokolekta namin ang mga application mula sa commit na ito at lahat ng kailangan namin para sa application na ito, i-pack namin ito. sa isang zip archive at i-save ito sa ilang maaasahang storage. At mula sa storage na ito maaari naming makuha ang zip archive na ito anumang oras.
Pagkatapos ay kinuha namin ito at awtomatikong i-deploy ito sa kapaligiran ng dev. Karera kami doon, at kung maayos ang lahat, pagkatapos ay i-deploy kami sa entablado. Kung ang lahat ay maayos, pagkatapos ay i-deploy namin ang parehong archive sa produksyon, ang parehong mga binary, na pinagsama-sama nang eksaktong isang beses.
Bilang karagdagan, kapag mayroon kaming isang gallery na tulad nito, nakakatulong din ito sa amin na tugunan ang mga panganib na natugunan namin sa huling slide noong pinag-usapan namin ang tungkol sa rollback sa nakaraang bersyon. Kung hindi mo sinasadyang na-deploy ang isang bagay na mali, maaari mong palaging kumuha ng anumang iba pang nakaraang bersyon mula sa gallery na ito at i-undeploy ito sa mga environment na ito sa parehong paraan. Nagbibigay-daan ito sa iyo na madaling bumalik sa nakaraang bersyon kung may mali.
May isa pang mahusay na pagsasanay. Nauunawaan mo at ko lahat na kapag ibinalik namin ang aming mga application sa isang nakaraang bersyon, maaaring mangahulugan ito na kailangan din namin ang imprastraktura ng nakaraang bersyon.
Kapag pinag-uusapan natin ang tungkol sa virtual na imprastraktura, iniisip ng maraming tao na ito ay isang bagay na na-set up ng mga admin. At kung kailangan mo, sabihin nating, upang makakuha ng isang bagong server kung saan nais mong subukan ang isang bagong bersyon ng iyong aplikasyon, pagkatapos ay dapat kang magsulat ng isang tiket sa mga admin o devops. Aabutin ng 3 linggo ang Devops para dito. At pagkatapos ng 3 linggo sasabihin nila sa iyo na nag-install kami ng virtual machine para sa iyo, na may isang core, dalawang gigabytes ng RAM at isang Windows server na walang DotNet. Sasabihin mo: "Ngunit gusto ko ang DotNet." Sila: "Ok, bumalik sa loob ng 3 linggo."
Ang ideya ay sa pamamagitan ng paggamit ng Infrastructure bilang mga kasanayan sa Code, maaari mong ituring ang iyong virtual na imprastraktura bilang isa pang mapagkukunan.
Marahil, kung sinuman sa inyo ang gumagawa ng mga application sa DotNet, maaaring narinig mo na ang tungkol sa isang library na tinatawag na Entity Framework. At maaaring narinig mo pa na ang Entity Framework ay isa sa mga diskarte na aktibong itinutulak ng Microsoft. Para sa pagtatrabaho sa isang database, ito ay isang diskarte na tinatawag na Code First. Ito ay kapag inilalarawan mo sa code kung paano mo gustong tingnan ang iyong database. At pagkatapos ay i-deploy mo ang application. Kumokonekta ito sa database, ito mismo ang tumutukoy kung aling mga talahanayan ang naroroon at kung aling mga talahanayan ang wala, at lumilikha ng lahat ng kailangan mo.
Magagawa mo rin ang iyong imprastraktura. Walang pagkakaiba sa pagitan kung kailangan mo ng database para sa isang proyekto o kung kailangan mo ng Windows server para sa isang proyekto. Ito ay isang mapagkukunan lamang. At maaari mong i-automate ang paglikha ng mapagkukunang ito, maaari mong i-automate ang pagsasaayos ng mapagkukunang ito. Alinsunod dito, sa tuwing gusto mong subukan ang ilang bagong konsepto, ilang bagong diskarte, hindi mo na kailangang magsulat ng isang tiket sa devops, maaari mo lamang i-deploy ang isang nakahiwalay na imprastraktura para sa iyong sarili mula sa mga yari na template, mula sa mga handa na script at ipatupad ito doon lahat ng iyong mga eksperimento. Maaari mong tanggalin ito, kumuha ng ilang mga resulta at mag-ulat pa tungkol dito.
Ang susunod na kasanayan, na mayroon din at mahalaga din, ngunit kakaunti ang gumagamit, ay ang Pagsubaybay sa Pagganap ng Application.
Isa lang ang gusto kong sabihin tungkol sa Application Performance Monitoring. Ano ang pinakamahalaga sa pagsasanay na ito? Ito ay kung ano ang Application Performance Monitoring ay halos kapareho ng pag-aayos ng isang apartment. Ito ay hindi isang pangwakas na estado, ito ay isang proseso. Kailangan mong gawin ito nang regular.
Sa mabuting paraan, mainam na isagawa ang Pagsubaybay sa Pagganap ng Application sa halos bawat build, bagaman, tulad ng naiintindihan mo, hindi ito palaging posible. Ngunit, sa pinakamababa, kailangan itong isagawa para sa bawat paglabas.
Bakit ito mahalaga? Dahil kung bigla kang makaranas ng pagbaba sa pagganap, kailangan mong malinaw na maunawaan kung bakit. Kung ang iyong koponan ay may, halimbawa, dalawang linggong sprint, pagkatapos ay hindi bababa sa isang beses bawat dalawang linggo dapat mong i-deploy ang iyong aplikasyon sa ilang hiwalay na server, kung saan mayroon kang malinaw na nakapirming processor, RAM, mga disk, atbp. At patakbuhin ang parehong mga pagsubok sa pagganap. . Makukuha mo ang resulta. Tingnan kung paano ito nagbago mula sa nakaraang sprint.
At kung nalaman mo na ang drawdown ay bumaba nang husto sa isang lugar, nangangahulugan ito na ito ay dahil lamang sa mga pagbabagong naganap sa nakalipas na dalawang linggo. Ito ay magbibigay-daan sa iyong kilalanin at ayusin ang problema nang mas mabilis. At muli, ang mga ito ay halos pareho ang mga sukatan kung saan mo masusukat kung gaano mo ito matagumpay na nagawa.
Ang susunod na kasanayan na mayroon kami ay ang kasanayan sa Pamamahala ng Configuration. Kakaunti lang ang nagseseryoso nito. Ngunit maniwala ka sa akin, ito ay talagang isang napakaseryosong bagay.
May nakakatawang kwento kamakailan. Lumapit sa akin ang mga lalaki at sinabing: "Tulungan kaming magsagawa ng security audit ng aming aplikasyon." Tiningnan namin ang code nang mahabang panahon, sinabi nila sa akin ang tungkol sa aplikasyon, gumuhit ng mga diagram. At plus o minus lahat ay lohikal, naiintindihan, ligtas, ngunit mayroong isa PERO! Mayroon silang mga configuration file sa kanilang source control, kabilang ang mga mula sa produksyon na may IP database, na may mga login at password para sa pagkonekta sa mga database na ito, atbp.
At sinasabi ko: "Guys, okay, isinara mo ang iyong kapaligiran sa produksyon gamit ang isang firewall, ngunit ang katotohanan na mayroon kang login at password para sa database ng produksyon sa mismong source control at ang sinumang developer ay makakabasa nito ay isang malaking panganib sa seguridad. . At gaano man ka-secure ang iyong application mula sa isang code point of view, kung iiwan mo ito sa source control, hindi ka makakapasa sa anumang audit kahit saan." Yan ang sinasabi ko.
Pamamahala ng configuration. Maaaring may iba't ibang configuration tayo sa iba't ibang environment. Halimbawa, maaaring mayroon kaming iba't ibang mga login at password para sa mga database para sa QA, demo, production environment, atbp.
Ang pagsasaayos na ito ay maaari ding maging awtomatiko. Dapat itong palaging hiwalay sa mismong aplikasyon. Bakit? Dahil isang beses mong binuo ang application, at pagkatapos ay walang pakialam ang application kung kumonekta ka sa SQL server sa pamamagitan ng ganoon at ganoong IP o ganoon at ganoong IP, dapat itong gumana nang pareho. Samakatuwid, kung biglang ang isa sa inyo ay nag-hardcode pa rin ng string ng koneksyon sa code, pagkatapos ay tandaan na hahanapin kita at parurusahan ka kung nakita mo ang iyong sarili sa parehong proyekto sa akin. Ito ay palaging inilalagay sa isang hiwalay na configuration, halimbawa, sa web.config.
At ang pagsasaayos na ito ay pinamamahalaan nang hiwalay, ibig sabihin, ito ang eksaktong sandali kung kailan maaaring dumating at maupo ang isang developer at isang administrator sa parehong silid. At masasabi ng developer: "Tingnan, narito ang mga binary ng aking aplikasyon. Nagtatrabaho sila. Ang application ay nangangailangan ng isang database upang gumana. Dito sa tabi ng mga binary mayroong isang file. Sa file na ito, ang patlang na ito ay responsable para sa pag-login, ito ay para sa password, ito ay para sa IP. I-deploy ito kahit saan." At ito ay simple at malinaw sa admin. Maaari niya itong i-deploy kahit saan sa pamamagitan ng pamamahala sa configuration na ito.
At ang huling pagsasanay na nais kong pag-usapan ay isang pagsasanay na napaka-kaugnay sa mga ulap. At nagdudulot ito ng maximum na epekto kung nagtatrabaho ka sa cloud. Ito ay Awtomatikong pag-aalis ng iyong kapaligiran.
Alam kong may ilang tao sa kumperensyang ito mula sa mga pangkat na kasama ko. At sa lahat ng team na kasama ko, ginagamit namin ang pagsasanay na ito.
Bakit? Siyempre, magiging maganda kung ang bawat developer ay may virtual machine na gagana 24/7. Ngunit marahil ito ay balita sa iyo, marahil ay hindi mo binigyang pansin, ngunit ang developer mismo ay hindi gumagana 24/7. Karaniwang gumagana ang isang developer ng 8 oras sa isang araw. Kahit na maaga siyang pumasok sa trabaho, mayroon siyang malaking tanghalian kung saan pumupunta siya sa gym. Hayaan itong maging 12 oras sa isang araw kapag aktwal na ginagamit ng developer ang mga mapagkukunang ito. Ayon sa ating batas, mayroon tayong 5 sa 7 araw sa isang linggo na itinuturing na araw ng trabaho.
Alinsunod dito, sa mga karaniwang araw ang makina na ito ay hindi dapat gumana nang 24 na oras, ngunit 12 lamang, at sa mga katapusan ng linggo ang makina na ito ay hindi dapat gumana. Tila ang lahat ay napaka-simple, ngunit ano ang mahalagang sabihin dito? Sa pamamagitan ng pagpapatupad ng simpleng kasanayang ito sa pangunahing iskedyul na ito, pinapayagan ka nitong bawasan ang gastos sa pagpapanatili ng mga environment na ito ng 70%, ibig sabihin, kinuha mo ang presyo ng iyong dev, QA, demo, environment at hinati ito ng 3.
Ang tanong, ano ang gagawin sa natitirang pera? Halimbawa, dapat bumili ang mga developer ng ReSharper kung hindi pa nila nabibili. O magkaroon ng cocktail party. Kung dati ay mayroon kang isang kapaligiran kung saan pareho ang dev at QA, at iyon nga, maaari ka na ngayong gumawa ng 3 iba't ibang kapaligiran na ihihiwalay, at ang mga tao ay hindi makikialam sa isa't isa.
Tungkol sa slide na may tuluy-tuloy na pagsukat ng pagganap, paano natin maihahambing ang pagganap kung mayroon tayong 1 na talaan sa database sa proyekto, pagkaraan ng dalawang buwan mayroong isang milyon? Paano maunawaan kung bakit at ano ang punto ng pagsukat ng pagganap?
Ito ay isang magandang tanong, dahil dapat mong palaging sukatin ang pagganap sa parehong mga mapagkukunan. Ibig sabihin, naglalabas ka ng bagong code, sinusukat mo ang performance sa bagong code. Halimbawa, kailangan mong subukan ang iba't ibang mga sitwasyon ng pagganap, sabihin nating gusto mong subukan kung paano gumaganap ang application sa isang light load, kung saan mayroong 1 mga gumagamit at ang laki ng database ay 000 gigabytes. Sinukat mo ito at nakuha ang mga numero. Susunod na gumawa kami ng isa pang senaryo. Halimbawa, 5 user, laki ng database 5 terabyte. Natanggap namin ang mga resulta at naalala namin ang mga ito.
Ano ang mahalaga dito? Ang mahalagang bagay dito ay depende sa senaryo, dami ng data, bilang ng sabay-sabay na user, atbp., maaari kang magkaroon ng ilang partikular na limitasyon. Halimbawa, sa limitasyon ng network card, o sa limitasyon ng hard drive, o sa limitasyon ng mga kakayahan ng processor. Ito ang mahalagang maunawaan mo. Sa iba't ibang mga sitwasyon, nakakaranas ka ng ilang partikular na limitasyon. At kailangan mong maunawaan ang mga numero kapag na-hit mo ang mga ito.
Pinag-uusapan ba natin ang pagsukat ng pagganap sa isang espesyal na kapaligiran sa pagsubok? Ibig sabihin, hindi ito produksyon?
Oo, hindi ito produksyon, ito ay isang pagsubok na kapaligiran, na palaging pareho upang maihambing mo ito sa mga nakaraang sukat.
Naiintindihan salamat!
Kung walang tanong, sa tingin ko ay makakatapos tayo. Salamat!
Pinagmulan: www.habr.com