Bästa DevOps-praxis för utvecklare. Anton Boyko (2017)

Rapporten kommer att tala om några DevOps-praxis, men från en utvecklares synvinkel. Vanligtvis har alla ingenjörer som går med i DevOps redan flera års administrativ erfarenhet bakom bältet. Men det betyder inte att det inte finns plats för utvecklaren här. Oftare än inte är utvecklare upptagna med att fixa "dagens nästa akut kritiska bugg", och de har inte tid att ens ta en snabb titt på DevOps-fältet. Enligt författarens förståelse är DevOps för det första sunt förnuft. För det andra är det en möjlighet att bli mer effektiv. Om du är en utvecklare, har sunt förnuft och vill bli mer effektiv som lagspelare, är den här rapporten för dig.

Låt mig presentera mig själv, jag erkänner fullt ut att det finns människor i rummet som inte känner mig. Jag heter Anton Boyko, jag är en Microsoft Azure MVP. Vad är MVP? Detta är Model-View-Presenter. Model-View-Presenter är precis jag.

Dessutom innehar jag för närvarande tjänsten som lösningsarkitekt på Ciklum. Och alldeles nyligen köpte jag mig en så vacker domän, och jag uppdaterade min e-post, som jag brukar visa vid presentationer. Du kan skriva till mig på: me [hund] byokoant.pro. Du kan maila mig med frågor. Jag brukar svara på dem. Det enda är att jag inte skulle vilja få frågor via mejl som rör två ämnen: politik och religion. Du kan skriva till mig om allt annat via e-post. Det kommer att gå en tid ska jag svara.

Några ord om mig själv:

• Jag har varit inom detta område i 10 år nu.
• Jag jobbade på Microsoft.
• Jag är grundaren till den ukrainska Azure-gemenskapen, som vi grundade någonstans 2014. Och vi har det fortfarande och utvecklar det.
• Jag är också far till grundaren av Azure-konferensen, som vi är värd för i Ukraina.
• Jag hjälper också till att organisera Global Azure Bootcamp i Kiev.
• Som jag sa, jag är en Microsoft Azure MVP.
• Jag talar på konferenser ganska ofta. Jag älskar verkligen att tala på konferenser. Under det senaste året har jag kunnat uppträda cirka 40 gånger. Om du passerar Ukraina, Vitryssland, Polen, Bulgarien, Sverige, Danmark, Nederländerna, Spanien eller ger eller tar ett annat land i Europa, så är det mycket möjligt att när du går på en konferens som har ett molntema i sin ström, du kanske ser mig på talarlistan.
• Jag är också ett Star Trek-fan.

Låt oss prata lite om Agenda. Vår agenda är väldigt enkel:

• Vi ska prata om vad DevOps är. Låt oss prata om varför detta är viktigt. Tidigare var DevOps ett nyckelord som du skrev på ditt CV och direkt fick +$500 i lön. Nu behöver du skriva till exempel blockchain i ditt CV för att få +500 dollar till din lön.
• Och sedan, när vi förstår lite om vad detta är, kommer vi att prata om vad DevOps-praxis är. Men inte så mycket i samband med DevOps i allmänhet, utan om de DevOps-praxis som kan vara av intresse för utvecklare. Jag ska berätta varför de kan vara av intresse för dig. Jag ska berätta varför du överhuvudtaget bör göra detta och hur det kan hjälpa dig att uppleva mindre smärta.

En traditionell bild som många visar. Det är vad som händer i många projekt. Det är då vi har utvecklings- och driftavdelningar som stödjer vår mjukvara. Och dessa avdelningar kommunicerar inte med varandra.

Kanske, om du inte kunde känna det så tydligt i DevOps- och operationsavdelningarna, kan du dra en analogi med Dev- och QA-avdelningarna. Det finns människor som utvecklar mjukvara och det finns QA-folk som är dåliga ur utvecklarnas synvinkel. Till exempel, jag överlåter min underbara kod till förvaret, och det sitter någon skurk som returnerar den här koden till mig och säger att din kod är dålig.

Allt detta händer för att människor inte kommunicerar med varandra. Och de kastar några paket, någon ansökan till varandra genom någon vägg av missförstånd och försöker göra något med dem.

