It rapport sil prate oer guon DevOps-praktiken, mar út it eachpunt fan ûntwikkelders. Typysk hawwe alle yngenieurs dy't meidwaan oan DevOps al ferskate jierren bestjoerlike ûnderfining ûnder har riem. Mar dit betsjut net dat d'r hjir gjin plak is foar de ûntwikkelder. Faker as net binne ûntwikkelders dwaande om "de folgjende dringende krityske brek fan 'e dei" te reparearjen, en se hawwe gjin tiid om sels in flugge blik op it DevOps-fjild te nimmen. Yn it begryp fan 'e auteur is DevOps, as earste, sûn ferstân. Twadder is it in kâns om effektiver te wêzen. As jo in ûntwikkelder binne, sûn ferstân hawwe en effektiver wolle wêze as teamspiler, dan is dit rapport foar jo.
Lit my mysels foarstelle, ik jou folslein ta dat der minsken yn 'e keamer binne dy't my net kenne. Myn namme is Anton Boyko, ik bin in Microsoft Azure MVP. Wat is MVP? Dit is Model-View-Presentator. Model-View-Presentator is krekt my.
Dêrnjonken beslach ik op dit stuit de funksje fan oplossingsarsjitekt by Ciklum. En krekt koartlyn kocht ik mysels sa'n prachtich domein, en ik haw myn e-post bywurke, dy't ik normaal sjen litte by presintaasjes. Jo kinne my skriuwe op: my [hûn] byokoant.pro. Jo kinne my maile mei fragen. Ik antwurdzje se meastentiids. It iennichste is dat ik gjin fragen per e-post ûntfange wol dy't relatearje oan twa ûnderwerpen: polityk en religy. Jo kinne my oer al it oare skriuwe fia e-mail. Der sil wat tiid foarby gean, sil ik antwurdzje.
In pear wurden oer mysels:
- Ik bin no 10 jier op dit mêd.
- Ik wurke by Microsoft.
- Ik bin de oprjochter fan 'e Oekraynske Azure-mienskip, dy't wy earne yn 2014 oprjochte hawwe. En wy hawwe it noch en ûntwikkelje it.
- Ik bin ek de heit fan 'e oprjochter fan' e Azure-konferinsje, dy't wy yn Oekraïne hostje.
- Ik help ek mei it organisearjen fan de Global Azure Bootcamp yn Kiev.
- Lykas ik sei, ik bin in Microsoft Azure MVP.
- Ik sprek faak op konferinsjes. Ik hâld echt fan praten op konferinsjes. It ôfrûne jier koe ik sa'n 40 kear optreden. As jo troch Oekraïne, Wyt-Ruslân, Poalen, Bulgarije, Sweden, Denemarken, Nederlân, Spanje passe of in oar lân yn Europa jouwe of nimme, dan is it heul mooglik dat as jo nei in konferinsje gean dy't in wolktema yn har stream hat, jo kinne my op 'e sprekkerslist sjen.
- Ik bin ek in Star Trek-fan.
Litte wy it in bytsje oer Agenda hawwe. Us Aginda is heul ienfâldich:
- Wy sille prate oer wat DevOps is. Litte wy prate wêrom dit wichtich is. Earder wie DevOps in kaaiwurd dat jo op jo cv skreaun hawwe en fuortendaliks +$500 yn salaris krigen. No moatte jo bygelyks blockchain yn jo cv skriuwe om +500 dollar oan jo salaris te krijen.
- En dan, as wy in bytsje begripe wat dit is, sille wy prate oer wat DevOps-praktiken binne. Mar net sasear yn 'e kontekst fan DevOps yn't algemien, mar oer dy DevOps-praktiken dy't fan belang wêze kinne foar ûntwikkelders. Ik sil jo fertelle wêrom't se foar jo ynteressearje kinne. Ik sil jo fertelle wêrom't jo dit überhaupt moatte dwaan en hoe't it jo kin helpe om minder pine te belibjen.
In tradisjoneel byld dat in protte minsken sjen litte. Dit is wat bart yn in protte projekten. Dit is as wy ôfdielingen foar ûntwikkeling en operaasje hawwe dy't ús software stypje. En dizze ôfdielings kommunisearje net mei elkoar.
Miskien, as jo it net sa dúdlik koene fiele yn 'e ôfdielingen DevOps en operaasjes, kinne jo in analogy tekenje mei de ôfdielingen Dev en QA. D'r binne minsken dy't software ûntwikkelje en d'r binne QA-minsken dy't min binne fanút it eachpunt fan 'e ûntwikkelders. Bygelyks, ik commit myn prachtige koade oan de repository, en der sit wat skelm dy't werom dizze koade oan my en seit dat jo koade is min.
Dit alles bart om't minsken net mei-inoar kommunisearje. En se smite wat pakketten, wat oanfraach nei elkoar troch wat muorre fan misferstân en besykje der wat mei te dwaan.
It is krekt dizze muorre dy't DevOps-kultuer is ûntwurpen om te ferneatigjen, d.w.s. minsken twinge om mei elkoar te kommunisearjen en op syn minst te begripen wat ferskillende minsken yn it projekt dogge en wêrom har wurk wichtich is.
En as wy prate oer DevOps, sil immen jo fertelle dat DevOps is wannear't it projekt trochgeande yntegraasje hat; immen sil sizze dat DevOps is as it projekt de praktyk "ynfrastruktuer as koade" ymplemintearret; immen sil sizze dat de earste stap nei DevOps is feature branching, feature flaggen.
Yn essinsje is dit allegear wier op syn eigen manier. Mar dit binne gewoan de ultime praktiken dy't wy hawwe. Foardat jo trochgean nei dizze praktiken, stel ik foar om nei dizze slide te sjen, dy't de 3-stadia toant fan it ymplementearjen fan Dev-Ops-metodology yn jo projekt, yn jo bedriuw.
Dizze slide hat ek in twadde net-offisjele namme. Jo kinne online sykje om út te finen wat de 3 Musketiers fan DevOps binne. It is mooglik dat jo dit artikel fine. Wêrom 3 Musketiers? Hjirûnder stiet: minsken, prosessen en produkten, d.w.s. PPP - Porthos, Porthos en Porthos. Hjir binne de 3 musketiers fan DevOps. Dit artikel beskriuwt yn mear detail wêrom dit wichtich is en wat it ynhâldt.
As jo begjinne mei it ymplementearjen fan in DevOps-kultuer, is it heul wichtich dat it wurdt ymplementearre yn 'e folgjende folchoarder.
Earst moatte jo mei minsken prate. En jo moatte minsken útlizze wat it is en hoe't se der wat foardielen fan krije kinne.
Us konferinsje hjit DotNet Fest. En sa’t de organisatoaren my fertelden, hawwe wy hjir benammen in publyk fan ûntwikkelders útnoege, dus ik hoopje dat de measte minsken yn de seal belutsen binne by de ûntwikkeling.
Wy sille prate oer minsken, wy sille prate oer wat ûntwikkelders elke dei wolle dwaan. Wat wolle se it meast? Se wolle wat nije koade skriuwe, nijmoadrige kaders brûke, nije funksjes meitsje. Wat wolle ûntwikkelders it minste? Fix âlde bugs. Ik hoopje dat jo it mei my iens binne. Dit is wat de ûntwikkelders wolle. Se wolle nije funksjes skriuwe, se wolle gjin bugs reparearje.
It oantal bugs dy't in bepaalde ûntwikkelder produseart hinget ôf fan hoe rjocht syn earms binne en hoefolle se groeie fan syn skouders, en net fan syn kontpockets. Mar nettsjinsteande, as wy in grut projekt hawwe, bart it soms dat it ûnmooglik is om alles by te hâlden, dus it soe moai wêze foar ús om guon oanpakken te brûken dy't ús sille helpe om stabiler en hegere kwaliteitskoade te skriuwen.
Wat wolle QA's it meast? Ik wit net oft se yn 'e seal binne. It is dreech foar my om te sizzen dat ik wol in QA, want ik haw nea west ien. En gjin mislediging foar de jonges, it sil sein wurde dat ik hoopje dat ik it noait sil. Mar net om 'e reden dat ik har wurk sinleas en nutteloos achtsje, mar om't ik mysels net as in persoan beskôgje dy't dit wurk effisjint dwaan koe, dus ik sil it net iens besykje. Mar fan wat ik begryp, is wat QA it meast net leuk is moarns te wurkjen, konstant wat soarte fan regressytests útfiere, op deselde bugs stappe dy't se 3 sprints lyn oan 'e ûntwikkelders rapporteare en sizze: "Wanneer sille jo , Monsieur D 'Artagnan, reparearje dizze brek.' En Monsieur D'Artagnan antwurdet him: "Ja, ja, ja, ik haw it al repareare." En hoe't it bart dat ik ien bug reparearre en 5 ûnderweis makke.
De minsken dy't dizze oplossing stypje yn produksje wolle dat dizze oplossing sûnder bugs wurket, sadat se de server net elke freed op 'e nij moatte opstarte, as alle normale minsken nei de bar geane. De ûntwikkelders ynset op freed, de admins sitte oant sneon, besykje dizze ynset op te heljen en te reparearjen.
En as jo minsken útlizze dat se rjochte binne op it oplossen fan deselde problemen, kinne jo trochgean mei it formalisearjen fan de prosessen. It is tige wichtich. Wêrom? Want as wy "formalisaasje" sizze, is it wichtich foar jo om te beskriuwen hoe't jo prosessen op syn minst earne op in servet foarkomme. Jo moatte begripe dat as jo bygelyks ynsette nei in QA-omjouwing as in produksjeomjouwing, dan bart it altyd yn dizze folchoarder; yn dizze stadia rinne wy bygelyks automatyske ienheidstests en UI-tests. Nei ynset kontrolearje wy oft de ynset goed of min ferrûn is. Mar jo hawwe al in dúdlike list fan aksjes dy't moatte wurde werhelle hieltyd wer as jo ynsette nei produksje.
En pas as jo prosessen formalisearre binne, begjinne jo produkten te selektearjen dy't jo sille helpe om dizze prosessen te automatisearjen.
Spitigernôch sjoch ik dit hiel faak yn omkearde barren. Sadree't immen it wurd "DevOps" heart, suggerearje se fuortendaliks Jenkins te ynstallearjen, om't se leauwe dat sa gau as se Jenkins ynstallearje, se DevOps sille hawwe. Se ynstallearren Jenkins, lies de "How to"-artikels op 'e Jenkins-webside, besochten prosessen yn dizze How to-artikels te stopjen, en kamen doe nei minsken en bûgden minsken oer, sizzende dat it boek seit dat jo it op dizze manier moatte dwaan, dus wy dogge it op dizze manier.
It is net dat Jenkins in min ark is. Ik bedoel dat op gjin inkelde manier te sizzen. Mar dit is mar ien fan 'e produkten. En hokker produkt jo brûke moatte jo lêste beslút wêze, en lang net jo earste. Jo produkt moat net wurde dreaun troch de ymplemintaasje fan kultuer en oanpak. Dit is heul wichtich om te begripen, en dêrom besteegje ik safolle tiid oan dizze slide en ferklearje dit alles sa lang.
Litte wy prate oer DevOps-praktiken yn 't algemien. Wat binne dat? Wat is it ferskil? Hoe kinne jo se besykje? Wêrom binne se wichtich?
De earste praktyk wêrfan jo miskien hawwe heard hjit Continuous Integration. Miskien hat immen op it projekt Continuous Integration (CI).
It grutste probleem is dat it meastentiids as ik in persoan freegje: "Hawwe jo CI op it projekt?" en hy seit: "Ja," dan as ik freegje wat er docht, hy beskriuwt my perfoarst it hiele automatisearring proses. Dit is net hielendal wier.
Yn feite is de praktyk fan CI gewoan rjochte op it yntegrearjen fan de koade dy't ferskate minsken skriuwe yn in soarte fan ienige koadebasis. Da's alles.
Tegearre mei CI binne d'r meastentiids oare praktiken ûnderweis - lykas Continuous Deployment, Release Management, mar dêr sille wy letter oer prate.
CI sels fertelt ús dat ferskate minsken koade skriuwe en dizze koade moat kontinu yntegreare wurde yn ien koadebasis.
Wat jout dit ús en wêrom is it wichtich? As wy DotNet hawwe, dan is dat goed, it is in gearstalde taal, wy kinne ús applikaasje kompilearje. As it kompilearret, dan is dit al in goed teken. Dit betsjut noch neat, mar it is it earste goede teken dat wy op syn minst kinne kompilearje.
Dan kinne wy wat tests útfiere, dat is ek in aparte praktyk. De testen binne allegear grien - dit is it twadde goede teken. Mar wer, dit betsjut neat.
Mar wêrom soene jo dit dwaan? Alle praktiken dêr't ik hjoed oer praat drage sawat deselde wearde, dus sawat deselde foardielen en wurde ek sawat deselde manier mjitten.
Earst lit it jo levering fersnelle. Hoe lit dit jo de levering fersnelle? As wy wat nije feroarings meitsje oan ús koadebasis, kinne wy fuortendaliks besykje wat te dwaan mei dizze koade. Wy wachtsje net oant tongersdei komt, want op tongersdei jouwe wy it út oan QA Environment, wy dogge it hjir en krekt hjir.
Ik sil dy ien tryst ferhaal út myn libben fertelle. It wie lang lyn, doe't ik noch jong en kreas wie. No bin ik al jong, moai en tûk, en beskieden. In skoft lyn siet ik yn in projekt. Wy hiene in grut team fan sa'n 30 ûntwikkelders. En wy hienen in grut, grut Enterprise-projekt dat sawat 10 jier ûntwikkele. En wy hiene ferskate tûken. Yn de repository hienen wy in tak dêr't ûntwikkelders yn rûnen. En d'r wie in branch dy't de ferzje fan 'e koade werjûn dy't yn produksje is.
De produksjetak wie 3 moannen efter de branch dy't beskikber wie foar ûntwikkelders. Wat betsjut dit? Dit betsjut dat sa gau as ik earne in brek haw dy't nei produksje giet troch de skuld fan 'e ûntwikkelders, om't se it tastien hawwe, en troch de skuld fan QA, om't se it seagen, dan betsjut dit dat as ik in taak foar hotfix foar produksje, dan moat ik myn koadewizigingen weromdraaie 3 moannen lyn. Ik moat ûnthâlde wat ik hie 3 moannen lyn en besykje te reparearjen it dêr.
As jo dizze ûnderfining noch net hawwe hân, kinne jo it besykje op jo thúsprojekt. It wichtichste is, besykje it net op in kommersjeel. Skriuw in pear rigels koade, ferjit se seis moannen, en kom dan werom en besykje fluch út te lizzen wêr't dy rigels koade oer geane en hoe't jo se kinne reparearje of optimalisearje. It is in heul, heul spannende ûnderfining.
As wy in trochgeande yntegraasjepraktyk hawwe, dan kinne wy it kontrolearje mei in oantal automatisearre ark hjir en no krekt, sa gau as ik myn koade haw skreaun. Dit kin my net it folsleine byld jaan, mar dochs sil it op syn minst guon fan 'e risiko's fuortsmite. En as d'r in potinsjele brek is, sil ik it no krekt witte, dat is letterlik oer in pear minuten. Ik hoech net 3 moannen werom te draaien. Ik hoech mar 2 minuten werom te rôljen. In goede kofje masine sil net iens hawwe tiid om te brouwen kofje yn 2 minuten, dus dat is moai cool.
Dit hat de wearde dat it op elk projekt kear op kear werhelle wurde kin, d.w.s. net allinich dejinge wêrop jo it ynsteld hawwe. Jo kinne sawol de praktyk sels werhelje en CI sels sil werhelle wurde foar elke nije feroaring dy't jo meitsje oan it projekt. Hjirmei kinne jo boarnen optimalisearje, om't jo team effisjinter wurket. Jo sille gjin situaasje mear hawwe wêr't in brek nei jo komt fan 'e koade wêrmei jo 3 moannen lyn wurke hawwe. Jo sille gjin kontekstwikseling mear hawwe as jo de earste twa oeren sitte en besteegje oan besykje te begripen wat der doe barde en yn 'e essinsje fan' e kontekst komme foardat jo wat begjinne te korrigearjen.
Hoe kinne wy it sukses of mislearjen fan dizze praktyk mjitte? As jo rapportearje oan de grutte baas wat wy útfierd op de CI projekt, hy heart blah blah blah. Wy hawwe it ymplementearre, OK, mar wêrom, wat hat it ús brocht, hoe mjitte wy it, hoe goed of ferkeard implementearje wy it?
De earste is dat wy, tanksij CI, hieltyd faker kinne ynsette, en faker krekt om't ús koade potinsjeel stabiler is. Op deselde manier wurdt ús tiid om in flater te finen fermindere en de tiid om dizze flater te korrigearjen wurdt fermindere krekt om't wy hjir en no in antwurd krije fan it systeem, wat is der mis mei ús koade.
In oare praktyk dy't wy hawwe is de praktyk foar automatisearring, dy't meastentiids komt mei de CI-praktyk. Se geane hân yn hân.
Wat is hjir wichtich om te begripen? It is wichtich om te begripen dat ús tests oars binne. En elke automatisearre test is rjochte op it oplossen fan har eigen problemen. Wy hawwe bygelyks unit tests dy't tastean ús te testen in module apart, d.w.s. Hoe wurket it yn in fakuüm? Dit is goed.
Wy hawwe ek yntegraasjetests dy't ús kinne begripe hoe't ferskate modules mei elkoar yntegrearje. It is ek goed.
Wy kinne UI-automatisearringstests hawwe wêrtroch ús kinne kontrolearje hoe goed it wurk mei de UI foldocht oan bepaalde easken ynsteld troch de klant, ensfh.
De spesifike tests dy't jo útfiere kinne beynfloedzje hoe faak jo se útfiere. Ienheidstests wurde normaal koart en lyts skreaun. En se kinne regelmjittich lansearre wurde.
As wy it hawwe oer UI-automatisaasjetests, dan is it goed as jo projekt lyts is. Jo UI-automatisaasjetests kinne wat adekwate tiid nimme. Mar normaal is in UI-automatisearringstest iets dat ferskate oeren nimt op in grut projekt. En it is goed as it in pear oeren is. It ienige ding is dat d'r gjin punt is om se foar elke bou út te fieren. It makket sin om se nachts te rinnen. En as elkenien moarns oan it wurk kaam: sawol testers as ûntwikkelders, krigen se in soarte fan rapport dat wy nachts de UI-autotest rûnen en dizze resultaten krigen. En hjir sil in oere wurk fan in server dy't sil kontrolearje dat jo produkt oan guon easken foldocht, folle goedkeaper wêze as in oere wurk fan deselde QA-yngenieur, sels as hy in Junior QA-yngenieur is dy't wurket foar iten en tank. Lykwols, in oere fan masine operaasje sil wêze goedkeaper. Dêrom is it sinfol om dêryn te ynvestearjen.
Ik haw in oar projekt dêr't ik oan wurke haw. Wy hiene twa wiken sprints op dit projekt. It projekt wie grut, wichtich foar de finansjele sektor, en der koe net in flater makke wurde. En nei in sprint fan twa wiken waard de ûntwikkelingssyklus folge troch in testproses, dat noch 4 wiken duorre. Besykje de skaal fan 'e trageedzje foar te stellen. Wy skriuwe koade foar twa wiken, dan dogge wy it ala CodeFreeze, pakke it yn in nije ferzje fan 'e applikaasje, en rôlje it út nei testers. Testers testen it noch 4 wiken, d.w.s. Wylst se it testen, hawwe wy tiid om noch twa ferzjes foar har te meitsjen. Dit is in echt tryst gefal.
En wy fertelden har dat as jo produktiver wolle wêze, it logysk is foar jo om automatisearre testpraktiken te ymplementearjen, om't dit is wat jo hjir, op it stuit, sear docht.
Oefenje Continuous Deployment. Geweldich, jo hawwe boud. Dit is al goed. Jo koade is kompilearre. No soe it moai wêze om dizze build op wat omjouwing yn te setten. Litte wy sizze yn in omjouwing foar ûntwikkelders.
Wêrom is it wichtich? Earst kinne jo sjen hoe suksesfol jo binne mei it ynsetproses sels. Ik haw projekten lykas dit moete, as ik freegje: "Hoe set jo in nije ferzje fan 'e applikaasje yn?", fertelle de jonges my: "Wy stelle it gear en pakke it yn in zip-argyf. Wy stjoere it per post nei de admin. De admin downloadt en wreidet dit argyf út. En it hiele kantoar begjint te bidden dat de tsjinner de nije ferzje sil ophelje. ”
Litte wy begjinne mei wat ienfâldich. Se fergeaten bygelyks CSS yn it argyf te pleatsen of fergeat de hashtag te feroarjen yn 'e java-script triemnamme. En as wy in fersyk oan 'e tsjinner meitsje, tinkt de browser dat it dit java-skriptbestân al hat en beslút it net te downloaden. En der wie in âlde ferzje, der miste wat. Yn 't algemien kinne d'r in protte problemen wêze. Dêrom lit de praktyk fan Continuous Deployment jo op syn minst testen wat der barre soe as jo in skjinne referinsjeôfbylding nimme en it uploade nei in folslein skjinne nije omjouwing. Jo kinne sjen wêr't dit liedt.
Ek, as jo yntegrearje koade tusken elkoar, i.e. tusken it kommando kinne jo ek sjen hoe't it derút sjocht op 'e UI.
Ien fan 'e problemen dy't optreedt wêr't in protte vanilla java-skript wurdt brûkt, is dat twa ûntwikkelders in fariabele mei deselde namme yn it finsterobjekt oerhearrich ferklearre. En dan, ôfhinklik fan jo gelok. Waans java-skripttriem twadde wurdt útlutsen sil de wizigingen fan de oare oerskriuwe. It is ek hiel spannend. Jo komme yn: ien ding wurket foar de iene, in oar wurket net foar in oar. En it is "prachtig" as it allegear komt út yn produksje.
De folgjende praktyk dy't wy hawwe is de praktyk fan Automatysk weromsette, nammentlik weromrollen nei de foarige ferzje fan 'e applikaasje.
Wêrom is dit wichtich foar ûntwikkelders? Der binne noch dyjingen dy't ûnthâlde de fiere, fiere jierren '90, doe't kompjûters wiene grut en programma wiene lyts. En de ienige manier foar webûntwikkeling wie fia PHP. It is net dat PHP in minne taal is, hoewol it is.
Mar it probleem wie oars. Doe't wy in nije ferzje fan ús php-side ynsetten, hoe hawwe wy it ynset? Meast faak we iepene Far Manager of wat oars. En uploade dizze bestannen nei FTP. En wy realisearre ynienen dat wy hiene wat lytse, lytse bug, bygelyks, wy fergetten te setten in puntkomma of fergetten te feroarjen it wachtwurd foar de databank, en der is in wachtwurd foar de databank, dat is op de lokale host. En wy beslute om fluch te ferbinen mei FTP en de bestannen dêr direkt te bewurkjen. Dit is gewoan fjoer! Dit is wat populêr wie yn 'e jierren '90.
Mar, as jo de kalinder net hawwe sjoen, wiene de jierren '90 hast 30 jier lyn. No bart alles wat oars. En besykje de skaal fan 'e trageedzje foar te stellen as se jo fertelle: "Wy hawwe ynset op produksje, mar dêr gie der wat mis. Hjir is jo FTP-oanmelding en wachtwurd, ferbine mei produksje en reparearje it dêr fluch. As jo Chuck Norris binne, sil dit wurkje. Sa net, dan riskearje jo dat as jo ien brek reparearje, jo mear meitsje 10. Dit is krekt wêrom dizze praktyk fan weromrollen nei de foarige ferzje jo in protte kinne berikke.
Sels as der wat slims earne yn prod kaam, dan is it slim, mar net fataal. Jo kinne weromrolle nei de foarige ferzje dy't jo hawwe. Neam it in reservekopy, as it makliker is om it yn dy terminology te fernimmen. Jo kinne rôlje werom nei dizze foarige ferzje, en brûkers sille noch by steat wêze om te wurkjen mei jo produkt, en do silst hawwe adekwate buffer tiid. Jo kinne rêstich, sûnder haast, dit alles nimme en it lokaal testje, it reparearje en dan in nije ferzje uploade. It makket echt sin om dit te dwaan.
Litte wy no besykje de twa eardere praktiken op ien of oare manier te kombinearjen. Wy sille in tredde krije mei de namme Release Management.
As wy prate oer Continuous Deployment yn syn klassike foarm, sizze wy dat wy koade moatte lûke fan in tûke út it repository, kompilearje en ynsette. It is goed as wy deselde omjouwing hawwe. As wy ferskate omjouwings hawwe, betsjut dit dat wy elke kear de koade moatte lûke, sels út deselde commit. Wy sille it elke kear útlûke, wy sille it elke kear bouwe en wy sille it ynsette yn in nije omjouwing. As earste is dit tiid, want om in projekt te bouwen, as jo in grutte hawwe en út 'e jierren '90 kamen, dan kin it ferskate oeren duorje.
Boppedat is der noch in fertriet. As jo bouwe, sels op deselde masine, sille jo deselde boarnen bouwe, jo hawwe noch gjin garânsje dat dizze masine yn deselde steat is as it wie tidens de lêste bou.
Litte wy sizze dat ien binnen kaam en DotNet foar jo bywurke, of oarsom, immen besleat wat te wiskjen. En dan hawwe jo kognitive dissonânsje dat wy fan dizze commit twa wiken lyn in build bouden en alles wie goed, mar no liket it op deselde masine, deselde commit, deselde koade dy't wy besykje te bouwen, mar it wurket net . Jo sille omgean mei dit foar in lange tiid en it is net in feit dat jo sille útfine. Op syn minst sille jo jo senuwen in protte bedjerre.
Dêrom suggerearret de praktyk fan Release Management it yntrodusearjen fan in ekstra abstraksje neamd in artefaktrepository of galery of biblioteek. Jo kinne it neame wat jo wolle.
It haadgedachte is dat sa gau as wy dêr in soarte fan commit hawwe, sis, yn in branch dat wy ree binne om yn te setten yn ús ferskate omjouwings, wy applikaasjes sammelje fan dizze commit en alles wat wy nedich binne foar dizze applikaasje, wy pakke it yn yn in zip-argyf en bewarje it yn wat betroubere opslach. En út dizze opslach kinne wy dit zip-argyf op elk momint krije.
Dan nimme wy it en ynsette it automatysk yn 'e dev-omjouwing. Wy race dêr, en as alles goed is, dan sette wy yn op it poadium. As alles goed is, dan sette wy itselde argyf yn foar produksje, deselde binaries, presys ien kear gearstald.
Derneist, as wy in galery lykas dizze hawwe, helpt it ús ek om de risiko's oan te pakken dy't wy oanpakten op 'e lêste dia doe't wy praatten oer weromdraaien nei de foarige ferzje. As jo per ongeluk wat ferkeard ynset hawwe, kinne jo altyd elke oare foarige ferzje fan dizze galery nimme en it op deselde manier yn dizze omjouwings ûntsette. Hjirmei kinne jo maklik weromrolle nei de foarige ferzje as der wat mis giet.
D'r is in oare geweldige praktyk. Jo en ik begripe allegear dat as wy ús applikaasjes weromrôlje nei in eardere ferzje, dit kin betsjutte dat wy ek de ynfrastruktuer fan 'e foarige ferzje nedich binne.
As wy prate oer firtuele ynfrastruktuer, tinke in protte minsken dat dit iets is dat admins ynstelle. En as jo bygelyks in nije server moatte krije wêrop jo in nije ferzje fan jo applikaasje wolle testen, dan moatte jo in kaartsje skriuwe nei de admins of devops. Devops sil hjirfoar 3 wiken duorje. En nei 3 wiken sille se jo fertelle dat wy in firtuele masine foar jo ynstalleare hawwe, mei ien kearn, twa gigabyte RAM en in Windows-tsjinner sûnder DotNet. Jo sizze: "Mar ik woe DotNet." Se: "Ok, kom oer 3 wiken werom."
It idee is dat troch ynfrastruktuer te brûken as koadepraktiken, jo jo firtuele ynfrastruktuer as gewoan in oare boarne kinne behannelje.
Miskien, as ien fan jo applikaasjes op DotNet ûntwikkelet, hawwe jo miskien heard oer in bibleteek neamd Entity Framework. En jo hawwe miskien sels heard dat Entity Framework ien fan 'e oanpak is dy't Microsoft aktyf triuwt. Foar it wurkjen mei in databank is dit in oanpak neamd Code First. Dit is as jo yn koade beskriuwe hoe't jo wolle dat jo databank derút sjocht. En dan sette jo de applikaasje yn. It slút oan by de databank, it bepaalt sels hokker tabellen der binne en hokker tabellen net binne, en makket alles wat jo nedich binne.
Jo kinne itselde dwaan mei jo ynfrastruktuer. Der is gjin ferskil tusken oft jo nedich hawwe in databank foar in projekt of oft jo nedich hawwe in Windows tsjinner foar in projekt. It is gewoan in boarne. En jo kinne it oanmeitsjen fan dizze boarne automatisearje, jo kinne de konfiguraasje fan dizze boarne automatisearje. Sadwaande, elke kear as jo wat nij konsept wolle testen, wat nije oanpak, hoege jo gjin kaartsje te skriuwen foar devops, jo kinne gewoan in isolearre ynfrastruktuer foar josels ynsette fan klearmakke sjabloanen, fan klearmakke skripts en útfiere dêr al dyn eksperiminten. Jo kinne dit wiskje, wat resultaten krije en der fierder oer melde.
De folgjende praktyk, dy't ek bestiet en ek wichtich is, mar dy't in pear minsken brûke, is Application Performance Monitoring.
Ik woe mar ien ding sizze oer Application Performance Monitoring. Wat is it wichtichste oan dizze praktyk? Dit is wat Applikaasje Performance Monitoring sawat itselde is as reparearjen fan in appartemint. Dit is gjin definitive steat, it is in proses. Jo moatte it regelmjittich dwaan.
Op in goede manier soe it goed wêze om tafersjoch op applikaasjeprestaasjes op hast elke bou út te fieren, hoewol, lykas jo begripe, dit net altyd mooglik is. Mar, op syn minst, it moat wurde útfierd foar elke release.
Wêrom is it wichtich? Want as jo ynienen in drop yn prestaasjes ûnderfine, dan moatte jo dúdlik begripe wêrom. As jo team bygelyks twa wiken sprints hat, dan moatte jo op syn minst ien kear yn 'e twa wiken jo applikaasje ynsette op in aparte server, wêr't jo in dúdlik fêste prosessor, RAM, skiven, ensfh. En útfiere dy deselde prestaasjetests . Jo krije it resultaat. Sjoch hoe't it feroare is fan 'e foarige sprint.
En as jo útfine dat de drawdown earne skerp gie, sil it betsjutte dat it allinich wie troch de feroaringen dy't de ôfrûne twa wiken plakfûn hawwe. Hjirmei kinne jo it probleem folle flugger identifisearje en reparearje. En nochris, dit binne sawat deselde metriken wêrmei jo kinne mjitte hoe suksesfol jo it dien hawwe.
De folgjende praktyk dy't wy hawwe is de praktyk fan konfiguraasjebehear. Der binne in pear dy't dit serieus nimme. Mar leau my, dit is eins in hiel serieus ding.
Der wie koartlyn in grappich ferhaal. De jonges kamen nei my ta en seine: "Help ús in befeiligingskontrôle fan ús applikaasje te fieren." Wy seagen tegearre nei de koade foar in lange tiid, se fertelden my oer de applikaasje, tekene diagrammen. En plus of min alles wie logysk, begryplik, feilich, mar der wie ien MAAR! Se hiene konfiguraasjebestannen yn har boarnekontrôle, ynklusyf dy fan produksje mei de IP-database, mei oanmeldingen en wachtwurden foar ferbining mei dizze databases, ensfh.
En ik sis: "Jongens, goed, jo hawwe jo produksjeomjouwing sletten mei in firewall, mar it feit dat jo de oanmelding en wachtwurd hawwe foar de produksjedatabase direkt yn 'e boarnekontrôle en elke ûntwikkelder kin it lêze is al in enoarm feiligensrisiko . En nettsjinsteande hoe super feilich jo applikaasje is út in koade-oogpunt, as jo it yn boarnekontrôle litte, dan sille jo noait oeral in kontrôle trochjaan. Dat is wêr ik oer praat.
Konfiguraasje behear. Wy kinne ferskate konfiguraasjes hawwe yn ferskate omjouwings. Wy kinne bygelyks ferskate oanmeldingen en wachtwurden hawwe foar databases foar QA, demo, produksjeomjouwing, ensfh.
Dizze konfiguraasje kin ek automatisearre wurde. It moat altyd apart wêze fan 'e applikaasje sels. Wêrom? Om't jo de applikaasje ien kear boud hawwe, en dan makket de applikaasje neat út oft jo fia sa'n en sa'n IP of sa'n IP ferbine mei de SQL-tsjinner, soe it itselde moatte wurkje. Dêrom, as ien fan jo ynienen noch hurdkodearret de ferbiningstring yn 'e koade, tink dan dat ik jo sil fine en jo straf as jo josels op itselde projekt mei my fine. Dit wurdt altyd pleatst yn in aparte konfiguraasje, bygelyks yn web.config.
En dizze konfiguraasje wurdt al apart beheard, dus dit is krekt it momint dat in ûntwikkelder en in behearder yn deselde keamer komme kinne en sitte. En de ûntwikkelder kin sizze: "Sjoch, hjir binne de binaries fan myn applikaasje. Sy wurkje. De applikaasje hat in databank nedich om te wurkjen. Hjir njonken de binaries is der in triem. Yn dit bestân is dit fjild ferantwurdlik foar de oanmelding, dit is foar it wachtwurd, dit is foar it IP. Set it oeral yn." En it is ienfâldich en dúdlik foar de admin. Hy kin it echt oeral ynsette troch dizze konfiguraasje te behearjen.
En de lêste praktyk dêr't ik it oer ha wol is in praktyk dy't heul, heul besibbe is oan wolken. En it bringt maksimale effekt as jo wurkje yn 'e wolk. Dit is automatyske ferwidering fan jo omjouwing.
Ik wit dat d'r ferskate minsken op dizze konferinsje binne fan 'e teams wêrmei ik wurkje. En mei alle teams wêrmei ik wurkje, brûke wy dizze praktyk.
Wêrom? Fansels soe it geweldich wêze as elke ûntwikkelder in firtuele masine hie dy't 24/7 soe wurkje. Mar miskien is dit nijs foar jo, miskien hawwe jo net omtinken, mar de ûntwikkelder sels wurket net 24/7. In ûntwikkelder wurket normaal 8 oeren deis. Sels as er betiid oan it wurk komt, hat er in grutte lunch wêryn hy nei de sportskoalle giet. Lit it 12 oeren deis wêze as de ûntwikkelder dizze boarnen eins brûkt. Neffens ús wetjouwing hawwe wy 5 fan de 7 dagen yn 'e wike dy't as wurkdagen beskôge wurde.
Dêrom, op wurkdagen dizze masine moat net wurkje 24 oeren, mar allinnich 12, en yn it wykein, dizze masine moat net wurkje hielendal. It soe lykje dat alles is hiel simpel, mar wat is wichtich om te sizzen hjir? Troch dizze ienfâldige praktyk op dit basisskema te ymplementearjen, kinne jo de kosten fan it ûnderhâld fan dizze omjouwings mei 70% ferminderje, dat wol sizze jo namen de priis fan jo dev, QA, demo, omjouwing en dield it troch 3.
De fraach is, wat te dwaan mei de rest fan it jild? Bygelyks, de ûntwikkelders moatte ReSharper keapje as se dat net al hawwe. Of hawwe in cocktailparty. As jo earder hie ien omjouwing dêr't sawol dev en QA weide, en dat is it, no kinne jo meitsje 3 ferskillende dy't sil wurde isolearre, en minsken sille net bemuoie mei elkoar.
Oangeande de slide mei trochgeande prestaasjesmjitting, hoe kinne wy prestaasjes fergelykje as wy 1 records yn 'e databank yn it projekt hiene, twa moanne letter binne d'r in miljoen? Hoe te begripen wêrom en wat is it punt fan it mjitten fan prestaasjes?
Dit is in goede fraach, om't jo prestaasjes altyd moatte mjitte op deselde boarnen. Dat is, jo rôlje nije koade út, jo mjitte prestaasjes op 'e nije koade. Jo moatte bygelyks ferskate prestaasjessenario's testen, litte wy sizze dat jo wolle testen hoe't de applikaasje prestearret op in lichte lading, wêr't d'r 1 brûkers binne en de databankgrutte 000 gigabyte is. Jo hawwe it mjitten en de sifers krigen. Folgjende nimme wy in oar senario. Bygelyks, 5 brûkers, databankgrutte 5 terabyte. Wy krigen de resultaten en ûnthâlden se.
Wat is hjir wichtich? It wichtige ding hjir is dat ôfhinklik fan it senario, it folume fan gegevens, it oantal simultane brûkers, ensfh., Jo kinne yn bepaalde grinzen rinne. Bygelyks, oant de limyt fan in netwurkkaart, of oan 'e limyt fan in hurde skiif, of oan' e limyt fan prosessormooglikheden. Dit is wat wichtich is foar jo om te begripen. Yn ferskate senario's rinne jo yn bepaalde grinzen. En jo moatte de sifers begripe as jo se reitsje.
Hawwe wy it oer it mjitten fan prestaasjes yn in spesjale testomjouwing? Dat is, dit is gjin produksje?
Ja, dit is gjin produksje, dit is in testomjouwing, dy't altyd itselde is, sadat jo it kinne fergelykje mei eardere mjittingen.
Begrepen tank!
As der gjin fragen binne, tink ik dat wy ôfmeitsje kinne. Dankewol!
Boarne: www.habr.com