Txostenak DevOps praktika batzuei buruz hitz egingo du, baina garatzaile baten ikuspuntutik. Normalean, DevOps-ekin bat egiten duten ingeniari guztiek hainbat urteko esperientzia administratiboa dute jada. Baina horrek ez du esan nahi hemen garatzaileentzako lekurik ez dagoenik. Sarritan, garatzaileak lanpetuta daude "eguneko premiazko hurrengo akatsa" konpontzen, eta ez dute DevOps eremuari begirada azkar bat emateko astirik. Egilearen ustez, DevOps, lehenik eta behin, zentzu komuna da. Bigarrenik, eraginkorragoa izateko aukera bat da. Garatzailea bazara, zentzu ona baduzu eta talde-jokalari gisa eraginkorragoa izan nahi baduzu, txosten hau zuretzat da.
Utzi neure burua aurkezten, guztiz onartzen dut gelan ezagutzen ez nauten jendea dagoela. Nire izena Anton Boyko da, Microsoft Azure MVP bat naiz. Zer da MVP? Hau Model-View-Presenter da. Model-View-Presenter ni naiz zehazki.
Horrez gain, gaur egun Ciklum-en soluzio-arkitektu postua daukat. Eta duela gutxi erosi nuen neure buruari hain domeinu eder bat, eta posta elektronikoa eguneratu nuen, aurkezpenetan erakutsi ohi dudana. Honetan idatz diezazukezu: ni [txakurra] byokoant.pro. Posta elektronikoz egin diezadakezu galderekin. Nik normalean erantzuten diet. Gauza bakarra da ez nukeela gustatuko bi gairi dagozkion galderak posta elektronikoz jasotzea: politika eta erlijioa. Beste guztiari buruz idatz diezazukezu posta elektronikoz. Denbora pasako da, erantzungo dut.
Zure buruari buruzko hitz batzuk:
- 10 urte daramatzat alor honetan.
- Microsoften lan egin nuen.
- 2014an nonbait sortu genuen Ukrainako Azure komunitatearen aita sortzailea naiz. Eta oraindik badugu eta garatzen ari gara.
- Ukrainan antolatzen ari garen Azure konferentziaren sortzailearen aita ere naiz.
- Kyiv-en Global Azure Bootcamp-a antolatzen ere laguntzen dut.
- Esan bezala, Microsoft Azure MVP bat naiz.
- Kongresuetan askotan hitz egiten dut. Asko gustatzen zait hitzaldietan hitz egitea. Azken urtean 40 bat aldiz eman ahal izan nuen. Ukraina, Bielorrusia, Polonia, Bulgaria, Suedia, Danimarka, Herbehereak, Espainiatik pasatzen bazara edo Europako beste herrialde bat ematen edo hartzen baduzu, baliteke korrontean hodeiaren gaia duen konferentzia batera joaten zarenean, hizlarien zerrendan ikusiko nauzu.
- Star Trek zalea ere banaiz.
Hitz egin dezagun apur bat Agendari buruz. Gure Agenda oso erraza da:
- DevOps zer den hitz egingo dugu. Esan dezagun zergatik den garrantzitsua. Aurretik, DevOps zure curriculumean idatzi zenuen gako-hitz bat zen eta berehala + $ 500 soldata jaso zituen. Orain, adibidez, blockchain idatzi behar duzu zure curriculumean + 500 dolar lortzeko zure soldatara.
- Eta gero, hau zer den pixka bat ulertzen dugunean, DevOps praktikak zer diren hitz egingo dugu. Baina ez hainbeste DevOps-en testuinguruan, oro har, baizik eta garatzaileentzat interesgarriak izan daitezkeen DevOps praktika horiei buruz. Esango dizut zergatik izan daitezkeen interesgarriak zuretzat. Esango dizut zergatik egin behar duzun hori eta nola lagundu dezakeen min gutxiago jasaten.
Jende askok erakusten duen irudi tradizionala. Hori da proiektu askotan gertatzen dena. Hau da, gure softwarea onartzen duten garapen eta operazio sailak ditugu. Eta sail hauek ez dira elkarren artean komunikatzen.
Agian, DevOps eta eragiketa sailetan hain argi sentitu ez bazenuen, Dev eta QA sailekin analogia egin dezakezu. Badago softwarea garatzen duen jendea eta garatzaileen ikuspuntutik txarrak diren QA jendea dago. Esate baterako, nire kode zoragarria biltegira konprometitzen dut, eta han eserita dagoen txapeldun bat dago kode hau itzultzen didana eta zure kodea txarra dela esaten duena.
Hau dena gertatzen da jendea ez delako elkarren artean komunikatzen. Eta pakete batzuk, aplikazio batzuk elkarri botatzen dizkiote gaizki-ulertuaren horma batetik eta haiekin zerbait egiten saiatzen dira.
Hain zuzen, horma hori da DevOps kultura suntsitzeko diseinatuta dagoena, hau da. jendea elkarren artean komunikatzera behartu eta, gutxienez, proiektuko pertsona ezberdinek zer egiten duten eta euren lana zergatik den garrantzitsua ulertzera.
Eta DevOps-i buruz hitz egiten dugunean, norbaitek esango dizu DevOps proiektuak etengabeko integrazioa duenean dela; norbaitek esango du DevOps dela proiektuak "azpiegitura kode gisa" praktika ezartzen badu; norbaitek esango du DevOps-en lehen urratsa ezaugarrien adarkatzea dela, ezaugarrien banderak.
Funtsean, hau guztia egia da bere erara. Baina hauek ditugun azken praktikak besterik ez dira. Praktika hauetara pasatu aurretik, zure proiektuan Dev-Ops metodologia ezartzeko 3 etapak erakusten dituen diapositiba hau ikustea proposatzen dizut, zure enpresan.
Diapositiba honek bigarren izen ez ofizial bat ere badu. Sarean bilatu dezakezu DevOps-eko 3 mosketariak zer diren jakiteko. Baliteke artikulu hau aurkitzea. Zergatik 3 Mosketari? Hona hemen azpian: pertsonak, prozesuak eta produktuak, hau da. PPP β Porthos, Porthos eta Porthos. Hona hemen DevOps-eko 3 mosketariak. Artikulu honek zehatzago deskribatzen du zergatik den garrantzitsua eta zertan datzan.
DevOps kultura inplementatzen hasten zarenean, oso garrantzitsua da hurrengo ordenan inplementatzea.
Hasieran jendearekin hitz egin behar duzu. Eta jendeari azaldu behar diozu zer den eta nola lor ditzaketen onura batzuk.
Gure hitzaldia DotNet Fest izena du. Eta antolatzaileek esan didatenez, batez ere garatzaileen ikusle bat gonbidatu genuen hona, beraz, espero dut aretoko jende gehienak garapenean parte hartzea.
Jendeari buruz hitz egingo dugu, garatzaileek egunero egin nahi dutenari buruz hitz egingo dugu. Zer nahi dute gehien? Kode berri batzuk idatzi nahi dituzte, marko berriak erabili, funtzio berriak sortu. Zer nahi dute gutxien garatzaileek? Konpondu akats zaharrak. Espero dut nirekin ados egotea. Hau da garatzaileek nahi dutena. Ezaugarri berriak idatzi nahi dituzte, ez dituzte akatsak konpondu nahi.
Garatzaile jakin batek sortzen dituen akatsen kopurua bere besoak zein zuzen dauden eta sorbaldetatik zenbat hazten diren, eta ez ipurdiko poltsikoetatik, araberakoa da. Baina, hala ere, proiektu handi bat dugunean, batzuetan gertatzen da ezinezkoa dela guztiaren jarraipena egitea, beraz, ondo legoke kode egonkorrago eta kalitate handiagoko idazten lagunduko diguten zenbait planteamendu erabiltzea.
Zer nahi dute gehien QAek? Ez dakit aretoan dauden. Zaila egiten zait QA nahi dudala esatea, ez naizelako inoiz izan. Eta mutilei erasorik ez, esango da espero dudala inoiz egingo ez dudala. Baina ez haien lana zentzugabetzat eta alferrikakoa dela uste dudalako, baizik eta ez dudalako nire burua lan hau modu eraginkorrean egin dezakeen pertsonatzat hartzen, beraz, ez naiz egiten saiatuko ere. Baina ulertzen dudanaren arabera, QA-k gehien gustatzen ez zaiona goizean lanera joatea da, etengabe nolabaiteko erregresio-probak eginez, duela 3 sprint garatzaileei jakinarazi zizkieten akats berdinak zapalduz eta esanez: βNoiz egingo duzu. , Monsieur D 'Artagnan, konpondu akats hau.' Eta D'Artagnan jaunak erantzuten dio: "Bai, bai, bai, dagoeneko konpondu dut". Eta nola gertatzen den akats bat konpondu dudala eta bidean 5 egin ditudala.
Produkzioan irtenbide hau onartzen duten pertsonek irtenbide honek akatsik gabe funtzionatzea nahi dute, ostiralero zerbitzaria berrabiarazi beharrik izan ez dezaten, jende normal guztiak tabernara joaten direnean. Ostiralean zabaldutako garatzaileak, administratzaileak larunbatera arte esertzen dira, inplementazio hau martxan jarri eta konpondu nahian.
Eta jendeari arazo berdinak konpontzera zuzenduta daudela azaltzen diozunean, prozesuak formalizatzera pasa zaitezke. Oso garrantzitsua da. Zergatik? Zeren "formalizazioa" esaten dugunean, garrantzitsua da zure prozesuak nola gertatzen diren deskribatzea ezpainzapi batean behintzat. Ulertu behar duzu, adibidez, QA ingurune batean edo produkzio-ingurune batera inplementatzen bazara, beti ordena honetan gertatzen dela; fase hauetan, adibidez, unitate-proba automatikoak eta UI probak egiten ditugu. Inplementatu ondoren, hedapena ondo edo gaizki joan den egiaztatzen dugu. Baina dagoeneko duzu ekoizpenera zabaltzen duzunean behin eta berriro errepikatu beharreko ekintzen zerrenda argia.
Eta zure prozesuak formalizatzen direnean soilik hasten zara prozesu horiek automatizatzen lagunduko dizuten produktuak hautatzen.
Zoritxarrez, askotan ikusten dut hori alderantziz gertatzen dela. Norbaitek "DevOps" hitza entzun bezain laster, Jenkins instalatzea iradokitzen du berehala, uste baitute Jenkins instalatu bezain laster DevOps izango dutela. Jenkins instalatu zuten, Jenkins webguneko "Nola" artikuluak irakurri zituzten, Nola egin artikulu hauetan prozesuak sartzen saiatu ziren, eta gero jendearengana etorri eta jendea makurtu zen, liburuak horrela egin behar duzula esaten zuela esanez. beraz, horrela egiten dugu.
Ez da Jenkins tresna txarra denik. Ez dut hori inola ere esan nahi. Baina hau produktuetako bat besterik ez da. Eta zein produktu erabiltzen duzun zure azken erabakia izan behar du, eta ez inola ere lehen erabakia. Zure produktua ez da kulturaren eta planteamenduen ezarpenak bultzatu behar. Hau oso garrantzitsua da ulertzea, horregatik denbora asko ematen dut diapositiba honetan eta hau guztia azaltzen dut hainbeste denboran.
Hitz egin dezagun, oro har, DevOps praktikei buruz. Zer dira? Zein da aldea? Nola probatu? Zergatik dira garrantzitsuak?
Entzun zenezakeen lehen praktika Integrazio jarraitua deritzo. Beharbada, proiektuko norbaitek etengabeko integrazioa (CI) du.
Arazorik handiena da gehienetan pertsona bati galdetzen diodanean: "Ba al duzu CI proiektuan?" eta esaten du: βBaiβ, orduan zer egiten duen galdetzean, automatizazio prozesu osoa deskribatzen dit. Hau ez da guztiz egia.
Izan ere, CI praktikak pertsona ezberdinek idazten duten kodea kode-oinarri bakar batean integratzea besterik ez du helburu. Hori da dena.
CIrekin batera, beste praktika batzuk egon ohi dira bidean, hala nola, Etengabeko Inplementapena, Argitalpenen Kudeaketa, baina horri buruz geroago hitz egingo dugu.
CIk berak esaten digu pertsona ezberdinek kodea idazten dutela eta kode hori etengabe kode oinarri bakar batean integratuta egon behar dela.
Zer ematen digu horrek eta zergatik da garrantzitsua? DotNet badugu, hori ona da, konpilatutako hizkuntza bat da, gure aplikazioa konpilatu dezakegu. Konpilatzen bada, seinale ona da dagoeneko. Horrek ez du ezer esan nahi oraindik, baina gutxienez konpilatu dezakegun lehen seinale ona da.
Ondoren, proba batzuk egin ditzakegu, eta hori ere praktika bereizia da. Probak guztiak berdeak dira - hau da bigarren seinale ona. Baina berriro ere, honek ez du ezer esan nahi.
Baina zergatik egingo zenuke hau? Gaur hitz egingo dudan praktika guztiek balio berdina dute gutxi gorabehera, hau da, gutxi gorabehera onura berdinak dira eta, gainera, modu berean neurtzen dira gutxi gorabehera.
Lehenik eta behin, entrega bizkortzeko aukera ematen du. Nola ematen dizu bidalketa azkartzeko? Gure kode oinarrian aldaketa berri batzuk egiten ditugunean, berehala saiatu gaitezke kode honekin zerbait egiten. Ez dugu itxaron osteguna iritsi arte, ostegunean QA Environment-era kaleratzen dugulako, hemen bertan eta hementxe egiten dugu.
Nire bizitzako istorio triste bat kontatuko dizut. Aspaldi zen, oraindik gazte eta guapo nintzela. Orain jada gaztea naiz, ederra eta inteligentea eta apala. Duela denbora pixka bat proiektu batean egon nintzen. 30 bat garatzailez osatutako talde handi bat genuen. Eta 10 bat urtez garatu zen Enterprise proiektu handi eta handi bat genuen. Eta adar desberdinak genituen. Biltegian garatzaileak ibiltzen ziren adar bat genuen. Eta ekoizpenean dagoen kodearen bertsioa erakusten zuen adar bat zegoen.
Ekoizpen adarra garatzaileentzat eskuragarri zegoen adarrarekin 3 hilabete atzeratuta zegoen. Zer esan nahi du honek? Horrek esan nahi du garatzaileen erruagatik produkziora doan akats bat dudan bezain laster nonbait, baimendu dutelako, eta QAren erruagatik, begiratu dutelako, horrek esan nahi du bat jasotzen badut. Ekoizpenerako konponketa egiteko zeregina, orduan nire kodearen aldaketak atzera egin behar ditut duela 3 hilabete. Duela 3 hilabete zer nuen gogoratu eta bertan konpontzen saiatu behar dut.
Oraindik esperientzia hau izan ez baduzu, zure etxeko proiektuan proba dezakezu. Gauza nagusia da ez probatu komertzio batean. Idatzi kode-lerro pare bat, ahaztu sei hilabetez, eta gero itzuli eta saiatu azkar azaltzen kode-lerro horiek zertan diren eta nola konpondu edo optimiza ditzakezun. Oso-oso esperientzia zirraragarria da.
Etengabeko Integrazio praktika bat badugu, honek tresna automatizatu batzuekin egiaztatzeko aukera ematen digu hemen eta oraintxe bertan, nire kodea idatzi bezain laster. Horrek ez dit argazki osoa emango, baina, hala ere, arrisku batzuk gutxienez kenduko ditu. Eta balizko akatsik badago, oraintxe bertan jakingo dut, hau da, literalki minutu pare batean. Ez dut 3 hilabete atzera egin beharko. 2 minutu baino ez ditut atzera egin beharko. Kafe-makina on batek ez du 2 minututan kafea prestatzeko astirik izango, beraz, polita da.
Horrek badu balioa proiektu bakoitzean behin eta berriz errepika daitekeela, hau da. ez bakarrik zuk ezarri duzuna. Praktika bera eta CI bera errepikatu ditzakezu proiektuan egiten duzun aldaketa berri bakoitzeko. Horri esker, baliabideak optimiza ditzakezu zure taldeak modu eraginkorragoan lan egiten duelako. Aurrerantzean ez duzu izango duela 3 hilabeterekin lan egin zenuen kodetik akats bat etortzen zaizun egoerarik. Jada ez duzu testuinguru-aldaketarik izango esertzen zarenean eta lehen bi orduak orduan gertatu zena ulertzen saiatzen eta zerbait zuzentzen hasi baino lehen testuinguruaren mamian sartzen zarenean.
Nola neur dezakegu praktika honen arrakasta edo porrota? Ugazaba handiari CI proiektuan inplementatu dugunaren berri ematen badiozu, bla bla bla entzuten du. Inplementatu dugu, ados, baina zergatik, zer ekarri digu, nola neurtzen dugu, zein zuzen edo gaizki ezartzen ari gara?
Lehenengoa da, CI-ri esker, gero eta sarriago zabaldu dezakegula, eta maizago, hain zuzen ere, gure kodea egonkorragoa delako potentzialki. Modu berean, errore bat aurkitzeko gure denbora murrizten da eta errore hori zuzentzeko denbora, hain zuzen ere, sistemaren erantzuna jasotzen dugulako hemen bertan eta une honetan, gure kodearekin zer dagoen gaizki.
Daukagun beste praktika bat Automation Testing praktika da, gehienetan CI praktikarekin etortzen dena. Eskuz eskutik doaz.
Zer da garrantzitsua hemen ulertzea? Garrantzitsua da ulertzea gure probak desberdinak direla. Eta proba automatizatu bakoitzak bere arazoak konpontzera zuzenduta dago. Modulu bat bereizita probatzeko aukera ematen duten unitate-probak ditugu, adibidez, hau da. Nola funtzionatzen du hutsean? Hau ona da.
Modulu desberdinak elkarren artean nola integratzen diren ulertzeko aukera ematen duten integrazio probak ere baditugu. Ona da ere.
UI automatizazio probak izan ditzakegu, UI-rekin egindako lanak bezeroak ezarritako zenbait baldintza betetzen dituen egiaztatzeko, etab.
Exekutatzen dituzun proba zehatzek zenbateko maiztasunarekin exekutatzen dituzun eragin dezakete. Unitateko probak laburrak eta txikiak izan ohi dira. Eta aldizka abiarazi daitezke.
UI automatizazio probei buruz ari bagara, orduan ona da zure proiektua txikia bada. Zure interfazearen automatizazio-probak denbora egokia izan dezakete. Baina normalean UI automatizazioaren proba proiektu handi batean ordu batzuk hartzen dituen zerbait da. Eta ona da ordu batzuk badira. Gauza bakarra da ez duela ezertarako balio horiek exekutatzeko eraikuntza bakoitzean. Zentzuzkoa da gauez exekutatzeko. Eta denak goizean lanera etortzen zirenean: bai probatzaileak bai garatzaileak, gauez UI autotesta egin genuela eta emaitza hauek lortu genituen txosten moduko bat jaso zuten. Eta hemen, zure produktuak baldintza batzuk betetzen dituela egiaztatuko duen zerbitzari baten lan ordu bat askoz merkeagoa izango da QA ingeniari beraren ordu bat baino, nahiz eta janari eta eskerrak lortzeko lan egiten duen Junior QA ingeniari bat izan. Dena den, ordubeteko makinaren funtzionamendua merkeagoa izango da. Horregatik, zentzuzkoa da horretan inbertitzea.
Badaukat beste proiektu bat lantzen ari naizena. Proiektu honetan bi asteko sprintak egin genituen. Proiektua handia zen, garrantzitsua finantza sektorearentzat, eta ezin izan zen akatsik egin. Eta bi asteko esprintaren ondoren, garapen-zikloari proba-prozesu bat jarraitu zitzaion, eta beste 4 aste behar izan zituen. Saiatu tragediaren tamaina imajinatzen. Bi astez kodea idazten dugu, ondoren CodeFreeze egiten dugu, aplikazioaren bertsio berri batean paketatzen dugu eta probatzaileetara zabaltzen dugu. Probatzaileek beste 4 astez probatzen dute, hau da. Probatzen ari diren bitartean, beste bi bertsio prestatzeko denbora dugu. Hau benetan kasu tristea da.
Eta esan genien produktiboagoa izan nahi baduzu, zentzuzkoa dela Proba Automatizatuen praktikak ezartzea, horrek min egiten zaituelako hemen, oraintxe bertan.
Etengabeko hedapena praktikatu. Bikaina, eraikitzea egin duzu. Hau dagoeneko ona da. Zure kodea konpilatu da. Orain polita litzateke eraikuntza hau ingurune batzuetan zabaltzea. Demagun garatzaileentzako ingurune batean.
Zergatik da garrantzitsua? Lehenik eta behin, inplementazio-prozesuarekin nolako arrakasta duzun ikus dezakezu. Horrelako proiektuak ezagutu ditut, galdetzen dudanean: βNola zabaldu aplikazioaren bertsio berri bat?β, mutilek esaten didate: βMundu egiten dugu eta zip artxibo batean sartzen dugu. Administratzaileari postaz bidaltzen diogu. Administratzaileak artxibo hau deskargatu eta zabaltzen du. Eta bulego osoa otoitz egiten hasten da zerbitzariak bertsio berria jaso dezanΒ».
Has gaitezen zerbait sinple batekin. Adibidez, CSS artxiboan jartzea ahaztu zaie edo java-script fitxategiaren izenan hashtag-a aldatzea ahaztu zaie. Eta zerbitzariari eskaera bat egiten diogunean, nabigatzaileak jada java-script fitxategi hau duela pentsatzen du eta ez deskargatzea erabakitzen du. Eta bazegoen bertsio zahar bat, zerbait falta zen. Oro har, arazo asko egon daitezke. Hori dela eta, Etengabeko Hedapenaren praktikak, gutxienez, erreferentziazko irudi garbi bat hartu eta ingurune guztiz garbi batera igoko bazenu zer gertatuko litzatekeen probatzeko aukera ematen du. Honek nora eramaten duen ikus dezakezu.
Gainera, kodea elkarren artean integratzen duzunean, alegia. komandoaren artean, honek UI-an nola dagoen ikusteko aukera ematen du.
Banilla java-script asko erabiltzen direnean gertatzen den arazoetako bat da bi garatzaileek leiho-objektuan izen bereko aldagai bat deklaratu dutela. Eta gero, zure zortearen arabera. Noren java-script fitxategia bigarren ateratzen den bestearen aldaketak gainidatziko ditu. Oso zirraragarria da ere. Sartzen zara: gauza batek funtzionatzen du pertsona bati, beste batek ez dio balio beste bati. Eta "zoragarria" da ekoizpenean dena ateratzen denean.
Daukagun hurrengo praktika Berreskuratze automatikoaren praktika da, hots, aplikazioaren aurreko bertsiora itzultzea.
Zergatik da garrantzitsua hau garatzaileentzat? Bada oraindik 90eko hamarkada urrun eta urruna gogoratzen duena, ordenagailuak handiak zirenean eta programak txikiak zirenean. Eta web garapenerako bide bakarra PHP bidez izan zen. Ez da PHP hizkuntza txarra denik, hala den arren.
Baina arazoa bestelakoa zen. Gure php gunearen bertsio berri bat zabaldu genuenean, nola zabaldu genuen? Gehienetan Far Manager edo beste zerbait ireki genuen. Eta fitxategi hauek FTPra kargatu ditu. Eta bat-batean konturatu ginen akats txiki eta txiki batzuk genituela, adibidez, puntu eta koma jartzea ahaztu zitzaigun edo datu-basearen pasahitza aldatzea ahaztu zitzaigun, eta datu-basearen pasahitz bat dago, tokiko ostalarian dagoena. Eta FTPra azkar konektatzea eta fitxategiak bertan editatzea erabakitzen dugu. Hau sua besterik ez da! Hau da 90eko hamarkadan ezaguna zena.
Baina, egutegiari begiratu ez badiozu, 90eko hamarkada duela ia 30 urte izan zen. Orain dena apur bat ezberdinean gertatzen ari da. Eta saiatu tragediaren tamaina imajinatzen esaten dizutenean: Β«Produkziora zabaldu ginen, baina zerbait gaizki atera zen bertan. Hona hemen zure FTP saio-hasiera eta pasahitza, konektatu produkziora eta konpondu azkar han". Chuck Norris bazara, honek funtzionatuko du. Hala ez bada, akats bat konpontzen baduzu, 10 gehiago egingo dituzula arriskatzen duzu. Horregatik, hain zuzen, aurreko bertsiora itzultzeko praktika honek asko lor ditzakezu.
Nahiz eta zerbait txarra nolabait prod sartu nonbait, orduan txarra da, baina ez hilgarria. Daukazun aurreko bertsiora itzuli dezakezu. Deitu segurtasun kopia, terminologia horretan errazagoa bada hautematea. Aurreko bertsio honetara atzera egin dezakezu, eta erabiltzaileek zure produktuarekin lan egin ahal izango dute, eta buffer denbora egokia izango duzu. Lasai, presarik gabe, hau guztia hartu eta lokalean probatu, konpondu eta gero bertsio berri bat igo dezakezu. Benetan zentzuzkoa da hau egiteak.
Orain saia gaitezen nolabait aurreko bi praktikak elkarrekin uztartzen. Hirugarren bat lortuko dugu Release Management izenekoa.
Etengabeko Hedapenari buruz hitz egiten dugunean bere forma klasikoan, esaten dugu biltegitik adar batzuetako kodea atera behar dugula, konpilatu eta zabaldu. Ona da ingurune bera badugu. Hainbat ingurune baditugu, horrek esan nahi du aldi bakoitzean kodea atera behar dugula, baita konpromezu beretik ere. Aldi bakoitzean aterako dugu, aldi bakoitzean eraikiko dugu eta ingurune berri batera zabalduko dugu. Lehenik eta behin, hau da denbora, izan ere, proiektu bat eraikitzeko, handi bat baduzu eta 90eko hamarkadatik etorri bazara, hainbat ordu behar izan daitezke.
Gainera, bada beste tristura bat. Eraikitzen duzunean, nahiz eta makina berean, iturri berdinak eraikiko dituzu, oraindik ez duzu ziurtatzen makina hau azken eraikuntzan zegoen egoera berean dagoenik.
Demagun norbait sartu eta DotNet eguneratu duela zuretzat edo, alderantziz, norbaitek zerbait ezabatzea erabaki duela. Eta orduan disonantzia kognitiboa duzu duela bi aste konpromiso honetatik eraikitzen ari ginen eta dena ondo zegoen, baina orain badirudi makina bera, konpromezu bera, eraikitzen saiatzen ari garen kode bera, baina ez dabil funtzionatzen. . Denbora luzez arituko zara horri aurre egiten eta ez da kontua asmatuko duzunik. Gutxienez, nerbioak asko hondatuko dituzu.
Horregatik, Release Management praktikak artefaktuen biltegi edo galeria edo liburutegi izeneko abstrakzio gehigarri bat sartzea proposatzen du. Nahi duzun moduan deitu diezaiokezu.
Ideia nagusia da hor nolabaiteko konpromisoa izan bezain laster, esate baterako, gure ingurune desberdinetara zabaltzeko prest gauden adar batean, konpromiso honetatik aplikazioak biltzen ditugula eta aplikazio honetarako behar dugun guztia, paketatzen dugu. zip artxibo batean eta gorde biltegiratze fidagarri batean. Eta biltegiratze honetatik edozein unetan lor dezakegu zip artxibo hau.
Ondoren, hartu eta automatikoki garatzaileen ingurunera zabalduko dugu. Bertan lasterketa egiten dugu, eta dena ondo badago, etapara zabaltzen gara. Dena ondo badago, artxibo bera zabaltzen dugu ekoizpenera, bitar berdinak, zehatz-mehatz behin konpilatuta.
Gainera, horrelako galeria bat dugunean, aurreko bertsiora itzultzeari buruz hitz egin genuenean azken diapositiban jorratu genituen arriskuei aurre egiten laguntzen digu. Ustekabean zerbait gaizki zabaldu baduzu, galeria honetatik aurreko beste edozein bertsio hartu eta ingurune horietara desplega dezakezu modu berean. Horrek aurreko bertsiora erraz itzultzeko aukera ematen du zerbait gaizki gertatzen bada.
Bada beste praktika handi bat. Zuk eta biok ulertzen dugu gure aplikazioak aurreko bertsio batera itzultzen ditugunean, horrek aurreko bertsioaren azpiegitura ere behar dugula esan nahi duela.
Azpiegitura birtualei buruz hitz egiten dugunean, jende askok pentsatzen du hau administratzaileek konfiguratzen duten zerbait dela. Eta, esate baterako, zure aplikazioaren bertsio berri bat probatu nahi duzun zerbitzari berri bat lortu behar baduzu, txartel bat idatzi behar diezu administratzaileei edo debopeei. Devops-ek 3 aste beharko ditu horretarako. Eta 3 asteren buruan esango dizute makina birtual bat instalatu dugula zuretzat, nukleo batekin, bi gigabyte RAM eta DotNet gabeko Windows zerbitzari batekin. Zuk diozu: "Baina DotNet nahi nuen". Haiek: "Ok, itzuli 3 aste barru".
Ideia da Azpiegitura Kode praktika gisa erabiliz, zure azpiegitura birtuala beste baliabide bat bezala trata dezakezula.
Agian, zuetakoren bat DotNet-en aplikazioak garatzen ari bazara, Entity Framework izeneko liburutegi baten berri izan dezakezu. Eta agian entzun izana Entity Framework Microsoft-ek aktiboki bultzatzen duen planteamenduetako bat dela. Datu-base batekin lan egiteko, Code First izeneko ikuspegia da. Hau da, kodean deskribatzen duzunean zure datu-basea nola begiratu nahi duzun. Eta gero aplikazioa zabaltzen duzu. Datu basera konektatzen da, berak zehazten du zein taula dauden eta zein ez, eta behar duzun guztia sortzen du.
Gauza bera egin dezakezu zure azpiegiturekin. Ez dago alderik proiektu baterako datu-base bat behar duzun ala proiektu baterako Windows zerbitzari bat behar duzun ala ez. Baliabide bat besterik ez da. Eta baliabide honen sorrera automatizatu dezakezu, baliabide honen konfigurazioa automatizatu dezakezu. Horren arabera, kontzeptu berriren bat, ikuspegi berriren bat probatu nahi duzun bakoitzean, ez duzu txartel bat idatzi beharko devops-en, zuretzako azpiegitura isolatu bat zabaldu dezakezu prest egindako txantiloietatik, prest egindako scriptetatik eta inplementatu. hor zure esperimentu guztiak. Hau ezabatu, emaitza batzuk lortu eta horri buruzko informazio gehiago eman dezakezu.
Hurrengo praktika, hori ere badago eta garrantzitsua dena, baina jende gutxik erabiltzen duena, Aplikazioen Errendimenduaren Monitorizazioa da.
Gauza bakarra esan nahi nuen Aplikazioen Errendimenduaren Monitorizazioari buruz. Zer da garrantzitsuena praktika honek? Hau da Aplikazioen Errendimenduaren Monitorizazioa apartamentu bat konpontzearen parekoa. Hau ez da azken egoera bat, prozesu bat da. Aldian-aldian egin behar duzu.
Modu onean, ondo legoke aplikazioen errendimenduaren jarraipena egitea ia eraikuntza guztietan, nahiz eta, ulertzen duzunez, hori beti posible ez den. Baina, gutxienez, kaleratze bakoitzerako egin behar da.
Zergatik da garrantzitsua? Zeren eta bat-batean errendimenduan jaitsiera bat jasaten baduzu, orduan argi ulertu behar duzu zergatik. Zure taldeak, demagun, bi asteko esprintak baditu, bi astean behin gutxienez zure aplikazioa zerbitzari bereizi batean zabaldu beharko zenuke, non argi eta garbi finkatutako prozesadorea, RAM, diskoak, etab. Eta exekutatu errendimendu-proba berdinak. . Emaitza lortzen duzu. Ikusi nola aldatu den aurreko esprintetik.
Eta jakiten baduzu beherakada nabarmen jaitsi zela nonbait, azken bi asteotan gertatutako aldaketengatik izan zela esan nahi du. Horrek arazoa askoz azkarrago identifikatu eta konpontzeko aukera emango dizu. Eta berriro ere, gutxi gorabehera neurri berdinak dira, zeinen bidez egin duzun arrakasta neurtu dezakezun.
Daukagun hurrengo praktika Konfigurazioa Kudeatzeko praktika da. Oso gutxi dira hau serio hartzen dutenak. Baina sinetsi iezadazu, hau benetan gauza serioa da.
Istorio barregarri bat izan zen duela gutxi. Mutilak niregana etorri ziren eta esan zidaten: "Lagun iezaguzu gure aplikazioaren segurtasun auditoria egiten". Kodea elkarrekin begiratu genuen denbora luzez, aplikazioaren berri eman zidaten, diagramak marraztu zituzten. Eta gehi edo ken dena zen logikoa, ulergarria, segurua, baina bazegoen BAINA! Iturburu-kontrolean konfigurazio fitxategiak zituzten, IP datu-basearekin produkziokoak barne, datu-base horietara konektatzeko saio-hasiera eta pasahitzak, etab.
Eta nik esaten diot: "Mutilak, ados, zure produkzio-ingurunea suebaki batekin itxi duzu, baina ekoizpen-datu-basearen saio-hasiera eta pasahitza iturburu-kontrolean edukitzea eta edozein garatzailek irakur dezakeela segurtasun-arrisku handia da dagoeneko. . Eta edozein dela ere zure aplikazioa kodearen ikuspuntutik oso segurua den, iturburu-kontrolean uzten baduzu, ez duzu inoiz inondik inora inongo auditoria gaindituko". Horretaz ari naiz.
Konfigurazioaren kudeaketa. Ingurune desberdinetan konfigurazio desberdinak izan ditzakegu. Adibidez, datu-baseetarako saio-hasiera eta pasahitz desberdinak izan ditzakegu QArako, demorako, ekoizpen ingurunerako, etab.
Konfigurazio hau automatizatu ere egin daiteke. Beti aplikaziotik bereizita egon behar da. Zergatik? Aplikazioa behin eraiki zenuenez, eta orduan aplikazioari berdin dio SQL zerbitzariari halako eta halako IP edo halako IP baten bidez konektatzen zaren ala ez, berdin funtzionatu beharko luke. Hori dela eta, bat-batean zuetako batek oraindik konexio-katea kodean gogor kodetzen badu, gogoratu aurkituko zaitudala eta zigortuko zaitudala nirekin proiektu berean aurkitzen bazara. Hau beti bereizitako konfigurazio batean jartzen da, adibidez, web.config-en.
Eta konfigurazio hori dagoeneko bereiz kudeatzen da, hau da, garatzaile bat eta administratzaile bat gela berean eser daitezkeen unea da. Eta garatzaileak esan dezake: βBegira, hona hemen nire aplikazioaren bitarrak. Lan egiten dute. Aplikazioak datu-base bat behar du funtzionatzeko. Hemen bitarren ondoan fitxategi bat dago. Fitxategi honetan, eremu hau saio-hasieraz arduratzen da, hau pasahitzarena da, hau IParena. Zabal ezazu edonon". Eta erraza eta argia da administratzailearentzat. Benetan heda dezake edonon konfigurazio hau kudeatuz.
Eta hitz egin nahiko nukeen azken praktika hodeiekin oso-oso lotuta dagoen praktika bat da. Eta hodeian lan egiten baduzu efektu handiena dakar. Hau zure ingurunea automatikoki kentzea da.
Badakit hitzaldi honetan lan egiten dudan taldeetako hainbat pertsona daudela. Eta lan egiten dudan talde guztiekin praktika hau erabiltzen dugu.
Zergatik? Noski, bikaina litzateke garatzaile bakoitzak 24/7 funtzionatuko lukeen makina birtual bat edukitzea. Baina agian hau albiste da zuretzat, agian ez duzu kasurik egin, baina garatzaileak berak ez du 24/7 funtzionatzen. Garatzaile batek egunean 8 ordu lan egiten du normalean. Lanera goiz etortzen bada ere, bazkari handi bat egiten du eta bertan kiroldegira joaten da. Izan bedi egunean 12 ordu garatzaileak baliabide horiek benetan erabiltzen dituenean. Gure legediaren arabera, astean laneguntzat hartzen diren 5 egunetatik 7 ditugu.
Horren arabera, lanegunetan makina honek ez luke 24 orduz funtzionatu behar, 12 orduz baizik, eta asteburuetan makina honek ez luke batere funtzionatu behar. Dena oso erraza dela dirudi, baina zer da garrantzitsua hemen esatea? Oinarrizko egutegi honetan praktika sinple hau ezarriz, ingurune hauek mantentzearen kostua % 70 murrizteko aukera ematen du, hau da, zure garapenaren, QAren, demoaren, ingurunearen prezioa hartu eta 3z zatitu zenuen.
Galdera da, zer egin gainerako diruarekin? Esate baterako, garatzaileek ReSharper erosi beharko lukete oraindik egin ez badute. Edo koktel bat egin. Lehen ingurune bat bazenuen garatzaileak eta QA bazkatzen ziren, eta kito, orain 3 desberdin egin ditzakezu isolatuta egongo direnak, eta jendeak ez du elkar oztopatu.
Etengabeko errendimenduaren neurketa duen diapositibari dagokionez, nola konpara dezakegu errendimendua proiektuan datu basean 1 erregistro bagenu, bi hilabete geroago milioi bat daude? Nola ulertu zergatik eta zertarako balio du errendimendua neurtzeak?
Galdera ona da, beti neurtu behar duzulako errendimendua baliabide berdinetan. Hau da, kode berria zabaltzen duzu, kode berriaren errendimendua neurtzen duzu. Adibidez, errendimendu eszenatoki desberdinak probatu behar dituzu, demagun aplikazioak karga arin batean nola funtzionatzen duen probatu nahi duzula, non 1 erabiltzaile dauden eta datu-basearen tamaina 000 gigabyte den. Neurtu eta zenbakiak lortu dituzu. Jarraian, beste eszenatoki bat hartuko dugu. Adibidez, 5 erabiltzaile, datu-basearen tamaina 5 terabyte. Emaitzak jaso eta gogoratu genituen.
Zer da garrantzitsua hemen? Garrantzitsuena da agertokiaren, datuen bolumenaren, aldibereko erabiltzaile kopuruaren eta abarren arabera, zenbait mugarekin topo egin dezakezula. Adibidez, sare-txartel baten mugaraino, edo disko gogor baten mugaraino, edo prozesadorearen gaitasunen mugaraino. Hau da ulertzea garrantzitsua dena. Eszenatoki ezberdinetan zenbait mugarekin topo egiten duzu. Eta zenbakiak sakatzen dituzunean ulertu behar dituzu.
Errendimendua proba-ingurune berezi batean neurtzeaz ari al gara? Hau da, hau ez da ekoizpena?
Bai, hau ez da ekoizpena, hau proba-ingurune bat da, beti berdina, aurreko neurketekin alderatu ahal izateko.
Ulertua eskerrik asko!
Galderarik ez badago, amaitu dezakegula uste dut. Eskerrik asko!
Iturria: www.habr.com