Det är just denna vägg som DevOps-kulturen är designad för att förstöra, d.v.s. tvinga människor att kommunicera med varandra och åtminstone förstå vad olika personer i projektet gör och varför deras arbete är viktigt.

Och när vi pratar om DevOps kommer någon att berätta för dig att DevOps är när projektet har kontinuerlig integration; någon kommer att säga att DevOps är om projektet implementerar "infrastruktur som kod"-praxis; någon kommer att säga att det första steget till DevOps är funktionsförgrening, funktionsflaggor.

I huvudsak är allt detta sant på sitt sätt. Men det här är bara de ultimata metoderna vi har. Innan du går vidare till dessa metoder föreslår jag att du tittar på den här bilden, som visar de tre stegen för att implementera Dev-Ops-metodologin i ditt projekt, i ditt företag.

Den här bilden har också ett andra inofficiellt namn. Du kan söka online för att ta reda på vad de 3 musketörerna i DevOps är. Det är möjligt att du hittar den här artikeln. Varför 3 musketörer? Nedan står det: människor, processer och produkter, d.v.s. PPP – Porthos, Porthos och Porthos. Här är de 3 musketörerna från DevOps. Den här artikeln beskriver mer i detalj varför detta är viktigt och vad det innebär.

När du börjar implementera en DevOps-kultur är det mycket viktigt att den implementeras i följande ordning.

Till en början måste du prata med folk. Och du måste förklara för folk vad det är och hur de kan få några fördelar av det.

Vår konferens heter DotNet Fest. Och som arrangörerna sa till mig bjöd vi framför allt hit en publik av utvecklare, så jag hoppas att de flesta i hallen är engagerade i utvecklingen.

Vi kommer att prata om människor, vi kommer att prata om vad utvecklare vill göra varje dag. Vad vill de mest? De vill skriva lite ny kod, använda nymodiga ramverk, skapa nya funktioner. Vad vill utvecklare minst ha? Fixa gamla buggar. Jag hoppas att du håller med mig. Detta är vad utvecklarna vill ha. De vill skriva nya funktioner, de vill inte fixa buggar.

Antalet buggar som en viss utvecklare producerar beror på hur raka hans armar är och hur mycket de växer från hans axlar, och inte från hans rumpfickor. Men ändå, när vi har ett stort projekt, händer det ibland att det är omöjligt att hålla reda på allt, så det skulle vara trevligt för oss att använda några metoder som hjälper oss att skriva mer stabil kod med högre kvalitet.

Vad vill QA mest? Jag vet inte om de är i hallen. Det är svårt för mig att säga att jag vill ha en QA, för jag har aldrig varit det. Och inget illa vid killarna, det kommer att sägas att jag hoppas att jag aldrig kommer att göra det. Men inte av den anledningen att jag anser att deras arbete är meningslöst och värdelöst, utan för att jag inte anser mig själv vara en person som skulle kunna utföra detta arbete effektivt, så jag kommer inte ens försöka göra det. Men vad jag förstår, vad QA inte gillar mest är att jobba på morgonen, ständigt köra någon form av regressionstest, trampa på samma buggar som de rapporterade till utvecklarna för 3 sprints sedan och säga: "När kommer du , Monsieur D 'Artagnan, fixa detta fel.' Och Monsieur D'Artagnan svarar honom: "Ja, ja, ja, jag har redan fixat det." Och hur det kommer sig att jag fixade en bugg och gjorde 5 på vägen.

De som stödjer denna lösning i produktionen vill att den här lösningen ska fungera utan buggar, så att de inte behöver starta om servern varje fredag, när alla normala människor går till baren. Utvecklarna som distribuerades på fredagen, administratörerna sitter tills lördag och försöker få upp den här distributionen och fixa den.

Och när du förklarar för människor att de syftar till att lösa samma problem, kan du gå vidare till att formalisera processerna. Det är väldigt viktigt. Varför? För när vi säger "formalisering" är det viktigt för dig att beskriva hur dina processer sker åtminstone någonstans på en servett. Du måste förstå att om du till exempel distribuerar till en QA-miljö eller en produktionsmiljö, så sker det alltid i denna ordning, i dessa skeden kör vi till exempel automatiska enhetstester och UI-tester. Efter utplaceringen kontrollerar vi om utplaceringen gick bra eller dåligt. Men du har redan en tydlig lista över åtgärder som måste upprepas om och om igen när du distribuerar till produktion.

