Rapporten vil snakke om noen DevOps-praksis, men fra en utviklers synspunkt. Vanligvis har alle ingeniører som blir med i DevOps allerede flere års administrativ erfaring under beltet. Men dette betyr ikke at det ikke er plass for utbygger her. Oftere enn ikke er utviklere opptatt med å fikse «dagens neste kritiske feil», og de har ikke tid til å ta en rask titt på DevOps-feltet. Etter forfatterens forståelse er DevOps for det første sunn fornuft. For det andre er det en mulighet til å bli mer effektiv. Hvis du er en utvikler, har sunn fornuft og ønsker å bli mer effektiv som lagspiller, er denne rapporten for deg.
La meg presentere meg selv, jeg innrømmer fullt ut at det er folk i rommet som ikke kjenner meg. Mitt navn er Anton Boyko, jeg er en Microsoft Azure MVP. Hva er MVP? Dette er Model-View-Presenter. Model-View-Presenter er akkurat meg.
I tillegg har jeg for tiden stillingen som løsningsarkitekt i Ciklum. Og nylig kjøpte jeg meg et så vakkert domene, og jeg oppdaterte e-posten min, som jeg vanligvis viser på presentasjoner. Du kan skrive til meg på: me [dog] byokoant.pro. Du kan sende meg en e-post med spørsmål. Jeg pleier å svare dem. Det eneste er at jeg ikke ønsker å motta spørsmål på e-post som er knyttet til to temaer: politikk og religion. Du kan skrive til meg om alt annet på e-post. Det går litt tid, skal jeg svare.
Noen få ord om deg selv:
- Jeg har vært i dette feltet i 10 år nå.
- Jeg jobbet i Microsoft.
- Jeg er grunnleggeren av det ukrainske Azure-samfunnet, som vi grunnla et sted i 2014. Og vi har det fortsatt og utvikler det.
- Jeg er også far til grunnleggeren av Azure-konferansen, som vi er vertskap for i Ukraina.
- Jeg hjelper også til med å organisere Global Azure Bootcamp i Kiev.
- Som jeg sa, jeg er en Microsoft Azure MVP.
- Jeg snakker ganske ofte på konferanser. Jeg elsker virkelig å snakke på konferanser. I løpet av det siste året var jeg i stand til å opptre rundt 40 ganger. Hvis du går forbi Ukraina, Hviterussland, Polen, Bulgaria, Sverige, Danmark, Nederland, Spania eller gir eller tar et annet land i Europa, så er det godt mulig at når du går på en konferanse som har et skytema i strømmen, du kan se meg på listen over høyttalere.
- Jeg er også en Star Trek-fan.
La oss snakke litt om Agenda. Agendaen vår er veldig enkel:
- Vi skal snakke om hva DevOps er. La oss snakke om hvorfor dette er viktig. Tidligere var DevOps et nøkkelord som du skrev på CV-en din og umiddelbart fikk +$500 i lønn. Nå må du skrive for eksempel blockchain i CV-en din for å få +500 dollar til lønnen din.
- Og så, når vi forstår litt om hva dette er, vil vi snakke om hva DevOps-praksis er. Men ikke så mye i sammenheng med DevOps generelt, men om de DevOps-praksisene som kan være av interesse for utviklere. Jeg skal fortelle deg hvorfor de kan være av interesse for deg. Jeg skal fortelle deg hvorfor du i det hele tatt bør gjøre dette og hvordan det kan hjelpe deg å oppleve mindre smerte.
Et tradisjonelt bilde som mange viser. Dette er det som skjer i mange prosjekter. Dette er når vi har utviklings- og driftsavdelinger som støtter programvaren vår. Og disse avdelingene kommuniserer ikke med hverandre.
Kanskje, hvis du ikke var i stand til å føle det så tydelig i DevOps- og driftsavdelingene, kan du trekke en analogi med Dev- og QA-avdelingene. Det er folk som utvikler programvare og det er QA-folk som er dårlige fra utviklerens synspunkt. For eksempel forplikter jeg den fantastiske koden min til depotet, og det sitter en skurk som returnerer denne koden til meg og sier at koden din er dårlig.
Alt dette skjer fordi folk ikke kommuniserer med hverandre. Og de kaster noen pakker, noen søknader til hverandre gjennom en vegg av misforståelser og prøver å gjøre noe med dem.
Det er nettopp denne veggen DevOps-kulturen er designet for å ødelegge, d.v.s. tvinge folk til å kommunisere med hverandre og i det minste forstå hva ulike personer i prosjektet gjør og hvorfor arbeidet deres er viktig.
Og når vi snakker om DevOps, vil noen fortelle deg at DevOps er når prosjektet har kontinuerlig integrasjon; noen vil si at DevOps er hvis prosjektet implementerer "infrastruktur som kode"-praksis; noen vil si at det første trinnet til DevOps er funksjonsforgrening, funksjonsflagg.
I hovedsak er alt dette sant på sin egen måte. Men dette er bare den ultimate praksisen vi har. Før du går videre til disse praksisene, foreslår jeg at du ser på dette lysbildet, som viser de 3 stadiene for implementering av Dev-Ops-metodikk i prosjektet ditt, i din bedrift.
Dette lysbildet har også et annet uoffisielt navn. Du kan søke på nettet for å finne ut hva de 3 musketerene til DevOps er. Det er mulig du finner denne artikkelen. Hvorfor 3 musketerer? Under står det: mennesker, prosesser og produkter, d.v.s. OPS – Porthos, Porthos og Porthos. Her er de 3 musketerene til DevOps. Denne artikkelen beskriver mer detaljert hvorfor dette er viktig og hva det innebærer.
Når du begynner å implementere en DevOps-kultur, er det svært viktig at den implementeres i følgende rekkefølge.
I utgangspunktet må du snakke med folk. Og du må forklare folk hva det er og hvordan de kan få noen fordeler av det.
Konferansen vår heter DotNet Fest. Og som arrangørene fortalte meg, inviterte vi hovedsakelig et publikum av utviklere hit, så jeg håper at de fleste i salen er med på utvikling.
Vi skal snakke om mennesker, vi skal snakke om hva utviklere vil gjøre hver dag. Hva ønsker de mest? De vil skrive ny kode, bruke nymotens rammeverk, lage nye funksjoner. Hva ønsker utviklerne minst? Rett opp gamle feil. Jeg håper du er enig med meg. Det er dette utviklerne ønsker. De vil skrive nye funksjoner, de vil ikke fikse feil.
Antall bugs som en bestemt utvikler produserer, avhenger av hvor rette armene hans er og hvor mye de vokser fra skuldrene hans, og ikke fra rumpelommene. Men likevel, når vi har et stort prosjekt, hender det noen ganger at det er umulig å holde styr på alt, så det ville være fint for oss å bruke noen tilnærminger som vil hjelpe oss å skrive mer stabil kode med høyere kvalitet.
Hva ønsker QAer mest? Jeg vet ikke om de er i hallen. Det er vanskelig for meg å si at jeg vil ha en QA, for jeg har aldri vært det. Og ingen fornærmelse mot gutta, det skal sies at jeg håper jeg aldri vil gjøre det. Men ikke av den grunn at jeg anser arbeidet deres som meningsløst og ubrukelig, men fordi jeg ikke anser meg selv som en person som kunne gjøre dette arbeidet effektivt, så jeg vil ikke engang prøve å gjøre det. Men etter det jeg forstår, det QA ikke liker best er å gå på jobb om morgenen, hele tiden kjøre noen form for regresjonstester, tråkke på de samme feilene som de rapporterte til utviklerne for tre spurter siden og si: «Når vil du , Monsieur D 'Artagnan, fiks denne feilen.' Og Monsieur D'Artagnan svarer ham: "Ja, ja, ja, jeg har allerede fikset det." Og hvordan det har seg at jeg fikset en feil og laget 3 underveis.
De som støtter denne løsningen i produksjonen vil at denne løsningen skal fungere uten feil, slik at de ikke trenger å starte serveren på nytt hver fredag, når alle vanlige mennesker går til baren. Utviklerne distribuert på fredag, administratorene sitter til lørdag og prøver å få denne distribusjonen opp og fikset.
Og når du forklarer folk at de er rettet mot å løse de samme problemene, kan du gå videre til å formalisere prosessene. Det er veldig viktig. Hvorfor? For når vi sier «formalisering», er det viktig for deg å beskrive hvordan prosessene dine skjer i det minste et sted på en serviett. Du må forstå at hvis du for eksempel distribuerer til et QA-miljø eller et produksjonsmiljø, så skjer det alltid i denne rekkefølgen; på disse stadiene kjører vi for eksempel automatiske enhetstester og UI-tester. Etter utplassering sjekker vi om utplasseringen gikk bra eller dårlig. Men du har allerede en klar liste over handlinger som må gjentas om og om igjen når du distribuerer til produksjon.
Og først når prosessene dine er formalisert, begynner du å velge produkter som vil hjelpe deg med å automatisere disse prosessene.
Dessverre ser jeg veldig ofte at dette skjer omvendt. Så snart noen hører ordet "DevOps", foreslår de umiddelbart å installere Jenkins, fordi de tror at så snart de installerer Jenkins, vil de ha DevOps. De installerte Jenkins, leste «How to»-artiklene på Jenkins-nettstedet, prøvde å stappe inn prosesser i disse How to-artiklene, og kom så til folk og bøyde folk og sa at boken sier at du må gjøre det på denne måten, så vi gjør det på denne måten.
Det er ikke det at Jenkins er et dårlig verktøy. Jeg mener ikke å si det på noen måte. Men dette er bare ett av produktene. Og hvilket produkt du bruker bør være din siste avgjørelse, og på ingen måte din første. Produktet ditt bør ikke være drevet av implementering av kultur og tilnærminger. Dette er veldig viktig å forstå, og det er derfor jeg bruker så mye tid på dette lysbildet og forklarer alt dette så lenge.
La oss snakke om DevOps-praksis generelt. Hva er de? Hva er forskjellen? Hvordan prøve dem? Hvorfor er de viktige?
Den første praksisen du kanskje har hørt om kalles kontinuerlig integrasjon. Kanskje noen på prosjektet har Continuous Integration (CI).
Det største problemet er at jeg oftest spør en person: "Har du CI på prosjektet?" og han sier: "Ja," så når jeg spør hva han gjør, beskriver han for meg absolutt hele automatiseringsprosessen. Dette er ikke helt sant.
Faktisk er praksisen med CI bare rettet mot å integrere koden som forskjellige mennesker skriver inn i en slags enkelt kodebase. Det er alt.
Sammen med CI er det vanligvis andre praksiser underveis - for eksempel kontinuerlig distribusjon, utgivelsesadministrasjon, men vi skal snakke om det senere.
CI selv forteller oss at forskjellige personer skriver kode og denne koden må kontinuerlig integreres i en enkelt kodebase.
Hva gir dette oss og hvorfor er det viktig? Hvis vi har DotNet, så er det bra, det er et kompilert språk, vi kan kompilere applikasjonen vår. Hvis det kompileres, er dette allerede et godt tegn. Dette betyr ikke noe ennå, men det er det første gode tegnet som vi i det minste kan kompilere.
Da kan vi kjøre noen tester, som også er en egen praksis. Alle testene er grønne – dette er det andre gode tegnet. Men igjen, dette betyr ingenting.
Men hvorfor skulle du gjøre dette? Alle praksisene jeg skal snakke om i dag har omtrent samme verdi, dvs. omtrent de samme fordelene og måles også omtrent på samme måte.
For det første lar det deg fremskynde leveringen. Hvordan lar dette deg fremskynde leveringen? Når vi gjør noen nye endringer i kodebasen vår, kan vi umiddelbart prøve å gjøre noe med denne koden. Vi venter ikke til torsdag kommer, for på torsdag slipper vi den til QA Environment, vi gjør det her og akkurat her.
Jeg skal fortelle deg en trist historie fra livet mitt. Det var lenge siden, da jeg fortsatt var ung og kjekk. Nå er jeg allerede ung, vakker og smart, og beskjeden. For en tid siden var jeg i et prosjekt. Vi hadde et stort team på rundt 30 utviklere. Og vi hadde et stort, stort Enterprise-prosjekt som utviklet seg i omtrent 10 år. Og vi hadde forskjellige grener. I depotet hadde vi en gren der utviklere gikk. Og det var en gren som viste versjonen av koden som er i produksjon.
Produksjonsgrenen lå 3 måneder bak grenen som var tilgjengelig for utviklere. Hva betyr dette? Dette betyr at så snart jeg har en feil et sted som går til produksjon på grunn av feilen til utviklerne, fordi de tillot det, og på grunn av feilen til QA, fordi de så på den, så betyr dette at hvis jeg mottar en oppgave for hurtigreparasjon for produksjon, så må jeg rulle tilbake kodeendringene mine for 3 måneder siden. Jeg må huske hva jeg hadde for 3 måneder siden og prøve å fikse det der.
Hvis du ikke har hatt denne opplevelsen ennå, kan du prøve den på hjemmeprosjektet ditt. Det viktigste er, ikke prøv det på en kommersiell en. Skriv et par linjer med kode, glem dem i seks måneder, og kom så tilbake og prøv å raskt forklare hva disse kodelinjene handler om og hvordan du kan fikse eller optimalisere dem. Det er en veldig, veldig spennende opplevelse.
Hvis vi har en kontinuerlig integrasjonspraksis, så lar dette oss sjekke det med en rekke automatiserte verktøy akkurat her og akkurat nå, så snart jeg har skrevet koden min. Dette gir meg kanskje ikke hele bildet, men likevel vil det fjerne i det minste noen av risikoene. Og hvis det er noen potensiell feil, vil jeg vite om det akkurat nå, det vil si bokstavelig talt om et par minutter. Jeg trenger ikke rulle tilbake 3 måneder. Jeg trenger bare å rulle tilbake 2 minutter. En god kaffemaskin har ikke engang tid til å brygge kaffe på 2 minutter, så det er ganske kult.
Dette har den verdien at det kan gjentas gang etter gang på hvert prosjekt, d.v.s. ikke bare den du satte den opp på. Du kan gjenta både selve øvelsen og selve CI vil bli gjentatt for hver ny endring du gjør i prosjektet. Dette lar deg optimalisere ressursene fordi teamet ditt jobber mer effektivt. Du vil ikke lenger ha en situasjon der en feil kommer til deg fra koden du jobbet med for 3 måneder siden. Du vil ikke lenger ha kontekstbytte når du sitter og bruker de to første timene på å prøve å forstå hva som skjedde da og komme inn i essensen av konteksten før du begynner å rette opp noe.
Hvordan kan vi måle suksessen eller fiaskoen til denne praksisen? Hvis du rapporterer til den store sjefen hva vi implementerte på CI-prosjektet, hører han bla bla bla. Vi implementerte det, OK, men hvorfor, hva ga det oss, hvordan måler vi det, hvor riktig eller feil implementerer vi det?
Den første er at vi, takket være CI, kan distribuere oftere og oftere, og oftere nettopp fordi koden vår potensielt er mer stabil. På samme måte reduseres tiden vår til å finne en feil og tiden for å rette denne feilen reduseres nettopp av den grunn at vi får svar fra systemet akkurat her og akkurat nå, hva som er galt med koden vår.
En annen praksis vi har er praksisen Automation Testing, som oftest følger med CI-praksisen. De går hånd i hånd.
Hva er viktig å forstå her? Det er viktig å forstå at testene våre er forskjellige. Og hver automatisert test er rettet mot å løse sine egne problemer. Vi har for eksempel enhetstester som gjør at vi kan teste en modul separat, dvs. Hvordan fungerer det i et vakuum? Dette er bra.
Vi har også integrasjonstester som lar oss forstå hvordan ulike moduler integreres med hverandre. Det er også bra.
Vi kan ha UI-automatiseringstester som lar oss sjekke hvor godt arbeidet med UI oppfyller visse krav som er satt av kunden, etc.
De spesifikke testene du kjører kan påvirke hvor ofte du kjører dem. Enhetsprøver er vanligvis skrevet korte og små. Og de kan lanseres regelmessig.
Hvis vi snakker om UI-automatiseringstester, så er det bra hvis prosjektet ditt er lite. UI-automatiseringstestene dine kan ta litt tid. Men vanligvis er en UI-automatiseringstest noe som tar flere timer på et stort prosjekt. Og det er bra om det er noen timer. Det eneste er at det ikke er noen vits i å kjøre dem for hvert bygg. Det er fornuftig å kjøre dem om natten. Og når alle kom på jobb om morgenen: både testere og utviklere, fikk de en slags rapport om at vi kjørte UI-autotesten om natten og fikk disse resultatene. Og her vil en times arbeid av en server som skal sjekke at produktet ditt oppfyller noen krav være mye billigere enn en times arbeid av samme QA-ingeniør, selv om det er en Junior QA-ingeniør som jobber for mat og takk. Likevel vil en times maskindrift være billigere. Det er derfor det er fornuftig å investere i det.
Jeg har et annet prosjekt jeg har jobbet med. Vi hadde to ukers sprint på dette prosjektet. Prosjektet var stort, viktig for finanssektoren, og en feil kunne ikke gjøres. Og etter en to ukers sprint ble utviklingssyklusen fulgt av en testprosess, som tok ytterligere 4 uker. Prøv å forestille deg omfanget av tragedien. Vi skriver kode i to uker, så gjør vi det ala CodeFreeze, pakker det inn i en ny versjon av applikasjonen og ruller det ut til testere. Testere tester den i ytterligere 4 uker, dvs. Mens de tester den, har vi tid til å forberede ytterligere to versjoner for dem. Dette er en virkelig trist sak.
Og vi fortalte dem at hvis du ønsker å være mer produktiv, er det fornuftig for deg å implementere automatiserte testpraksis, fordi det er dette som gjør deg vondt her, akkurat nå.
Øv på kontinuerlig distribusjon. Flott, du har bygget ferdig. Dette er allerede bra. Koden din er kompilert. Nå ville det vært fint å distribuere denne bygningen på et eller annet miljø. La oss si i et miljø for utviklere.
Hvorfor er det viktig? Først kan du se på hvor vellykket du er med selve distribusjonsprosessen. Jeg har møtt prosjekter som dette, når jeg spør: "Hvordan distribuerer du en ny versjon av applikasjonen?", forteller gutta: "Vi setter den sammen og pakker den inn i et zip-arkiv. Vi sender det til admin på mail. Administratoren laster ned og utvider dette arkivet. Og hele kontoret begynner å be om at serveren skal hente den nye versjonen.»
La oss starte med noe enkelt. For eksempel glemte de å legge CSS i arkivet eller glemte å endre hashtaggen i java-script-filnavnet. Og når vi sender en forespørsel til serveren, tror nettleseren at den allerede har denne java-script-filen og bestemmer seg for ikke å laste den ned. Og det var en gammel versjon, noe manglet. Generelt kan det være mange problemer. Derfor lar praksisen med Continuous Deployment deg i det minste teste hva som ville skje hvis du tok et rent referansebilde og lastet det opp til et helt rent nytt miljø. Du kan se hvor dette fører.
Også når du integrerer kode mellom hverandre, dvs. mellom kommandoen lar dette deg også se hvordan det ser ut på brukergrensesnittet.
Et av problemene som oppstår der det brukes mye vanilla java-script er at to utviklere overilte deklarerte en variabel med samme navn i vinduet-objektet. Og så, avhengig av lykken din. Hvis java-script-filen er trukket ut nummer to, vil overskrive endringene til den andre. Det er også veldig spennende. Du kommer inn: en ting fungerer for en person, en annen fungerer ikke for en annen. Og det er "fantastisk" når alt kommer ut i produksjon.
Den neste praksisen vi har er praksisen med automatisk gjenoppretting, nemlig å rulle tilbake til forrige versjon av applikasjonen.
Hvorfor er dette viktig for utviklere? Det er fortsatt de som husker det fjerne, fjerne 90-tallet, da datamaskiner var store og programmer var små. Og den eneste måten å utvikle web på var gjennom PHP. Det er ikke det at PHP er et dårlig språk, selv om det er det.
Men problemet var annerledes. Da vi implementerte en ny versjon av php-siden vår, hvordan implementerte vi den? Oftest åpnet vi Far Manager eller noe annet. Og lastet opp disse filene til FTP. Og vi skjønte plutselig at vi hadde en liten, liten feil, for eksempel glemte vi å sette et semikolon eller glemte å endre passordet for databasen, og det er et passord for databasen, som er på den lokale verten. Og vi bestemmer oss for å raskt koble til FTP og redigere filene der. Dette er bare brann! Det var dette som var populært på 90-tallet.
Men, hvis du ikke har sett på kalenderen, var 90-tallet nesten 30 år siden. Nå skjer alt litt annerledes. Og prøv å forestille deg omfanget av tragedien når de forteller deg: «Vi distribuerte til produksjon, men noe gikk galt der. Her er din FTP-pålogging og passord, koble til produksjonen og fiks det raskt der." Hvis du er Chuck Norris, vil dette fungere. Hvis ikke, så risikerer du at hvis du fikser én feil, vil du tjene 10 til. Det er nettopp derfor denne praksisen med å rulle tilbake til forrige versjon lar deg oppnå mye.
Selv om noe dårlig på en eller annen måte havnet i prod et sted, så er det dårlig, men ikke dødelig. Du kan rulle tilbake til den forrige versjonen du har. Kall det en sikkerhetskopi, hvis det er lettere å oppfatte det i den terminologien. Du kan rulle tilbake til denne forrige versjonen, og brukere vil fortsatt kunne jobbe med produktet ditt, og du vil ha tilstrekkelig buffertid. Du kan rolig, uten hastverk, ta alt dette og teste det lokalt, fikse det og deretter laste opp en ny versjon. Det er virkelig fornuftig å gjøre dette.
La oss nå prøve å kombinere de to tidligere praksisene på en eller annen måte. Vi får en tredje som heter Release Management.
Når vi snakker om Continuous Deployment i sin klassiske form, sier vi at vi må hente kode fra en gren fra depotet, kompilere den og distribuere den. Det er bra om vi har samme miljø. Hvis vi har flere miljøer betyr dette at vi må trekke koden hver gang, selv fra samme commit. Vi vil trekke det ut hver gang, vi vil bygge det hver gang og vi vil distribuere det til et nytt miljø. For det første er dette på tide, for å bygge et prosjekt, hvis du har et stort og kom fra 90-tallet, kan det ta flere timer.
Dessuten er det en annen tristhet. Når du bygger, selv på samme maskin, vil du bygge de samme kildene, du har fortsatt ingen garanti for at denne maskinen er i samme tilstand som den var under forrige bygging.
La oss si at noen kom inn og oppdaterte DotNet for deg, eller omvendt, noen bestemte seg for å slette noe. Og så har du kognitiv dissonans at fra denne forpliktelsen for to uker siden bygde vi en build og alt var bra, men nå virker det som den samme maskinen, den samme forpliktelsen, den samme koden som vi prøver å bygge, men den fungerer ikke . Du kommer til å håndtere dette i lang tid, og det er ikke et faktum at du vil finne ut av det. I det minste vil du ødelegge nervene dine mye.
Derfor foreslår Release Management-praksis å introdusere en ekstra abstraksjon kalt et artefaktlager eller galleri eller bibliotek. Du kan kalle det hva du vil.
Hovedideen er at så snart vi har en form for commit der, for eksempel i en gren som vi er klare til å distribuere til våre forskjellige miljøer, samler vi inn søknader fra denne commit og alt vi trenger for denne applikasjonen, vi pakker det inn. inn i et zip-arkiv og lagre det i en pålitelig lagring. Og fra denne lagringen kan vi hente dette zip-arkivet når som helst.
Så tar vi det og distribuerer det automatisk til utviklermiljøet. Vi kjører der, og hvis alt er bra, så deployerer vi til etappen. Hvis alt er bra, distribuerer vi det samme arkivet til produksjon, de samme binære filene, kompilert nøyaktig én gang.
I tillegg, når vi har et galleri som dette, hjelper det oss også med å adressere risikoene som vi adresserte på det siste lysbildet da vi snakket om tilbakeføring til forrige versjon. Hvis du ved et uhell har implementert noe feil, kan du alltid ta en hvilken som helst annen tidligere versjon fra dette galleriet og avinstallere den til disse miljøene på samme måte. Dette lar deg enkelt rulle tilbake til forrige versjon hvis noe går galt.
Det er en annen god praksis. Du og jeg forstår alle at når vi ruller tilbake applikasjonene våre til en tidligere versjon, kan dette bety at vi også trenger infrastrukturen til den forrige versjonen.
Når vi snakker om virtuell infrastruktur, tror mange at dette er noe administratorer setter opp. Og hvis du trenger for eksempel å få en ny server som du vil teste en ny versjon av applikasjonen din på, må du skrive en billett til admins eller devops. Devops vil ta 3 uker for dette. Og etter 3 uker vil de fortelle deg at vi har installert en virtuell maskin for deg, med én kjerne, to gigabyte RAM og en Windows-server uten DotNet. Du sier: "Men jeg ville ha DotNet." De: "Ok, kom tilbake om 3 uker."
Tanken er at ved å bruke infrastruktur som kodepraksis, kan du behandle din virtuelle infrastruktur som bare en annen ressurs.
Kanskje, hvis noen av dere utvikler applikasjoner på DotNet, har du kanskje hørt om et bibliotek kalt Entity Framework. Og du har kanskje til og med hørt at Entity Framework er en av tilnærmingene som Microsoft driver aktivt. For å jobbe med en database er dette en tilnærming kalt Code First. Dette er når du beskriver i kode hvordan du vil at databasen din skal se ut. Og så distribuerer du applikasjonen. Den kobles til databasen, den bestemmer selv hvilke tabeller som er der og hvilke tabeller som ikke er det, og lager alt du trenger.
Du kan gjøre det samme med infrastrukturen din. Det er ingen forskjell på om du trenger en database for et prosjekt eller om du trenger en Windows-server for et prosjekt. Det er bare en ressurs. Og du kan automatisere opprettelsen av denne ressursen, du kan automatisere konfigurasjonen av denne ressursen. Følgelig, hver gang du vil teste et nytt konsept, en ny tilnærming, trenger du ikke å skrive en billett til devops, du kan ganske enkelt distribuere en isolert infrastruktur for deg selv fra ferdige maler, fra ferdige skript og implementere den der alle eksperimentene dine. Du kan slette dette, få noen resultater og rapportere videre om det.
Den neste praksisen, som også finnes og også er viktig, men som få mennesker bruker, er Application Performance Monitoring.
Jeg ville bare si én ting om applikasjonsytelsesovervåking. Hva er viktigst med denne praksisen? Dette er hva Application Performance Monitoring er omtrent det samme som å reparere en leilighet. Dette er ikke en endelig tilstand, det er en prosess. Du må gjøre det regelmessig.
På en god måte ville det være bra å utføre applikasjonsytelsesovervåking på nesten alle bygg, selv om, som du forstår, dette ikke alltid er mulig. Men det må i det minste utføres for hver utgivelse.
Hvorfor er det viktig? For hvis du plutselig opplever et fall i ytelsen, så må du tydelig forstå hvorfor. Hvis teamet ditt har for eksempel to-ukers sprints, bør du minst en gang annenhver uke distribuere applikasjonen din til en separat server, hvor du har en tydelig fast prosessor, RAM, disker osv. Og kjøre de samme ytelsestestene . Du får resultatet. Se hvordan det har endret seg fra forrige sprint.
Og hvis du finner ut at nedtrekket gikk kraftig ned et sted, vil det bety at det bare var på grunn av endringene som har skjedd de siste to ukene. Dette vil tillate deg å identifisere og fikse problemet mye raskere. Og igjen, dette er omtrent de samme beregningene som du kan måle hvor vellykket du gjorde det.
Den neste praksisen vi har er Configuration Management-praksisen. Det er svært få som tar dette seriøst. Men tro meg, dette er faktisk en veldig alvorlig ting.
Det var en morsom historie nylig. Gutta kom til meg og sa: «Hjelp oss med å gjennomføre en sikkerhetsrevisjon av applikasjonen vår.» Vi så lenge på koden sammen, de fortalte meg om applikasjonen, tegnet diagrammer. Og pluss eller minus alt var logisk, forståelig, trygt, men det var ett MEN! De hadde konfigurasjonsfiler i kildekontrollen, inkludert de fra produksjon med IP-databasen, med pålogginger og passord for å koble til disse databasene osv.
Og jeg sier: «Gutter, ok, dere har lukket produksjonsmiljøet med en brannmur, men det faktum at dere har pålogging og passord for produksjonsdatabasen rett i kildekontrollen og enhver utviklere kan lese det er allerede en stor sikkerhetsrisiko . Og uansett hvor supersikker applikasjonen din er fra et kodesynspunkt, hvis du lar den være i kildekontroll, vil du aldri bestå noen revisjon hvor som helst." Det er det jeg snakker om.
Konfigurasjonsstyring. Vi kan ha forskjellige konfigurasjoner i forskjellige miljøer. For eksempel kan vi ha ulike pålogginger og passord for databaser for QA, demo, produksjonsmiljø osv.
Denne konfigurasjonen kan også automatiseres. Den skal alltid være atskilt fra selve applikasjonen. Hvorfor? Fordi du bygde applikasjonen en gang, og da bryr applikasjonen seg ikke om du kobler til SQL-serveren via en slik og en IP eller en slik og en IP, bør det fungere på samme måte. Derfor, hvis plutselig en av dere fortsatt hardkoder forbindelsesstrengen i koden, husk at jeg vil finne deg og straffe deg hvis du befinner deg på samme prosjekt som meg. Denne plasseres alltid i en egen konfigurasjon, for eksempel i web.config.
Og denne konfigurasjonen er allerede administrert separat, det vil si at dette er akkurat det øyeblikket da en utvikler og en administrator kan komme og sitte i samme rom. Og utvikleren kan si: "Se, her er binærfilene til applikasjonen min. De jobber. Applikasjonen trenger en database for å fungere. Her ved siden av binærfilene er det en fil. I denne filen er dette feltet ansvarlig for påloggingen, dette er for passordet, dette er for IP-en. Distribuer den hvor som helst." Og det er enkelt og oversiktlig for administratoren. Han kan distribuere det virkelig hvor som helst ved å administrere denne konfigurasjonen.
Og den siste praksisen jeg vil snakke om er en praksis som er veldig, veldig relatert til skyer. Og det gir maksimal effekt hvis du jobber i skyen. Dette er automatisk fjerning av miljøet ditt.
Jeg vet at det er flere personer på denne konferansen fra teamene jeg jobber med. Og med alle teamene jeg jobber med, bruker vi denne praksisen.
Hvorfor? Selvfølgelig ville det vært flott om hver utvikler hadde en virtuell maskin som ville fungere 24/7. Men kanskje dette er nyheter for deg, kanskje du ikke tok hensyn, men utvikleren selv jobber ikke 24/7. En utvikler jobber vanligvis 8 timer om dagen. Selv om han kommer tidlig på jobb, spiser han en stor lunsj der han går på treningssenteret. La det være 12 timer om dagen når utvikleren faktisk bruker disse ressursene. I henhold til vårt lovverk har vi 5 av 7 dager i en uke som regnes som virkedager.
Følgelig skal denne maskinen på ukedager ikke fungere 24 timer, men bare 12, og i helgene skal denne maskinen ikke fungere i det hele tatt. Det ser ut til at alt er veldig enkelt, men hva er viktig å si her? Ved å implementere denne enkle praksisen på denne grunnleggende tidsplanen, lar den deg redusere kostnadene for å vedlikeholde disse miljøene med 70 %, det vil si at du tok prisen på utviklingen, QA, demoen, miljøet og delte den på 3.
Spørsmålet er hva du skal gjøre med resten av pengene? For eksempel bør utviklerne kjøpe ReSharper hvis de ikke allerede har gjort det. Eller ha et cocktailparty. Hvis du tidligere hadde ett miljø der både dev og QA beitet, og det er det, kan du nå lage 3 forskjellige som vil bli isolert, og folk vil ikke forstyrre hverandre.
Når det gjelder lysbildet med kontinuerlig ytelsesmåling, hvordan kan vi sammenligne ytelsen hvis vi hadde 1 poster i databasen i prosjektet, to måneder senere er det en million? Hvordan forstå hvorfor og hva er poenget med å måle ytelse?
Dette er et godt spørsmål, fordi du alltid bør måle ytelse på de samme ressursene. Det vil si at du ruller ut ny kode, du måler ytelsen på den nye koden. For eksempel må du teste ulike ytelsesscenarier, la oss si at du vil teste hvordan applikasjonen yter på en lett belastning, der det er 1 brukere og databasestørrelsen er 000 gigabyte. Du målte det og fikk tallene. Deretter tar vi et annet scenario. For eksempel 5 brukere, databasestørrelse 5 terabyte. Vi mottok resultatene og husket dem.
Hva er viktig her? Det viktige her er at avhengig av scenariet, datavolumet, antall samtidige brukere, etc., kan du komme inn i visse grenser. For eksempel til grensen for et nettverkskort, eller til grensen for en harddisk, eller til grensen for prosessorkapasitet. Det er dette som er viktig for deg å forstå. I forskjellige scenarier møter du visse grenser. Og du må forstå tallene når du treffer dem.
Snakker vi om måling av ytelse i et spesielt testmiljø? Det vil si at dette ikke er produksjon?
Ja, dette er ikke produksjon, dette er et testmiljø, som alltid er det samme slik at du kan sammenligne det med tidligere målinger.
Forstått takk!
Hvis det ikke er spørsmål, tror jeg vi kan fullføre. Takk skal du ha!
Kilde: www.habr.com