Izvještaj će govoriti o nekim DevOps praksama, ali sa stajališta programera. Tipično, svi inženjeri koji se pridruže DevOpsu 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 popravljanjem "sljedeće hitno kritične greške dana", a nemaju vremena čak ni baciti brzi pogled na polje DevOps. Prema autorovom razumijevanju, DevOps je, prije svega, zdrav razum. Drugo, to je prilika da budete učinkovitiji. Ako ste programer, imate zdrav razum i želite biti učinkovitiji kao timski igrač, ovo je izvješće za vas.
Dopustite 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. Što je MVP? Ovo je Model-View-Presenter. Model-View-Presenter sam upravo ja.
Osim toga, trenutno obnašam funkciju arhitekta rješenja u Ciklumu. I baš sam si nedavno kupio tako lijepu domenu i ažurirao svoju e-poštu koju inače pokazujem na prezentacijama. Možete mi pisati na: ja [pas] byokoant.pro. Možete mi poslati e-poštu s pitanjima. Obično im odgovaram. Jedino što ne bih volio primati mailom pitanja koja se tiču dvije teme: politike i vjere. Za sve ostalo možete mi pisati na mail. Proći će neko vrijeme, odgovorit ću.
Nekoliko riječi o sebi:
- U ovom sam području već 10 godina.
- Radio sam u Microsoftu.
- Utemeljitelj sam zajednice Ukrainian Azure, koju smo osnovali negdje 2014. godine. I još uvijek ga imamo i razvijamo.
- Otac sam i osnivača Azure konferencije čiji smo domaćini u Ukrajini.
- Također pomažem u organizaciji Global Azure Bootcampa u Kijevu.
- Kao što sam rekao, ja sam Microsoft Azure MVP.
- Često govorim na konferencijama. Stvarno volim govoriti na konferencijama. Tijekom prošle godine uspio sam nastupiti oko 40 puta. Ako prođete pored Ukrajine, Bjelorusije, Poljske, Bugarske, Švedske, Danske, Nizozemske, Španjolske ili više-manje neke zemlje u Europi, onda je sasvim moguće da kada odete na konferenciju koja ima temu oblaka u svom streamu, možda ćete me vidjeti na popisu govornika.
- Također sam obožavatelj Zvjezdanih staza.
Razgovarajmo malo o Agendi. Naš dnevni red je vrlo jednostavan:
- Razgovarat ćemo o tome što je DevOps. Razgovarajmo zašto je to važno. Ranije je DevOps bila ključna riječ koju ste napisali u svom životopisu i odmah dobili +500$ plaće. Sada trebate napisati npr. blockchain u svom životopisu kako biste dobili +500 dolara na svoju plaću.
- A onda, kada malo shvatimo što je to, razgovarat ćemo o tome što su DevOps prakse. Ali ne toliko u kontekstu DevOpsa općenito, koliko o onim DevOps praksama koje bi mogle biti zanimljive programerima. Reći ću vam zašto bi vam mogli biti zanimljivi. Reći ću vam zašto biste to uopće trebali učiniti i kako vam to može pomoći da osjećate manje boli.
Tradicionalna slika koju mnogi ljudi pokazuju. To je ono što se događa u mnogim projektima. Tada imamo razvojne i operativne odjele koji podržavaju naš softver. A ti odjeli međusobno ne komuniciraju.
Možda, ako to niste mogli tako jasno osjetiti u DevOps i operativnim odjelima, možete povući analogiju s Dev i QA odjelima. Postoje ljudi koji razvijaju softver i postoje QA ljudi koji su loši sa stajališta programera. Na primjer, predam svoj divni kod u repozitorij, a tamo sjedi neki nitkov koji mi vrati ovaj kod i kaže da je vaš kod loš.
Sve se to događa jer ljudi ne komuniciraju jedni s drugima. I oni jedni drugima probacuju neke pakete, neku prijavu kroz neki zid nesporazuma i pokušavaju s njima nešto napraviti.
Upravo taj zid DevOps kultura je dizajnirana da uništi, tj. prisiliti ljude da komuniciraju jedni s drugima i barem razumiju što različiti ljudi u projektu rade i zašto je njihov rad važan.
A kada govorimo o DevOpsu, netko će vam reći da je DevOps kada projekt ima kontinuiranu integraciju; netko će reći da je DevOps ako projekt implementira praksu “infrastruktura kao kod”; netko će reći da je prvi korak do DevOpsa grananje značajki, oznake značajki.
U biti, sve je to istina na svoj način. Ali ovo su samo ultimativne prakse koje imamo. Prije nego prijeđemo na ove prakse, predlažem da pogledate ovaj slajd koji prikazuje 3 faze implementacije Dev-Ops metodologije u vaš projekt, u vašoj tvrtki.
Ovaj slajd ima i drugo neslužbeno ime. Možete pretraživati na internetu kako biste saznali što 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. PPP – Porthos, Porthos i Porthos. Ovo su 3 mušketira DevOpsa. Ovaj članak detaljnije opisuje zašto je to važno i što podrazumijeva.
Kada počnete implementirati DevOps kulturu, vrlo je važno da je implementirate sljedećim redoslijedom.
U početku morate razgovarati s ljudima. I morate ljudima objasniti što je to i kako od toga mogu imati neke koristi.
Naša konferencija zove se DotNet Fest. I kao što su mi rekli organizatori, ovdje smo uglavnom pozvali publiku programera, pa se nadam da je većina ljudi u dvorani uključena u razvoj.
Razgovarat ćemo o ljudima, razgovarat ćemo o tome što programeri žele raditi svaki dan. Što najviše žele? Žele napisati neki novi kod, koristiti novonastale okvire, stvoriti nove značajke. Što programeri najmanje žele? Ispravite stare greške. Nadam se da se slažete sa mnom. To je ono što programeri žele. Žele pisati nove značajke, ne žele ispravljati greške.
Broj grešaka koje određeni programer proizvede ovisi o tome koliko su mu ruke ravne i koliko rastu iz njegovih ramena, a ne iz džepova stražnjice. Ali ipak, kada imamo veliki projekt, ponekad se dogodi da je nemoguće sve pratiti, pa bi bilo lijepo da koristimo neke pristupe koji će nam pomoći da napišemo stabilniji i kvalitetniji kod.
Što QA najviše žele? Ne znam jesu li u dvorani. Teško mi je reći da želim QA, jer nikad nisam bio. I bez uvrede momcima, reći će se da se nadam da nikad neću. Ali ne iz razloga što njihov rad smatram besmislenim i beskorisnim, već zato što se ne smatram osobom koja bi taj posao mogla učinkovito obavljati, pa ga neću ni pokušavati raditi. Ali koliko ja razumijem, ono što QA najviše ne voli je raditi ujutro, neprestano izvoditi nekakve regresijske testove, gaziti iste greške koje su prijavili programerima prije 3 sprinta i govoriti: "Kad ćeš , Monsieur D 'Artagnan, ispravite ovu grešku.' A monsieur D'Artagnan mu odgovara: "Da, da, da, već sam to sredio." I kako se dogodilo da sam popravio jedan bug i usput napravio 5.
Ljudi koji podržavaju ovo rješenje u produkciji žele da ovo rješenje radi bez grešaka, tako da ne moraju ponovno dizati server svaki petak, kada svi normalni ljudi idu u birtiju. Programeri su pokrenuli u petak, administratori sjede do subote, pokušavajući pokrenuti i popraviti ovu implementaciju.
A kada objasnite ljudima da su usmjereni na rješavanje istih problema, možete prijeći na formalizaciju procesa. Vrlo je važno. Zašto? Jer kad kažemo "formalizacija", važno je da barem negdje na salveti opišete kako se odvijaju vaši procesi. Morate razumjeti da ako, na primjer, implementirate u QA okruženje ili proizvodno okruženje, onda se to uvijek događa ovim redoslijedom; u tim fazama izvodimo, na primjer, automatske testove jedinica i testove korisničkog sučelja. Nakon implementacije provjeravamo je li implementacija prošla dobro ili loše. Ali već imate jasan popis radnji koje se moraju ponavljati uvijek iznova kada implementirate u proizvodnju.
I tek kada su vaši procesi formalizirani, počinjete birati proizvode koji će vam pomoći automatizirati te procese.
Nažalost, vrlo često vidim da se to događa obrnuto. Čim netko čuje riječ “DevOps”, odmah predlaže instaliranje Jenkinsa, jer vjeruju da će čim instaliraju Jenkins imati DevOps. Instalirali su Jenkinsa, pročitali članke "Kako" na Jenkinsovoj web stranici, pokušali ugurati procese u te članke Kako, a onda su došli do ljudi i savijali ih, govoreći da knjiga kaže da to trebate učiniti na ovaj način, pa to radimo ovako.
Nije da je Jenkins loš alat. Ne želim to reći ni na koji način. Ali ovo je samo jedan od proizvoda. A koji ćete proizvod koristiti neka vam bude zadnja, a nikako prva odluka. Vaš proizvod ne bi trebao biti vođen implementacijom kulture i pristupa. Ovo je vrlo važno razumjeti, zbog čega provodim toliko vremena na ovom slajdu i objašnjavam sve ovo tako dugo.
Razgovarajmo o DevOps praksi općenito. Što 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 netko na projektu ima kontinuiranu integraciju (CI).
Najveći problem je što najčešće kada pitam osobu: “Imate li CI na projektu?” a on kaže: "Da", a onda kada ga pitam što radi, on mi opisuje apsolutno cijeli proces automatizacije. Ovo nije posve točno.
Zapravo, praksa CI-ja samo je 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 je kontinuirana implementacija, upravljanje izdanjima, ali o tome ćemo kasnije.
Sam CI nam govori da različiti ljudi pišu kod i taj kod mora biti kontinuirano integriran u jednu bazu koda.
Što nam to daje i zašto je važno? Ako imamo DotNet, onda je to dobro, to je kompilirani jezik, možemo kompajlirati svoju aplikaciju. Ako se kompilira, to je već dobar znak. Ovo još ništa ne znači, ali je prvi dobar znak da možemo barem sastaviti.
Zatim možemo provesti neke testove, što je također posebna praksa. Svi testovi su zeleni - ovo je drugi dobar znak. Ali opet, ovo ništa ne znači.
Ali zašto biste to učinili? Sve prakse o kojima ću danas govoriti imaju približno istu vrijednost, odnosno približno iste dobrobiti i mjere se približno na isti način.
Prvo, omogućuje vam ubrzanje isporuke. Kako vam to omogućuje da ubrzate isporuku? Kada napravimo neke nove promjene u našoj bazi koda, možemo odmah pokušati učiniti nešto s ovim kodom. Ne čekamo do četvrtka jer u četvrtak to objavljujemo za QA Environment, radimo to upravo ovdje i upravo ovdje.
Ispričat ću vam jednu tužnu priču iz svog života. Bilo je to davno, dok sam još bio mlad i zgodan. Sada sam već mlada, lijepa i pametna, a skromna. Prije nekog vremena bio sam u jednom projektu. Imali smo veliki tim od 30-ak programera. I imali smo veliki, veliki Enterprise projekt koji se razvijao oko 10 godina. I imali smo različite grane. U repozitoriju smo imali granu u kojoj su hodali programeri. I postojala je grana koja je prikazivala verziju koda koja je u proizvodnji.
Proizvodni ogranak kasnio je 3 mjeseca za ogrankom koji je bio dostupan programerima. Što to znači? To znači da čim negdje imam grešku koja ide u proizvodnju zbog krivnje programera, jer su oni to dopustili, i zbog greške QA-a, jer su je pogledali, to znači da ako dobijem zadatak za hitni popravak za proizvodnju, onda moram vratiti svoje promjene koda prije 3 mjeseca. Moram se sjetiti što sam imao prije 3 mjeseca i pokušati to tamo popraviti.
Ako još niste imali ovo iskustvo, možete ga isprobati na svom kućnom projektu. Glavna stvar je, nemojte ga isprobavati na komercijalnom. Napišite nekoliko redaka koda, zaboravite na njih šest mjeseci, a zatim se vratite i pokušajte brzo objasniti o čemu se radi u tim redcima koda i kako ih možete popraviti ili optimizirati. To je vrlo, vrlo uzbudljivo iskustvo.
Ako imamo praksu kontinuirane integracije, onda nam to omogućuje da to provjerimo s brojnim automatiziranim alatima upravo ovdje i upravo sada, čim sam napisao svoj kod. Ovo mi možda neće dati potpunu sliku, ali svejedno će ukloniti barem neke od rizika. A ako postoji neki potencijalni bug, znat ću o tome odmah, odnosno doslovno za nekoliko minuta. Neću morati vraćati 3 mjeseca unazad. Trebat ću vratiti samo 2 minute. Dobar aparat za kavu neće imati vremena čak ni skuhati kavu u 2 minute, 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. To vam omogućuje da optimizirate resurse jer vaš tim radi učinkovitije. Više nećete imati situaciju da vam dođe bug iz koda s kojim ste radili prije 3 mjeseca. Više nećete imati mijenjanje konteksta kada sjedite i provedete prva dva sata pokušavajući shvatiti što se tada dogodilo i ući u bit konteksta prije nego počnete nešto ispravljati.
Kako možemo mjeriti uspjeh ili neuspjeh ove prakse? Ako izvijestite velikog šefa što smo implementirali na CI projektu, on čuje bla bla bla. Proveli smo to, dobro, ali zašto, što nam je to donijelo, kako to mjerimo, koliko to ispravno ili netočno provodimo?
Prvi je da zahvaljujući CI-ju možemo implementirati sve češće, i to češće upravo zato što je naš kod potencijalno stabilniji. Na isti način smanjuje nam se vrijeme za pronalaženje greške i vrijeme za ispravljanje te greške upravo iz razloga što upravo ovdje i sada dobijemo odgovor od sustava što nije u redu s našim kodom.
Još jedna praksa koju imamo je praksa testiranja automatizacije, koja najčešće dolazi s praksom CI. Idu ruku pod ruku.
Što je ovdje važno razumjeti? Važno je razumjeti da su naši testovi drugačiji. A svaki automatizirani test usmjeren je na rješavanje vlastitih problema. Imamo, na primjer, jedinične testove koji nam omogućuju zasebno testiranje modula, tj. Kako radi u vakuumu? Ovo je dobro.
Imamo i integracijske testove koji nam omogućuju da razumijemo kako se različiti moduli međusobno integriraju. Također je dobro.
Možemo imati testove automatizacije korisničkog sučelja koji nam omogućuju da provjerimo koliko dobro rad s korisničkim sučeljem zadovoljava određene zahtjeve koje je postavio korisnik itd.
Specifični testovi koje izvodite mogu utjecati na to koliko ih često izvodite. Jedinični testovi obično su kratki i mali. I mogu se redovito pokretati.
Ako govorimo o testovima automatizacije korisničkog sučelja, onda je dobro ako je vaš projekt mali. Vaši 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 nekoliko sati. Jedina stvar je da nema smisla pokretati ih za svaku izgradnju. Ima smisla izvoditi ih noću. I kad su ujutro svi došli na posao: i testeri i programeri, dobili su nekakav izvještaj da smo noću pokrenuli autotest korisničkog sučelja i dobili ove rezultate. I ovdje će vam sat vremena rada poslužitelja koji će provjeriti zadovoljava li vaš proizvod neke zahtjeve biti puno jeftiniji od sata rada istog QA inženjera, pa makar on bio Junior QA inženjer koji radi za hranu i hvala. Svejedno, sat rada stroja bit će jeftiniji. Zbog toga ima smisla ulagati u njega.
Imam još jedan projekt na kojem radim. Imali smo dvotjedne sprinteve na ovom projektu. Projekt je bio velik, važan za financijski sektor i nije se mogla pogriješiti. Nakon dvotjednog sprinta, nakon razvojnog ciklusa uslijedio je proces testiranja koji je trajao još 4 tjedna. Pokušajte zamisliti razmjere tragedije. Kod pišemo dva tjedna, zatim to radimo ala CodeFreeze, pakiramo u novu verziju aplikacije i puštamo testerima. Testeri ga testiraju još 4 tjedna, t.j. Dok ga oni testiraju, imamo vremena pripremiti im još dvije verzije. Ovo je zaista tužan slučaj.
I rekli smo im da ako želite biti produktivniji, ima smisla implementirati prakse automatiziranog testiranja, jer je to ono što vam šteti upravo ovdje, upravo sada.
Vježbajte kontinuiranu implementaciju. Odlično, završili ste s izgradnjom. Ovo je već dobro. Vaš kod je kompajliran. Sada bi bilo lijepo implementirati ovu nadogradnju u neko okruženje. Recimo u okruženju za programere.
Zašto je to važno? Prvo, možete pogledati koliko ste uspješni u samom procesu implementacije. Susreo sam se s ovakvim projektima, kad pitam: “Kako implementirati novu verziju aplikacije?”, dečki mi kažu: “Mi to montiramo i spakiramo u zip arhivu. Šaljemo adminu poštom. Administrator preuzima i proširuje ovu arhivu. I cijeli se ured počinje moliti da poslužitelj prihvati 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 poslužitelju, preglednik misli da već ima ovu java-script datoteku i odluči je ne preuzeti. A bila je i stara verzija, nešto je nedostajalo. Općenito, može biti mnogo problema. Stoga vam praksa kontinuiranog postavljanja omogućuje da barem testirate što bi se dogodilo da ste uzeli čistu referentnu sliku i učitali je u potpuno čisto novo okruženje. Vidite kamo ovo vodi.
Također, kada međusobno integrirate kod, tj. između naredbe, to vam također omogućuje da vidite kako to izgleda na korisničkom sučelju.
Jedan od problema koji se javlja tamo gdje se koristi mnogo vanilla java-scripta je da su dva programera nepromišljeno deklarirala varijablu s istim imenom u objektu prozora. A onda, ovisno o sreći. Čija se java-script datoteka izvuče druga, prebrisat će promjene onog drugog. Također je vrlo uzbudljivo. Ulazite: jedna stvar radi za jednu osobu, druga ne radi za drugu. I "divno" je kad sve izađe u produkciji.
Sljedeća praksa koju imamo je praksa automatskog vraćanja, odnosno vraćanje na prethodnu verziju aplikacije.
Zašto je to važno za programere? Još uvijek postoje oni koji se sjećaju dalekih, dalekih 90-ih, kada su računala bila velika, a programi mali. A jedini način za web razvoj bio je kroz PHP. Nije da je PHP loš jezik, iako jest.
Ali problem je bio drugačiji. Kad smo postavili novu verziju naše php stranice, kako smo je postavili? Najčešće smo otvorili Far Manager ili nešto drugo. I učitao ove datoteke na FTP. I odjednom smo shvatili da imamo neki mali, mali bug, na primjer, zaboravili smo staviti točku i zarez ili zaboravili promijeniti lozinku za bazu, a postoji lozinka za bazu, koja je na lokalnom hostu. I odlučujemo se brzo spojiti na FTP i tamo urediti datoteke. Ovo je samo vatra! To je ono što je bilo popularno 90-ih.
Ali, ako niste pogledali u kalendar, devedesete su bile prije skoro 90 godina. Sada se sve događa malo drugačije. I pokušajte zamisliti razmjere tragedije kada vam kažu: “Rasporedili smo se u proizvodnju, ali tamo je nešto pošlo po zlu. Evo vaše FTP prijave i lozinke, povežite se s produkcijom i tamo to brzo popravite.” Ako ste Chuck Norris, ovo će upaliti. Ako ne, onda riskirate da ako ispravite jedan bug, napravite ih još 30. Upravo zbog toga ova praksa vraćanja na prethodnu verziju omogućuje vam da postignete puno.
Čak i ako je nešto loše negdje ušlo u prod, onda je loše, ali nije fatalno. Možete se vratiti na prethodnu verziju koju imate. Nazovite to sigurnosnom kopijom, 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 odgovarajuće vrijeme međuspremnika. Sve ovo možete mirno, bez žurbe, uzeti i testirati lokalno, popraviti, a zatim uploadati novu verziju. Stvarno ima smisla učiniti ovo.
Pokušajmo sada nekako spojiti dvije prethodne prakse. Dobit ćemo treći pod nazivom Upravljanje izdanjima.
Kada govorimo o Continuous Deploymentu u njegovom klasičnom obliku, kažemo da moramo izvući kod iz neke grane iz repozitorija, kompajlirati ga i implementirati. Dobro je ako imamo isto okruženje. Ako imamo nekoliko okruženja, to znači da moramo povući kod svaki put, čak i iz istog predanja. Svaki put ćemo ga izvući, svaki put ćemo ga izgraditi i rasporediti u novu sredinu. Prvo, ovo je vrijeme, jer izgradnja projekta, ako imate veliki i dolazite iz 90-ih, može trajati nekoliko sati.
Osim toga, postoji još jedna tuga. Kada gradite, čak i na istom stroju, izgradit ćete iste izvore, još uvijek nemate jamstva da je ovaj stroj u istom stanju kao što je bio tijekom posljednje izgradnje.
Recimo da je netko došao i ažurirao DotNet za vas ili, obrnuto, netko je odlučio nešto izbrisati. I onda imate kognitivnu disonancu da smo od ovog predanja prije dva tjedna gradili međugradnju i sve je bilo u redu, ali sada se čini kao isti stroj, isto predanje, isti kod koji pokušavamo izgraditi, ali ne radi . Dugo ćete se nositi s tim i nije činjenica da ćete to shvatiti. U najmanju ruku, jako ćete si pokvariti živce.
Stoga, praksa upravljanja izdanjima predlaže uvođenje dodatne apstrakcije koja se zove spremište artefakata ili galerija ili biblioteka. Možete to zvati kako god želite.
Glavna ideja je da čim tamo imamo neku vrstu predaje, recimo, u grani koju smo spremni implementirati u naša različita okruženja, skupljamo aplikacije iz te obveze i sve što nam je potrebno za tu aplikaciju, pakiramo to u zip arhivu i spremite je u neku pouzdanu pohranu. I iz ove pohrane možemo dobiti ovu zip arhivu u bilo koje vrijeme.
Zatim ga uzimamo i automatski postavljamo u razvojno okruženje. Tamo se utrkujemo, a ako je sve u redu, onda se raspoređujemo na pozornicu. Ako je sve u redu, tada postavljamo istu arhivu u proizvodnju, iste binarne datoteke, kompajlirane točno jednom.
Osim toga, kada imamo ovakvu galeriju, to nam također pomaže u rješavanju rizika o kojima smo govorili na prošlom slajdu kada smo govorili o vraćanju na prethodnu verziju. Ako ste slučajno implementirali nešto pogrešno, uvijek možete uzeti bilo koju drugu prethodnu verziju iz ove galerije i poništiti je implementaciju u tim okruženjima na isti način. To vam omogućuje da se jednostavno vratite na prethodnu verziju ako nešto pođe po zlu.
Postoji još jedna odlična praksa. Vi i ja svi razumijemo da kada svoje aplikacije vratimo na prethodnu verziju, to može značiti da nam je potrebna i infrastruktura prethodne verzije.
Kada govorimo o virtualnoj infrastrukturi, mnogi ljudi misle da je to nešto što postavljaju administratori. A ako trebate, recimo, nabaviti novi server na kojem želite testirati novu verziju svoje aplikacije, onda morate napisati tiket adminima ili devopsima. Devopsu će za to trebati 3 tjedna. I nakon 3 tjedna reći će vam da smo vam instalirali virtualni stroj, s jednom jezgrom, dva gigabajta RAM-a i Windows serverom bez DotNeta. Kažete: "Ali ja sam želio DotNet." Oni: "U redu, vratite se za 3 tjedna."
Ideja je da korištenjem prakse Infrastructure as Code svoju virtualnu infrastrukturu možete tretirati samo kao još jedan resurs.
Možda ste, ako netko od vas razvija aplikacije na DotNetu, možda čuli za biblioteku pod nazivom Entity Framework. A možda ste čak čuli da je Entity Framework jedan od pristupa koji Microsoft aktivno forsira. Za rad s bazom podataka, ovo je pristup koji se zove Code First. To je kada u kodu opisujete kako želite da vaša baza podataka izgleda. I onda implementirate aplikaciju. Spaja se na bazu podataka, sam određuje koje tablice postoje, a koje ne i kreira sve što vam treba.
Isto možete učiniti sa svojom infrastrukturom. Nema razlike između toga trebate li bazu podataka za projekt ili trebate li Windows poslužitelj za projekt. To je samo resurs. I možete automatizirati stvaranje ovog resursa, možete automatizirati konfiguraciju ovog resursa. Sukladno tome, svaki put kada želite testirati neki novi koncept, neki novi pristup, nećete morati napisati kartu za devops, možete jednostavno implementirati izoliranu infrastrukturu za sebe iz gotovih šablona, iz gotovih skripti i implementirati je tu su svi tvoji eksperimenti. Možete ovo izbrisati, dobiti neke rezultate i dalje izvještavati o tome.
Sljedeća praksa, koja također postoji i također je važna, ali koju malo ljudi koristi je Praćenje performansi aplikacije.
Htio sam reći samo jednu stvar o praćenju performansi aplikacije. Što je najvažnije u ovoj praksi? To je ono što je Praćenje performansi aplikacije otprilike isto što i popravak stana. Ovo nije konačno stanje, to je proces. Morate to činiti redovito.
U dobrom smislu, bilo bi dobro provesti Praćenje performansi aplikacije na gotovo svakoj izgradnji, iako, kao što razumijete, to nije uvijek moguće. No, potrebno ga je barem 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, dvotjedne sprinteve, tada biste barem jednom svaka dva tjedna trebali implementirati svoju aplikaciju na neki zasebni poslužitelj, gdje imate jasno fiksiran procesor, RAM, diskove, itd. I pokrenuti te iste testove performansi . Dobivate rezultat. Pogledajte kako se promijenio u odnosu na prethodni sprint.
A ako saznate da je pad negdje naglo pao, to će značiti da je to samo zbog promjena koje su se dogodile u posljednja dva tjedna. To će vam omogućiti da puno brže prepoznate i riješite problem. I opet, to 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 to shvaćaju ozbiljno. Ali vjerujte mi, ovo je zapravo vrlo ozbiljna stvar.
Nedavno je bila smiješna priča. Dečki su mi došli i rekli: "Pomozite nam da provedemo sigurnosnu reviziju naše aplikacije." Dugo smo zajedno 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 one iz proizvodnje s IP bazom podataka, s prijavama i lozinkama za povezivanje s tim bazama podataka itd.
A ja kažem: "Društvo, u redu, zatvorili ste svoje proizvodno okruženje vatrozidom, ali činjenica da imate prijavu i lozinku za proizvodnu bazu podataka točno u izvornoj kontroli i bilo koji programer to može pročitati već predstavlja veliki sigurnosni rizik . I bez obzira na to 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.” O tome ti ja pričam.
Konfiguracijski menadžment. 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 se konfiguracija također može automatizirati. Uvijek bi trebao biti odvojen od same aplikacije. Zašto? Budući da ste aplikaciju izgradili jednom, a onda je aplikaciji svejedno hoćete li se na SQL poslužitelj spojiti preko tog i tog IP-a ili tog i tog IP-a, trebala bi raditi isto. Stoga, ako iznenada netko od vas i dalje tvrdo kodira vezu u kodu, sjetite se da ću vas pronaći i kazniti ako se nađete na istom projektu sa mnom. To se uvijek stavlja u zasebnu konfiguraciju, na primjer, u web.config.
I ovom se konfiguracijom već upravlja zasebno, tj. upravo je to trenutak kada programer i administrator mogu doći i sjediti u istoj prostoriji. A programer može reći: "Gledajte, ovdje su binarne datoteke moje aplikacije. Oni rade. Aplikacija treba bazu podataka za rad. Postoji datoteka pored binarnih datoteka. U ovoj datoteci, ovo polje je odgovorno za prijavu, ovo je za lozinku, ovo je za IP. Rasporedite ga bilo gdje." I to je jednostavno i jasno administratoru. Upravljajući ovom konfiguracijom, može ga postaviti doista bilo gdje.
I posljednja praksa o kojoj bih želio govoriti je praksa koja je vrlo, vrlo povezana s oblacima. A maksimalan učinak donosi ako radite u oblaku. Ovo je automatsko uklanjanje vašeg okruženja.
Znam da je nekoliko ljudi na ovoj konferenciji iz timova s kojima radim. I sa svim timovima s kojima radim koristimo ovu praksu.
Zašto? Naravno, bilo bi super kada bi svaki programer imao virtualni stroj koji bi radio 24/7. Ali možda je ovo novost za vas, možda niste obratili pozornost, ali sam programer ne radi 24/7. Programer obično radi 8 sati dnevno. Čak i ako ranije dođe na posao, ima obilan ručak tijekom kojeg ide u teretanu. Neka to bude 12 sati dnevno kada programer zapravo koristi te resurse. Prema našem zakonodavstvu imamo 5 od 7 dana u tjednu koji se smatraju radnim danima.
Prema tome, radnim danima ovaj stroj ne bi trebao raditi 24 sata, već samo 12, a vikendom ovaj stroj ne bi trebao raditi uopće. Čini se da je sve vrlo jednostavno, ali što je ovdje važno reći? Implementacijom ove jednostavne prakse na ovom osnovnom rasporedu, omogućuje vam smanjenje troškova održavanja ovih okruženja za 70%, tj. uzeli ste cijenu svog razvojnog programera, QA-a, demo, okruženja i podijelili to s 3.
Pitanje je što učiniti s ostatkom novca? Na primjer, programeri bi trebali kupiti ReSharper ako već nisu. Ili priredite koktel zabavu. Ako ste prije imali jedno okruženje u kojem su pasali i dev i QA i to je to, sada možete napraviti 3 različita koja će biti izolirana, a ljudi neće smetati jedni drugima.
Što se tiče slajda s kontinuiranim mjerenjem performansi, kako možemo usporediti performanse ako smo imali 1 zapisa u bazi podataka u projektu, dva mjeseca kasnije ima ih milijun? Kako razumjeti zašto i koji je smisao mjerenja učinka?
Ovo je dobro pitanje jer biste uvijek trebali mjeriti izvedbu na istim resursima. Odnosno, uvedete novi kod, mjerite izvedbu na novom kodu. Na primjer, trebate testirati različite scenarije izvedbe, recimo da želite testirati kako aplikacija radi pri malom opterećenju, gdje postoji 1 korisnika, a veličina baze podataka je 000 gigabajta. Izmjerili ste i dobili brojke. Zatim ćemo uzeti drugi scenarij. Na primjer, 5 korisnika, veličina baze podataka 5 terabajt. Dobili smo rezultate i zapamtili ih.
Što je tu važno? Ovdje je važna stvar da ovisno o scenariju, količini podataka, broju istodobnih 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 razumijete. U različitim scenarijima nailazite na određena ograničenja. I morate razumjeti brojke 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 da ga možete usporediti s prethodnim mjerenjima.
Razumijem hvala!
Ako nema pitanja, mislim da možemo završiti. Hvala vam!
Izvor: www.habr.com