Och först när dina processer är formaliserade börjar du välja produkter som hjälper dig att automatisera dessa processer.

Tyvärr ser jag väldigt ofta detta hända omvänt. Så fort någon hör ordet "DevOps" föreslår de omedelbart att installera Jenkins, eftersom de tror att så fort de installerar Jenkins kommer de att ha DevOps. De installerade Jenkins, läste "Hur man"-artiklarna på Jenkins webbplats, försökte stoppa in processer i dessa How to-artiklar, och kom sedan till folk och böjde folk över sig och sa att boken säger att man måste göra på det här sättet, så vi gör på det här sättet.

Det är inte så att Jenkins är ett dåligt verktyg. Jag menar inte att säga det på något sätt. Men det här är bara en av produkterna. Och vilken produkt du använder bör vara ditt sista beslut, och inte på något sätt ditt första. Din produkt bör inte drivas av implementeringen av kultur och tillvägagångssätt. Detta är väldigt viktigt att förstå, och det är därför jag spenderar så mycket tid på den här bilden och förklarar allt detta så länge.

Låt oss prata om DevOps-praxis i allmänhet. Vad är dem? Vad är skillnaden? Hur provar man dem? Varför är de viktiga?

Den första övningen du kanske har hört talas om kallas kontinuerlig integration. Kanske har någon i projektet Continuous Integration (CI).

Det största problemet är att jag oftast frågar en person: "Har du CI på projektet?" och han säger: "Ja", sedan när jag frågar vad han gör, beskriver han för mig absolut hela automatiseringsprocessen. Detta är inte helt sant.

Faktum är att utövandet av CI bara syftar till att integrera koden som olika människor skriver till någon slags enda kodbas. Det är allt.

Tillsammans med CI finns det vanligtvis andra metoder längs vägen - som kontinuerlig driftsättning, releasehantering, men vi kommer att prata om det senare.

CI själv berättar för oss att olika personer skriver kod och denna kod måste kontinuerligt integreras i en enda kodbas.

Vad ger detta oss och varför är det viktigt? Om vi ​​har DotNet så är det bra, det är ett kompilerat språk, vi kan kompilera vår applikation. Om det kompileras är detta redan ett gott tecken. Det här betyder ingenting än, men det är det första goda tecknet på att vi åtminstone kan kompilera.

Sedan kan vi köra några tester, vilket också är en separat praxis. Alla tester är gröna – detta är det andra goda tecknet. Men återigen, detta betyder ingenting.

Men varför skulle du göra det här? Alla metoder som jag kommer att prata om idag har ungefär samma värde, dvs ungefär samma fördelar och mäts också ungefär på samma sätt.

För det första låter det dig påskynda leveransen. Hur gör detta att du kan påskynda leveransen? När vi gör några nya ändringar i vår kodbas kan vi omedelbart försöka göra något med den här koden. Vi väntar inte tills torsdagen kommer för på torsdag släpper vi den till QA Environment, vi gör det här och precis här.

Jag ska berätta en sorglig historia från mitt liv. Det var länge sedan, när jag fortfarande var ung och snygg. Nu är jag redan ung, vacker och smart och blygsam. För en tid sedan var jag i ett projekt. Vi hade ett stort team på cirka 30 utvecklare. Och vi hade ett stort, stort Enterprise-projekt som utvecklades i cirka 10 år. Och vi hade olika grenar. I förvaret hade vi en gren där utvecklare gick. Och det fanns en gren som visade versionen av koden som är i produktion.

Produktionsgrenen låg tre månader efter den filial som var tillgänglig för utvecklare. Vad betyder det här? Det betyder att så fort jag har en bugg någonstans som går till produktion på grund av utvecklarnas fel, för att de tillät det, och på grund av QA:s fel, för att de tittade på det, så betyder det att om jag får en uppgift för snabbkorrigering för produktion, då måste jag återställa mina kodändringar för 3 månader sedan. Jag måste komma ihåg vad jag hade för 3 månader sedan och försöka fixa det där.

