Raporti do të flasë për disa praktika DevOps, por nga këndvështrimi i një zhvilluesi. Në mënyrë tipike, të gjithë inxhinierët që bashkohen me DevOps kanë tashmë disa vite përvojë administrative nën brezin e tyre. Por kjo nuk do të thotë se nuk ka vend për zhvilluesin këtu. Më shpesh sesa jo, zhvilluesit janë të zënë me rregullimin e "defektit tjetër urgjentisht kritik të ditës" dhe ata nuk kanë kohë as të hedhin një vështrim të shpejtë në fushën DevOps. Në kuptimin e autorit, DevOps është, së pari, sens i përbashkët. Së dyti, është një mundësi për të qenë më efektiv. Nëse jeni një zhvillues, keni sens të përbashkët dhe dëshironi të jeni më efektiv si lojtar ekipi, ky raport është për ju.
Më lejoni të prezantohem, e pranoj plotësisht që ka njerëz në dhomë që nuk më njohin. Emri im është Anton Boyko, unë jam një MVP i Microsoft Azure. Çfarë është MVP? Ky është Model-View-Presenter. Model-View-Presenter jam pikërisht unë.
Për më tepër, aktualisht mbaj pozicionin e arkitektit të zgjidhjeve në Ciklum. Dhe kohët e fundit bleva vetes një domen kaq të bukur dhe përditësova emailin tim, të cilin zakonisht e shfaq në prezantime. Mund të më shkruani në: me [qen] byokoant.pro. Mund të më dërgoni email me pyetje. Unë zakonisht u përgjigjem atyre. E vetmja gjë është se nuk do të doja të merrja me email pyetje që kanë të bëjnë me dy tema: politikë dhe fe. Ju mund të më shkruani për gjithçka tjetër me email. Do të kalojë pak kohë, do të përgjigjem.
Disa fjalë për veten time:
- Unë jam në këtë fushë për 10 vjet tani.
- Kam punuar në Microsoft.
- Unë jam babai themelues i komunitetit ukrainas Azure, të cilin e themeluam diku në 2014. Dhe ne ende e kemi atë dhe po e zhvillojmë.
- Unë jam gjithashtu babai i themeluesit të konferencës Azure, të cilën po e presim në Ukrainë.
- Unë ndihmoj gjithashtu në organizimin e Bootcamp Global Azure në Kiev.
- Siç thashë, unë jam një MVP i Microsoft Azure.
- Unë flas në konferenca mjaft shpesh. Më pëlqen shumë të flas në konferenca. Gjatë vitit të kaluar kam qenë në gjendje të performoj rreth 40 herë. Nëse kaloni pranë Ukrainës, Bjellorusisë, Polonisë, Bullgarisë, Suedisë, Danimarkës, Holandës, Spanjës ose jepni ose merrni një vend tjetër në Evropë, atëherë është shumë e mundur që kur shkoni në një konferencë që ka një temë cloud në rrjedhën e saj, ju mund të më shihni në listën e folësve.
- Unë jam gjithashtu një fans i Star Trek.
Le të flasim pak për Axhendën. Axhenda jonë është shumë e thjeshtë:
- Ne do të flasim për atë që është DevOps. Le të flasim pse kjo është e rëndësishme. Më parë, DevOps ishte një fjalë kyçe që keni shkruar në CV dhe menjëherë keni marrë + 500 dollarë në pagë. Tani ju duhet të shkruani, për shembull, blockchain në CV në mënyrë që të merrni +500 dollarë për pagën tuaj.
- Dhe më pas, kur të kuptojmë pak se çfarë është kjo, do të flasim se cilat janë praktikat e DevOps. Por jo aq shumë në kontekstin e DevOps në përgjithësi, por për ato praktika DevOps që mund të jenë me interes për zhvilluesit. Unë do t'ju them pse ato mund të jenë me interes për ju. Unë do t'ju them pse duhet ta bëni këtë fare dhe si mund t'ju ndihmojë të përjetoni më pak dhimbje.
Një foto tradicionale që e tregojnë shumë njerëz. Kjo është ajo që ndodh në shumë projekte. Kjo është kur ne kemi departamente të zhvillimit dhe operacioneve që mbështesin softuerin tonë. Dhe këto departamente nuk komunikojnë me njëri-tjetrin.
Ndoshta, nëse nuk keni mundur ta ndjeni kaq qartë në departamentet e DevOps dhe operacioneve, mund të bëni një analogji me departamentet Dev dhe QA. Ka njerëz që zhvillojnë softuer dhe ka njerëz të QA që janë të këqij nga këndvështrimi i zhvilluesve. Për shembull, unë e dorëzoj kodin tim të mrekullueshëm në depo, dhe aty është ulur një i poshtër që ma kthen këtë kod dhe më thotë se kodi yt është i keq.
E gjithë kjo ndodh sepse njerëzit nuk komunikojnë me njëri-tjetrin. Dhe ata hedhin disa pako, disa aplikime me njëri-tjetrin përmes një muri keqkuptimi dhe përpiqen të bëjnë diçka me to.
Është pikërisht ky mur që kultura DevOps është projektuar për të shkatërruar, d.m.th. detyroni njerëzit të komunikojnë me njëri-tjetrin dhe të paktën të kuptojnë se çfarë bëjnë njerëzit e ndryshëm në projekt dhe pse puna e tyre është e rëndësishme.
Dhe kur flasim për DevOps, dikush do t'ju thotë se DevOps është kur projekti ka integrim të vazhdueshëm; dikush do të thotë se DevOps është nëse projekti zbaton praktikën "infrastruktura si kod"; dikush do të thotë se hapi i parë për DevOps është degëzimi i veçorive, flamujt e veçorive.
Në thelb, e gjithë kjo është e vërtetë në mënyrën e vet. Por këto janë vetëm praktikat përfundimtare që ne kemi. Përpara se të kaloni në këto praktika, unë sugjeroj të shikoni këtë sllajd, i cili tregon 3 fazat e zbatimit të metodologjisë Dev-Ops në projektin tuaj, në kompaninë tuaj.
Ky rrëshqitje ka gjithashtu një emër të dytë jozyrtar. Mund të kërkoni në internet për të zbuluar se cilët janë 3 musketierët e DevOps. Është e mundur që ju të gjeni këtë artikull. Pse 3 musketierë? Më poshtë thotë: njerëzit, proceset dhe produktet, d.m.th. PPP – Porthos, Porthos dhe Porthos. Këtu janë 3 musketierët e DevOps. Ky artikull përshkruan në mënyrë më të detajuar pse kjo është e rëndësishme dhe çfarë përfshin.
Kur filloni të zbatoni një kulturë DevOps, është shumë e rëndësishme që ajo të zbatohet në rendin e mëposhtëm.
Fillimisht duhet të flisni me njerëzit. Dhe ju duhet t'u shpjegoni njerëzve se çfarë është dhe si mund të marrin disa përfitime prej tij.
Konferenca jonë quhet DotNet Fest. Dhe siç më thanë organizatorët, ne kryesisht ftuam një audiencë zhvilluesish këtu, kështu që shpresoj që shumica e njerëzve në sallë të jenë të përfshirë në zhvillim.
Ne do të flasim për njerëzit, ne do të flasim për atë që zhvilluesit duan të bëjnë çdo ditë. Çfarë duan më shumë? Ata duan të shkruajnë një kod të ri, të përdorin korniza të reja, të krijojnë veçori të reja. Çfarë duan më së paku zhvilluesit? Rregulloni defektet e vjetra. Shpresoj se jeni dakord me mua. Kjo është ajo që duan zhvilluesit. Ata duan të shkruajnë veçori të reja, nuk duan të rregullojnë gabimet.
Numri i gabimeve që prodhon një zhvillues i veçantë varet nga sa drejt janë krahët e tij dhe sa rriten nga supet e tij dhe jo nga xhepat e prapanicës. Por megjithatë, kur kemi një projekt të madh, ndonjëherë ndodh që është e pamundur të mbajmë gjurmët e gjithçkaje, kështu që do të ishte mirë që ne të përdorim disa qasje që do të na ndihmojnë të shkruajmë kode më të qëndrueshme dhe më cilësore.
Çfarë duan më shumë QA-të? Nuk e di nëse janë në sallë. Është e vështirë për mua të them se dua një SC, sepse nuk kam qenë kurrë. Dhe pa ofendim për djemtë, do të thuhet se shpresoj se nuk do ta bëj kurrë. Por jo për arsyen se unë e konsideroj punën e tyre të pakuptimtë dhe të padobishme, por sepse nuk e konsideroj veten një person që mund ta bëjë këtë punë me efikasitet, ndaj as që do të përpiqem ta bëj. Por me sa kuptoj unë, ajo që QA nuk i pëlqen më shumë është të shkojë në punë në mëngjes, duke kryer vazhdimisht disa lloj testesh regresioni, duke shkelur të njëjtat gabime që ata raportuan te zhvilluesit 3 sprinte më parë dhe duke thënë: “Kur do të , Monsieur D 'Artagnan, rregulloje këtë defekt.' Dhe imzot D'Artagnan i përgjigjet: "Po, po, po, e kam rregulluar tashmë." Dhe si ndodh që rregullova një gabim dhe bëra 5 gjatë rrugës.
Njerëzit që mbështesin këtë zgjidhje në prodhim duan që kjo zgjidhje të funksionojë pa gabime, në mënyrë që ata të mos kenë nevojë të rinisin serverin çdo të premte, kur të gjithë njerëzit normalë shkojnë në bar. Zhvilluesit u vendosën të Premten, administratorët ulen deri të shtunën, duke u përpjekur ta rregullojnë këtë vendosje.
Dhe kur u shpjegoni njerëzve se ata synojnë të zgjidhin të njëjtat probleme, mund të kaloni në formalizimin e proceseve. Eshte shume e rendesishme. Pse? Sepse kur themi "formalizimi", është e rëndësishme që ju të përshkruani se si ndodhin proceset tuaja të paktën diku në një pecetë. Ju duhet të kuptoni se nëse, për shembull, vendoseni në një mjedis QA ose një mjedis prodhimi, atëherë kjo ndodh gjithmonë në këtë mënyrë; në këto faza ne kryejmë, për shembull, teste automatike të njësisë dhe teste UI. Pas vendosjes, ne kontrollojmë nëse vendosja shkoi mirë apo keq. Por ju tashmë keni një listë të qartë veprimesh që duhet të përsëriten vazhdimisht kur të vendosni në prodhim.
Dhe vetëm kur proceset tuaja të zyrtarizohen, ju filloni të zgjidhni produkte që do t'ju ndihmojnë të automatizoni këto procese.
Fatkeqësisht, unë shpesh e shoh këtë të ndodhë në të kundërt. Sapo dikush dëgjon fjalën “DevOps”, ata sugjerojnë menjëherë instalimin e Jenkins, sepse besojnë se sapo të instalojnë Jenkins, do të kenë DevOps. Ata instaluan Jenkins, lexuan artikujt "Si të" në faqen e internetit të Jenkins, u përpoqën të futnin procese në këta artikuj "How to" dhe më pas erdhën te njerëzit dhe i përkulën njerëzit, duke thënë se libri thotë që ju duhet ta bëni këtë në këtë mënyrë, kështu që ne e bëjmë në këtë mënyrë.
Nuk është se Jenkins është një mjet i keq. Nuk dua ta them në asnjë mënyrë. Por ky është vetëm një nga produktet. Dhe cili produkt që përdorni duhet të jetë vendimi juaj i fundit, dhe aspak i pari. Produkti juaj nuk duhet të drejtohet nga zbatimi i kulturës dhe qasjeve. Kjo është shumë e rëndësishme për t'u kuptuar, prandaj shpenzoj kaq shumë kohë në këtë rrëshqitje dhe i shpjegoj të gjitha këto për kaq gjatë.
Le të flasim për praktikat e DevOps në përgjithësi. Cilat janë ato? Qfare eshte dallimi? Si t'i provoni ato? Pse janë të rëndësishme?
Praktika e parë për të cilën mund të keni dëgjuar quhet Integrimi i vazhdueshëm. Ndoshta dikush në projekt ka Integrim të Vazhdueshëm (CI).
Problemi më i madh është se më shpesh kur pyes një person: "A keni CI në projekt?" dhe ai thotë: "Po", atëherë kur e pyes se çfarë bën, ai më përshkruan absolutisht të gjithë procesin e automatizimit. Kjo nuk është plotësisht e vërtetë.
Në fakt, praktika e CI synon vetëm integrimin e kodit që shkruajnë njerëz të ndryshëm në një lloj baze të vetme kodi. Kjo eshte e gjitha.
Së bashku me CI, zakonisht ka praktika të tjera gjatë rrugës - të tilla si vendosja e vazhdueshme, menaxhimi i lëshimit, por ne do të flasim për këtë më vonë.
Vetë CI na thotë se njerëz të ndryshëm shkruajnë kodin dhe ky kod duhet të integrohet vazhdimisht në një bazë të vetme kodi.
Çfarë na jep kjo dhe pse është e rëndësishme? Nëse kemi DotNet, atëherë kjo është mirë, është një gjuhë e kompiluar, ne mund të përpilojmë aplikacionin tonë. Nëse përpilohet, atëherë kjo është tashmë një shenjë e mirë. Kjo nuk do të thotë asgjë ende, por është shenja e parë e mirë që të paktën mund ta përpilojmë.
Më pas mund të kryejmë disa teste, që është gjithashtu një praktikë më vete. Testet janë të gjitha jeshile - kjo është shenja e dytë e mirë. Por përsëri, kjo nuk do të thotë asgjë.
Por pse do ta bënit këtë? Të gjitha praktikat për të cilat do të flas sot kanë përafërsisht të njëjtën vlerë, pra përafërsisht të njëjtat përfitime dhe gjithashtu maten afërsisht në të njëjtën mënyrë.
Së pari, ju lejon të përshpejtoni shpërndarjen. Si ju lejon kjo të përshpejtoni shpërndarjen? Kur bëjmë disa ndryshime të reja në bazën tonë të kodit, mund të përpiqemi menjëherë të bëjmë diçka me këtë kod. Nuk presim të vijë e enjtja sepse të enjten e lëshojmë në QA Environment, e bëjmë pikërisht këtu dhe këtu.
Unë do t'ju tregoj një histori të trishtë nga jeta ime. Ishte shumë kohë më parë, kur isha ende i ri dhe i pashëm. Tani jam tashmë e re, e bukur dhe e zgjuar dhe modeste. Para disa kohësh isha në një projekt. Ne kishim një ekip të madh prej rreth 30 zhvilluesish. Dhe ne patëm një projekt të madh e të madh të Ndërmarrjes që u zhvillua për rreth 10 vjet. Dhe ne kishim degë të ndryshme. Në depo kishim një degë në të cilën ecnin zhvilluesit. Dhe kishte një degë që shfaqte versionin e kodit që është në prodhim.
Dega e prodhimit ishte 3 muaj pas degës që ishte në dispozicion të zhvilluesve. Çfarë do të thotë kjo? Kjo do të thotë që sapo kam një gabim diku që shkon në prodhim për fajin e zhvilluesve, sepse ata e lejuan atë dhe për faj të QA, sepse ata e shikuan atë, atëherë kjo do të thotë që nëse marr një detyrë për hotfix për prodhim, atëherë më duhet të rikthej ndryshimet e kodit tim 3 muaj më parë. Më duhet të kujtoj atë që kisha 3 muaj më parë dhe të përpiqem ta rregulloj atje.
Nëse nuk e keni pasur ende këtë përvojë, mund ta provoni në projektin tuaj të shtëpisë. Gjëja kryesore është, mos e provoni në një komercial. Shkruani disa rreshta kodi, harrojini ato për gjashtë muaj dhe më pas kthehuni dhe përpiquni të shpjegoni shpejt se për çfarë bëjnë fjalë ato rreshta kodi dhe si mund t'i rregulloni ose optimizoni ato. Është një përvojë shumë, shumë emocionuese.
Nëse kemi një praktikë të Integrimit të Vazhdueshëm, atëherë kjo na lejon ta kontrollojmë atë me një numër mjetesh të automatizuara pikërisht këtu dhe tani, sapo të shkruaj kodin tim. Kjo mund të mos më japë një pamje të plotë, por megjithatë, do të heqë të paktën disa nga rreziqet. Dhe nëse ka ndonjë gabim të mundshëm, unë do ta di për të menjëherë, domethënë, fjalë për fjalë brenda disa minutash. Nuk do të duhet të kthehem pas 3 muajsh. Do të më duhet të kthehem pas 2 minutash. Një aparat kafeje e mirë nuk do të ketë as kohë për të krijuar kafe në 2 minuta, kështu që është shumë e bukur.
Kjo ka vlerën që mund të përsëritet herë pas here në çdo projekt, d.m.th. jo vetëm ai në të cilin e keni vendosur. Ju mund të përsërisni edhe vetë praktikën dhe vetë CI do të përsëriten për çdo ndryshim të ri që bëni në projekt. Kjo ju lejon të optimizoni burimet sepse ekipi juaj punon në mënyrë më efikase. Nuk do të keni më një situatë ku ju vjen një gabim nga kodi me të cilin keni punuar 3 muaj më parë. Nuk do të keni më ndërrim të kontekstit kur uleni dhe kaloni dy orët e para duke u përpjekur të kuptoni se çfarë ndodhi më pas dhe të futeni në thelbin e kontekstit përpara se të filloni të korrigjoni diçka.
Si mund ta masim suksesin apo dështimin e kësaj praktike? Nëse i raporton shefit të madh atë që kemi zbatuar në projektin CI, ai dëgjon bla bla bla. E kemi zbatuar, në rregull, por pse, çfarë na ka sjellë, si e masim, sa saktë apo gabim po e zbatojmë?
E para është se, falë CI, ne mund të vendosim gjithnjë e më shpesh, dhe më shpesh pikërisht sepse kodi ynë është potencialisht më i qëndrueshëm. Në të njëjtën mënyrë, koha jonë për të gjetur një gabim zvogëlohet dhe koha për të korrigjuar këtë gabim zvogëlohet pikërisht për arsyen se ne marrim një përgjigje nga sistemi pikërisht këtu dhe tani, se çfarë nuk shkon me kodin tonë.
Një praktikë tjetër që kemi është praktika e Automatizimit të Testimit, e cila më së shpeshti vjen me praktikën CI. Ata shkojnë dorë për dore.
Çfarë është e rëndësishme për të kuptuar këtu? Është e rëndësishme të kuptojmë se testet tona janë të ndryshme. Dhe çdo test i automatizuar ka për qëllim zgjidhjen e problemeve të veta. Ne kemi, për shembull, teste të njësive që na lejojnë të testojmë një modul veçmas, d.m.th. Si funksionon në vakum? Kjo eshte mire.
Ne kemi gjithashtu teste integrimi që na lejojnë të kuptojmë se si module të ndryshme integrohen me njëri-tjetrin. Është gjithashtu e mirë.
Ne mund të kemi teste të automatizimit të UI që na lejojnë të kontrollojmë se sa mirë puna me UI plotëson disa kërkesa të vendosura nga klienti, etj.
Testet specifike që kryeni mund të ndikojnë në sa shpesh i kryeni ato. Testet e njësive zakonisht shkruhen të shkurtra dhe të vogla. Dhe ato mund të lansohen rregullisht.
Nëse po flasim për testet e automatizimit të UI, atëherë është mirë nëse projekti juaj është i vogël. Testet tuaja të automatizimit të ndërfaqes së përdoruesit mund të kërkojnë pak kohë të mjaftueshme. Por zakonisht një test i automatizimit UI është diçka që kërkon disa orë në një projekt të madh. Dhe është mirë nëse janë disa orë. E vetmja gjë është se nuk ka kuptim t'i ekzekutosh ato për çdo ndërtim. Ka kuptim t'i drejtoni ato gjatë natës. Dhe kur të gjithë erdhën në punë në mëngjes: si testuesit ashtu edhe zhvilluesit, ata morën një lloj raporti se ne kryenim autotestin UI gjatë natës dhe morëm këto rezultate. Dhe këtu, një orë punë e një serveri që do të kontrollojë nëse produkti juaj plotëson disa kërkesa do të jetë shumë më lirë se një orë punë e të njëjtit inxhinier të QA, edhe nëse ai është një inxhinier i ri i QA që punon për ushqim dhe falenderime. Gjithsesi, një orë funksionimi i makinës do të jetë më i lirë. Kjo është arsyeja pse ka kuptim të investoni në të.
Kam një projekt tjetër për të cilin jam duke punuar. Ne patëm sprinte dy-javore në këtë projekt. Projekti ishte i madh, i rëndësishëm për sektorin financiar dhe nuk mund të bëhej një gabim. Dhe pas një sprint dyjavor, cikli i zhvillimit u pasua nga një proces testimi, i cili zgjati 4 javë të tjera. Mundohuni të imagjinoni shkallën e tragjedisë. Ne shkruajmë kodin për dy javë, pastaj e bëjmë atë ala CodeFreeze, e paketojmë në një version të ri të aplikacionit dhe e shpërndajmë te testuesit. Testuesit e testojnë edhe 4 javë të tjera, d.m.th. Ndërsa ata janë duke e testuar, ne kemi kohë për të përgatitur dy versione të tjera për ta. Ky është një rast vërtet i trishtuar.
Dhe ne u thamë atyre se nëse doni të jeni më produktivë, ka kuptim që ju të zbatoni praktikat e Testimit të Automatizuar, sepse kjo është ajo që ju lëndon pikërisht këtu, tani.
Praktikoni vendosjen e vazhdueshme. E shkëlqyeshme, ju keni mbaruar ndërtimin. Kjo tashmë është mirë. Kodi juaj është përpiluar. Tani do të ishte mirë ta vendosje këtë ndërtim në një mjedis. Le të themi në një mjedis për zhvilluesit.
Pse është e rëndësishme? Së pari, mund të shikoni se sa i suksesshëm jeni me vetë procesin e vendosjes. Kam takuar projekte të tilla, kur pyes: "Si e vendos një version të ri të aplikacionit?", djemtë më thonë: "Ne e mbledhim atë dhe e paketojmë në një arkiv zip. Ne ia dërgojmë administratorit me postë. Administratori e shkarkon dhe e zgjeron këtë arkiv. Dhe e gjithë zyra fillon të lutet që serveri të marrë versionin e ri.”
Le të fillojmë me diçka të thjeshtë. Për shembull, ata harruan të vendosnin CSS në arkiv ose harruan të ndryshonin hashtag në emrin e skedarit java-script. Dhe kur i bëjmë një kërkesë serverit, shfletuesi mendon se tashmë e ka këtë skedar java-script dhe vendos të mos e shkarkojë atë. Dhe kishte një version të vjetër, diçka mungonte. Në përgjithësi, mund të ketë shumë probleme. Prandaj, praktika e vendosjes së vazhdueshme ju lejon të paktën të provoni se çfarë do të ndodhte nëse merrni një imazh të pastër referimi dhe e ngarkoni atë në një mjedis të ri plotësisht të pastër. Ju mund të shihni se ku të çon kjo.
Gjithashtu, kur integroni kodin mes njëri-tjetrit, d.m.th. ndërmjet komandës, kjo ju lejon të shihni gjithashtu se si duket në UI.
Një nga problemet që shfaqet kur përdoret shumë java-skrip vanilje është se dy zhvillues deklaruan me nxitim një variabël me të njëjtin emër në objektin e dritares. Dhe pastaj, në varësi të fatit tuaj. Skedari i të cilit java-script nxirret i dyti do të mbishkruajë ndryshimet e tjetrit. Është gjithashtu shumë emocionuese. Ju hyni: një gjë funksionon për një person, një tjetër nuk funksionon për një tjetër. Dhe është "e mrekullueshme" kur gjithçka del në prodhim.
Praktika tjetër që kemi është praktika e Rivendosjes Automatike, pra kthimi në versionin e mëparshëm të aplikacionit.
Pse është kjo e rëndësishme për zhvilluesit? Ka ende nga ata që kujtojnë vitet e largëta, të largëta 90, kur kompjuterët ishin të mëdhenj dhe programet ishin të vegjël. Dhe e vetmja mënyrë për zhvillimin e uebit ishte përmes PHP. Nuk është se PHP është një gjuhë e keqe, megjithëse është.
Por problemi ishte ndryshe. Kur vendosëm një version të ri të faqes sonë php, si e vendosëm atë? Më shpesh kemi hapur Far Manager ose diçka tjetër. Dhe i ngarkoi këto skedarë në FTP. Dhe papritmas kuptuam se kishim një gabim të vogël, të vogël, për shembull, harruam të vendosnim një pikëpresje ose harruam të ndryshonim fjalëkalimin për bazën e të dhënave, dhe ekziston një fjalëkalim për bazën e të dhënave, i cili është në hostin lokal. Dhe ne vendosim të lidhemi shpejt me FTP dhe të modifikojmë skedarët pikërisht atje. Ky është vetëm zjarr! Kjo ishte ajo që ishte e njohur në vitet '90.
Por, nëse nuk e keni parë kalendarin, vitet '90 ishin gati 30 vjet më parë. Tani gjithçka po ndodh pak më ndryshe. Dhe përpiquni të imagjinoni përmasat e tragjedisë kur ju thonë: “Ne u vendosëm në prodhim, por diçka nuk shkoi keq atje. Këtu është identifikimi dhe fjalëkalimi juaj FTP, lidheni me prodhimin dhe rregulloni shpejt atje." Nëse je Chuck Norris, kjo do të funksionojë. Nëse jo, atëherë rrezikoni që nëse rregulloni një gabim, do të bëni 10. Pikërisht për këtë arsye kjo praktikë e rikthimit në versionin e mëparshëm ju lejon të arrini shumë.
Edhe nëse diçka e keqe disi ka hyrë në nxitje diku, atëherë është e keqe, por jo fatale. Mund të ktheheni te versioni i mëparshëm që keni. Quajeni atë një kopje rezervë, nëse është më e lehtë ta perceptosh atë në atë terminologji. Mund të riktheheni te ky version i mëparshëm dhe përdoruesit do të jenë ende në gjendje të punojnë me produktin tuaj dhe do të keni kohë të mjaftueshme për tampon. Ju mund t'i merrni me qetësi, pa nxitim, të gjitha këto dhe ta provoni në vend, ta rregulloni dhe më pas të ngarkoni një version të ri. Është me të vërtetë kuptim për ta bërë këtë.
Tani le të përpiqemi të kombinojmë disi dy praktikat e mëparshme së bashku. Ne do të marrim një të tretë të quajtur Menaxhimi i lëshimit.
Kur flasim për vendosjen e vazhdueshme në formën e tij klasike, themi se duhet të nxjerrim kodin nga një degë nga depoja, ta përpilojmë dhe ta vendosim atë. Është mirë nëse kemi të njëjtin mjedis. Nëse kemi disa mjedise, kjo do të thotë që ne duhet ta tërheqim kodin çdo herë, qoftë edhe nga i njëjti commit. Ne do ta nxjerrim atë çdo herë, do ta ndërtojmë çdo herë dhe do ta vendosim në një mjedis të ri. Së pari, kjo është koha, sepse për të ndërtuar një projekt, nëse keni një të madh dhe keni ardhur nga vitet '90, atëherë mund të duhen disa orë.
Përveç kësaj, ka një trishtim tjetër. Kur ndërtoni, edhe në të njëjtën makinë, do të ndërtoni të njëjtat burime, nuk keni ende asnjë garanci që kjo makinë është në të njëjtën gjendje siç ishte gjatë ndërtimit të fundit.
Le të themi se dikush hyri dhe përditësoi DotNet për ju ose, anasjelltas, dikush vendosi të fshinte diçka. Dhe pastaj keni disonancë konjitive që nga ky angazhim dy javë më parë ne po ndërtonim një ndërtim dhe gjithçka ishte në rregull, por tani duket sikur e njëjta makinë, i njëjti angazhim, i njëjti kod që po përpiqemi të ndërtojmë, por nuk po funksionon . Ju do të merreni me këtë për një kohë të gjatë dhe nuk është fakt që do ta kuptoni. Te pakten do i prishni shume nervat.
Prandaj, praktika e Menaxhimit të Release sugjeron futjen e një abstraksioni shtesë të quajtur një depo ose galeri ose bibliotekë artifakte. Mund ta quani si të doni.
Ideja kryesore është që sapo të kemi një lloj angazhimi atje, të themi, në një degë që jemi gati ta vendosim në mjediset tona të ndryshme, ne mbledhim aplikacione nga ky commit dhe gjithçka që na nevojitet për këtë aplikacion, ne e paketojmë atë. në një arkiv zip dhe ruajeni në një ruajtje të besueshme. Dhe nga kjo ruajtje ne mund ta marrim këtë arkiv zip në çdo kohë.
Më pas e marrim dhe e vendosim automatikisht në mjedisin dev. Ne garojmë atje dhe nëse gjithçka është mirë, atëherë vendosemi në skenë. Nëse gjithçka është mirë, atëherë ne vendosim të njëjtin arkiv në prodhim, të njëjtat binare, të përpiluara saktësisht një herë.
Përveç kësaj, kur kemi një galeri si kjo, na ndihmon gjithashtu të adresojmë rreziqet që trajtuam në rrëshqitjen e fundit kur folëm për rikthimin në versionin e mëparshëm. Nëse keni vendosur aksidentalisht diçka të gabuar, gjithmonë mund të merrni çdo version tjetër të mëparshëm nga kjo galeri dhe ta shpërndani atë në këto mjedise në të njëjtën mënyrë. Kjo ju lejon të ktheheni lehtësisht në versionin e mëparshëm nëse diçka shkon keq.
Ekziston një praktikë tjetër e shkëlqyer. Ju dhe unë të gjithë e kuptojmë se kur i kthejmë aplikacionet tona në një version të mëparshëm, kjo mund të nënkuptojë se kemi nevojë edhe për infrastrukturën e versionit të mëparshëm.
Kur flasim për infrastrukturën virtuale, shumë njerëz mendojnë se kjo është diçka që vendosin administratorët. Dhe nëse keni nevojë, të themi, për të marrë një server të ri në të cilin dëshironi të testoni një version të ri të aplikacionit tuaj, atëherë duhet t'i shkruani një biletë administratorëve ose devops. Devops do të marrë 3 javë për këtë. Dhe pas 3 javësh ata do t'ju thonë se ne kemi instaluar një makinë virtuale për ju, me një bërthamë, dy gigabajt RAM dhe një server Windows pa DotNet. Ju thoni: "Por unë doja DotNet." Ata: "Ok, kthehu pas 3 javësh."
Ideja është që duke përdorur Infrastrukturën si praktika të Kodit, ju mund ta trajtoni infrastrukturën tuaj virtuale si një burim tjetër.
Ndoshta, nëse ndonjë prej jush po zhvillon aplikacione në DotNet, mund të keni dëgjuar për një bibliotekë të quajtur Entity Framework. Dhe madje mund të keni dëgjuar se Entity Framework është një nga qasjet që Microsoft po e shtyn në mënyrë aktive. Për të punuar me një bazë të dhënash, kjo është një qasje e quajtur Code First. Kjo është kur përshkruani në kod se si dëshironi të duket databaza juaj. Dhe pastaj vendosni aplikacionin. Ai lidhet me bazën e të dhënave, ai vetë përcakton se cilat tabela janë atje dhe cilat jo, dhe krijon gjithçka që ju nevojitet.
Ju mund të bëni të njëjtën gjë me infrastrukturën tuaj. Nuk ka asnjë ndryshim nëse keni nevojë për një bazë të dhënash për një projekt ose nëse keni nevojë për një server Windows për një projekt. Është thjesht një burim. Dhe ju mund të automatizoni krijimin e këtij burimi, ju mund të automatizoni konfigurimin e këtij burimi. Prandaj, sa herë që dëshironi të testoni ndonjë koncept të ri, ndonjë qasje të re, nuk do t'ju duhet të shkruani një biletë për devops, thjesht mund të vendosni një infrastrukturë të izoluar për veten tuaj nga shabllonet e gatshme, nga skriptet e gatshme dhe ta zbatoni atë. aty të gjitha eksperimentet tuaja. Ju mund ta fshini këtë, të merrni disa rezultate dhe të raportoni më tej për të.
Praktika tjetër, e cila gjithashtu ekziston dhe është gjithashtu e rëndësishme, por që pak njerëz e përdorin, është Monitorimi i Performancës së Aplikimit.
Doja të them vetëm një gjë për monitorimin e performancës së aplikacionit. Çfarë është më e rëndësishme për këtë praktikë? Kjo është ajo që Monitorimi i Performancës së Aplikimit është pothuajse i njëjtë me riparimin e një apartamenti. Ky nuk është një gjendje përfundimtare, është një proces. Duhet ta bëni rregullisht.
Në një mënyrë të mirë, do të ishte mirë të kryhej Monitorimi i performancës së aplikacionit pothuajse në çdo ndërtim, megjithëse, siç e kuptoni, kjo nuk është gjithmonë e mundur. Por, së paku, duhet të kryhet për çdo lëshim.
Pse është e rëndësishme? Sepse nëse papritmas përjetoni një rënie të performancës, atëherë duhet të kuptoni qartë pse. Nëse ekipi juaj ka, të themi, sprinte dy-javore, atëherë të paktën një herë në dy javë duhet ta vendosni aplikacionin tuaj në ndonjë server të veçantë, ku keni një procesor, RAM, disqe, etj. . Ju merrni rezultatin. Shihni se si ka ndryshuar nga sprinti i mëparshëm.
Dhe nëse zbuloni se tërheqja ka rënë ndjeshëm diku, do të thotë se ishte vetëm për shkak të ndryshimeve që ndodhën gjatë dy javëve të fundit. Kjo do t'ju lejojë të identifikoni dhe rregulloni problemin shumë më shpejt. Dhe përsëri, këto janë afërsisht të njëjtat metrika me të cilat mund të matni se sa me sukses e keni bërë atë.
Praktika tjetër që kemi është praktika e Menaxhimit të Konfigurimit. Janë të paktë ata që e marrin këtë seriozisht. Por më besoni, kjo është në fakt një gjë shumë serioze.
Kohët e fundit ka pasur një histori qesharake. Djemtë erdhën tek unë dhe më thanë: "Na ndihmoni të bëjmë një auditim sigurie të aplikacionit tonë." Ne e shikuam kodin së bashku për një kohë të gjatë, ata më treguan për aplikacionin, vizatuan diagrame. Dhe plus ose minus gjithçka ishte logjike, e kuptueshme, e sigurt, por kishte një POR! Ata kishin skedarë konfigurimi në kontrollin e tyre burimor, përfshirë ato nga prodhimi me bazën e të dhënave IP, me hyrje dhe fjalëkalime për t'u lidhur me këto baza të të dhënave, etj.
Dhe unë them: "Djema, në rregull, ju e keni mbyllur mjedisin tuaj të prodhimit me një mur zjarri, por fakti që keni hyrjen dhe fjalëkalimin për bazën e të dhënave të prodhimit pikërisht në kontrollin e burimit dhe çdo zhvillues mund ta lexojë atë është tashmë një rrezik i madh sigurie. . Dhe pa marrë parasysh se sa super i sigurt është aplikacioni juaj nga pikëpamja e kodit, nëse e lini atë në kontrollin e burimit, atëherë nuk do të kaloni kurrë asnjë auditim askund.” Kjo është ajo që unë jam duke folur për.
Menaxhimi i konfigurimit. Mund të kemi konfigurime të ndryshme në mjedise të ndryshme. Për shembull, ne mund të kemi hyrje dhe fjalëkalime të ndryshme për bazat e të dhënave për QA, demo, mjedisin e prodhimit, etj.
Ky konfigurim gjithashtu mund të automatizohet. Duhet të jetë gjithmonë i ndarë nga vetë aplikacioni. Pse? Për shkak se e keni ndërtuar aplikacionin një herë, dhe më pas aplikacionit nuk i intereson nëse lidheni me serverin SQL nëpërmjet një IP të tillë ose të një IP të tillë e të tillë, ai duhet të funksionojë njësoj. Prandaj, nëse papritmas njëri prej jush po kodon ende vargun e lidhjes në kod, atëherë mbani mend se unë do t'ju gjej dhe do t'ju ndëshkoj nëse e gjeni veten në të njëjtin projekt me mua. Kjo vendoset gjithmonë në një konfigurim të veçantë, për shembull, në web.config.
Dhe ky konfigurim tashmë menaxhohet veçmas, d.m.th. është pikërisht momenti kur një zhvillues dhe një administrator mund të vijnë dhe të ulen në të njëjtën dhomë. Dhe zhvilluesi mund të thotë: "Shiko, këtu janë binaret e aplikacionit tim. Ata punojnë. Aplikacioni ka nevojë për një bazë të dhënash për të punuar. Këtu pranë binarëve ka një skedar. Në këtë skedar, kjo fushë është përgjegjëse për hyrjen, kjo është për fjalëkalimin, kjo është për IP-në. Vendoseni atë kudo." Dhe është e thjeshtë dhe e qartë për administratorin. Ai mund ta vendosë atë me të vërtetë kudo duke menaxhuar këtë konfigurim.
Dhe praktika e fundit për të cilën do të doja të flisja është një praktikë që lidhet shumë, shumë me retë. Dhe sjell efekt maksimal nëse punoni në re. Kjo është heqja automatike e mjedisit tuaj.
E di që ka disa njerëz në këtë konferencë nga ekipet me të cilat punoj. Dhe me të gjitha ekipet me të cilat punoj, ne e përdorim këtë praktikë.
Pse? Sigurisht, do të ishte mirë nëse secili zhvillues do të kishte një makinë virtuale që do të funksiononte 24/7. Por mbase ky është një lajm për ju, mbase nuk i keni kushtuar vëmendje, por vetë zhvilluesi nuk punon 24/7. Një zhvillues zakonisht punon 8 orë në ditë. Edhe nëse vjen herët në punë, ha një drekë të madhe gjatë së cilës shkon në palestër. Le të jenë 12 orë në ditë kur zhvilluesi i përdor këto burime. Sipas legjislacionit tonë, ne kemi 5 nga 7 ditë në javë që konsiderohen ditë pune.
Prandaj, gjatë ditëve të javës kjo makinë nuk duhet të punojë 24 orë, por vetëm 12, dhe gjatë fundjavave kjo makinë nuk duhet të funksionojë fare. Duket se gjithçka është shumë e thjeshtë, por çfarë është e rëndësishme të thuhet këtu? Duke zbatuar këtë praktikë të thjeshtë në këtë orar bazë, ju lejon të ulni koston e mirëmbajtjes së këtyre mjediseve me 70%, d.m.th. ju morët çmimin e zhvilluesit, QA, demo, mjedisin tuaj dhe e ndatë atë me 3.
Pyetja është, çfarë të bëjmë me pjesën tjetër të parave? Për shembull, zhvilluesit duhet të blejnë ReSharper nëse nuk e kanë bërë tashmë. Ose bëni një koktej. Nëse më parë keni pasur një mjedis në të cilin kullotnin si dev ashtu edhe QA, dhe kaq, tani mund të bëni 3 të ndryshme që do të izolohen dhe njerëzit nuk do të ndërhyjnë me njëri-tjetrin.
Sa i përket rrëshqitjes me matje të vazhdueshme të performancës, si mund të krahasojmë performancën nëse në projekt kishim 1 regjistrime në bazën e të dhënave, dy muaj më vonë janë një milion? Si të kuptojmë pse dhe cili është qëllimi i matjes së performancës?
Kjo është një pyetje e mirë, sepse gjithmonë duhet të matni performancën në të njëjtat burime. Kjo do të thotë, ju vendosni kodin e ri, ju matni performancën në kodin e ri. Për shembull, duhet të testoni skenarë të ndryshëm të performancës, le të themi se dëshironi të provoni se si funksionon aplikacioni në një ngarkesë të lehtë, ku ka 1 përdorues dhe madhësia e bazës së të dhënave është 000 gigabajt. E matët dhe morët numrat. Më pas marrim një skenar tjetër. Për shembull, 5 përdorues, madhësia e bazës së të dhënave 5 terabajt. Ne morëm rezultatet dhe i kujtuam ato.
Çfarë është e rëndësishme këtu? Gjëja e rëndësishme këtu është se në varësi të skenarit, vëllimit të të dhënave, numrit të përdoruesve të njëkohshëm etj., mund të hasni në kufij të caktuar. Për shembull, në kufirin e një karte rrjeti, ose në kufirin e një hard disk, ose në kufirin e aftësive të procesorit. Kjo është ajo që është e rëndësishme që ju të kuptoni. Në skenarë të ndryshëm ju hasni në kufij të caktuar. Dhe ju duhet të kuptoni numrat kur i goditni ato.
A po flasim për matjen e performancës në një mjedis të veçantë testimi? Domethënë, ky nuk është prodhim?
Po, ky nuk është prodhim, ky është një mjedis testimi, i cili është gjithmonë i njëjtë që të mund ta krahasoni me matjet e mëparshme.
Kuptohet faleminderit!
Nëse nuk ka pyetje, mendoj se mund të përfundojmë. Faleminderit!
Burimi: www.habr.com