Tatalakayin sa talakayang ito ang ilang kasanayan sa DevOps, ngunit mula sa pananaw ng isang developer. Kadalasan, ang mga inhinyero na sumasali sa DevOps ay mayroon nang ilang taon ng karanasan sa administrasyon. Ngunit hindi ibig sabihin nito na walang lugar para sa mga developer. Kadalasan, abala ang mga developer sa pag-aayos ng "pinakabagong apurahan at kritikal na bug ng panahon," at wala silang oras para kahit tingnan ang mundo ng DevOps. Una, nakikita ng may-akda ang DevOps bilang sentido komun. Pangalawa, ito ay isang pagkakataon upang maging mas epektibo. Kung ikaw ay isang developer, may sentido komun, at gustong maging mas epektibong miyembro ng team, ang talakayang ito ay para sa iyo.
Hayaan ninyong ipakilala ko ang aking sarili. Inaasahan kong may mga tao sa silid na ito na hindi nakakakilala sa akin. Ang pangalan ko ay Anton Boyko, at ako ay isang Microsoft Azure MVP. Ano ang isang MVP? Ito ay isang Model-View-Presenter. Model-View-Presenter—ako iyon.
Isa rin akong solution architect sa Ciklum. Kamakailan ko lang binili ang magandang domain na ito at in-update ang aking email address, na karaniwan kong ginagamit sa mga presentasyon. Maaari mo akong sulatan sa: me [at] byokoant.pro. Maaari mo akong i-email kung may mga tanong ka. Karaniwan ko itong sinasagot. Ang tanging ayaw kong matanggap ay mga tanong na may kaugnayan sa dalawang paksa: politika at relihiyon. Para sa lahat ng iba pa, maaari mo akong i-email. Sasagutin ko ang mga ito sa lalong madaling panahon.
Ilang salita tungkol sa aking sarili:
- Sampung taon na ako sa larangang ito.
- Nagtrabaho ako sa Microsoft.
- Ako ang nagtatag ng komunidad ng Ukrainian Azure, na itinatag namin noong bandang 2014. Buhay pa rin ito at maayos.
- Ako rin ang nagtatag ng kumperensya ng Azure, na aming ginaganap sa Ukraine.
- Tumutulong din ako sa pag-oorganisa ng Global Azure Bootcamp sa Kyiv.
- Gaya ng sabi ko, isa akong Microsoft Azure MVP.
- Madalas akong magsalita sa mga kumperensya. Mahilig talaga akong magsalita sa mga kumperensya. Noong nakaraang taon, nakapagpresenta ako ng halos 40 beses. Kung sakaling madaanan mo ang Ukraine, Belarus, Poland, Bulgaria, Sweden, Denmark, Netherlands, Spain, o marahil sa ibang bansa sa Europa, posible na kapag dumalo ka sa isang kumperensya na nagtatampok ng cloud computing, makikita mo ako bilang isang tagapagsalita.
- Fan din ako ng Star Trek.
Pag-usapan natin nang kaunti ang Adyenda. Napakasimple lang ng sa amin:
- Pag-uusapan natin kung ano ang DevOps at kung bakit ito mahalaga. Dati, ang DevOps ay isang keyword na maaari mong isulat sa iyong resume at agad na makakuha ng $500 na pagtaas ng suweldo. Ngayon, kailangan mong isulat, halimbawa, ang "blockchain" sa iyong resume para makakuha ng $500 na pagtaas ng suweldo.
- At pagkatapos, kapag mas naunawaan na natin kung ano ito, pag-uusapan natin ang mga kasanayan sa DevOps. Hindi gaanong sa konteksto ng DevOps sa pangkalahatan, kundi sa mga kasanayan sa DevOps na maaaring maging interesado ang mga developer. Ipapaliwanag ko kung bakit maaaring maging interesado ka sa mga ito. Ipapaliwanag ko kung bakit mo dapat gawin ito at kung paano ito makakatulong sa iyo na makaranas ng mas kaunting paghihirap.
Ito ang tradisyonal na larawan na ipinapakita ng maraming tao. Ito ang nangyayari sa maraming proyekto. Ito ay kapag mayroon tayong mga departamento ng pag-unlad at operasyon na sumusuporta sa ating software. At ang mga departamentong ito ay hindi nakikipag-ugnayan sa isa't isa.
Marahil, kung hindi mo pa gaanong nauunawaan ang mga departamento ng DevOps at Operations, maaari kang gumawa ng paghahambing sa mga departamento ng Dev at QA. May mga taong bumubuo ng software, at may mga taong QA na masasama, mula sa pananaw ng mga developer. Halimbawa, inilalagay ko ang aking mahusay na code sa repository, at pagkatapos ay may isang taong walang pakundangan na uupo doon, ibinabalik ito sa akin, at sasabihin sa akin na ito ay masama.
Nangyayari ang lahat ng ito dahil hindi nakikipag-ugnayan ang mga tao sa isa't isa. At sa pamamagitan ng isang uri ng hindi pagkakaunawaan, nagpapalitan sila ng ilang mga pakete, isang uri ng aplikasyon, at sinusubukang gumawa ng isang bagay gamit ang mga ito.
Ang kultura ng DevOps ay dinisenyo upang gibain ang pader na ito, upang pilitin ang mga tao na makipag-ugnayan sa isa't isa at kahit papaano ay maunawaan kung ano ang ginagawa ng iba't ibang tao sa isang proyekto at kung bakit mahalaga ang kanilang trabaho.
At kapag pinag-uusapan natin ang DevOps, may magsasabi sa iyo na ang DevOps ay kapag ang isang proyekto ay may patuloy na integrasyon; may magsasabi na ang DevOps ay kapag ang isang proyekto ay nagpapatupad ng kasanayang "imprastraktura bilang code"; may magsasabi na ang unang hakbang sa DevOps ay ang feature branching at feature flags.
Sa esensya, totoo ang lahat ng ito sa sarili nitong paraan. Ngunit ito pa lamang ang mga huling kasanayan na mayroon tayo. Bago tayo magpatuloy sa mga kasanayang ito, iminumungkahi kong tingnan ang slide na ito, na nagpapakita ng tatlong yugto ng pagpapatupad ng metodolohiya ng Dev-Ops sa iyong proyekto at sa iyong kumpanya.
Mayroon ding ibang hindi opisyal na pangalan ang slide na ito. Maaari kang maghanap online para sa Tatlong Musketeer ng DevOps. Maaari mong makita ang artikulong ito. Bakit ang Tatlong Musketeer? Sa ibaba, sinasabi nito: Mga Tao, Proseso, at Produkto, i.e., PPP – Portos, Portos, at Portos. Kaya, iyon ang Tatlong Musketeer ng DevOps. Mas detalyado ang artikulong ito kung bakit ito mahalaga at kung ano ang kaakibat nito.
Kapag sinimulan mo ang pagpapatupad ng isang kultura ng DevOps, napakahalaga na ipatupad ito sa sumusunod na pagkakasunud-sunod.
Una, kailangan mong makipag-usap sa mga tao. At kailangan mong ipaliwanag sa kanila kung ano ito at kung paano sila makikinabang dito.
Ang aming kumperensya ay tinatawag na DotNet Fest. At gaya ng sinabi sa akin ng mga organizer, ang mga tagapakinig na aming inimbitahan ay pangunahing mga developer, kaya umaasa ako na karamihan sa mga tao sa silid ay mga developer.
Pag-uusapan natin ang tungkol sa mga tao, pag-uusapan kung ano ang gustong gawin ng mga developer araw-araw. Ano ang pinakagusto nila? Gusto nilang magsulat ng bagong code, gumamit ng mga makabagong framework, at bumuo ng mga bagong feature. Ano ang pinakakaunting gusto ng mga developer? Ayusin ang mga lumang bug. Sana ay sasang-ayon kayo sa akin. Iyan ang gusto ng mga developer. Gusto nilang magsulat ng mga bagong feature, ayaw nilang ayusin ang mga bug.
Ang bilang ng mga bug na nalilikha ng isang developer ay nakadepende sa kung gaano katatag ang kanilang mga kamay at kung gaano sila lumalaki mula sa kanilang mga balikat sa halip na mula sa kanilang puwitan. Gayunpaman, kapag mayroon tayong malaking proyekto, minsan ay imposibleng subaybayan ang lahat, kaya mainam na gumamit ng ilang mga pamamaraan na makakatulong sa atin na magsulat ng mas matatag at mas mataas na kalidad na code.
Ano ang pinaka-gusto ng mga QA engineer? Hindi ko alam kung mayroon sa silid na ito. Mahirap para sa akin na sabihin na gusto kong maging isang QA engineer dahil hindi pa ako naging ganito. At walang masama sa kanila, sana ay hindi ako maging ganito. Hindi dahil sa iniisip kong walang saysay at walang silbi ang kanilang trabaho, kundi dahil hindi ko itinuturing ang aking sarili na isang taong kayang gawin ito nang mahusay, kaya hindi ko na susubukan. Ngunit sa pagkakaintindi ko, ang pinaka-kinaiinisan ng mga QA engineer ay ang magtrabaho sa umaga, patuloy na nagpapatakbo ng mga regression test, nakakatagpo ng parehong mga bug na iniulat nila sa mga developer tatlong sprint na ang nakalipas, at sinasabing, "Kailan mo aayusin ang bug na ito, Monsieur D'Artagnan?" At sumagot si Monsieur D'Artagnan, "Oo, oo, oo, naayos ko na ito." At habang nangyayari ito, inaayos mo ang isang bug at pagkatapos ay inaayos ang lima pa.
Gusto ng mga taong sumusuporta sa solusyong ito sa produksyon na gumana ito nang walang mga bug, para hindi nila kailangang i-restart ang server tuwing Biyernes kapag ang lahat ay pupunta sa bar. Nagde-deploy ang mga developer tuwing Biyernes, at ang mga admin ay naghihintay hanggang Sabado upang subukang patakbuhin at ayusin ang deployment.
At kapag naipaliwanag mo na sa mga tao na lahat sila ay nakatuon sa paglutas ng parehong mga problema, maaari ka nang magpatuloy sa pagpopormalisa ng mga proseso. Napakahalaga nito. Bakit? Dahil kapag sinabi nating "pormalisasyon," mahalagang ilarawan kung paano gumagana ang iyong mga proseso, kahit man lang sa isang maliit na napkin. Kailangan mong maunawaan na kung ikaw, halimbawa, ay magde-deploy sa isang QA environment o isang production environment, palagi itong nangyayari sa ganitong pagkakasunud-sunod. Ito ang mga yugto kung saan tayo nagpapatakbo, halimbawa, ng mga automated unit test at UI test. Pagkatapos ng deployment, sinusuri namin kung gaano kahusay o kahirap ang naging deployment. Ngunit mayroon ka nang malinaw na listahan ng mga aksyon na dapat ulitin nang paulit-ulit kapag nag-deploy ka sa production.
At kapag pormal na ang iyong mga proseso, saka ka lamang magsisimulang pumili ng mga produktong makakatulong sa iyong i-automate ang mga prosesong ito.
Sa kasamaang palad, madalas ko itong nakikitang nangyayari nang pabaligtad. Sa sandaling marinig ng isang tao ang salitang "DevOps," agad nilang iminumungkahi na i-install ang Jenkins, dahil iniisip nila na kapag na-install na nila ang Jenkins, magkakaroon na sila ng DevOps. Nag-install sila ng Jenkins, binasa ang mga artikulong "Paano" sa website ng Jenkins, sinubukang isiksik ang mga proseso sa mga artikulong "Paano", at pagkatapos ay lumapit sa mga tao at pinilit sila, sinasabing sinasabi ng libro na gawin ito sa ganitong paraan, kaya ganoon namin ito ginagawa.
Hindi naman sa masamang kagamitan ang Jenkins. Hindi ko sinasabi 'yan. Pero isa lang itong produkto. At kung aling produkto ang gagamitin mo ang dapat mong pangwakas na desisyon, hindi kailanman ang una. Hindi dapat ang iyong produkto ang maging puwersang nagtutulak sa pag-aampon ng kultura at mga pamamaraan. Mahalagang maunawaan ito, kaya naman gumugugol ako ng napakaraming oras sa slide na ito at ipinapaliwanag ang lahat.
Pag-usapan natin ang mga kasanayan sa DevOps sa pangkalahatan. Ano ang mga ito? Paano sila nagkakaiba? Paano sila sinusukat? Bakit sila mahalaga?
Ang unang kasanayang maaaring narinig mo na ay tinatawag na Continuous Integration. Marahil ay may isang tao sa iyong proyekto na gumagamit ng Continuous Integration (CI).
Ang pinakamalaking problema ay kadalasan, kapag tinatanong ko ang isang tao, "Mayroon ka bang CI sa iyong proyekto?" at sinasabi nilang, "Oo," kapag tinanong ko sila kung ano ang kanilang ginagawa, inilalarawan nila ang buong proseso ng automation. Hindi iyon lubos na totoo.
Sa katotohanan, ang pagsasanay ng CI ay naglalayong pagsamahin ang code na isinulat ng iba't ibang tao sa iisang code base. Iyon lang.
Kasama ng CI, karaniwang may iba pang mga kasanayan sa proseso, tulad ng Continuous Deployment at Release Management, ngunit pag-uusapan natin iyon mamaya.
Sinasabi mismo sa atin ng CI na iba't ibang tao ang sumusulat ng code at ang code na ito ay dapat na patuloy na maisama sa isang code base.
Ano ang ibig sabihin nito para sa atin, at bakit ito mahalaga? Kung mayroon tayong DotNet, mabuti iyon; isa itong na-compile na wika, at maaari nating i-compile ang ating aplikasyon. Kung ito ay nag-compile, isa na itong magandang senyales. Wala itong ibig sabihin, ngunit ito ang unang magandang senyales na maaari na nating i-compile.
Pagkatapos ay maaari tayong magsagawa ng ilang mga pagsubok, na isa ring hiwalay na kasanayan. Lahat ng mga pagsubok ay berde—isa na namang magandang senyales iyon. Ngunit muli, wala itong ibig sabihin.
Pero bakit mo naman gagawin ito? Lahat ng mga gawaing tatalakayin ko ngayon ay may halos parehong halaga, ibig sabihin ay nag-aalok ang mga ito ng halos parehong mga benepisyo at sinusukat sa halos parehong paraan.
Una, pinapayagan ka nitong pabilisin ang paghahatid. Paano nito pinapabilis ang paghahatid? Kapag mayroon kaming mga bagong pagbabagong idinagdag sa aming codebase, maaari naming agad na subukang gamitin ito. Hindi kami naghihintay hanggang Huwebes, dahil sa Huwebes ay inilalabas namin ito sa QA Environment; ginagawa namin ito dito mismo.
Ikukuwento ko sa inyo ang isang malungkot na kwento mula sa aking buhay. Matagal na panahon na ang nakalipas, noong bata pa ako at guwapo. Ngayon ay bata pa ako, guwapo, matalino, at mahinhin. Ilang panahon na ang nakalipas, nasa isang proyekto ako. Mayroon kaming isang malaking pangkat na binubuo ng humigit-kumulang 30 developer. At mayroon kaming isang malaking proyekto ng Enterprise na nasa proseso ng pagbuo nang halos 10 taon. At mayroon kaming iba't ibang sangay. Sa repository, mayroon kaming isang sangay kung saan nagtatambay ang mga developer. At mayroong isang sangay na kumakatawan sa bersyon ng code na ginagawa pa lamang.
Tatlong buwang nahuli ang production branch sa branch na available sa mga developer. Ano ang ibig sabihin nito? Nangangahulugan ito na sa sandaling may bug sa aking code na naitulak sa production dahil sa kasalanan ng mga developer sa pagpayag nito, at dahil sa kasalanan ng QA sa hindi pagpansin nito, kung makakakuha ako ng hotfix task para sa production, kailangan kong i-rollback ang mga pagbabago sa aking code tatlong buwan na ang nakalipas. Kailangan kong tandaan kung ano ang nangyari sa akin tatlong buwan na ang nakalipas at subukang ayusin ito doon.
Kung hindi mo pa nararanasan ito, maaari mo itong subukan sa iyong proyekto sa bahay. Huwag mo lang itong subukan sa isang komersyal na proyekto. Sumulat ng ilang linya ng code, kalimutan ang mga ito sa loob ng anim na buwan, pagkatapos ay bumalik at subukang mabilis na ipaliwanag kung ano ang mga linyang iyon ng code at kung paano ito maaayos o ma-optimize. Isa itong tunay na kamangha-manghang karanasan.
Kung mayroon tayong kasanayan sa Continuous Integration, pinapayagan tayo nitong suriin ang aking code dito mismo at ngayon, sa sandaling isulat ko ito, gamit ang ilang awtomatikong tool. Maaaring hindi nito maibigay sa akin ang buong larawan, ngunit kahit papaano ay maaalis nito ang ilan sa mga panganib. At kung mayroong potensyal na bug, malalaman ko agad ito, literal sa loob ng ilang minuto. Hindi ko na kailangang i-roll back ang tatlong buwan. Dalawang minuto lang ang kailangan kong i-roll back. Ang isang mahusay na coffee machine ay hindi magkakaroon ng oras para magtimpla ng isang tasa ng kape sa loob ng dalawang minuto, kaya medyo kahanga-hanga iyon.
Ang halaga ng pamamaraang ito ay maaari itong ulitin nang paulit-ulit sa bawat proyekto, hindi lamang sa proyektong iyong na-configure. Maaari mong ulitin ang parehong pagsasanay mismo at ang CI mismo para sa bawat bagong pagbabagong gagawin mo sa proyekto. Nagbibigay-daan ito sa iyo na i-optimize ang mga mapagkukunan dahil mas mahusay ang iyong koponan sa pagtatrabaho. Hindi ka na makakatagpo ng bug sa code na iyong pinagtrabahuhan tatlong buwan na ang nakakaraan. Hindi ka na makakaranas ng context switching, kung saan gugugulin mo ang unang dalawang oras sa pagsisikap na maunawaan ang nangyari at maunawaan ang konteksto bago mo pa man ito simulan ang pag-aayos.
Paano natin masusukat ang tagumpay o kabiguan ng gawaing ito? Kung irereport natin sa malaking amo na naipatupad natin ang CI sa isang proyekto, ang maririnig lang niya ay blah-blah-blah. "Ipinatupad natin ito," sabi niya, "Sige, pero bakit?" Ano ang naidulot nito sa atin? Paano natin ito masusukat? Gaano kahusay natin ito naipatupad nang tama o mali?
Una, salamat sa CI, mas madalas tayong makapag-deploy, at mas madalas dahil mas matatag ang ating code. Gayundin, nababawasan natin ang oras na kailangan para mahanap at maayos ang mga bug dahil nakakakuha tayo ng feedback mula sa sistema dito mismo at ngayon tungkol sa kung ano ang mali sa ating code.
Ang isa pang kasanayan namin ay ang automated testing, na kadalasang kasabay ng CI.
Ano ang mahalagang maunawaan dito? Mahalagang maunawaan na ang ating mga pagsubok ay may iba't ibang uri. At ang bawat awtomatikong pagsubok ay idinisenyo upang malutas ang sarili nitong partikular na problema. Halimbawa, mayroon tayong mga unit test na nagbibigay-daan sa amin na subukan ang isang partikular na module, ibig sabihin, kung paano ito gumagana nang walang kontrol. Mabuti iyan.
Mayroon din kaming mga integration test na nagbibigay-daan sa amin upang maunawaan kung paano nagsasama-sama ang iba't ibang module. Maganda rin iyon.
Maaari kaming magkaroon ng mga UI automation test na nagbibigay-daan sa amin upang suriin kung gaano kahusay na natutugunan ng UI work ang mga kinakailangan ng customer, atbp.
Ang mga partikular na pagsubok na iyong isinasagawa ay maaaring makaimpluwensya kung gaano kadalas mo ito isinasagawa. Karaniwan kaming nagsusulat ng maikli at maigsi na mga unit test, at maaari itong regular na patakbuhin.
Kung pag-uusapan natin ang mga UI automation test, ayos lang kung maliit ang iyong proyekto. Ang iyong mga UI automation test ay maaaring tumakbo sa makatwirang tagal ng panahon. Ngunit kadalasan, ang isang UI automation test sa isang malaking proyekto ay tumatagal ng ilang oras. At ayos lang iyon kung ilang oras lang ang kailangan. Ang problema lang, hindi makatuwiran ang pagpapatakbo ng mga ito sa bawat build. Makatuwiran naman na patakbuhin ang mga ito sa gabi. At kapag ang lahat ay pumapasok sa trabaho sa umaga—parehong mga tester at developer—nakatanggap sila ng ulat na nagsasabing pinatakbo namin ang UI automation test nang magdamag at nakuha ang mga resultang ito. Iyan ay isang oras na trabaho. serverAng isang QA engineer na susuri kung ang iyong produkto ay nakakatugon sa ilang mga kinakailangan ay magiging mas mura kaysa sa isang oras na trabaho ng isang QA engineer, kahit na ito ay isang Junior QA engineer na nagtatrabaho nang libre. Mas mura pa rin ang isang oras na trabaho sa makina. Kaya naman makatuwiran na mamuhunan dito.
Nagtrabaho ako sa isa pang proyekto. Nagkaroon kami ng dalawang linggong sprint para dito. Malaking proyekto ito, mahalaga para sa sektor ng pananalapi, at hindi namin kayang magkamali. At pagkatapos ng dalawang linggong sprint, sinundan ng pagsubok ang development cycle, na tumagal pa ng apat na linggo. Subukan mong isipin ang laki ng trahedya. Gumagawa kami ng code sa loob ng dalawang linggo, pagkatapos ay gumagawa kami ng CodeFreeze-style update, ipinapakete ito sa isang bagong bersyon ng app, at inilalabas ito sa mga tester. Pagkatapos ay sinusubukan ito ng mga tester sa loob ng apat na linggo pa, ibig sabihin habang sinusubukan nila, nakapaghanda kami ng dalawa pang bersyon para sa kanila. Talagang nakakalungkot.
At sinabi namin sa kanila na kung gusto mong maging mas produktibo, makatuwiran para sa iyo na ipatupad ang Automated Testing, dahil dito ka nagkakaroon ng problema ngayon din.
Pagsasanay sa Patuloy na Pag-deploy. Magaling, nakagawa ka na ng isang build. Sapat na iyan. Na-compile na ang iyong code. Ngayon, magandang ideya na i-deploy ang build na ito sa isang environment. Sabihin nating, isang development environment.
Bakit ito mahalaga? Una, makikita mo kung gaano katagumpay ang proseso ng iyong pag-deploy. Nakakita na ako ng mga proyekto kung saan, kapag tinatanong ko, "Paano mo ide-deploy ang isang bagong bersyon ng app?" ang sagot nila sa akin, "Iko-compile namin ito at ilalagay sa isang zip archive. Ie-email namin ito sa admin. Ida-download ng admin ang archive at ide-deploy ito. At pagkatapos ay magsisimulang magdasal ang buong team na hawakan ng server ang bagong bersyon."
Magsimula tayo sa isang simpleng bagay. Halimbawa, nakalimutan nilang maglagay ng CSS sa archive o nakalimutan nilang palitan ang hashtag sa pangalan ng JavaScript file. At kapag humiling tayo na tagapagsilbi, iniisip ng browser na mayroon na itong JavaScript file at nagpasyang huwag itong i-download. Ngunit may kulang sa lumang bersyon. Sa madaling salita, maaaring maraming problema. Samakatuwid, ang pagsasagawa ng Continuous Deployment ay nagbibigay-daan sa iyo, kahit man lang, na subukan kung ano ang mangyayari kung kukuha ka ng isang malinis na reference na imahe at itulak ito sa isang ganap na malinis na bagong kapaligiran. Makikita mo kung ano ang mangyayari.
Bukod pa rito, kapag pinagsama ninyo ang code sa inyong dalawa, ibig sabihin, sa pagitan ng isang team, makikita mo rin kung ano ang hitsura nito sa UI.
Isa sa mga problemang nangyayari kapag maraming vanilla JavaScript ang ginagamit ay kapag ang dalawang developer ay padalus-dalos na nagdeklara ng isang variable na may parehong pangalan sa window object. At pagkatapos, sa swerte naman, ang isa na ang JavaScript file ay nahuli sa pangalawang pull ay mag-o-overwrite sa mga pagbabago ng isa pa. Nakakapanabik din ito. Papasok ka at makikita mong gumagana ang isang tao, habang ang isa naman ay hindi. At "kahanga-hanga" ay kapag ang lahat ng ito ay lumabas sa produksyon.
Ang susunod nating kasanayan ay ang kasanayang Awtomatikong Pagbawi, lalo na ang pagbabalik sa nakaraang bersyon ng aplikasyon.
Bakit ito mahalaga para sa mga developer? Mayroon pa ring mga nakakaalala sa malayong dekada 90, noong malalaki pa ang mga computer at maliliit pa ang mga programa. At ang landas patungo sa web development ay sa pamamagitan lamang ng PHP. Hindi naman sa masamang wika ang PHP, bagama't masama ito.
Pero iba ang problema. Kapag nag-deploy kami ng bagong bersyon ng aming PHP site, paano namin ito ide-deploy? Kadalasan, binubuksan namin ang Far Manager o iba pa at ina-upload ang mga file sa FTP. At bigla naming napagtanto na mayroon kaming maliit na bug—halimbawa, nakalimutan namin ang isang semicolon o nakalimutan naming baguhin ang password ng database, at ang password ay para sa isang database sa localhost. Kaya napagpasyahan naming mabilis na kumonekta sa FTP at i-edit ang mga file doon mismo. Ang galing naman! Iyan ang sikat noong dekada 90.
Pero kung hindi mo pa nababasa ang kalendaryo, ang dekada 90 ay halos 30 taon na ang nakalilipas. Medyo iba na ang mga bagay-bagay ngayon. At subukang isipin ang laki ng trahedya kapag may nagsabi sa iyo, "Nag-deploy kami sa production, pero may nangyaring mali. Narito ang iyong FTP login at password, kumonekta sa production at ayusin ito agad." Kung ikaw si Chuck Norris, gagana ito. Kung hindi, nanganganib kang ayusin ang isang bug at lumikha ng 10 pa. Kaya nga ang ganitong gawi ng pagbabalik sa nakaraang bersyon ay nagbibigay-daan sa iyo na makamit ang napakaraming bagay.
Kahit na may mangyaring hindi maganda sa produksyon, masama pa rin ito, pero hindi naman nakamamatay. Maaari kang bumalik sa dating bersyon na mayroon ka. Tawagin itong backup, kung mas madaling isipin iyon. Maaari kang bumalik sa dating bersyong ito, at magagawa pa rin ng mga user ang iyong produkto, at magkakaroon ka ng sapat na oras. Maaari mong mahinahon, nang hindi nagmamadali, na subukan ang lahat, ayusin ito, at pagkatapos ay i-promote ang bagong bersyon. Talagang may katuturan ito.
Ngayon, subukan nating pagsamahin ang dalawang naunang kasanayan. Magkakaroon tayo ng pangatlo, na tinatawag na Release Management.
Kapag pinag-uusapan natin ang Continuous Deployment sa klasikong kahulugan nito, sinasabi natin na kailangan nating kumuha ng code mula sa isang partikular na branch ng repository, i-compile ito, at i-deploy ito. Ayos lang ito kung mayroon tayong iisang environment. Kung mayroon tayong maraming environment, nangangahulugan ito na kailangan nating kunin ang code sa bawat pagkakataon, kahit na mula sa parehong commit. Kukunin natin ito sa bawat pagkakataon, bubuuin ito sa bawat pagkakataon, at i-deploy ito sa isang bagong environment. Una, matagal ito: ang pagbuo ng isang malaking proyekto, kahit na ito ay mula pa noong dekada 90, ay maaaring tumagal ng ilang oras.
May isa pang problema rin. Kahit na bumuo ka sa parehong makina, gagawa ka pa rin mula sa parehong source code, ngunit wala ka pa ring garantiya na ang makina ay nasa parehong estado nito noong huling pagbuo.
Sabihin nating may pumasok at nag-update ng iyong DotNet, o, sa kabaligtaran, may nagdesisyong mag-alis ng isang bagay. Pagkatapos ay makakaranas ka ng cognitive dissonance: dalawang linggo na ang nakalipas ay bumubuo kami ng isang build mula sa commit na ito at maayos naman ang lahat, ngunit ngayon ay parang pareho lang ang makina, ang parehong commit, ang parehong code na sinusubukan naming buuin, ngunit hindi ito gumagana. Matagal kang mag-aayos nito, at hindi garantisado na malalaman mo ito. Sa pinakamababa, talagang mabibigo ka.
Samakatuwid, ang kasanayan sa Release Management ay nagmumungkahi ng pagpapatupad ng isang karagdagang abstraksyon na tinatawag na artifact repository, gallery, o library. Maaari mo itong tawagin kahit anong gusto mo.
Ang pangunahing ideya ay sa sandaling mayroon na tayong commit, halimbawa, sa isang branch na handa na nating i-deploy sa ating iba't ibang environment, bubuo tayo ng mga application mula sa commit na iyon at lahat ng kailangan natin para sa application na iyon papunta sa isang zip archive at iimbak ito sa isang ligtas na storage. At maaari nating makuha ang zip archive na iyon mula sa storage na iyon anumang oras.
Pagkatapos ay awtomatiko namin itong ide-deploy sa dev environment. Doon namin ito sinusubukan, at kung magiging maayos ang lahat, ide-deploy namin ito sa stage. Kung magiging maayos ang lahat, ide-deploy namin ang parehong archive, ang parehong mga binary, na na-compile nang eksaktong isang beses, sa production.
Bukod pa rito, ang pagkakaroon ng gallery na tulad nito ay nakakatulong sa atin na matugunan ang mga panganib na ating tinugunan sa nakaraang slide nang pag-usapan natin ang pagbabalik sa dating bersyon. Kung hindi mo sinasadyang mai-deploy ang isang bagay nang mali, maaari mo itong kunin anumang iba pang nakaraang bersyon mula sa gallery na ito at i-deploy ito sa mga environment na iyon sa parehong paraan. Nagbibigay-daan ito sa iyo na madaling bumalik sa dating bersyon sakaling magkaroon ng sakuna.
May isa pang magandang kasanayan. Nauunawaan nating lahat na kapag ibinalik natin ang ating mga aplikasyon sa dating bersyon, maaaring mangahulugan ito na kailangan natin ang parehong imprastraktura mula sa nakaraang bersyon.
Kapag pinag-uusapan natin ang virtual infrastructure, maraming tao ang nag-iisip na ito ay isang bagay na inaayos ng mga admin. Kaya, kung kailangan mo, halimbawa, ng isang bagong server para subukan ang isang bagong bersyon ng iyong application, kailangan mong mag-file ng ticket sa mga admin o DevOps. Aabutin ng tatlong linggo ang DevOps para magawa ito. At pagkatapos ng tatlong linggo, sasabihin nila sa iyo na nakapag-install na kami ng virtual machine para sa iyo na may isang core, dalawang gigabytes ng RAM, at isang Windows server na walang DotNet. Sasabihin mo, "Pero gusto ko ang DotNet." Sasabihin nila, "Sige, bumalik ka pagkalipas ng tatlong linggo."
Ang ideya ay sa pamamagitan ng paggamit ng Infrastructure as Code practice, maaari mong ituring ang iyong virtual infrastructure bilang isa lamang mapagkukunan.
Kung mayroon sa inyo na bumubuo ng mga aplikasyon gamit ang DotNet, maaaring narinig na ninyo ang tungkol sa isang library na tinatawag na Entity Framework. Maaaring narinig na rin ninyo na ang Entity Framework ay isa sa mga pamamaraang aktibong isinusulong ng Microsoft. Para sa pagtatrabaho sa isang database, ang pamamaraang ito ay tinatawag na Code First. Ito ay kapag inilalarawan mo sa code kung paano mo gustong maging hitsura ng iyong database. Pagkatapos ay idine-deploy mo ang application. Kumokonekta ito sa database, awtomatikong tinutukoy kung aling mga talahanayan ang naroroon at alin ang nawawala, at lumilikha ng lahat ng kailangan mo.
Magagawa mo rin ito sa iyong imprastraktura. Hindi mahalaga kung kailangan mo ng database para sa isang proyekto o isang Windows server. Isa lamang itong resource. At maaari mong i-automate ang paglikha ng resource na ito, maaari mong i-automate ang configuration ng resource na ito. Samakatuwid, sa tuwing gusto mong subukan ang isang bagong konsepto o diskarte, hindi mo na kailangang mag-file ng DevOps ticket. Maaari ka lamang mag-deploy ng isang nakahiwalay na imprastraktura gamit ang mga handa nang template at script at patakbuhin ang lahat ng iyong mga eksperimento doon. Maaari mo itong burahin, kumuha ng ilang resulta, at mag-ulat pabalik.
Ang susunod na kasanayan, na umiiral din at mahalaga rin, ngunit kakaunti lamang ang gumagamit, ay ang Application Performance Monitoring.
May gusto lang akong sabihin tungkol sa Application Performance Monitoring. Ano ang pinakamahalaga sa gawaing ito? Parang pagkukumpuni ng apartment. Hindi ito isang pinal na estado, ito ay isang proseso. Kailangan mo itong gawin nang regular.
Sa isip, halos lahat ng build ay isasagawa gamit ang Application Performance Monitoring, bagama't, gaya ng naiintindihan mo, hindi ito laging posible. Ngunit, sa pinakamababa, dapat itong isagawa para sa bawat release.
Bakit ito mahalaga? Dahil kung bigla kang makaranas ng pagbaba ng performance, kailangan mong malinaw na maunawaan kung bakit. Kung ang iyong team ay may, halimbawa, dalawang linggong sprint, dapat mong i-deploy ang iyong application kahit isang beses kada dalawang linggo sa isang hiwalay na server na may nakapirming CPU, RAM, mga disk, atbp. At patakbuhin ang parehong mga performance test. Pagkatapos ay makukuha mo ang mga resulta. Tingnan kung paano ito nagbago mula noong nakaraang sprint.
At kung matutuklasan mong bumaba nang husto ang pagbaba, nangangahulugan ito na ito ay dahil lamang sa mga pagbabagong naganap sa nakalipas na dalawang linggo. Mas mabilis mong matutukoy at maitama ang problema. At muli, halos pareho lang ang mga sukatan na ito kung saan mo masusukat kung gaano mo ito katagumpay na nagawa.
Ang susunod nating gawain ay ang Configuration Management. Iilan lang ang mga taong sineseryoso ito. Pero maniwala ka sa akin, isa itong napakaseryosong bagay.
May nakakatawa akong kwento kamakailan. May mga lumapit sa akin at nagsabing, "Tulungan mo kaming magsagawa ng security audit ng aming application." Matagal naming pinag-aralan ang code, ipinaliwanag nila sa akin ang app, gumuhit ng mga diagram. At halos lahat ay lohikal, naiintindihan, at ligtas, pero may isa PERO! Mayroon silang mga configuration file sa source control, kabilang ang mga mula sa production, kasama ang IP database, mga login at password para sa pagkonekta sa mga database na ito, atbp.
At sasabihin ko, "Mga kasama, sige, na-secure ninyo ang inyong production environment gamit ang firewall, pero ang katotohanang mayroon kayong login at password para sa production database mismo sa source control, at mababasa ito ng sinumang developer, ay isang malaking panganib sa seguridad. At gaano man ka-secure ang inyong application mula sa perspektibo ng code, kung iiwan ninyo ito sa source control, hindi kayo kailanman makakapasa sa anumang audit." Iyan mismo ang tinutukoy ko.
Pamamahala ng configuration. Maaaring mayroon kaming iba't ibang configuration para sa iba't ibang environment. Halimbawa, maaaring mayroon kaming iba't ibang login at password para sa mga database para sa QA, demo, at production environment, atbp.
Maaari ring i-automate ang configuration na ito. Dapat itong laging hiwalay sa mismong application. Bakit? Dahil minsan mo lang binubuo ang application, at hindi na dapat mahalaga kung kumokonekta ka sa SQL server sa pamamagitan ng IP address na ito o ng IP address na iyon—dapat itong gumana nang pareho. Kaya kung mayroon sa inyo na nagha-hardcode pa rin ng connection string sa inyong code, tandaan na hahanapin ko kayo at parurusahan kung sakaling makasama ko kayo sa paggawa sa parehong proyekto. Dapat itong palaging gawin sa isang hiwalay na configuration, halimbawa, sa web.config.
At ang configuration na ito ay pinamamahalaan nang hiwalay, ibig sabihin ito ang sandali kung kailan ang isang developer at isang admin ay maaaring magsama-sama sa iisang silid. At maaaring sabihin ng developer, "Tingnan mo, narito ang mga binary ng aking application. Gumagana ang mga ito. Kailangan ng application ng database para gumana. Sa tabi ng mga binary ay isang file. Sa file na ito, ang field na ito ay responsable para sa pag-login, ito para sa password, ito para sa IP. I-deploy ito kahit saan." At para sa admin, ito ay simple at malinaw. Maaari nila itong i-deploy kahit saan, na pinamamahalaan ang configuration na ito.
At ang huling kasanayan na nais kong banggitin ay isa na talagang partikular sa cloud. At ito ay pinakaepektibo kung nagtatrabaho ka sa cloud. Ito ay tinatawag na Awtomatikong Pagbubura ng Iyong Kapaligiran.
Alam kong maraming tao mula sa mga pangkat na aking katrabaho ang naroroon sa kumperensyang ito. At ginagamit namin ang pagsasanay na ito sa lahat ng mga pangkat na aking katrabaho.
Bakit? Siyempre, maganda sana kung ang bawat developer ay may virtual machine na tumatakbo 24/7. Ngunit maaaring bago ito sa iyo, o marahil ay hindi mo pa napapansin, ngunit ang mga developer ay hindi nagtatrabaho 24/7. Karaniwan silang nagtatrabaho ng 8 oras sa isang araw. Sabihin nating maaga silang pumapasok sa trabaho, kumakain ng malaking pananghalian, at pumupunta sa gym. Sabihin nating 12 oras sa isang araw kung kailan 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 mga araw ng trabaho.
Alinsunod dito, sa mga karaniwang araw, ang makinang ito ay hindi dapat tumakbo nang 24 oras, kundi 12 oras lamang, at sa mga katapusan ng linggo, hindi ito dapat tumakbo nang kahit kailan. Tila napakasimple lang nito, ngunit ano ang mahalagang tandaan dito? Sa pamamagitan ng pagpapatupad ng simpleng kasanayang ito kasama ang pangunahing iskedyul na ito, mababawasan mo ang gastos sa pagpapanatili ng mga kapaligirang ito ng 70%—ibig sabihin, kukunin mo ang gastos ng iyong dev, QA, demo, at mga kapaligiran at hahatiin ito sa tatlo.
Ang tanong ay, ano ang dapat kong gawin sa natitirang pera? Halimbawa, bumili ng ReSharper para sa mga developer, kung hindi pa nila nagagawa. O kaya naman ay magdaos ng cocktail party. Kung dati ay mayroon kang isang kapaligiran kung saan nagtatrabaho ang dev, QA, at lahat ng iba pa, ngayon ay maaari ka nang lumikha ng tatlong magkakaibang kapaligiran na magkakahiwalay, para hindi na makialam ang mga tao sa isa't isa.
Tungkol sa slide tungkol sa patuloy na pagsukat ng pagganap, paano natin maihahambing ang pagganap kung ang ating proyekto ay mayroong 1,000 talaan ng database at pagkalipas ng dalawang buwan ay mayroon nang isang milyon? Paano natin mauunawaan kung bakit at ano ang punto ng pagsukat ng pagganap?
Magandang tanong ito dahil dapat mong palaging sukatin ang performance sa parehong resources. Ibig sabihin, kapag nag-deploy ka ng bagong code, sinusukat mo ang performance sa bagong code na ito. Halimbawa, kailangan mong subukan ang iba't ibang senaryo ng performance. Sabihin nating gusto mong suriin kung paano tumatakbo ang application sa ilalim ng magaan na load, na may 1,000 user at isang 5 gigabyte database. Susukatin mo at kukunin ang mga numero. Pagkatapos ay susubukan mo ang ibang senaryo. Halimbawa, 5,000 user, isang 1 terabyte database. Kukunin mo ang mga resulta at ise-save ang mga ito.
Ano ang mahalaga rito? Ang mahalaga rito ay depende sa senaryo, dami ng data, bilang ng mga sabay-sabay na gumagamit, at iba pa, maaari kang umabot sa ilang partikular na limitasyon. Halimbawa, ang limitasyon ng network card, ang limitasyon ng hard drive, o ang limitasyon ng processor. Iyan ang kailangan mong maunawaan. Maaabot mo ang ilang partikular na limitasyon sa iba't ibang senaryo. At kailangan mong maunawaan ang mga numero kapag naabot mo ang mga ito.
Pinag-uusapan ba natin dito ang mga sukat ng pagganap sa isang nakalaang kapaligiran sa pagsubok? Kaya hindi ito produksyon?
Oo, hindi ito produksyon, ito ay isang kapaligirang pangsubok, na palaging pareho para maihambing mo ito sa mga nakaraang sukat.
Nakuha ko, salamat!
Kung walang tanong, sa tingin ko ay matatapos na natin ito. Salamat!
Pinagmulan: www.habr.com