Om du inte har haft den här upplevelsen än kan du prova den på ditt hemprojekt. Huvudsaken är, försök inte på en kommersiell. Skriv ett par rader kod, glöm dem i sex månader och kom sedan tillbaka och försök snabbt förklara vad de kodraderna handlar om och hur du kan fixa eller optimera dem. Det är en väldigt, väldigt spännande upplevelse.

Om vi ​​har en praxis för kontinuerlig integration, så tillåter detta oss att kontrollera det med ett antal automatiserade verktyg här och just nu, så snart jag har skrivit min kod. Detta kanske inte ger mig hela bilden, men ändå kommer det att ta bort åtminstone några av riskerna. Och om det finns någon potentiell bugg kommer jag att veta om det just nu, det vill säga bokstavligen inom ett par minuter. Jag behöver inte gå tillbaka tre månader. Jag behöver bara rulla tillbaka 3 minuter. En bra kaffemaskin hinner inte ens brygga kaffe på 2 minuter, så det är ganska coolt.

Detta har värdet att det kan upprepas gång på gång på varje projekt, d.v.s. inte bara den du ställer in den på. Du kan upprepa både själva övningen och CI själv kommer att upprepas för varje ny förändring du gör i projektet. Detta gör att du kan optimera resurser eftersom ditt team arbetar mer effektivt. Du kommer inte längre att ha en situation där en bugg kommer till dig från koden du arbetade med för 3 månader sedan. Du kommer inte längre att ha kontextbyte när du sitter och ägnar de första två timmarna åt att försöka förstå vad som hände då och komma in i sammanhangets essens innan du börjar rätta till något.

Hur kan vi mäta framgången eller misslyckandet med denna praxis? Om du rapporterar till den stora chefen vad vi implementerade på CI-projektet så hör han bla bla bla. Vi implementerade det, okej, men varför, vad gav det oss, hur mäter vi det, hur korrekt eller felaktigt implementerar vi det?

Den första är att vi tack vare CI kan distribuera allt oftare, och oftare just för att vår kod potentiellt är mer stabil. På samma sätt minskar vår tid för att hitta ett fel och tiden för att rätta detta fel minskar just av den anledningen att vi får svar från systemet just här och just nu, vad som är fel på vår kod.

En annan praxis vi har är praxis Automation Testing, som oftast följer med CI-praxis. De går hand i hand.

Vad är viktigt att förstå här? Det är viktigt att förstå att våra tester är olika. Och varje automatiserat test syftar till att lösa sina egna problem. Vi har till exempel enhetstester som gör att vi kan testa en modul separat, d.v.s. Hur fungerar det i ett vakuum? Det här är bra.

Vi har även integrationstester som gör att vi kan förstå hur olika moduler integreras med varandra. Det är också bra.

Vi kan ha UI-automatiseringstester som gör att vi kan kontrollera hur väl arbetet med UI uppfyller vissa krav som kunden ställer osv.

De specifika testerna du kör kan påverka hur ofta du kör dem. Enhetsprov skrivs vanligtvis korta och små. Och de kan lanseras regelbundet.

Om vi ​​pratar om UI-automatiseringstester är det bra om ditt projekt är litet. Dina UI-automatiseringstester kan ta lite tid. Men vanligtvis är ett UI-automatiseringstest något som tar flera timmar på ett stort projekt. Och det är bra om det är några timmar. Det enda är att det inte är någon idé att köra dem för varje byggnad. Det är vettigt att köra dem på natten. Och när alla kom till jobbet på morgonen: både testare och utvecklare fick de någon form av rapport om att vi körde UI-autotestet på natten och fick dessa resultat. Och här kommer en timmes arbete av en server som kontrollerar att din produkt uppfyller vissa krav att vara mycket billigare än en timmes arbete för samma QA-ingenjör, även om han är en Junior QA-ingenjör som jobbar för mat och tack. Samtidigt blir en timmes maskindrift billigare. Det är därför det är vettigt att investera i det.

