Izvještaj će govoriti o nekim DevOps praksama, ali sa stanovišta programera. Obično svi inženjeri koji se pridruže DevOps-u već imaju nekoliko godina administrativnog iskustva iza sebe. Ali to ne znači da ovdje nema mjesta za programera. Češće nego ne, programeri su zauzeti ispravljanjem "sljedeće hitno kritične greške u danu", a nemaju vremena čak ni da na brzinu pogledaju DevOps polje. U autorovom shvatanju, DevOps je, pre svega, zdrav razum. Drugo, to je prilika da budete efikasniji. Ako ste programer, imate zdrav razum i želite da budete efikasniji kao timski igrač, ovaj izvještaj je za vas.
Da se predstavim, u potpunosti priznajem da u prostoriji ima ljudi koji me ne poznaju. Moje ime je Anton Boyko, ja sam Microsoft Azure MVP. Šta je MVP? Ovo je Model-View-Presenter. Model-View-Presenter sam upravo ja.
Osim toga, trenutno sam na poziciji arhitekte rješenja u Ciklumu. A tek nedavno sam sebi kupio tako lijep domen, i ažurirao svoju e-poštu, koju obično pokazujem na prezentacijama. Možete mi pisati na: me [pas] byokoant.pro. Možete mi poslati e-poštu sa pitanjima. Obično im odgovaram. Jedino što ne bih volio da primam mejlom pitanja koja se odnose na dvije teme: politiku i religiju. O svemu ostalom možete mi pisati putem mejla. Proći će neko vrijeme, odgovorit ću.
Par riječi o sebi:
- Ja sam u ovoj oblasti već 10 godina.
- Radio sam u Microsoftu.
- Ja sam osnivač ukrajinske zajednice Azure koju smo osnovali negdje 2014. godine. I još ga imamo i razvijamo ga.
- Također sam i otac osnivača Azure konferencije, čiji smo domaćin u Ukrajini.
- Također pomažem u organizaciji Global Azure Bootcamp-a u Kijevu.
- Kao što sam rekao, ja sam Microsoft Azure MVP.
- Prilično često govorim na konferencijama. Zaista volim govoriti na konferencijama. Tokom prošle godine bio sam u mogućnosti da nastupim oko 40 puta. Ako prođete pored Ukrajine, Belorusije, Poljske, Bugarske, Švedske, Danske, Holandije, Španije ili date ili uzmete neku drugu državu u Evropi, onda je sasvim moguće da kada odete na konferenciju koja ima temu oblaka u svom streamu, možda me vidite na listi govornika.
- Takođe sam fan Zvjezdanih staza.
Hajde da pričamo malo o dnevnom redu. Naš plan je vrlo jednostavan:
- Razgovaraćemo o tome šta je DevOps. Hajde da razgovaramo zašto je ovo važno. Ranije je DevOps bila ključna riječ koju ste napisali u svom životopisu i odmah primili +500$ plaće. Sada trebate upisati, na primjer, blockchain u svoj životopis kako biste dobili +500 dolara na svoju platu.
- A onda, kada malo shvatimo šta je ovo, razgovaraćemo o tome šta su DevOps prakse. Ali ne toliko u kontekstu DevOps-a općenito, već o onim DevOps praksama koje bi mogle biti zanimljive programerima. Reći ću vam zašto bi vas mogli zanimati. Reći ću vam zašto biste to uopće trebali učiniti i kako vam to može pomoći da manje bolujete.
Tradicionalna slika koju mnogi ljudi pokazuju. To se dešava u mnogim projektima. Tada imamo razvojne i operativne odjele koji podržavaju naš softver. I ova odjeljenja ne komuniciraju jedni s drugima.
Možda, ako niste bili u mogućnosti da to tako jasno osjetite u DevOps i operativnim odjelima, možete povući analogiju sa odjelima za razvoj i osiguranje kvalitete. Postoje ljudi koji razvijaju softver, a postoje ljudi za osiguranje kvaliteta koji su loši sa stanovišta programera. Na primjer, predajem svoj divni kod u spremište, a tamo sjedi neki nitkov koji mi vraća ovaj kod i kaže da je vaš kod loš.
Sve se to dešava jer ljudi ne komuniciraju jedni s drugima. I bacaju neke pakete, neku aplikaciju jedni drugima kroz neki zid nesporazuma i pokušavaju nešto da urade s njima.
Upravo taj zid je dizajniran da uništi DevOps kultura, tj. prisiliti ljude da međusobno komuniciraju i barem razumiju šta različiti ljudi u projektu rade i zašto je njihov rad važan.
A kada govorimo o DevOps-u, neko će vam reći da je DevOps kada projekat ima kontinuiranu integraciju; neko će reći da je DevOps ako projekat implementira praksu „infrastruktura kao kod“; neko će reći da je prvi korak ka DevOps-u grananje karakteristika, zastavice funkcija.
U suštini, sve je to tačno na svoj način. Ali ovo su samo vrhunske prakse koje imamo. Prije nego što pređemo na ove prakse, predlažem da pogledate ovaj slajd, koji prikazuje 3 faze implementacije Dev-Ops metodologije u vašem projektu, u vašoj kompaniji.
Ovaj slajd ima i drugo nezvanično ime. Možete pretraživati na mreži kako biste saznali koja su 3 mušketira DevOpsa. Moguće je da ćete pronaći ovaj članak. Zašto 3 mušketira? Ispod piše: ljudi, procesi i proizvodi, tj. JPP – Porthos, Porthos i Porthos. Evo 3 mušketira DevOpsa. Ovaj članak detaljnije opisuje zašto je to važno i šta podrazumijeva.
Kada počnete implementirati DevOps kulturu, vrlo je važno da se implementira sljedećim redoslijedom.
U početku morate razgovarati s ljudima. I morate ljudima objasniti šta je to i kako mogu izvući neke koristi od toga.
Naša konferencija se zove DotNet Fest. I kao što su mi rekli organizatori, ovdje smo uglavnom pozvali publiku programera, tako da se nadam da je većina ljudi u dvorani uključena u razvoj.
Pričaćemo o ljudima, razgovaraćemo o tome šta programeri žele da rade svaki dan. Šta oni najviše žele? Žele da napišu neki novi kod, koriste novonastale okvire, kreiraju nove funkcije. Šta programeri najmanje žele? Popravite stare greške. Nadam se da se slažete sa mnom. To je ono što programeri žele. Žele da pišu nove funkcije, ne žele da popravljaju greške.
Broj grešaka koje određeni programer proizvodi ovisi o tome koliko su mu ruke ravne i koliko rastu iz njegovih ramena, a ne iz džepova na zadnjici. Ali ipak, kada imamo veliki projekat, ponekad se desi da je nemoguće sve pratiti, pa bi bilo dobro da koristimo neke pristupe koji će nam pomoći da napišemo stabilniji i kvalitetniji kod.
Šta QA najviše žele? Ne znam da li su u sali. Teško mi je reći da želim QA, jer to nikada nisam bio. I bez uvrede za momke, reći će se da se nadam da nikada neću. Ali ne iz razloga što njihov rad smatram besmislenim i beskorisnim, već zato što sebe ne smatram osobom koja bi taj posao mogla da radi efikasno, pa neću ni pokušavati. Ali koliko sam shvatio, ono što QA najviše ne voli je da radi ujutro, da stalno radi neke vrste regresijskih testova, gazi iste greške koje su prijavili programerima prije 3 sprinta i govore: „Kada ćeš , Monsieur D 'Artagnan, popravi ovu grešku.' A gospodin D'Artagnan mu odgovara: "Da, da, da, već sam to popravio." I kako se desi da sam popravio jednu grešku i napravio 5 usput.
Ljudi koji podržavaju ovo rešenje u produkciji žele da ovo rešenje radi bez grešaka, kako ne bi morali da restartuju server svakog petka, kada svi normalni ljudi idu u bar. Programeri su raspoređeni u petak, admini sjede do subote, pokušavajući da podignu i poprave ovu implementaciju.
A kada objasnite ljudima da su oni usmjereni na rješavanje istih problema, možete prijeći na formalizaciju procesa. To je veoma važno. Zašto? Jer kada kažemo „formalizacija“, važno je da opišete kako se vaši procesi odvijaju barem negdje na salveti. Morate razumjeti da ako, na primjer, implementirate u QA okruženje ili proizvodno okruženje, onda se to uvijek događa ovim redoslijedom; u ovim fazama pokrećemo, na primjer, automatske testove jedinica i UI testove. Nakon raspoređivanja provjeravamo da li je implementacija protekla dobro ili loše. Ali već imate jasnu listu radnji koje se moraju ponavljati iznova i iznova kada se implementirate u proizvodnju.
I tek kada su vaši procesi formalizovani, počinjete da birate proizvode koji će vam pomoći da automatizujete ove procese.
Nažalost, vrlo često vidim da se to dešava obrnuto. Čim neko čuje riječ „DevOps“, odmah predlažu instaliranje Jenkinsa, jer vjeruju da će čim instaliraju Jenkins imati DevOps. Instalirali su Jenkinsa, pročitali članke "Kako da" na web stranici Jenkinsa, pokušali ubaciti procese u ove članke Kako to, a onda su došli do ljudi i sagnuli ljude, govoreći da knjiga kaže da to treba učiniti na ovaj način, pa to radimo na ovaj način.
Nije da je Dženkins loš alat. Ne želim to reći ni na koji način. Ali ovo je samo jedan od proizvoda. I koji proizvod ćete koristiti trebala bi biti vaša posljednja odluka, a nikako prva. Vaš proizvod ne bi trebao biti vođen implementacijom kulture i pristupa. Ovo je veoma važno razumjeti, zbog čega provodim toliko vremena na ovom slajdu i sve ovo toliko dugo objašnjavam.
Hajde da pričamo o DevOps praksi uopšte. Šta su oni? Koja je razlika? Kako ih isprobati? Zašto su važni?
Prva praksa za koju ste možda čuli zove se Kontinuirana integracija. Možda neko na projektu ima kontinuiranu integraciju (CI).
Najveći problem je što najčešće kada pitam osobu: „Imaš li CI na projektu?“ a on kaže: „Da“, onda kada ga pitam šta radi, on mi opisuje apsolutno ceo proces automatizacije. Ovo nije sasvim tačno.
Zapravo, praksa CI-ja je samo usmjerena na integraciju koda koji različiti ljudi pišu u neku vrstu jedinstvene baze koda. To je sve.
Uz CI, obično postoje i druge prakse na putu - kao što su kontinuirana implementacija, upravljanje izdanjima, ali o tome ćemo kasnije.
Sam CI nam govori da različiti ljudi pišu kod i da se taj kod mora kontinuirano integrirati u jednu bazu koda.
Šta nam to daje i zašto je važno? Ako imamo DotNet, onda je to dobro, to je kompajlirani jezik, možemo kompajlirati našu aplikaciju. Ako se kompajlira, to je već dobar znak. Ovo još ništa ne znači, ali je prvi dobar znak da možemo barem kompajlirati.
Onda možemo da pokrenemo neke testove, što je takođe posebna praksa. Svi testovi su zeleni – ovo je drugi dobar znak. Ali opet, ovo ne znači ništa.
Ali zašto bi ovo uradio? Sve prakse o kojima ću danas govoriti nose približno istu vrijednost, odnosno približno iste koristi i mjere se približno na isti način.
Prvo, omogućava vam da ubrzate isporuku. Kako vam to omogućava da ubrzate isporuku? Kada napravimo neke nove promjene u našoj bazi koda, možemo odmah pokušati nešto učiniti s ovim kodom. Ne čekamo da dođe četvrtak jer ga u četvrtak objavljujemo u QA Environment, radimo to ovdje i ovdje.
Ispričaću vam jednu tužnu priču iz mog života. Bilo je to davno, kada sam još bio mlad i zgodan. Sad sam već mlada, lijepa i pametna, i skromna. Prije nekog vremena bio sam u projektu. Imali smo veliki tim od oko 30 programera. I imali smo veliki, veliki Enterprise projekat koji se razvijao oko 10 godina. I imali smo različite filijale. U spremištu smo imali granu u kojoj su programeri hodali. I postojala je grana koja je prikazivala verziju koda koja je u proizvodnji.
Proizvodna grana je zaostajala 3 mjeseca za granom koja je bila dostupna programerima. Šta to znači? To znači da čim imam grešku negdje koja ide u proizvodnju greškom programera, jer su to dozvolili, i greškom QA, jer su je pogledali, onda to znači da ako dobijem zadatak za hitnu popravku za proizvodnju, onda moram vratiti promjene koda prije 3 mjeseca. Moram se sjetiti šta sam imao prije 3 mjeseca i pokušati to popraviti.
Ako još niste imali ovo iskustvo, možete ga isprobati na svom kućnom projektu. Glavna stvar je da to ne pokušavate na komercijalnom. Napišite nekoliko redova koda, zaboravite na njih šest mjeseci, a zatim se vratite i pokušajte brzo objasniti o čemu se radi u tim linijama koda i kako ih možete popraviti ili optimizirati. To je veoma, veoma uzbudljivo iskustvo.
Ako imamo praksu kontinuirane integracije, to nam omogućava da to provjerimo s brojnim automatiziranim alatima upravo ovdje i sada, čim napišem svoj kod. Ovo mi možda neće dati potpunu sliku, ali će ipak ukloniti barem neke od rizika. A ako postoji neka potencijalna greška, znat ću za nju odmah, odnosno bukvalno za par minuta. Neću morati da vraćam 3 mjeseca unazad. Trebat ću vratiti samo 2 minute unazad. Dobar aparat za kafu neće imati vremena ni da skuha kafu za 2 minuta, tako da je to prilično cool.
Ovo ima vrijednost da se može ponavljati svaki put na svakom projektu, tj. ne samo onaj na koji ste ga postavili. Možete ponoviti i samu praksu i sam CI će se ponavljati za svaku novu promjenu koju napravite na projektu. Ovo vam omogućava da optimizujete resurse jer vaš tim radi efikasnije. Više nećete imati situaciju da vam greška dođe iz koda s kojim ste radili prije 3 mjeseca. Više nećete imati promjenu konteksta kada sjedite i provedete prva dva sata pokušavajući da shvatite šta se tada dogodilo i uđete u suštinu konteksta prije nego počnete nešto ispravljati.
Kako možemo izmjeriti uspjeh ili neuspjeh ove prakse? Ako prijavite velikom šefu šta smo implementirali na CI projektu, on čuje bla bla bla. Mi smo to implementirali, OK, ali zašto, šta nam je to donijelo, kako to mjerimo, koliko ispravno ili netačno implementiramo?
Prvi je da zahvaljujući CI-ju možemo sve češće implementirati, i to češće upravo zato što je naš kod potencijalno stabilniji. Na isti način, naše vrijeme za pronalaženje greške je smanjeno i vrijeme za ispravljanje ove greške je smanjeno upravo iz razloga što upravo ovdje i sada dobijamo odgovor od sistema šta nije u redu sa našim kodom.
Druga praksa koju imamo je praksa Automation Testing, koja najčešće dolazi sa praksom CI. Oni idu ruku pod ruku.
Šta je ovdje važno razumjeti? Važno je shvatiti da se naši testovi razlikuju. I svaki automatizirani test ima za cilj rješavanje vlastitih problema. Imamo, na primjer, jedinične testove koji nam omogućavaju da zasebno testiramo modul, tj. Kako to funkcionira u vakuumu? Ovo je dobro.
Takođe imamo integracijske testove koji nam omogućavaju da razumemo kako se različiti moduli integrišu jedan sa drugim. Takođe je dobro.
Možda imamo testove automatizacije korisničkog sučelja koji nam omogućavaju da provjerimo koliko dobro rad sa korisničkim sučeljem ispunjava određene zahtjeve koje postavlja kupac, itd.
Specifični testovi koje izvodite mogu uticati na to koliko često ćete ih izvoditi. Jedinični testovi se obično pišu kratko i malo. I mogu se redovno lansirati.
Ako govorimo o testovima automatizacije korisničkog sučelja, onda je dobro ako je vaš projekt mali. Testovi automatizacije korisničkog sučelja mogu potrajati neko vrijeme. Ali obično je test automatizacije korisničkog sučelja nešto što traje nekoliko sati na velikom projektu. I dobro je ako je to nekoliko sati. Jedina stvar je da nema smisla pokretati ih za svaku gradnju. Ima smisla voditi ih noću. A kada su svi ujutro došli na posao: i testeri i programeri, dobili su neku vrstu izvještaja da smo noću pokrenuli autotest korisničkog sučelja i dobili ove rezultate. I ovdje će sat rada servera koji će provjeriti da li vaš proizvod ispunjava neke zahtjeve biti mnogo jeftiniji od sata rada istog QA inženjera, čak i ako je Junior QA inženjer koji radi za hranu i hvala. Svejedno, sat rada mašine će biti jeftiniji. Zbog toga ima smisla ulagati u njega.
Imam još jedan projekat na kojem sam radio. Imali smo dvonedeljne sprintove na ovom projektu. Projekat je bio veliki, važan za finansijski sektor i nije se mogla napraviti greška. I nakon dvonedeljnog sprinta, razvojni ciklus je praćen procesom testiranja, koji je trajao još 4 nedelje. Pokušajte zamisliti razmjere tragedije. Pišemo kod dvije sedmice, a onda to radimo ala CodeFreeze, upakujemo ga u novu verziju aplikacije i puštamo testerima. Testeri ga testiraju još 4 sedmice, tj. Dok ga oni testiraju, imamo vremena da im pripremimo još dvije verzije. Ovo je zaista tužan slučaj.
I rekli smo im da ako želite da budete produktivniji, ima smisla da implementirate automatizovano testiranje, jer vas to boli upravo ovde, upravo sada.
Vježbajte kontinuiranu implementaciju. Odlično, završili ste izgradnju. Ovo je već dobro. Vaš kod je kompajliran. Sada bi bilo lijepo primijeniti ovu verziju na nekom okruženju. Recimo u okruženju za programere.
Zašto je to važno? Prvo, možete pogledati koliko ste uspješni sa samim procesom implementacije. Susreo sam se sa ovakvim projektima, kada pitam: “Kako implementirati novu verziju aplikacije?”, momci mi kažu: “Sastavljamo je i spakujemo u zip arhivu. Šaljemo administratoru poštom. Administrator preuzima i proširuje ovu arhivu. I cijeli ured počinje da se moli da server preuzme novu verziju.”
Počnimo s nečim jednostavnim. Na primjer, zaboravili su staviti CSS u arhivu ili su zaboravili promijeniti hashtag u nazivu java-script datoteke. A kada uputimo zahtjev serveru, pretraživač misli da već ima ovaj java-script fajl i odlučuje da ga ne preuzme. I postojala je stara verzija, nešto je nedostajalo. Općenito, može biti mnogo problema. Stoga vam praksa kontinuirane implementacije omogućava da barem testirate šta bi se dogodilo da uzmete čistu referentnu sliku i učitate je u potpuno čisto novo okruženje. Možete vidjeti kuda ovo vodi.
Takođe, kada integrišete međusobne kodove, tj. između komande, ovo vam takođe omogućava da vidite kako to izgleda na korisničkom sučelju.
Jedan od problema koji se javlja kada se koristi mnogo vanilla java-scripta je taj što su dva programera naglo deklarirala varijablu s istim imenom u objektu prozora. A onda, u zavisnosti od vaše sreće. Čija java-script datoteka je izvučena drugi će prepisati promjene druge. Takođe je veoma uzbudljivo. Ulazite: jedna stvar radi za jednu osobu, druga ne radi za drugu. I “divan je” kada sve izađe u produkciju.
Sljedeća praksa koju imamo je praksa automatskog vraćanja u prethodno stanje, odnosno vraćanje na prethodnu verziju aplikacije.
Zašto je ovo važno za programere? Još uvijek ima onih koji se sjećaju dalekih, dalekih 90-ih, kada su kompjuteri bili veliki, a programi mali. A jedini način za razvoj weba bio je preko PHP-a. Nije da je PHP loš jezik, iako jeste.
Ali problem je bio drugačiji. Kada smo postavili novu verziju naše php stranice, kako smo je implementirali? Najčešće smo otvarali Far Manager ili nešto drugo. I otpremio ove fajlove na FTP. I odjednom smo shvatili da imamo neku malu, malu grešku, na primjer, zaboravili smo staviti tačku-zarez ili smo zaboravili promijeniti lozinku za bazu podataka, a postoji lozinka za bazu podataka koja je na lokalnom hostu. I mi odlučujemo da se brzo povežemo na FTP i uredimo fajlove upravo tamo. Ovo je samo vatra! To je ono što je bilo popularno 90-ih.
Ali, ako niste pogledali kalendar, 90-te su bile prije skoro 30 godina. Sada se sve dešava malo drugačije. I pokušajte zamisliti razmjere tragedije kada vam kažu: „Pokrenuli smo se u proizvodnju, ali je tu nešto pošlo po zlu. Evo vaše FTP prijave i lozinke, povežite se s proizvodnjom i brzo to popravite tamo.” Ako ste Chuck Norris, ovo će uspjeti. Ako ne, onda rizikujete da ćete ako popravite jednu grešku napraviti još 10. Upravo zbog toga ova praksa vraćanja na prethodnu verziju vam omogućava da postignete mnogo.
Čak i ako je nešto loše nekako ušlo u prod negdje, onda je loše, ali nije fatalno. Možete se vratiti na prethodnu verziju koju imate. Nazovite to rezervnom, ako je to lakše shvatiti u toj terminologiji. Možete se vratiti na ovu prethodnu verziju, a korisnici će i dalje moći raditi s vašim proizvodom, a vi ćete imati adekvatno vrijeme međuspremnika. Možete mirno, bez žurbe, sve ovo uzeti i testirati lokalno, popraviti, a zatim postaviti novu verziju. Zaista ima smisla ovo uraditi.
Pokušajmo sada nekako spojiti dvije prethodne prakse zajedno. Dobit ćemo treći koji se zove Release Management.
Kada govorimo o Continuous Deploymentu u njegovom klasičnom obliku, kažemo da moramo izvući kod iz neke grane iz spremišta, kompajlirati ga i implementirati. Dobro je ako imamo isto okruženje. Ako imamo nekoliko okruženja, to znači da moramo svaki put povući kod, čak i iz istog urezivanja. Svaki put ćemo ga izvući, svaki put ćemo ga izgraditi i postaviti ga u novo okruženje. Prvo, ovo je vrijeme, jer za izgradnju projekta, ako imate veliki i dolazite iz 90-ih, onda može potrajati nekoliko sati.
Osim toga, postoji još jedna tuga. Kada gradite, čak i na istoj mašini, izgradićete iste izvore, još uvek nemate garanciju da je ova mašina u istom stanju kao što je bila tokom poslednje izgradnje.
Recimo da je neko došao i ažurirao DotNet umjesto vas ili, obrnuto, neko je odlučio da izbriše nešto. I onda imate kognitivnu disonancu da smo od ovog urezivanja prije dvije sedmice pravili build i sve je bilo u redu, ali sada izgleda kao ista mašina, isti urezivanje, isti kod koji pokušavamo da napravimo, ali ne radi . Dugo ćete se baviti ovim i nije činjenica da ćete to shvatiti. U najmanju ruku, dosta ćete pokvariti svoje živce.
Stoga praksa upravljanja izdanjima predlaže uvođenje dodatne apstrakcije koja se zove skladište artefakata ili galerija ili biblioteka. Možete to nazvati kako god želite.
Glavna ideja je da čim imamo neku vrstu urezivanja tamo, recimo, u grani koju smo spremni da implementiramo u naša različita okruženja, prikupimo aplikacije iz ovog urezivanja i sve što nam je potrebno za ovu aplikaciju, mi to spakujemo u zip arhivu i spremite je u neko pouzdano skladište. I iz ove pohrane možemo dobiti ovu zip arhivu u bilo kojem trenutku.
Zatim ga uzimamo i automatski ga postavljamo u okruženje za razvoj. Trkamo se tamo, i ako je sve u redu, onda idemo na binu. Ako je sve u redu, onda postavljamo istu arhivu u produkciju, iste binarne datoteke, kompajlirane tačno jednom.
Pored toga, kada imamo ovakvu galeriju, to nam takođe pomaže da se pozabavimo rizicima o kojima smo govorili na zadnjem slajdu kada smo govorili o vraćanju na prethodnu verziju. Ako ste slučajno postavili nešto pogrešno, uvijek možete uzeti bilo koju drugu prethodnu verziju iz ove galerije i na isti način je poništiti u tim okruženjima. Ovo vam omogućava da se lako vratite na prethodnu verziju ako nešto krene po zlu.
Postoji još jedna odlična praksa. Svi vi i ja razumijemo da kada vraćamo naše aplikacije na prethodnu verziju, to može značiti da nam je potrebna i infrastruktura prethodne verzije.
Kada govorimo o virtuelnoj infrastrukturi, mnogi misle da je to nešto što administratori postavljaju. A ako trebate, recimo, da dobijete novi server na kojem želite da testirate novu verziju svoje aplikacije, onda morate napisati tiket administratorima ili devops-u. Devops-u će za ovo trebati 3 sedmice. I nakon 3 sedmice će vam reći da smo za vas instalirali virtuelnu mašinu, sa jednom jezgrom, dva gigabajta RAM-a i Windows serverom bez DotNet-a. Kažete: "Ali ja sam htio DotNet." Oni: "Dobro, vrati se za 3 sedmice."
Ideja je da koristeći infrastrukturu kao praksu koda, svoju virtuelnu infrastrukturu možete tretirati kao samo još jedan resurs.
Možda, ako neko od vas razvija aplikacije na DotNet-u, možda ste čuli za biblioteku pod nazivom Entity Framework. Možda ste čak i čuli da je Entity Framework jedan od pristupa koje Microsoft aktivno zagovara. Za rad sa bazom podataka, ovo je pristup koji se zove Code First. Ovo je kada u kodu opišete kako želite da vaša baza podataka izgleda. I onda implementirate aplikaciju. Povezuje se sa bazom podataka, sam određuje koje tabele postoje, a koje ne, i kreira sve što vam treba.
Isto možete učiniti sa svojom infrastrukturom. Ne postoji razlika između toga da li vam je potrebna baza podataka za projekat ili da li vam je potreban Windows server za projekat. To je samo resurs. I možete automatizirati kreiranje ovog resursa, možete automatizirati konfiguraciju ovog resursa. Shodno tome, svaki put kada poželite da testirate neki novi koncept, neki novi pristup, nećete morati da pišete tiket za devops, možete jednostavno da postavite izolovanu infrastrukturu za sebe iz gotovih šablona, iz gotovih skripti i implementirate je tu su svi tvoji eksperimenti. Možete izbrisati ovo, dobiti neke rezultate i izvijestiti dalje o tome.
Sljedeća praksa, koja također postoji i također je važna, ali koju malo ljudi koristi, je Monitoring performansi aplikacije.
Htio sam reći samo jednu stvar o praćenju performansi aplikacije. Šta je najvažnije u ovoj praksi? Ovo je ono što je praćenje performansi aplikacije otprilike isto kao i popravka stana. Ovo nije konačno stanje, to je proces. Morate to raditi redovno.
Na dobar način, bilo bi dobro sprovesti Monitoring performansi aplikacije na skoro svakoj gradnji, iako, kao što razumete, to nije uvek moguće. Ali, u najmanju ruku, potrebno ga je provesti za svako izdanje.
Zašto je to važno? Jer ako iznenada doživite pad performansi, onda morate jasno razumjeti zašto. Ako vaš tim ima, recimo, dvonedeljne sprintove, onda barem jednom u dve nedelje treba da rasporedite svoju aplikaciju na neki poseban server, gde imate jasno fiksiran procesor, RAM, diskove itd. I pokrenite te iste testove performansi . Dobićete rezultat. Pogledajte kako se to promijenilo u odnosu na prethodni sprint.
A ako otkrijete da je pad negdje naglo opao, to će značiti da je to samo zbog promjena koje su se dogodile u protekle dvije sedmice. To će vam omogućiti da identificirate i riješite problem mnogo brže. I opet, ovo su otprilike iste metrike pomoću kojih možete mjeriti koliko ste uspješno to učinili.
Sljedeća praksa koju imamo je praksa upravljanja konfiguracijom. Malo je onih koji ovo shvataju ozbiljno. Ali vjerujte mi, ovo je zapravo vrlo ozbiljna stvar.
Nedavno je bila smiješna priča. Momci su došli do mene i rekli: “Pomozite nam da izvršimo sigurnosnu reviziju naše aplikacije.” Zajedno smo dugo gledali kod, pričali su mi o aplikaciji, crtali dijagrame. I plus-minus sve je bilo logično, razumljivo, sigurno, ali postojalo je jedno ALI! Imali su konfiguracijske datoteke u svojoj izvornoj kontroli, uključujući i one iz proizvodnje s IP bazom podataka, s loginovima i lozinkama za povezivanje s tim bazama podataka, itd.
I ja kažem: „Dečki, dobro, zatvorili ste svoje proizvodno okruženje zaštitnim zidom, ali činjenica da imate login i lozinku za proizvodnu bazu podataka direktno u izvornoj kontroli i bilo koji programer može to pročitati već je veliki sigurnosni rizik . I bez obzira koliko je vaša aplikacija super sigurna sa stajališta koda, ako je ostavite u kontroli izvora, nikada nigdje nećete proći nikakvu reviziju.” To je ono o čemu ja pričam.
Upravljanje konfiguracijom. Možemo imati različite konfiguracije u različitim okruženjima. Na primjer, možemo imati različite prijave i lozinke za baze podataka za QA, demo, proizvodno okruženje, itd.
Ova konfiguracija se također može automatizirati. Uvijek treba biti odvojen od same aplikacije. Zašto? Budući da ste jednom napravili aplikaciju, a onda aplikaciji nije važno hoćete li se povezati na SQL server preko te i takve IP ili takve i takve IP adrese, ona bi trebala raditi isto. Stoga, ako iznenada neko od vas još uvijek tvrdo kodira niz veze u kodu, onda zapamtite da ću vas pronaći i kazniti ako se nađete na istom projektu sa mnom. Ovo se uvijek stavlja u posebnu konfiguraciju, na primjer, u web.config.
I ovom konfiguracijom se već upravlja odvojeno, odnosno upravo je to trenutak kada programer i administrator mogu doći i sjediti u istoj prostoriji. A programer može reći: „Vidi, evo binarnih datoteka moje aplikacije. Oni rade. Aplikaciji je potrebna baza podataka da bi radila. Ovdje pored binarnih datoteka nalazi se datoteka. U ovoj datoteci ovo polje je odgovorno za prijavu, ovo je za lozinku, ovo je za IP. Rasporedite ga bilo gde." I to je jednostavno i jasno administratoru. On ga može postaviti bilo gdje upravljajući ovom konfiguracijom.
I poslednja praksa o kojoj bih želeo da govorim je praksa koja je veoma, veoma povezana sa oblacima. A maksimalni efekat donosi ako radite u oblaku. Ovo je Automatsko uklanjanje vašeg okruženja.
Znam da je na ovoj konferenciji nekoliko ljudi iz timova s kojima radim. I sa svim timovima sa kojima radim koristimo ovu praksu.
Zašto? Naravno, bilo bi sjajno kada bi svaki programer imao virtuelnu mašinu koja bi radila 24/7. Ali možda je ovo vijest za vas, možda niste obratili pažnju, ali sam programer ne radi 24/7. Programer obično radi 8 sati dnevno. Čak i ako rano dođe na posao, ima obilan ručak tokom kojeg ide u teretanu. Neka programer zaista koristi ove resurse 12 sati dnevno. Prema našem zakonodavstvu, imamo 5 od 7 dana u sedmici koji se smatraju radnim danima.
Shodno tome, radnim danima ova mašina ne bi trebalo da radi 24 sata, već samo 12, a vikendom ova mašina ne bi trebalo da radi uopšte. Čini se da je sve vrlo jednostavno, ali šta je ovdje važno reći? Implementacijom ove jednostavne prakse na ovom osnovnom rasporedu, ona vam omogućava da smanjite troškove održavanja ovih okruženja za 70%, tj. uzeli ste cijenu vašeg dev-a, QA, demo-a, okruženja i podijelili je sa 3.
Postavlja se pitanje šta učiniti sa ostatkom novca? Na primjer, programeri bi trebali kupiti ReSharper ako već nisu. Ili napravite koktel zabavu. Ako ste ranije imali jedno okruženje u kojem su pali i dev i QA, i to je to, sada možete napraviti 3 različita koja će biti izolirana, a ljudi se neće miješati jedni u druge.
Što se tiče slajda sa kontinuiranim merenjem performansi, kako da uporedimo performanse ako smo imali 1 zapisa u bazi podataka u projektu, dva meseca kasnije ima milion? Kako razumjeti zašto i koja je svrha mjerenja učinka?
Ovo je dobro pitanje, jer biste uvijek trebali mjeriti performanse na istim resursima. To jest, uvodite novi kod, mjerite performanse na novom kodu. Na primjer, trebate testirati različite scenarije performansi, recimo da želite testirati kako aplikacija radi na malom opterećenju, gdje ima 1 korisnika, a veličina baze podataka je 000 gigabajta. Izmjerili ste i dobili brojeve. Zatim uzimamo drugi scenario. Na primjer, 5 korisnika, veličina baze podataka 5 terabajt. Dobili smo rezultate i zapamtili ih.
Šta je tu važno? Ovdje je važno da u zavisnosti od scenarija, količine podataka, broja istovremenih korisnika itd., možete naići na određena ograničenja. Na primjer, do granice mrežne kartice, ili do granice tvrdog diska, ili do granice mogućnosti procesora. To je ono što je važno da shvatite. U različitim scenarijima nailazite na određene granice. I morate razumjeti brojeve kada ih pogodite.
Govorimo li o mjerenju performansi u posebnom testnom okruženju? Odnosno, ovo nije proizvodnja?
Da, ovo nije proizvodnja, ovo je testno okruženje, koje je uvijek isto tako da ga možete uporediti sa prethodnim mjerenjima.
Razumeo hvala!
Ako nema pitanja, mislim da možemo završiti. Hvala ti!
izvor: www.habr.com