Poročilo bo govorilo o nekaterih praksah DevOps, vendar z vidika razvijalca. Običajno imajo vsi inženirji, ki se pridružijo DevOps, že nekaj let administrativnih izkušenj. Vendar to ne pomeni, da tukaj ni mesta za razvijalca. Pogosteje kot ne, so razvijalci zaposleni z odpravljanjem "naslednje nujno kritične napake dneva" in nimajo časa, da bi si na hitro ogledali področje DevOps. Po avtorjevem razumevanju je DevOps najprej zdrava pamet. Drugič, to je priložnost za večjo učinkovitost. Če ste razvijalec, imate zdrav razum in želite biti učinkovitejši kot timski igralec, je to poročilo za vas.
Naj se predstavim, popolnoma priznam, da so v sobi ljudje, ki me ne poznajo. Moje ime je Anton Boyko, sem Microsoft Azure MVP. Kaj je MVP? To je Model-View-Presenter. Model-View-Presenter sem točno jaz.
Poleg tega trenutno opravljam funkcijo arhitekta rešitev v Ciklumu. In ravno pred kratkim sem si kupil tako lepo domeno in posodobil e-pošto, ki jo ponavadi pokažem na predstavitvah. Lahko mi pišete na: jaz [pes] byokoant.pro. Z vprašanji mi lahko pošljete e-pošto. Ponavadi jim odgovorim. Edina stvar je, da ne bi želel prejemati vprašanj po e-pošti, ki se nanašajo na dve temi: politiko in vero. Za vse ostalo mi lahko pišete na mail. Nekaj časa bo minilo, bom odgovoril.
Nekaj besed o sebi:
- Na tem področju sem že 10 let.
- Delal sem pri Microsoftu.
- Sem idejni oče skupnosti Ukrainian Azure, ki smo jo ustanovili nekje leta 2014. In še vedno ga imamo in razvijamo.
- Sem tudi oče ustanovitelja konference Azure, ki jo gostimo v Ukrajini.
- Pomagam tudi pri organizaciji Global Azure Bootcampa v Kijevu.
- Kot sem rekel, sem Microsoft Azure MVP.
- Pogosto govorim na konferencah. Zelo rada govorim na konferencah. V preteklem letu mi je uspelo nastopiti okoli 40-krat. Če greste mimo Ukrajine, Belorusije, Poljske, Bolgarije, Švedske, Danske, Nizozemske, Španije ali več ali manj še katere druge države v Evropi, potem je povsem možno, da ko greste na konferenco, ki ima v svojem toku temo oblaka, me boste morda videli na seznamu govorcev.
- Sem tudi oboževalec Zvezdnih stez.
Pogovorimo se malo o Agendi. Naš dnevni red je zelo preprost:
- Govorili bomo o tem, kaj je DevOps. Pogovorimo se, zakaj je to pomembno. Prej je bila DevOps ključna beseda, ki ste jo zapisali v svoj življenjepis in takoj prejeli +500 USD plače. Zdaj morate v svoj življenjepis napisati na primer blockchain, da dobite +500 dolarjev k vaši plači.
- In potem, ko bomo malo razumeli, kaj je to, bomo govorili o tem, kaj so prakse DevOps. Vendar ne toliko v kontekstu DevOps na splošno, temveč o tistih praksah DevOps, ki bi lahko zanimale razvijalce. Povedal vam bom, zakaj bi vas lahko zanimali. Povedal vam bom, zakaj bi to sploh morali narediti in kako vam lahko pomaga do manjše bolečine.
Tradicionalna slika, ki jo veliko ljudi pokaže. To se dogaja pri mnogih projektih. Takrat imamo razvojne in operativne oddelke, ki podpirajo našo programsko opremo. In ti oddelki med seboj ne komunicirajo.
Če tega niste mogli tako jasno občutiti v oddelkih DevOps in operacij, lahko morda potegnete analogijo z oddelkoma Dev in QA. So ljudje, ki razvijajo programsko opremo, in obstajajo QA ljudje, ki so slabi z vidika razvijalcev. Na primer, svojo čudovito kodo dodam v repozitorij, tam pa sedi nek lopov, ki mi to kodo vrne in pravi, da je vaša koda slaba.
Vse to se zgodi, ker ljudje med seboj ne komunicirajo. In drug drugemu skozi nek zid nerazumevanja vržejo neke pakete, kakšno prijavo in poskušajo z njimi nekaj narediti.
Ravno ta zid je namenjen rušenju DevOps kulture, tj. prisiliti ljudi, da komunicirajo med seboj in vsaj razumejo, kaj počnejo različni ljudje v projektu in zakaj je njihovo delo pomembno.
In ko govorimo o DevOps, vam bo nekdo rekel, da je DevOps takrat, ko ima projekt stalno integracijo; nekdo bo rekel, da je DevOps, če projekt izvaja prakso »infrastruktura kot koda«; nekdo bo rekel, da je prvi korak k DevOps razvejanje funkcij, zastavice funkcij.
V bistvu je vse to po svoje res. Toda to so le najvišje prakse, ki jih imamo. Preden preidete na te prakse, predlagam, da si ogledate ta diapozitiv, ki prikazuje 3 stopnje izvajanja metodologije Dev-Ops v vašem projektu, v vašem podjetju.
Ta diapozitiv ima tudi drugo neuradno ime. Na spletu lahko poiščete, kaj so 3 mušketirji DevOps. Možno je, da boste našli ta članek. Zakaj 3 mušketirji? Spodaj piše: ljudje, procesi in izdelki, tj. PPP – Porthos, Porthos in Porthos. Tukaj so 3 mušketirji DevOps. Ta članek podrobneje opisuje, zakaj je to pomembno in kaj vključuje.
Ko začnete izvajati kulturo DevOps, je zelo pomembno, da je implementirana v naslednjem vrstnem redu.
Na začetku se morate pogovarjati z ljudmi. In ljudem morate razložiti, kaj je to in kako lahko od tega pridobijo nekaj koristi.
Naša konferenca se imenuje DotNet Fest. In kot so mi povedali organizatorji, smo sem povabili predvsem publiko razvijalcev, tako da upam, da se večina ljudi v dvorani ukvarja z razvojem.
Pogovarjali se bomo o ljudeh, o tem, kaj razvijalci želijo početi vsak dan. Kaj si najbolj želijo? Želijo napisati novo kodo, uporabiti novodobna ogrodja, ustvariti nove funkcije. Česa si razvijalci najmanj želijo? Popravi stare napake. Upam, da se strinjate z mano. To si želijo razvijalci. Želijo pisati nove funkcije, nočejo pa odpravljati napak.
Število hroščev, ki jih proizvaja določen razvijalec, je odvisno od tega, kako ravne so njegove roke in koliko rastejo iz njegovih ramen, ne iz žepov na zadnjici. Ampak kljub temu, ko imamo velik projekt, se včasih zgodi, da je nemogoče slediti vsemu, zato bi bilo dobro, da uporabimo nekaj pristopov, ki nam bodo pomagali napisati stabilnejšo in kvalitetnejšo kodo.
Kaj si QA najbolj želijo? Ne vem, če so v dvorani. Težko rečem, da si želim QA, ker nikoli nisem bil. Pa brez zamere fantom, bo rečeno, upam, da nikoli ne bom. A ne zato, ker menim, da je njihovo delo nesmiselno in neuporabno, ampak zato, ker se nimam za človeka, ki bi lahko to delo opravljal učinkovito, zato tega niti ne bom poskušal opravljati. Toda kolikor razumem, QA najbolj ne mara, da dela zjutraj, nenehno izvaja nekakšne regresijske teste, stopi na iste hrošče, o katerih so pred tremi sprinti poročali razvijalcem, in reče: »Kdaj boš , Monsieur D 'Artagnan, popravi to napako.' In gospod D'Artagnan mu odgovori: "Da, da, da, to sem že popravil." In kako se zgodi, da sem popravil eno napako in spotoma naredil 3.
Ljudje, ki podpirajo to rešitev v proizvodnji, želijo, da bi ta rešitev delovala brez napak, da jim ne bi bilo treba znova zagnati strežnika vsak petek, ko gredo vsi normalni ljudje v bar. Razvijalci so uvedli v petek, skrbniki sedijo do sobote in poskušajo vzpostaviti in popraviti to uvedbo.
In ko ljudem razložite, da so usmerjeni v reševanje istih problemov, lahko preidete na formalizacijo procesov. Je zelo pomembno. Zakaj? Ker ko rečemo »formalizacija«, je pomembno, da vsaj nekje na prtičku opišete, kako potekajo vaši procesi. Razumeti morate, da če na primer uvedete v okolje QA ali produkcijsko okolje, se to vedno zgodi v tem vrstnem redu; na teh stopnjah izvajamo na primer samodejne teste enot in teste uporabniškega vmesnika. Po uvedbi preverimo, ali je uvedba potekala dobro ali slabo. Toda že imate jasen seznam dejanj, ki jih je treba vedno znova ponavljati, ko uvajate v proizvodnjo.
In šele ko so vaši procesi formalizirani, začnete izbirati izdelke, ki vam bodo pomagali avtomatizirati te procese.
Na žalost zelo pogosto vidim, da se to dogaja ravno obratno. Takoj, ko nekdo sliši besedo “DevOps”, takoj predlaga namestitev Jenkinsa, saj verjame, da bo takoj, ko bo namestil Jenkins, imel DevOps. Namestili so Jenkinsa, prebrali članke »Kako« na Jenkinsovem spletnem mestu, poskušali vstaviti procese v te članke »Kako«, potem pa so prišli do ljudi in jih nagovarjali, češ da knjiga pravi, da morate to narediti na ta način, tako da naredimo tako.
Ne gre za to, da je Jenkins slabo orodje. Tega nikakor ne mislim reči. Ampak to je le eden od izdelkov. In kateri izdelek boste uporabili, naj bo vaša zadnja odločitev, nikakor pa ne prva. Vaš produkt naj ne temelji na izvajanju kulture in pristopov. To je zelo pomembno razumeti, zato sem toliko časa posvetil temu diapozitivu in vse to tako dolgo razlagal.
Pogovorimo se o praksah DevOps na splošno. Kaj so oni? Kakšna je razlika? Kako jih preizkusiti? Zakaj so pomembni?
Prva praksa, za katero ste morda slišali, se imenuje Nenehna integracija. Morda ima nekdo na projektu stalno integracijo (CI).
Največja težava je, da največkrat, ko vprašam osebo: "Imate CI na projektu?" in reče: "Ja," potem ko ga vprašam, kaj počne, mi opiše absolutno celoten proces avtomatizacije. To ne drži povsem.
Pravzaprav je praksa CI namenjena integraciji kode, ki jo pišejo različni ljudje, v nekakšno enotno bazo kode. To je vse.
Poleg CI so običajno na poti še druge prakse - na primer neprekinjeno uvajanje, upravljanje izdaj, a o tem bomo govorili kasneje.
Sam CI nam pove, da različni ljudje pišejo kodo in da mora biti ta koda nenehno integrirana v eno samo kodno bazo.
Kaj nam to daje in zakaj je pomembno? Če imamo DotNet, potem je to dobro, to je preveden jezik, lahko prevedemo svojo aplikacijo. Če se prevede, je to že dober znak. To še ne pomeni nič, je pa prvi dober znak, da lahko vsaj sestavimo.
Potem lahko izvedemo nekaj testov, kar je tudi ločena praksa. Vsi testi so zeleni - to je drugi dober znak. Ampak spet, to ne pomeni nič.
Toda zakaj bi to naredil? Vse prakse, o katerih bom danes govoril, imajo približno enako vrednost, torej približno enake koristi in se tudi merijo približno enako.
Prvič, omogoča vam pospešitev dostave. Kako vam to omogoča pospešitev dostave? Ko naredimo nekaj novih sprememb v naši kodni bazi, lahko takoj poskusimo nekaj narediti s to kodo. Ne čakamo do četrtka, ker v četrtek to izdamo okolju QA, to naredimo tukaj in tukaj.
Povedal vam bom eno žalostno zgodbo iz svojega življenja. Bilo je davno, ko sem bil še mlad in čeden. Zdaj sem že mlada, lepa in pametna ter skromna. Pred časom sem bil v projektu. Imeli smo veliko ekipo približno 30 razvijalcev. In imeli smo velik, velik podjetniški projekt, ki se je razvijal približno 10 let. In imeli smo različne podružnice. V repozitoriju smo imeli vejo, v kateri so hodili razvijalci. Tam je bila veja, ki je prikazovala različico kode, ki je v izdelavi.
Proizvodna veja je 3 mesece zaostajala za vejo, ki je bila na voljo razvijalcem. Kaj to pomeni? To pomeni, da takoj, ko imam nekje napako, ki gre v proizvodnjo po krivdi razvijalcev, ker so to dovolili, in po krivdi QA, ker so si jo ogledali, potem to pomeni, da če prejmem opravilo za sprotni popravek za proizvodnjo, potem moram vrniti svoje spremembe kode pred 3 meseci. Spomniti se moram, kaj sem imel pred 3 meseci, in to poskusiti tam popraviti.
Če te izkušnje še niste imeli, jo lahko preizkusite na svojem domačem projektu. Glavna stvar je, da tega ne preizkusite na komercialnem. Napišite nekaj vrstic kode, pozabite nanje za šest mesecev, nato pa se vrnite in poskusite na hitro razložiti, za kaj gre pri teh vrsticah kode in kako jih lahko popravite ali optimizirate. To je zelo, zelo razburljiva izkušnja.
Če imamo prakso neprekinjene integracije, nam to omogoča, da jo preverimo s številnimi avtomatiziranimi orodji tukaj in zdaj, takoj ko napišem kodo. To mi morda ne bo dalo popolne slike, vendar bo kljub temu odpravilo vsaj nekaj tveganj. In če obstaja kakšna morebitna napaka, bom vedel zanjo takoj, torej dobesedno čez nekaj minut. Ne bo mi treba vrniti 3 mesece nazaj. Vrniti se bom moral samo za 2 minuti. Dober aparat za kavo sploh ne bo imel časa skuhati kave v 2 minutah, tako da je to kar kul.
To ima vrednost, da se lahko večkrat ponovi pri vsakem projektu, tj. ne le tistega, na katerem ste ga nastavili. Ponovite lahko samo prakso in sam CI se bo ponovil za vsako novo spremembo, ki jo naredite v projektu. To vam omogoča optimizacijo virov, ker vaša ekipa deluje učinkoviteje. Ne boste več imeli situacije, ko bi hrošč prišel do vas iz kode, s katero ste delali pred 3 meseci. Ne boste več imeli preklapljanja konteksta, ko boste sedeli in prvi dve uri poskušali razumeti, kaj se je takrat zgodilo, in se poglobiti v bistvo konteksta, preden začnete nekaj popravljati.
Kako lahko merimo uspeh ali neuspeh te prakse? Če velikemu šefu poročaš, kaj smo izvajali na projektu CI, sliši bla bla bla. Izvedli smo ga, OK, ampak zakaj, kaj nam je prinesel, kako ga merimo, kako pravilno ali nepravilno ga izvajamo?
Prvi je ta, da lahko zahvaljujoč CI uvajamo vse pogosteje in pogosteje prav zato, ker je naša koda potencialno bolj stabilna. Na enak način se skrajša naš čas za iskanje napake in čas za odpravo te napake ravno zaradi tega, ker od sistema prejmemo odgovor tukaj in zdaj, kaj je narobe z našo kodo.
Druga praksa, ki jo imamo, je praksa avtomatiziranega testiranja, ki je najpogosteje povezana s prakso CI. Gredo z roko v roki.
Kaj je tukaj pomembno razumeti? Pomembno je razumeti, da so naši testi drugačni. In vsak avtomatiziran test je namenjen reševanju lastnih težav. Imamo na primer enotne teste, ki nam omogočajo, da testiramo modul ločeno, tj. Kako deluje v vakuumu? To je dobro.
Imamo tudi integracijske teste, ki nam omogočajo razumevanje, kako se različni moduli integrirajo med seboj. Prav tako je dobro.
Morda imamo teste avtomatizacije uporabniškega vmesnika, ki nam omogočajo, da preverimo, kako dobro delo z uporabniškim vmesnikom izpolnjuje določene zahteve, ki jih določi stranka itd.
Specifični testi, ki jih izvajate, lahko vplivajo na to, kako pogosto jih izvajate. Enotni testi so običajno napisani kratki in majhni. In jih je mogoče redno lansirati.
Če govorimo o testih avtomatizacije uporabniškega vmesnika, potem je dobro, če je vaš projekt majhen. Preizkusi avtomatizacije uporabniškega vmesnika lahko trajajo nekaj časa. Toda običajno je preizkus avtomatizacije uporabniškega vmesnika nekaj, kar pri velikem projektu traja več ur. In dobro je, če je nekaj ur. Edina stvar je, da jih nima smisla izvajati za vsako gradnjo. Smiselno jih je izvajati ponoči. In ko so zjutraj vsi prišli v službo: tako preizkuševalci kot razvijalci, so prejeli nekakšno poročilo, da smo ponoči izvedli samodejni test uporabniškega vmesnika in dobili te rezultate. In tukaj bo ura dela strežnika, ki bo preveril, ali vaš produkt izpolnjuje nekatere zahteve, veliko cenejša od ure dela istega QA inženirja, tudi če gre za Junior QA inženirja, ki dela za hrano in zahvalo. Vseeno bo ura delovanja stroja cenejša. Zato je vanj smiselno vlagati.
Imam še en projekt, na katerem delam. Pri tem projektu smo imeli dvotedenske sprinte. Projekt je bil velik, pomemben za finančni sektor in napake ni bilo. In po dvotedenskem sprintu je razvojnemu ciklu sledil proces testiranja, ki je trajal še 4 tedne. Poskusite si predstavljati razsežnost tragedije. Kodo pišemo dva tedna, nato jo naredimo ala CodeFreeze, jo zapakiramo v novo verzijo aplikacije in jo predstavimo preizkuševalcem. Testerji ga testirajo še 4 tedne, tj. Medtem ko ga testirajo, imamo čas, da jim pripravimo še dve različici. To je res žalosten primer.
Povedali smo jim, da če želite biti bolj produktivni, je smiselno, da uvedete prakso avtomatiziranega testiranja, ker je to tisto, kar vam škodi tukaj in zdaj.
Vadite neprekinjeno uvajanje. Odlično, končali ste z gradnjo. To je že dobro. Vaša koda je sestavljena. Zdaj bi bilo lepo razmestiti to zgradbo v nekem okolju. Recimo v okolju za razvijalce.
Zakaj je pomembno? Najprej lahko pogledate, kako uspešni ste pri samem procesu uvajanja. Srečal sem se s takšnimi projekti, ko vprašam: “Kako razmestiš novo različico aplikacije?”, mi fantje rečejo: “Mi jo sestavimo in zapakiramo v zip arhiv. Pošljemo adminu po pošti. Administrator prenese in razširi ta arhiv. In cela pisarna začne moliti, da bo strežnik prevzel novo različico.«
Začnimo z nečim preprostim. Na primer, pozabili so dati CSS v arhiv ali pozabili spremeniti hashtag v imenu datoteke java-script. In ko pošljemo zahtevo strežniku, brskalnik meni, da že ima to datoteko java-script in se odloči, da je ne bo prenesel. In tam je bila stara različica, nekaj je manjkalo. Na splošno je lahko veliko težav. Zato vam praksa neprekinjenega uvajanja omogoča vsaj preizkus, kaj bi se zgodilo, če bi posneli čisto referenčno sliko in jo naložili v povsem čisto novo okolje. Lahko vidite, kam to vodi.
Tudi, ko integrirate kodo med seboj, tj. med ukazom, vam to omogoča tudi ogled, kako je videti v uporabniškem vmesniku.
Ena od težav, ki se pojavi pri uporabi veliko java skripta, je ta, da sta dva razvijalca nepremišljeno prijavila spremenljivko z istim imenom v okenskem objektu. In potem, odvisno od vaše sreče. Čigava datoteka java-script je druga izvlečena, bo prepisala spremembe druge. Je tudi zelo razburljivo. Prideš: enemu dela eno, drugemu ne. In "čudovito" je, ko vse pride ven v produkciji.
Naslednja praksa, ki jo imamo, je praksa samodejne obnovitve, in sicer vrnitev na prejšnjo različico aplikacije.
Zakaj je to pomembno za razvijalce? Še vedno obstajajo tisti, ki se spominjajo daljnih, daljnih 90. let, ko so bili računalniki veliki in programi majhni. In edina pot do spletnega razvoja je bil PHP. Ne gre za to, da je PHP slab jezik, čeprav je.
Toda težava je bila drugačna. Ko smo uvedli novo različico našega spletnega mesta php, kako smo jo uvedli? Največkrat smo odprli Far Manager ali kaj drugega. In naložil te datoteke na FTP. In nenadoma smo ugotovili, da imamo nekaj majhnega, majhnega hrošča, na primer, pozabili smo vstaviti podpičje ali pozabili spremeniti geslo za bazo podatkov in obstaja geslo za bazo podatkov, ki je na lokalnem gostitelju. In se odločimo, da se hitro povežemo s FTP in uredimo datoteke kar tam. To je samo ogenj! To je bilo priljubljeno v 90. letih.
Ampak, če niste pogledali na koledar, so bila 90. leta skoraj 30 let nazaj. Zdaj se vse dogaja malo drugače. In poskusite si predstavljati razsežnost tragedije, ko vam rečejo: »Razporedili smo v proizvodnjo, a je šlo tam nekaj narobe. Tu sta vaša prijava in geslo za FTP, povežite se s produkcijo in tam hitro popravite.« Če ste Chuck Norris, bo to delovalo. Če ne, potem tvegate, da boste, če odpravite eno napako, naredili še 10. Ravno zato vam ta praksa vračanja na prejšnjo različico omogoča veliko.
Tudi če je nekje nekaj slabega nekako prišlo v prod, potem je slabo, ni pa usodno. Lahko se vrnete na prejšnjo različico, ki jo imate. Recimo temu rezervna kopija, če je to lažje razumeti v tej terminologiji. Lahko se vrnete na to prejšnjo različico in uporabniki bodo še vedno lahko delali z vašim izdelkom, vi pa boste imeli ustrezen čas medpomnilnika. Vse to lahko mirno, brez naglice vzamete in testirate lokalno, popravite in nato naložite novo različico. To je res smiselno narediti.
Zdaj pa poskusimo nekako združiti obe prejšnji praksi. Dobili bomo tretjega, imenovanega Upravljanje izdaj.
Ko govorimo o neprekinjenem uvajanju v njegovi klasični obliki, pravimo, da moramo potegniti kodo iz neke veje iz repozitorija, jo prevesti in namestiti. Dobro je, če imamo enako okolje. Če imamo več okolij, to pomeni, da moramo kodo potegniti vsakič, tudi iz iste objave. Vsakič ga bomo izvlekli, vsakič zgradili in postavili v novo okolje. Prvič, to je čas, saj lahko izgradnja projekta, če imate velikega in prihajate iz 90-ih, traja več ur.
Poleg tega je tu še ena žalost. Ko gradite, tudi na istem stroju, boste zgradili iste vire, še vedno nimate nobenega zagotovila, da je ta stroj v enakem stanju, kot je bil med zadnjo gradnjo.
Recimo, da je nekdo prišel in posodobil DotNet namesto vas ali pa se je nekdo odločil nekaj izbrisati. In potem imate kognitivno disonanco, da smo iz te objave pred dvema tednoma gradili gradnjo in je bilo vse v redu, zdaj pa se zdi, da je isti stroj, ista objava, ista koda, ki jo poskušamo zgraditi, vendar ne deluje . S tem se boste ukvarjali dolgo časa in ni dejstvo, da boste to ugotovili. Vsaj zelo si boste pokvarili živce.
Zato praksa upravljanja izdaj predlaga uvedbo dodatne abstrakcije, imenovane repozitorij ali galerija ali knjižnica artefaktov. Lahko ga imenujete kakor hočete.
Glavna zamisel je, da takoj, ko imamo nekakšno objavo tam, recimo v veji, ki smo jo pripravljeni namestiti v naša različna okolja, zberemo aplikacije iz te objave in vse, kar potrebujemo za to aplikacijo, to zapakiramo v arhiv zip in ga shranite v zanesljivo shrambo. In iz tega prostora za shranjevanje lahko kadar koli dobimo ta zip arhiv.
Nato ga vzamemo in samodejno namestimo v okolje za razvijalce. Tam dirkamo in če je vse v redu, se razporedimo na oder. Če je vse v redu, potem namestimo isti arhiv v produkcijo, iste binarne datoteke, prevedene natanko enkrat.
Poleg tega, ko imamo galerijo, kot je ta, nam tudi pomaga odpraviti tveganja, ki smo jih obravnavali na zadnjem diapozitivu, ko smo govorili o povrnitvi na prejšnjo različico. Če ste pomotoma razmestili kaj narobe, lahko kadar koli vzamete katero koli drugo prejšnjo različico iz te galerije in jo na enak način razmestite v ta okolja. To vam omogoča, da se preprosto vrnete na prejšnjo različico, če gre kaj narobe.
Obstaja še ena odlična praksa. Vi in jaz vsi razumemo, da ko vrnemo naše aplikacije na prejšnjo različico, to lahko pomeni, da potrebujemo tudi infrastrukturo prejšnje različice.
Ko govorimo o virtualni infrastrukturi, veliko ljudi misli, da je to nekaj, kar nastavijo skrbniki. In če morate, recimo, dobiti nov strežnik, na katerem želite preizkusiti novo različico vaše aplikacije, potem morate napisati vstopnico skrbnikom ali devopsom. Devops bo za to potreboval 3 tedne. In po 3 tednih vam bodo povedali, da smo vam namestili virtualni stroj z enim jedrom, dvema gigabajtoma RAM-a in Windows strežnikom brez DotNeta. Pravite: "Ampak hotel sem DotNet." Oni: "V redu, pridi nazaj čez 3 tedne."
Ideja je, da lahko z uporabo prakse Infrastructure as Code svojo virtualno infrastrukturo obravnavate kot le še en vir.
Če kdo od vas razvija aplikacije na DotNetu, je morda že slišal za knjižnico, imenovano Entity Framework. Morda ste celo slišali, da je Entity Framework eden od pristopov, ki jih Microsoft aktivno spodbuja. Za delo z bazo podatkov je to pristop, imenovan Code First. To je, ko v kodi opišete, kako želite, da izgleda vaša baza podatkov. In nato namestite aplikacijo. Povezuje se z bazo podatkov, sam ugotavlja, katere tabele so in katere ne, ter ustvari vse, kar potrebujete.
Enako lahko storite s svojo infrastrukturo. Ni razlike med tem, ali potrebujete bazo podatkov za projekt ali ali potrebujete strežnik Windows za projekt. To je samo vir. In lahko avtomatizirate ustvarjanje tega vira, lahko avtomatizirate konfiguracijo tega vira. V skladu s tem vsakič, ko želite preizkusiti nov koncept, nov pristop, vam ne bo treba napisati vozovnice za devops, lahko preprosto namestite izolirano infrastrukturo zase iz že pripravljenih predlog, iz pripravljenih skriptov in jo implementirate tam so vsi tvoji poskusi. To lahko izbrišete, pridobite nekaj rezultatov in poročate o tem.
Naslednja praksa, ki prav tako obstaja in je prav tako pomembna, a se je malokdo poslužuje, je Application Performance Monitoring.
Želel sem povedati samo eno stvar o spremljanju delovanja aplikacij. Kaj je najpomembnejše pri tej praksi? To je tisto, kar je spremljanje delovanja aplikacij približno enako kot popravilo stanovanja. To ni končno stanje, je proces. To morate storiti redno.
V dobrem smislu bi bilo dobro izvajati spremljanje delovanja aplikacij pri skoraj vsaki gradnji, čeprav, kot razumete, to ni vedno mogoče. Vendar pa ga je treba izvesti vsaj za vsako izdajo.
Zakaj je pomembno? Ker če nenadoma doživite padec učinkovitosti, potem morate jasno razumeti, zakaj. Če ima vaša ekipa, recimo, dvotedenske sprinte, morate vsaj enkrat na dva tedna namestiti svojo aplikacijo na nek ločen strežnik, kjer imate jasno fiksen procesor, RAM, diske itd. In zaženite te iste teste zmogljivosti . Dobiš rezultat. Poglejte, kako se je spremenil od prejšnjega sprinta.
In če ugotovite, da se je črpanje nekje močno znižalo, bo to pomenilo, da je to samo zaradi sprememb, ki so se zgodile v zadnjih dveh tednih. Tako boste veliko hitreje prepoznali in odpravili težavo. In spet, to so približno enake meritve, s katerimi lahko merite, kako uspešno ste to storili.
Naslednja praksa, ki jo imamo, je praksa upravljanja konfiguracije. Zelo malo jih je, ki to jemljejo resno. A verjemite, to je pravzaprav zelo resna stvar.
Nedavno je bila smešna zgodba. Fantje so prišli k meni in rekli: "Pomagajte nam opraviti varnostno revizijo naše aplikacije." Dolgo smo skupaj gledali kodo, povedali so mi o aplikaciji, risali diagrame. In plus ali minus je bilo vse logično, razumljivo, varno, vendar je bil en AMPAK! V svojem izvornem nadzoru so imeli konfiguracijske datoteke, vključno s tistimi iz proizvodnje z bazo IP, s prijavami in gesli za povezavo s temi bazami itd.
In rečem: »Fantje, v redu, svoje produkcijsko okolje ste zaprli s požarnim zidom, toda dejstvo, da imate prijavo in geslo za produkcijsko bazo podatkov neposredno v nadzoru vira in jih lahko vsak razvijalec prebere, je že veliko varnostno tveganje . In ne glede na to, kako zelo varna je vaša aplikacija z vidika kode, če jo pustite v nadzoru vira, ne boste nikoli nikjer opravili nobene revizije.« O tem govorim.
Upravljanje konfiguracije. V različnih okoljih imamo lahko različne konfiguracije. Na primer, lahko imamo različne prijave in gesla za zbirke podatkov za QA, demo, proizvodno okolje itd.
To konfiguracijo je mogoče tudi avtomatizirati. Vedno mora biti ločena od same aplikacije. Zakaj? Ker ste aplikacijo zgradili enkrat in je potem aplikaciji vseeno, ali se povežete s SQL strežnikom preko takega in tega IP-ja ali takega in tega IP-ja, bi morala delovati enako. Torej, če nenadoma eden od vas še vedno trdo kodira povezovalni niz v kodo, potem ne pozabite, da vas bom našel in kaznoval, če se znajdete na istem projektu z mano. To je vedno postavljeno v ločeno konfiguracijo, na primer v web.config.
In ta konfiguracija se že upravlja ločeno, tj. to je ravno trenutek, ko lahko razvijalec in skrbnik prideta in sedita v isti sobi. In razvijalec lahko reče: »Poglejte, tukaj so binarne datoteke moje aplikacije. Oni delajo. Aplikacija za delovanje potrebuje bazo podatkov. Tukaj poleg binarnih datotek je datoteka. V tej datoteki je to polje odgovorno za prijavo, to je za geslo, to je za IP. Razporedite ga kjer koli." In skrbniku je preprosto in jasno. Z upravljanjem te konfiguracije ga lahko namesti res kamor koli.
In zadnja praksa, o kateri bi rad govoril, je praksa, ki je zelo, zelo povezana z oblaki. Največji učinek pa prinaša, če delate v oblaku. To je samodejna odstranitev vašega okolja.
Vem, da je na tej konferenci več ljudi iz skupin, s katerimi delam. In z vsemi ekipami, s katerimi delam, uporabljamo to prakso.
Zakaj? Seveda bi bilo super, če bi vsak razvijalec imel virtualni stroj, ki bi deloval 24/7. Toda morda je to novica za vas, morda niste bili pozorni, vendar sam razvijalec ne deluje 24/7. Razvijalec običajno dela 8 ur na dan. Tudi če pride zgodaj v službo, ima veliko kosilo, med katerim gre v telovadnico. Naj bo 12 ur na dan, ko razvijalec dejansko uporablja te vire. Po naši zakonodaji imamo 5 od 7 dni v tednu, ki se štejejo za delovne dneve.
V skladu s tem ob delavnikih ta stroj ne bi smel delovati 24 ur, ampak le 12, ob vikendih pa ta stroj sploh ne bi smel delovati. Zdi se, da je vse zelo preprosto, toda kaj je tukaj pomembno povedati? Z izvajanjem te preproste prakse na tem osnovnem urniku vam omogoča znižanje stroškov vzdrževanja teh okolij za 70 %, tj. vzeli ste ceno svojega razvijalca, QA, demo, okolja in jo delili s 3.
Vprašanje je, kaj storiti s preostalim denarjem? Na primer, razvijalci bi morali kupiti ReSharper, če ga še niso. Ali pa naredite koktajl zabavo. Če si imel prej eno okolje v katerem sta se pasla tako dev kot QA in to je to, lahko sedaj narediš 3 različna, ki bodo izolirana, ljudje pa se ne bodo motili drug drugega.
Glede diapozitiva z neprekinjenim merjenjem uspešnosti, kako naj primerjamo uspešnost, če smo imeli v projektu 1 zapisov v bazi, dva meseca kasneje jih je milijon? Kako razumeti zakaj in kaj je smisel merjenja uspešnosti?
To je dobro vprašanje, saj bi morali vedno meriti uspešnost na istih virih. To pomeni, da uvedete novo kodo, merite uspešnost na novi kodi. Preizkusiti morate na primer različne scenarije delovanja, recimo, da želite preizkusiti, kako deluje aplikacija pri majhni obremenitvi, kjer je 1 uporabnikov in je velikost baze podatkov 000 gigabajtov. Izmerili ste in dobili številke. Nato vzamemo drug scenarij. Na primer, 5 uporabnikov, velikost baze podatkov 5 terabajt. Rezultate smo prejeli in si jih zapomnili.
Kaj je tukaj pomembno? Pri tem je pomembno, da lahko glede na scenarij, količino podatkov, število hkratnih uporabnikov itd. naletite na določene omejitve. Na primer do meje omrežne kartice, ali do meje trdega diska, ali do meje zmogljivosti procesorja. To je tisto, kar je pomembno, da razumete. V različnih scenarijih naletite na določene omejitve. In razumeti morate številke, ko jih zadenete.
Ali govorimo o merjenju zmogljivosti v posebnem testnem okolju? Se pravi, to ni proizvodnja?
Ja, to ni proizvodnja, to je testno okolje, ki je vedno enako, da ga lahko primerjaš s prejšnjimi meritvami.
Razumem hvala!
Če ni vprašanj, mislim, da lahko zaključimo. Hvala vam!
Vir: www.habr.com