Jag har ett annat projekt som jag har jobbat med. Vi hade två veckors sprint på det här projektet. Projektet var stort, viktigt för finanssektorn och ett misstag kunde inte göras. Och efter en två veckor lång sprint följdes utvecklingscykeln av en testprocess, som tog ytterligare 4 veckor. Försök att föreställa dig omfattningen av tragedin. Vi skriver kod i två veckor, sedan gör vi det ala CodeFreeze, paketerar det i en ny version av applikationen och rullar ut det till testare. Testare testar den i ytterligare 4 veckor, d.v.s. Medan de testar det har vi tid att förbereda ytterligare två versioner för dem. Det här är ett riktigt tråkigt fall.

Och vi sa till dem att om du vill bli mer produktiv, är det vettigt för dig att implementera automatiserade testmetoder, eftersom det är detta som skadar dig just här, just nu.

Öva på kontinuerlig implementering. Bra, du har byggt klart. Det här är redan bra. Din kod har kompilerats. Nu skulle det vara trevligt att distribuera den här byggnaden på någon miljö. Låt oss säga i en miljö för utvecklare.

Varför är det viktigt? Först kan du titta på hur framgångsrik du är med själva distributionsprocessen. Jag har mött sådana här projekt, när jag frågar: "Hur distribuerar du en ny version av applikationen?", säger killarna till mig: "Vi sätter ihop det och packar det i ett zip-arkiv. Vi skickar det till administratören via mail. Administratören laddar ner och utökar detta arkiv. Och hela kontoret börjar be att servern ska hämta den nya versionen.”

Låt oss börja med något enkelt. Till exempel glömde de att lägga in CSS i arkivet eller glömde att ändra hashtaggen i java-script-filnamnet. Och när vi gör en begäran till servern tror webbläsaren att den redan har denna java-script-fil och bestämmer sig för att inte ladda ner den. Och det fanns en gammal version, något saknades. Generellt kan det vara många problem. Därför låter praxisen med kontinuerlig driftsättning dig åtminstone testa vad som skulle hända om du tog en ren referensbild och laddade upp den till en helt ren ny miljö. Du kan se vart detta leder.

Dessutom, när man integrerar kod mellan varandra, dvs. mellan kommandot låter detta dig också se hur det ser ut i användargränssnittet.

Ett av problemen som uppstår när mycket vanilla java-script används är att två utvecklare hastigt deklarerat en variabel med samma namn i fönsterobjektet. Och sedan, beroende på din tur. Vars java-script-fil dras ut tvåa kommer att skriva över ändringarna av den andra. Det är också väldigt spännande. Du kommer in: en sak fungerar för en person, en annan fungerar inte för en annan. Och det är "underbart" när allt kommer ut i produktion.

Nästa praxis som vi har är praxis med automatisk återställning, nämligen att rulla tillbaka till den tidigare versionen av applikationen.

Varför är detta viktigt för utvecklare? Det finns fortfarande de som minns det avlägsna, avlägsna 90-talet, då datorer var stora och program var små. Och det enda sättet till webbutveckling var genom PHP. Det är inte så att PHP är ett dåligt språk, även om det är det.

Men problemet var ett annat. När vi distribuerade en ny version av vår php-webbplats, hur implementerade vi den? Oftast öppnade vi Far Manager eller något annat. Och laddade upp dessa filer till FTP. Och vi insåg plötsligt att vi hade någon liten, liten bugg, till exempel glömde vi att sätta ett semikolon eller glömde att ändra lösenordet för databasen, och det finns ett lösenord för databasen, som finns på den lokala värden. Och vi bestämmer oss för att snabbt ansluta till FTP och redigera filerna där. Det här är bara eld! Det var detta som var populärt på 90-talet.

Men, om du inte har tittat på kalendern så var 90-talet nästan 30 år sedan. Nu händer allt lite annorlunda. Och försök att föreställa dig omfattningen av tragedin när de säger till dig: "Vi distribuerade till produktion, men något gick fel där. Här är din FTP-inloggning och lösenord, anslut till produktionen och fixa det snabbt där." Om du är Chuck Norris kommer det här att fungera. Om inte, riskerar du att om du fixar en bugg kommer du att göra 10 till. Det är just därför som denna praxis att rulla tillbaka till den tidigare versionen gör att du kan uppnå mycket.

