Rapporten vil tale om nogle DevOps-praksis, men fra en udviklers synspunkt. Typisk har alle ingeniører, der slutter sig til DevOps, allerede flere års administrativ erfaring på bagen. Men det betyder ikke, at der ikke er plads til bygherren her. Oftere end ikke har udviklere travlt med at rette op på "dagens næste akut kritiske fejl", og de har ikke tid til at tage et hurtigt kig på DevOps-feltet. Efter forfatterens forståelse er DevOps for det første sund fornuft. For det andet er det en mulighed for at blive mere effektiv. Hvis du er udvikler, har sund fornuft og ønsker at være mere effektiv som teamplayer, er denne rapport noget for dig.
Lad mig præsentere mig selv, jeg indrømmer fuldt ud, at der er mennesker i rummet, der ikke kender mig. Mit navn er Anton Boyko, jeg er Microsoft Azure MVP. Hvad er MVP? Dette er Model-View-Presenter. Model-View-Presenter er præcis mig.
Derudover varetager jeg i dag stillingen som løsningsarkitekt hos Ciklum. Og for nylig købte jeg mig sådan et smukt domæne, og jeg opdaterede min e-mail, som jeg plejer at vise ved præsentationer. Du kan skrive til mig på: me [hund] byokoant.pro. Du kan maile mig med spørgsmål. Jeg plejer at svare dem. Det eneste er, at jeg ikke gerne vil modtage spørgsmål på e-mail, der vedrører to emner: politik og religion. Du kan skrive til mig om alt andet på mail. Der går noget tid, vil jeg svare.
Et par ord om mig selv:
- Jeg har været i dette felt i 10 år nu.
- Jeg arbejdede hos Microsoft.
- Jeg er grundlæggeren af det ukrainske Azure-fællesskab, som vi grundlagde et sted i 2014. Og vi har det stadig og udvikler det.
- Jeg er også far til grundlæggeren af Azure-konferencen, som vi er vært for i Ukraine.
- Jeg hjælper også med at organisere Global Azure Bootcamp i Kiev.
- Som jeg sagde, er jeg en Microsoft Azure MVP.
- Jeg taler til konferencer ret ofte. Jeg elsker virkelig at tale til konferencer. I løbet af det sidste år var jeg i stand til at optræde omkring 40 gange. Hvis du kommer forbi Ukraine, Hviderusland, Polen, Bulgarien, Sverige, Danmark, Holland, Spanien eller giver eller tager et andet land i Europa, så er det meget muligt, at når du tager til en konference, der har et sky-tema i sin strøm, du kan se mig på listen over højttalere.
- Jeg er også Star Trek-fan.
Lad os tale lidt om Agenda. Vores dagsorden er meget enkel:
- Vi vil tale om, hvad DevOps er. Lad os tale om, hvorfor dette er vigtigt. Tidligere var DevOps et nøgleord, som du skrev på dit CV og straks modtog +$500 i løn. Nu skal du skrive fx blockchain i dit CV for at få +500 dollars til din løn.
- Og så, når vi forstår lidt om, hvad dette er, vil vi tale om, hvad DevOps-praksis er. Men ikke så meget i forbindelse med DevOps generelt, men om de DevOps-praksis, der kan være af interesse for udviklere. Jeg vil fortælle dig, hvorfor de kunne være interessante for dig. Jeg vil fortælle dig, hvorfor du overhovedet bør gøre dette, og hvordan det kan hjælpe dig til at opleve mindre smerte.
Et traditionelt billede, som mange mennesker viser. Det er, hvad der sker i mange projekter. Det er, når vi har udviklings- og driftsafdelinger, der understøtter vores software. Og disse afdelinger kommunikerer ikke med hinanden.
Måske, hvis du ikke var i stand til at mærke det så tydeligt i DevOps- og driftsafdelingerne, kan du tegne en analogi med Dev- og QA-afdelingerne. Der er folk, der udvikler software, og der er QA-folk, der er dårlige fra udviklernes synspunkt. For eksempel overlader jeg min vidunderlige kode til depotet, og der sidder en slyngel der returnerer denne kode til mig og siger, at din kode er dårlig.
Alt dette sker, fordi folk ikke kommunikerer med hinanden. Og de kaster nogle pakker, nogle ansøgninger til hinanden gennem en mur af misforståelser og forsøger at gøre noget med dem.
Det er netop denne mur, som DevOps-kulturen er designet til at ødelægge, dvs. tvinge folk til at kommunikere med hinanden og i det mindste forstå, hvad forskellige mennesker i projektet gør, og hvorfor deres arbejde er vigtigt.
Og når vi taler om DevOps, vil nogen fortælle dig, at DevOps er, når projektet har kontinuerlig integration; nogen vil sige, at DevOps er, hvis projektet implementerer "infrastruktur som kode"-praksis; nogen vil sige, at det første skridt til DevOps er feature branching, feature flag.
I bund og grund er alt dette sandt på sin egen måde. Men det er bare den ultimative praksis, vi har. Inden du går videre til disse praksisser, foreslår jeg, at du ser på dette dias, som viser de 3 stadier af implementering af Dev-Ops-metodologi i dit projekt, i din virksomhed.
Dette dias har også et andet uofficielt navn. Du kan søge online for at finde ud af, hvad de 3 musketerer af DevOps er. Det er muligt, at du finder denne artikel. Hvorfor 3 musketerer? Herunder står der: mennesker, processer og produkter, dvs. OPP – Porthos, Porthos og Porthos. Her er de 3 musketerer fra DevOps. Denne artikel beskriver mere detaljeret, hvorfor dette er vigtigt, og hvad det indebærer.
Når du begynder at implementere en DevOps-kultur, er det meget vigtigt, at den implementeres i følgende rækkefølge.
I første omgang skal du tale med folk. Og du skal forklare folk, hvad det er, og hvordan de kan få nogle fordele ved det.
Vores konference hedder DotNet Fest. Og som arrangørerne fortalte mig, inviterede vi primært et publikum af udviklere hertil, så jeg håber, at de fleste i hallen er involveret i udvikling.
Vi taler om mennesker, vi taler om, hvad udviklere vil gøre hver dag. Hvad ønsker de sig mest? De vil skrive noget ny kode, bruge nymodens rammer, skabe nye funktioner. Hvad ønsker udviklere mindst? Ret gamle fejl. Jeg håber, du er enig med mig. Det er, hvad udviklerne ønsker. De vil skrive nye funktioner, de ønsker ikke at rette fejl.
Antallet af fejl, som en bestemt udvikler producerer, afhænger af, hvor lige hans arme er, og hvor meget de vokser fra hans skuldre, og ikke fra hans numselommer. Men ikke desto mindre, når vi har et stort projekt, sker det nogle gange, at det er umuligt at holde styr på alt, så det ville være rart for os at bruge nogle tilgange, der vil hjælpe os med at skrive mere stabil og højere kvalitetskode.
Hvad ønsker QA'er mest? Jeg ved ikke, om de er i hallen. Det er svært for mig at sige, at jeg vil have en QA, for det har jeg aldrig været. Og ingen fornærmelse af fyrene, det vil siges, at jeg håber, jeg aldrig vil. Men ikke af den grund, at jeg anser deres arbejde for meningsløst og ubrugeligt, men fordi jeg ikke betragter mig selv som en person, der kunne udføre dette arbejde effektivt, så jeg vil ikke engang prøve at gøre det. Men efter hvad jeg forstår, er det, QA ikke kan lide mest, at gå på arbejde om morgenen, konstant at køre en form for regressionstest, træde på de samme fejl, som de rapporterede til udviklerne for 3 sprints siden og sige: "Hvornår vil du , Monsieur D 'Artagnan, ret denne fejl.' Og Monsieur D'Artagnan svarer ham: "Ja, ja, ja, jeg har allerede rettet det." Og hvordan det sker, at jeg fik rettet en fejl og lavede 5 undervejs.
De mennesker, der understøtter denne løsning i produktionen, ønsker, at denne løsning fungerer uden fejl, så de ikke skal genstarte serveren hver fredag, når alle normale mennesker går i baren. Udviklerne installeret fredag, administratorerne sidder indtil lørdag og forsøger at få denne udrulning op og rettet.
Og når man forklarer folk, at de har til formål at løse de samme problemer, kan man gå videre til at formalisere processerne. Det er meget vigtigt. Hvorfor? For når vi siger "formalisering", er det vigtigt for dig at beskrive, hvordan dine processer foregår i det mindste et sted på en serviet. Du skal forstå, at hvis du for eksempel implementerer til et QA-miljø eller et produktionsmiljø, så sker det altid i denne rækkefølge; på disse stadier kører vi for eksempel automatiske enhedstests og UI-tests. Efter indsættelsen tjekker vi, om indsættelsen gik godt eller dårligt. Men du har allerede en klar liste over handlinger, som skal gentages igen og igen, når du implementerer til produktion.
Og først når dine processer er formaliserede, begynder du at vælge produkter, der hjælper dig med at automatisere disse processer.
Desværre ser jeg det meget ofte ske omvendt. Så snart nogen hører ordet "DevOps", foreslår de straks at installere Jenkins, fordi de tror, at så snart de installerer Jenkins, vil de have DevOps. De installerede Jenkins, læste "How to"-artiklerne på Jenkins-webstedet, forsøgte at putte processer ind i disse How to-artikler, og kom så til folk og bøjede folk over og sagde, at bogen siger, at du skal gøre det på denne måde, så vi gør det på denne måde.
Det er ikke, at Jenkins er et dårligt værktøj. Jeg mener ikke at sige det på nogen måde. Men dette er kun et af produkterne. Og hvilket produkt du bruger bør være din sidste beslutning, og på ingen måde din første. Dit produkt bør ikke være drevet af implementering af kultur og tilgange. Dette er meget vigtigt at forstå, og det er derfor, jeg bruger så meget tid på dette dias og forklarer alt dette i så lang tid.
Lad os tale om DevOps-praksis generelt. Hvad er de? Hvad er forskellen? Hvordan prøver man dem? Hvorfor er de vigtige?
Den første praksis, du måske har hørt om, hedder Kontinuerlig Integration. Måske har nogen på projektet Continuous Integration (CI).
Det største problem er, at jeg oftest spørger en person: "Har du CI på projektet?" og han siger: "Ja," så når jeg spørger, hvad han laver, beskriver han for mig absolut hele automatiseringsprocessen. Dette er ikke helt rigtigt.
Faktisk er praksis med CI blot rettet mod at integrere den kode, som forskellige mennesker skriver, i en slags enkelt kodebase. Det er alt.
Sammen med CI er der normalt andre praksisser undervejs - såsom Continuous Deployment, Release Management, men det vil vi tale om senere.
CI selv fortæller os, at forskellige mennesker skriver kode, og denne kode skal løbende integreres i en enkelt kodebase.
Hvad giver det os, og hvorfor er det vigtigt? Hvis vi har DotNet, så er det godt, det er et kompileret sprog, vi kan kompilere vores applikation. Hvis det kompilerer, er dette allerede et godt tegn. Dette betyder ikke noget endnu, men det er det første gode tegn på, at vi i det mindste kan kompilere.
Så kan vi køre nogle tests, som også er en særskilt praksis. Testene er alle grønne - dette er det andet gode tegn. Men igen, det betyder ikke noget.
Men hvorfor ville du gøre dette? Alle de praksisser, som jeg vil tale om i dag, har omtrent samme værdi, dvs. omtrent de samme fordele og måles også omtrent på samme måde.
For det første giver det dig mulighed for at fremskynde leveringen. Hvordan giver dette dig mulighed for at fremskynde leveringen? Når vi laver nogle nye ændringer i vores kodebase, kan vi straks prøve at gøre noget med denne kode. Vi venter ikke til torsdag kommer, for på torsdag udgiver vi det til QA Environment, vi gør det lige her og lige her.
Jeg vil fortælle dig en trist historie fra mit liv. Det var længe siden, da jeg stadig var ung og smuk. Nu er jeg allerede ung, smuk og klog og beskeden. For noget tid siden var jeg i et projekt. Vi havde et stort team på omkring 30 udviklere. Og vi havde et stort, stort Enterprise-projekt, der udviklede sig i omkring 10 år. Og vi havde forskellige grene. I depotet havde vi en gren, hvor udviklere gik. Og der var en filial, der viste den version af koden, der er i produktion.
Produktionsgrenen var 3 måneder bagefter den filial, der var tilgængelig for udviklere. Hvad betyder det? Det betyder, at så snart jeg har en fejl et sted, der går til produktion på grund af udviklernes skyld, fordi de tillod det, og på grund af QA's fejl, fordi de så på det, så betyder det, at hvis jeg modtager en opgave til hotfix til produktion, så skal jeg rulle mine kodeændringer tilbage for 3 måneder siden. Jeg skal huske hvad jeg havde for 3 måneder siden og prøve at ordne det der.
Hvis du ikke har haft denne oplevelse endnu, kan du prøve den på dit hjemmeprojekt. Det vigtigste er, prøv det ikke på en kommerciel. Skriv et par linjer kode, glem dem i seks måneder, og kom så tilbage og prøv hurtigt at forklare, hvad disse linjer kode handler om, og hvordan du kan rette eller optimere dem. Det er en meget, meget spændende oplevelse.
Hvis vi har en Continuous Integration-praksis, så giver det os mulighed for at tjekke det med en række automatiserede værktøjer lige her og lige nu, så snart jeg har skrevet min kode. Dette giver mig måske ikke det fulde billede, men ikke desto mindre vil det i det mindste fjerne nogle af risiciene. Og hvis der er en potentiel fejl, vil jeg vide om det lige nu, det vil sige bogstaveligt talt om et par minutter. Jeg behøver ikke rulle 3 måneder tilbage. Jeg skal kun rulle 2 minutter tilbage. En god kaffemaskine når ikke engang at brygge kaffe på 2 minutter, så det er ret fedt.
Dette har den værdi, at det kan gentages gang på gang på hvert projekt, dvs. ikke kun den du har sat den op på. Du kan gentage både selve øvelsen, og selve CI vil blive gentaget for hver ny ændring, du foretager i projektet. Dette giver dig mulighed for at optimere ressourcer, fordi dit team arbejder mere effektivt. Du vil ikke længere have en situation, hvor en fejl kommer til dig fra den kode, du arbejdede med for 3 måneder siden. Du vil ikke længere have kontekstskifte, når du sidder og bruger de første to timer på at prøve at forstå, hvad der skete dengang og komme ind i essensen af konteksten, før du begynder at rette noget.
Hvordan kan vi måle succesen eller fiaskoen af denne praksis? Hvis du rapporterer til den store chef, hvad vi implementerede på CI-projektet, hører han bla bla bla. Vi implementerede det, okay, men hvorfor, hvad gav det os, hvordan måler vi det, hvor korrekt eller forkert implementerer vi det?
Den første er, at vi takket være CI kan implementere oftere og oftere, og oftere netop fordi vores kode potentielt er mere stabil. På samme måde reduceres vores tid til at finde en fejl, og tiden til at rette denne fejl reduceres netop af den grund, at vi får svar fra systemet lige her og lige nu, hvad der er galt med vores kode.
En anden praksis, vi har, er Automation Testing-praksis, som oftest følger med CI-praksis. De går hånd i hånd.
Hvad er vigtigt at forstå her? Det er vigtigt at forstå, at vores tests er forskellige. Og hver automatiseret test er rettet mod at løse sine egne problemer. Vi har fx enhedstest, der giver os mulighed for at teste et modul separat, dvs. Hvordan fungerer det i et vakuum? Det er godt.
Vi har også integrationstest, der giver os mulighed for at forstå, hvordan forskellige moduler integreres med hinanden. Det er også godt.
Vi kan have UI-automatiseringstest, der giver os mulighed for at tjekke, hvor godt arbejdet med UI'en opfylder visse krav, som kunden stiller mv.
De specifikke test, du kører, kan påvirke, hvor ofte du kører dem. Enhedsprøver er normalt skrevet korte og små. Og de kan lanceres regelmæssigt.
Hvis vi taler om UI-automatiseringstest, så er det godt, hvis dit projekt er lille. Dine UI-automatiseringstest kan tage lidt tid. Men normalt er en UI-automatiseringstest noget, der tager flere timer på et stort projekt. Og det er godt, hvis det er et par timer. Det eneste er, at det ikke nytter noget at køre dem for hver build. Det giver mening at køre dem om natten. Og når alle kom på arbejde om morgenen: både testere og udviklere, modtog de en form for rapport om, at vi kørte UI-autotesten om natten og fik disse resultater. Og her vil en times arbejde af en server, der vil kontrollere, at dit produkt opfylder nogle krav, være meget billigere end en times arbejde for den samme QA-ingeniør, selvom han er en Junior QA-ingeniør, der arbejder for mad og tak. Alligevel vil en times maskindrift være billigere. Det er derfor, det giver mening at investere i det.
Jeg har et andet projekt, som jeg har arbejdet på. Vi havde to ugers spurter på dette projekt. Projektet var stort, vigtigt for finanssektoren, og der kunne ikke begås en fejl. Og efter en to-ugers sprint blev udviklingscyklussen efterfulgt af en testproces, som tog yderligere 4 uger. Prøv at forestille dig omfanget af tragedien. Vi skriver kode i to uger, derefter gør vi det ala CodeFreeze, pakker det ind i en ny version af applikationen og ruller det ud til testere. Testere tester den i yderligere 4 uger, dvs. Mens de tester det, har vi tid til at forberede yderligere to versioner til dem. Det er en rigtig trist sag.
Og vi fortalte dem, at hvis du vil være mere produktiv, giver det mening for dig at implementere automatiseret testpraksis, fordi det er det, der sårer dig lige her, lige nu.
Øv kontinuerlig implementering. Godt, du er færdig med at bygge. Det her er allerede godt. Din kode er kompileret. Nu ville det være rart at implementere denne build på et eller andet miljø. Lad os sige i et miljø for udviklere.
Hvorfor er det vigtigt? Først kan du se på, hvor vellykket du er med selve implementeringsprocessen. Jeg har mødt projekter som dette, da jeg spørger: "Hvordan implementerer du en ny version af applikationen?", fortæller fyrene mig: "Vi samler det og pakker det ind i et zip-arkiv. Vi sender det til admin via mail. Administratoren downloader og udvider dette arkiv. Og hele kontoret begynder at bede om, at serveren vil hente den nye version."
Lad os starte med noget simpelt. For eksempel glemte de at lægge CSS i arkivet eller glemte at ændre hashtagget i java-script filnavnet. Og når vi sender en anmodning til serveren, tror browseren, at den allerede har denne java-script-fil og beslutter sig for ikke at downloade den. Og der var en gammel version, der manglede noget. Generelt kan der være mange problemer. Derfor giver praksis med Kontinuerlig Deployment dig i det mindste mulighed for at teste, hvad der ville ske, hvis du tog et rent referencebillede og uploadede det til et helt rent nyt miljø. Du kan se, hvor det fører hen.
Også når man integrerer kode mellem hinanden, dvs. mellem kommandoen giver dette dig også mulighed for at se, hvordan det ser ud på brugergrænsefladen.
Et af de problemer, der opstår, hvor der bruges meget vanilla java-script, er, at to udviklere overilet deklarerede en variabel med samme navn i vinduesobjektet. Og så, afhængigt af dit held. Hvis java-script-filen trækkes ud for det andet, vil overskrive ændringerne af den anden. Det er også meget spændende. Du kommer ind: én ting virker for én person, en anden virker ikke for en anden. Og det er "vidunderligt", når det hele kommer ud i produktion.
Den næste praksis, vi har, er praksis med Automatisk gendannelse, nemlig at rulle tilbage til den tidligere version af applikationen.
Hvorfor er dette vigtigt for udviklere? Der er stadig dem, der husker de fjerne, fjerne 90'ere, hvor computere var store og programmer var små. Og den eneste vej til webudvikling var gennem PHP. Det er ikke, at PHP er et dårligt sprog, selvom det er det.
Men problemet var anderledes. Da vi implementerede en ny version af vores php-websted, hvordan implementerede vi den så? Oftest åbnede vi Far Manager eller noget andet. Og uploadede disse filer til FTP. Og vi indså pludselig, at vi havde en lille, lille fejl, for eksempel glemte vi at sætte et semikolon eller glemte at ændre adgangskoden til databasen, og der er en adgangskode til databasen, som er på den lokale vært. Og vi beslutter os for hurtigt at oprette forbindelse til FTP og redigere filerne lige der. Det her er bare ild! Det var det, der var populært i 90'erne.
Men hvis du ikke har kigget i kalenderen, var 90'erne næsten 30 år siden. Nu sker alting lidt anderledes. Og prøv at forestille dig omfanget af tragedien, når de fortæller dig: "Vi implementerede til produktion, men noget gik galt der. Her er dit FTP-login og adgangskode, opret forbindelse til produktionen og ret det hurtigt der." Hvis du er Chuck Norris, vil dette virke. Hvis ikke, så risikerer du, at hvis du retter én fejl, vil du tjene 10 mere. Det er netop derfor, at denne praksis med at rulle tilbage til den tidligere version giver dig mulighed for at opnå meget.
Selvom noget slemt på en eller anden måde kom i prod et eller andet sted, så er det slemt, men ikke fatalt. Du kan rulle tilbage til den tidligere version, du har. Kald det en backup, hvis det er nemmere at opfatte det i den terminologi. Du kan rulle tilbage til denne tidligere version, og brugerne vil stadig være i stand til at arbejde med dit produkt, og du vil have tilstrækkelig buffertid. Du kan roligt, uden hastværk, tage alt dette og teste det lokalt, rette det og derefter uploade en ny version. Det giver virkelig mening at gøre dette.
Lad os nu prøve at kombinere de to tidligere øvelser på en eller anden måde. Vi får en tredje kaldet Release Management.
Når vi taler om Continuous Deployment i dens klassiske form, siger vi, at vi skal trække kode fra en eller anden gren fra depotet, kompilere den og implementere den. Det er godt, hvis vi har det samme miljø. Hvis vi har flere miljøer, betyder det, at vi skal trække koden hver gang, også fra samme commit. Vi vil trække det ud hver gang, vi vil bygge det hver gang, og vi vil implementere det til et nyt miljø. For det første er det tid, for at bygge et projekt, hvis du har et stort og kom fra 90'erne, så kan det tage flere timer.
Desuden er der en anden sorg. Når du bygger, selv på den samme maskine, vil du bygge de samme kilder, du har stadig ingen garanti for, at denne maskine er i samme tilstand, som den var under den sidste build.
Lad os sige, at nogen kom ind og opdaterede DotNet for dig, eller omvendt, nogen besluttede at slette noget. Og så har du kognitiv dissonans, at fra denne commit for to uger siden byggede vi en build, og alt var fint, men nu ser det ud som den samme maskine, den samme commit, den samme kode, som vi forsøger at bygge, men den virker ikke . Du vil beskæftige dig med dette i lang tid, og det er ikke et faktum, at du vil finde ud af det. I det mindste vil du ødelægge dine nerver meget.
Derfor foreslår Release Management-praksis at introducere en ekstra abstraktion kaldet et artefaktlager eller galleri eller bibliotek. Du kan kalde det hvad du vil.
Hovedideen er, at så snart vi har en form for commit der, f.eks. i en filial, som vi er klar til at implementere til vores forskellige miljøer, samler vi ansøgninger fra denne commit og alt, hvad vi har brug for til denne applikation, vi pakker det ind i et zip-arkiv og gem det på et pålideligt lager. Og fra dette lager kan vi få dette zip-arkiv til enhver tid.
Så tager vi det og implementerer det automatisk til udviklermiljøet. Vi kører der, og hvis alt er godt, så sætter vi ind på etapen. Hvis alt er godt, så implementerer vi det samme arkiv til produktion, de samme binære filer, kompileret nøjagtigt én gang.
Derudover, når vi har et galleri som dette, hjælper det os også med at adressere de risici, som vi adresserede på det sidste slide, da vi talte om tilbagerulning til den tidligere version. Hvis du ved et uheld har implementeret noget forkert, kan du altid tage en hvilken som helst anden tidligere version fra dette galleri og fjerne den til disse miljøer på samme måde. Dette giver dig mulighed for nemt at rulle tilbage til den tidligere version, hvis noget går galt.
Der er en anden god praksis. Du og jeg forstår alle, at når vi ruller vores applikationer tilbage til en tidligere version, kan det betyde, at vi også har brug for infrastrukturen fra den tidligere version.
Når vi taler om virtuel infrastruktur, tror mange mennesker, at det er noget, som administratorer sætter op. Og hvis du for eksempel har brug for at få en ny server, som du vil teste en ny version af din applikation på, så skal du skrive en billet til admins eller devops. Devops vil tage 3 uger for dette. Og efter 3 uger vil de fortælle dig, at vi har installeret en virtuel maskine til dig, med én kerne, to gigabyte RAM og en Windows-server uden DotNet. Du siger: "Men jeg ville have DotNet." De: "Ok, kom tilbage om 3 uger."
Tanken er, at du ved at bruge Infrastruktur som kodepraksis kan behandle din virtuelle infrastruktur som blot endnu en ressource.
Måske, hvis nogen af jer udvikler applikationer på DotNet, har du måske hørt om et bibliotek kaldet Entity Framework. Og du har måske endda hørt, at Entity Framework er en af de tilgange, som Microsoft aktivt presser på. For at arbejde med en database er dette en tilgang kaldet Code First. Det er, når du beskriver i kode, hvordan du vil have din database til at se ud. Og så implementerer du applikationen. Den forbinder til databasen, den bestemmer selv hvilke tabeller der er der, og hvilke tabeller der ikke er, og opretter alt hvad du har brug for.
Точно так же вы можете делать с вашей инфраструктурой. Нет никакой разницы между тем нужна ли вам для проекта база данных или нужен для проекта Windows-сервер. Это всего лишь ресурс. И вы можете автоматизировать создание этого ресурса, вы можете автоматизировать настройку этого ресурса. Соответственно, каждый раз, когда вы захотите протестировать какую-то новую концепцию, какой-то новый подход, вам не надо будет писать тикет девопсам, вы сможете взять и просто развернуть сами себе из уже готовых шаблонов, из готовых скриптов изолированную инфраструктуру и провести там все ваши эксперименты. Можете удалить это, получить какие-то результаты и отраппортовать об этом дальше.
Den næste praksis, som også findes og også er vigtig, men som de færreste bruger, er Application Performance Monitoring.
Jeg ville kun sige én ting om Application Performance Monitoring. Hvad er vigtigst ved denne praksis? Dette er, hvad Application Performance Monitoring er omtrent det samme som at reparere en lejlighed. Dette er ikke en endelig tilstand, det er en proces. Du skal gøre det regelmæssigt.
På en god måde ville det være godt at udføre Application Performance Monitoring på næsten alle build, selvom det, som du forstår, ikke altid er muligt. Men det skal som minimum udføres for hver udgivelse.
Hvorfor er det vigtigt? For hvis du pludselig oplever et fald i ydeevnen, så skal du klart forstå hvorfor. Hvis dit hold f.eks. har to-ugers sprints, så skal du mindst én gang hver anden uge implementere din applikation til en separat server, hvor du har en klart fast processor, RAM, diske osv. Og køre de samme præstationstests . Du får resultatet. Se, hvordan det har ændret sig fra den forrige sprint.
Og hvis du finder ud af, at nedskrivningen gik kraftigt et sted, vil det betyde, at det kun var på grund af de ændringer, der er sket i løbet af de seneste to uger. Dette vil give dig mulighed for at identificere og løse problemet meget hurtigere. Og igen, det er nogenlunde de samme målinger, som du kan måle, hvor vellykket du gjorde det.
Den næste praksis, vi har, er Configuration Management-praksis. Det er de færreste, der tager dette alvorligt. Men tro mig, dette er faktisk en meget alvorlig ting.
Der var en sjov historie for nylig. Fyrene kom til mig og sagde: "Hjælp os med at udføre en sikkerhedsrevision af vores ansøgning." Vi kiggede på koden sammen i lang tid, de fortalte mig om applikationen, tegnede diagrammer. Og plus eller minus alt var logisk, forståeligt, sikkert, men der var et MEN! De havde konfigurationsfiler i deres kildekontrol, inklusive dem fra produktion med IP-databasen, med logins og adgangskoder til at forbinde til disse databaser osv.
Og jeg siger: "Gunner, okay, I har lukket jeres produktionsmiljø med en firewall, men det faktum, at I har login og adgangskode til produktionsdatabasen lige i kildekontrollen, og enhver udvikler kan læse det, er allerede en stor sikkerhedsrisiko. . Og uanset hvor supersikker din applikation er fra et kodesynspunkt, hvis du lader den være i kildekontrol, så vil du aldrig bestå nogen revision nogen steder." Det er det, jeg taler om.
Konfigurationsstyring. Vi kan have forskellige konfigurationer i forskellige miljøer. For eksempel kan vi have forskellige logins og adgangskoder til databaser til QA, demo, produktionsmiljø mv.
Denne konfiguration kan også automatiseres. Den skal altid være adskilt fra selve applikationen. Hvorfor? Fordi du byggede applikationen én gang, og så er applikationen ligeglad med, om du opretter forbindelse til SQL-serveren via sådan og sådan en IP eller sådan og sådan en IP, burde det fungere på samme måde. Derfor, hvis en af jer pludselig stadig hardkoder forbindelsesstrengen i koden, så husk, at jeg finder dig og straffer dig, hvis du befinder dig i det samme projekt som mig. Denne placeres altid i en separat konfiguration, for eksempel i web.config.
Og denne konfiguration administreres allerede separat, dvs. det er præcis det øjeblik, hvor en udvikler og en administrator kan komme og sidde i samme rum. Og udvikleren kan sige: "Se, her er de binære filer i min applikation. De arbejder. Applikationen skal have en database for at fungere. Her ved siden af de binære filer er der en fil. I denne fil er dette felt ansvarlig for login, dette er for adgangskoden, dette er for IP'en. Implementer det hvor som helst." Og det er enkelt og overskueligt for administratoren. Han kan implementere det virkelig hvor som helst ved at administrere denne konfiguration.
Og den sidste praksis, som jeg gerne vil tale om, er en praksis, der er meget, meget relateret til skyer. Og det giver maksimal effekt, hvis du arbejder i skyen. Dette er automatisk fjernelse af dit miljø.
Jeg ved, at der er flere personer på denne konference fra de teams, jeg arbejder med. Og med alle de teams, jeg arbejder med, bruger vi denne praksis.
Hvorfor? Selvfølgelig ville det være fantastisk, hvis hver udvikler havde en virtuel maskine, der ville arbejde 24/7. Men måske er dette en nyhed for dig, måske var du ikke opmærksom, men udvikleren selv arbejder ikke 24/7. En udvikler arbejder normalt 8 timer om dagen. Selvom han kommer tidligt på arbejde, spiser han en stor frokost, hvor han går i fitnesscenteret. Lad det være 12 timer om dagen, når udvikleren rent faktisk bruger disse ressourcer. I henhold til vores lovgivning har vi 5 ud af 7 dage på en uge, der anses for at være arbejdsdage.
Derfor bør denne maskine på hverdage ikke arbejde 24 timer, men kun 12, og i weekenden bør denne maskine slet ikke fungere. Det ser ud til, at alt er meget enkelt, men hvad er vigtigt at sige her? Ved at implementere denne enkle praksis på denne grundlæggende tidsplan giver den dig mulighed for at reducere omkostningerne ved at vedligeholde disse miljøer med 70 %, dvs. du tog prisen på din dev, QA, demo, miljø og dividerede den med 3.
Spørgsmålet er, hvad man skal gøre med resten af pengene? For eksempel bør udviklerne købe ReSharper, hvis de ikke allerede har gjort det. Eller hold et cocktailparty. Hvis du tidligere havde ét miljø, hvor både dev og QA græssede, og det er det, kan du nu lave 3 forskellige, der vil blive isoleret, og folk vil ikke forstyrre hinanden.
Med hensyn til dias med kontinuerlig præstationsmåling, hvordan kan vi sammenligne præstationer, hvis vi havde 1 poster i databasen i projektet, to måneder senere er der en million? Hvordan forstår man hvorfor og hvad er meningen med at måle ydeevne?
Dette er et godt spørgsmål, for du bør altid måle ydeevne på de samme ressourcer. Det vil sige, at du udruller ny kode, du måler ydeevne på den nye kode. For eksempel skal du teste forskellige ydelsesscenarier, lad os sige, at du vil teste, hvordan applikationen klarer sig ved en let belastning, hvor der er 1 brugere og databasestørrelsen er 000 gigabyte. Du målte det og fik tallene. Dernæst tager vi et andet scenarie. For eksempel 5 brugere, databasestørrelse 5 terabyte. Vi modtog resultaterne og huskede dem.
Hvad er vigtigt her? Det vigtige her er, at afhængigt af scenariet, mængden af data, antallet af samtidige brugere osv., kan du løbe ind i visse grænser. For eksempel til grænsen for et netværkskort, eller til grænsen for en harddisk, eller til grænsen for processorkapacitet. Det er det, der er vigtigt for dig at forstå. I forskellige scenarier løber du ind i visse grænser. Og du skal forstå tallene, når du rammer dem.
Taler vi om måling af ydeevne i et særligt testmiljø? Det vil sige, dette er ikke produktion?
Ja, det er ikke produktion, det er et testmiljø, som altid er det samme, så man kan sammenligne det med tidligere målinger.
Forstået tak!
Hvis der ikke er spørgsmål, tror jeg, vi kan afslutte. Tak skal du have!
Kilde: www.habr.com