Även om något dåligt på något sätt hamnat i prod någonstans, så är det dåligt, men inte dödligt. Du kan gå tillbaka till den tidigare versionen du har. Kalla det en backup, om det är lättare att uppfatta det i den terminologin. Du kan återgå till den tidigare versionen och användare kommer fortfarande att kunna arbeta med din produkt och du kommer att ha tillräcklig bufferttid. Du kan lugnt, utan brådska, ta allt detta och testa det lokalt, fixa det och sedan ladda upp en ny version. Det är verkligen vettigt att göra detta.

Låt oss nu försöka kombinera de två tidigare metoderna på något sätt. Vi kommer att få en tredje som heter Release Management.

När vi talar om Continuous Deployment i dess klassiska form, säger vi att vi måste hämta kod från någon gren från förvaret, kompilera den och distribuera den. Det är bra om vi har samma miljö. Om vi ​​har flera miljöer betyder det att vi måste dra koden varje gång, även från samma commit. Vi kommer att dra ut det varje gång, vi kommer att bygga det varje gång och vi kommer att distribuera det till en ny miljö. För det första är det här dags, för att bygga ett projekt, om du har ett stort och kom från 90-talet, kan det ta flera timmar.

Dessutom finns det en annan sorg. När du bygger, även på samma maskin, kommer du att bygga samma källor, du har fortfarande ingen garanti för att den här maskinen är i samma tillstånd som den var under förra bygget.

Låt oss säga att någon kom in och uppdaterade DotNet åt dig eller omvänt, någon bestämde sig för att ta bort något. Och sedan har du kognitiv dissonans att från den här commit för två veckor sedan byggde vi ett bygge och allt var bra, men nu verkar det som samma maskin, samma commit, samma kod som vi försöker bygga, men det fungerar inte . Du kommer att ta itu med detta under lång tid och det är inte ett faktum att du kommer att ta reda på det. Åtminstone kommer du att förstöra dina nerver mycket.

Därför föreslår Release Management praxis att införa en extra abstraktion som kallas ett artefaktförråd eller galleri eller bibliotek. Du kan kalla det vad du vill.

Huvudtanken är att så fort vi har någon form av commit där, säg, i en gren som vi är redo att distribuera till våra olika miljöer, samlar vi in ​​ansökningar från denna commit och allt vi behöver för denna applikation, vi packar det i ett zip-arkiv och spara det i någon pålitlig lagring. Och från denna lagring kan vi hämta detta zip-arkiv när som helst.

Sedan tar vi det och distribuerar det automatiskt till utvecklarmiljön. Vi tävlar där, och om allt är bra, så ställer vi in ​​till scenen. Om allt är bra, distribuerar vi samma arkiv till produktion, samma binärfiler, kompilerade exakt en gång.

Dessutom, när vi har ett sådant här galleri, hjälper det oss också att ta itu med de risker som vi tog upp på förra bilden när vi pratade om återställning till den tidigare versionen. Om du av misstag har distribuerat något fel kan du alltid ta vilken annan tidigare version som helst från det här galleriet och avinstallera den till dessa miljöer på samma sätt. Detta gör att du enkelt kan gå tillbaka till den tidigare versionen om något går fel.

Det finns en annan bra praxis. Du och jag förstår alla att när vi rullar tillbaka våra applikationer till en tidigare version kan det innebära att vi också behöver infrastrukturen från den tidigare versionen.

När vi pratar om virtuell infrastruktur tror många att detta är något som administratörer sätter upp. Och om du behöver, till exempel, skaffa en ny server som du vill testa en ny version av din applikation på, måste du skriva en biljett till administratörerna eller devops. Devops kommer att ta 3 veckor för detta. Och efter 3 veckor kommer de att berätta att vi har installerat en virtuell maskin åt dig, med en kärna, två gigabyte RAM och en Windows-server utan DotNet. Du säger: "Men jag ville ha DotNet." De: "Ok, kom tillbaka om 3 veckor."

Tanken är att genom att använda Infrastructure som kodpraxis kan du behandla din virtuella infrastruktur som bara en annan resurs.

Kanske, om någon av er utvecklar applikationer på DotNet, kanske ni har hört talas om ett bibliotek som heter Entity Framework. Och du kanske till och med har hört att Entity Framework är ett av de tillvägagångssätt som Microsoft aktivt driver. För att arbeta med en databas är detta ett tillvägagångssätt som kallas Code First. Det är då du beskriver i kod hur du vill att din databas ska se ut. Och sedan distribuerar du applikationen. Den ansluter till databasen, den bestämmer själv vilka tabeller som finns där och vilka tabeller som inte finns, och skapar allt du behöver.

Du kan göra samma sak med din infrastruktur. Det är ingen skillnad mellan om du behöver en databas för ett projekt eller om du behöver en Windows-server för ett projekt. Det är bara en resurs. Och du kan automatisera skapandet av den här resursen, du kan automatisera konfigurationen av den här resursen. Följaktligen, varje gång du vill testa något nytt koncept, något nytt tillvägagångssätt, behöver du inte skriva en biljett till devops, du kan helt enkelt distribuera en isolerad infrastruktur för dig själv från färdiga mallar, från färdiga skript och implementera den där alla dina experiment. Du kan ta bort detta, få några resultat och rapportera vidare om det.

Nästa praxis, som också finns och också är viktig, men som få människor använder, är Application Performance Monitoring.

Jag ville bara säga en sak om Application Performance Monitoring. Vad är viktigast med denna praxis? Det här är vad Application Performance Monitoring är ungefär detsamma som att reparera en lägenhet. Detta är inte ett sluttillstånd, det är en process. Du måste göra det regelbundet.

På ett bra sätt skulle det vara bra att utföra övervakning av applikationsprestanda på nästan varje byggnad, även om det, som du förstår, inte alltid är möjligt. Men det måste åtminstone utföras för varje release.

Varför är det viktigt? För om du plötsligt upplever en nedgång i prestanda, då måste du tydligt förstå varför. Om ditt team har, säg två veckors sprints, bör du minst en gång varannan vecka distribuera din applikation till någon separat server, där du har en tydligt fixerad processor, RAM, diskar, etc. Och köra samma prestandatest . Du får resultatet. Se hur det har förändrats från föregående sprint.

Och om du får reda på att neddragningen gick kraftigt ner någonstans, kommer det att betyda att det bara var på grund av förändringarna som skett under de senaste två veckorna. Detta gör att du kan identifiera och åtgärda problemet mycket snabbare. Och återigen, det här är ungefär samma mått som du kan mäta hur framgångsrikt du gjorde det.

Nästa praxis vi har är praxis Configuration Management. Det är väldigt få som tar detta på allvar. Men tro mig, det här är faktiskt en mycket allvarlig sak.

Det var en rolig historia nyligen. Killarna kom till mig och sa: "Hjälp oss att genomföra en säkerhetsgranskning av vår ansökan." Vi tittade länge på koden tillsammans, de berättade om applikationen, ritade diagram. Och plus eller minus allt var logiskt, förståeligt, säkert, men det fanns ett MEN! De hade konfigurationsfiler i sin källkontroll, inklusive de från produktion med IP-databasen, med inloggningar och lösenord för att ansluta till dessa databaser, etc.

Och jag säger: "Gubbar, okej, ni har stängt er produktionsmiljö med en brandvägg, men det faktum att ni har login och lösenord för produktionsdatabasen direkt i källkontrollen och vilken utvecklare som helst kan läsa det är redan en stor säkerhetsrisk . Och oavsett hur supersäker din applikation är ur kodsynpunkt, om du lämnar den i källkontroll kommer du aldrig att klara någon granskning någonstans." Det är vad jag pratar om.

Konfigurationshantering. Vi kan ha olika konfigurationer i olika miljöer. Vi kan till exempel ha olika inloggningar och lösenord för databaser för QA, demo, produktionsmiljö etc.

Denna konfiguration kan också automatiseras. Den ska alltid vara skild från själva applikationen. Varför? Eftersom du byggde applikationen en gång, och då applikationen inte bryr sig om du ansluter till SQL-servern via sådan och sådan IP eller sådan och sådan IP, borde det fungera likadant. Därför, om en av er plötsligt fortfarande hårdkodar anslutningssträngen i koden, kom ihåg att jag kommer att hitta dig och straffa dig om du befinner dig i samma projekt som mig. Detta placeras alltid i en separat konfiguration, till exempel i web.config.

Och den här konfigurationen hanteras redan separat, det vill säga det är exakt det ögonblick då en utvecklare och en administratör kan komma och sitta i samma rum. Och utvecklaren kan säga: "Titta, här är binärerna i min applikation. De arbetar. Applikationen behöver en databas för att fungera. Här bredvid binärerna finns en fil. I denna fil är detta fält ansvarigt för inloggningen, detta är för lösenordet, detta är för IP:n. Distribuera den var som helst." Och det är enkelt och tydligt för administratören. Han kan distribuera det verkligen var som helst genom att hantera den här konfigurationen.

Och den sista övningen som jag skulle vilja prata om är en övning som är väldigt, väldigt relaterad till moln. Och det ger maximal effekt om du arbetar i molnet. Detta är automatisk borttagning av din miljö.

Jag vet att det är flera personer på den här konferensen från de team jag arbetar med. Och med alla team jag arbetar med använder vi denna praxis.

Varför? Naturligtvis skulle det vara bra om varje utvecklare hade en virtuell maskin som skulle fungera 24/7. Men det här är kanske nyheter för dig, du kanske inte var uppmärksam, men utvecklaren själv fungerar inte 24/7. En utvecklare arbetar vanligtvis 8 timmar om dagen. Även om han kommer till jobbet tidigt äter han en stor lunch under vilken han går till gymmet. Låt det vara 12 timmar om dagen när utvecklaren faktiskt använder dessa resurser. Enligt vår lagstiftning har vi 5 av 7 dagar i veckan som räknas som arbetsdagar.

Följaktligen bör denna maskin på vardagar inte fungera 24 timmar, utan endast 12, och på helger bör den här maskinen inte fungera alls. Det verkar som att allt är väldigt enkelt, men vad är viktigt att säga här? Genom att implementera denna enkla praxis på detta grundläggande schema, låter det dig minska kostnaderna för att underhålla dessa miljöer med 70 %, dvs du tog priset på din dev, QA, demo, miljö och dividerade det med 3.

Frågan är vad man ska göra med resten av pengarna? Till exempel bör utvecklarna köpa ReSharper om de inte redan har gjort det. Eller ha ett cocktailparty. Om du tidigare hade en miljö där både dev och QA betade, och det är det, kan du nu göra 3 olika som kommer att isoleras, och människor kommer inte att störa varandra.

Angående glidningen med kontinuerlig prestationsmätning, hur kan vi jämföra prestanda om vi hade 1 000 poster i databasen i projektet, två månader senare finns det en miljon? Hur förstår man varför och vad är poängen med att mäta prestanda?

Detta är en bra fråga, eftersom du alltid bör mäta prestanda på samma resurser. Det vill säga att du rullar ut ny kod, du mäter prestanda på den nya koden. Du behöver till exempel testa olika prestandascenarier, låt oss säga att du vill testa hur applikationen presterar vid lätt belastning, där det finns 1 000 användare och databasstorleken är 5 gigabyte. Du mätte det och fick siffrorna. Därefter tar vi ett annat scenario. Till exempel 5 000 användare, databasstorlek 1 terabyte. Vi fick resultaten och kom ihåg dem.

Vad är viktigt här? Det viktiga här är att beroende på scenariot, mängden data, antalet samtidiga användare, etc., kan du stöta på vissa gränser. Till exempel, till gränsen för ett nätverkskort, eller till gränsen för en hårddisk, eller till gränsen för processorkapacitet. Det är detta som är viktigt för dig att förstå. I olika scenarier stöter du på vissa gränser. Och du måste förstå siffrorna när du slår dem.

Pratar vi om att mäta prestanda i en speciell testmiljö? Det vill säga, det här är inte produktion?

Ja, detta är inte produktion, detta är en testmiljö, som alltid är densamma så att man kan jämföra den med tidigare mätningar.

Förstod tack!

Om det inte finns några frågor tror jag att vi kan avsluta. Tack!

Källa: will.com