Zpráva bude hovořit o některých postupech DevOps, ale z pohledu vývojáře. Obvykle všichni inženýři, kteří se připojí k DevOps, již mají za sebou několik let administrativních zkušeností. To ale neznamená, že zde pro vývojáře není místo. Vývojáři jsou častěji zaneprázdněni opravou „další naléhavě kritické chyby dne“ a nemají čas ani se rychle podívat na pole DevOps. V autorově chápání je DevOps zaprvé zdravý rozum. Za druhé je to příležitost být efektivnější. Pokud jste vývojář, máte zdravý rozum a chcete být efektivnější jako týmový hráč, je tato zpráva určena právě vám.
Dovolte, abych se představil, plně přiznávám, že v místnosti jsou lidé, kteří mě neznají. Jmenuji se Anton Bojko a jsem MVP Microsoft Azure. Co je MVP? Toto je Model-View-Presenter. Model-View-Presenter jsem přesně já.
V současné době navíc zastávám pozici architekta řešení ve společnosti Ciklum. A nedávno jsem si koupil takovou krásnou doménu a aktualizoval jsem svůj email, který běžně ukazuji na prezentacích. Můžete mi napsat na: me [pes] byokoant.pro. S dotazy mi můžete poslat e-mail. Obvykle jim odpovídám. Jediná věc je, že bych nechtěl dostávat e-mailem otázky, které se týkají dvou témat: politiky a náboženství. O všem ostatním mi můžete napsat na email. Uplyne nějaký čas, odpovím.
Pár slov o sobě:
- V tomto oboru se pohybuji již 10 let.
- Pracoval jsem v Microsoftu.
- Jsem zakladatelem ukrajinské komunity Azure, kterou jsme založili někde v roce 2014. A stále ho máme a vyvíjíme.
- Jsem také otcem zakladatele konference Azure, kterou pořádáme na Ukrajině.
- Pomáhám také organizovat Global Azure Bootcamp v Kyjevě.
- Jak jsem řekl, jsem Microsoft Azure MVP.
- Na konferencích mluvím poměrně často. Opravdu rád mluvím na konferencích. Za poslední rok jsem mohl vystoupit asi 40krát. Pokud projedete kolem Ukrajiny, Běloruska, Polska, Bulharska, Švédska, Dánska, Nizozemska, Španělska nebo dáte nebo vezmete jinou zemi v Evropě, je docela možné, že když jdete na konferenci, která má ve svém proudu cloudové téma, můžete vidět, že jsem na seznamu řečníků.
- Jsem také fanouškem Star Treku.
Promluvme si trochu o Agendě. Náš program je velmi jednoduchý:
- Budeme mluvit o tom, co je DevOps. Pojďme si říct, proč je to důležité. Dříve bylo DevOps klíčové slovo, které jste si napsali do svého životopisu a okamžitě jste dostali plat +500 $. Nyní si musíte do životopisu napsat například blockchain, abyste ke svému platu dostali +500 dolarů.
- A pak, když trochu pochopíme, co to je, budeme mluvit o tom, co jsou DevOps praktiky. Ale ani ne tak v kontextu DevOps obecně, ale o těch DevOps praktikách, které by mohly vývojáře zajímat. Řeknu vám, proč by vás mohly zajímat. Řeknu vám, proč byste to vůbec měli dělat a jak vám to může pomoci zažít méně bolesti.
Tradiční obrázek, který ukazuje mnoho lidí. To se děje v mnoha projektech. To je, když máme vývojová a provozní oddělení, která podporují náš software. A tato oddělení spolu nekomunikují.
Možná, pokud jste to nebyli schopni tak jasně cítit v DevOps a provozních odděleních, můžete nakreslit analogii s odděleními Dev a QA. Jsou lidé, kteří vyvíjejí software, a jsou lidé z oblasti QA, kteří jsou z pohledu vývojářů špatní. Například odevzdám svůj úžasný kód do úložiště a sedí tam nějaký darebák, který mi tento kód vrátí a řekne, že váš kód je špatný.
To vše se děje proto, že lidé spolu nekomunikují. A přes nějakou zeď nedorozumění si navzájem hází nějaké balíčky, nějakou aplikaci a snaží se s nimi něco udělat.
Je to právě tato zeď, kterou má kultura DevOps zničit, tzn. donutit lidi, aby spolu komunikovali a alespoň pochopili, co různí lidé v projektu dělají a proč je jejich práce důležitá.
A když mluvíme o DevOps, někdo vám řekne, že DevOps je, když má projekt nepřetržitou integraci; někdo řekne, že DevOps je, pokud projekt implementuje praxi „infrastruktura jako kód“; někdo řekne, že prvním krokem k DevOps je větvení funkcí, příznaky funkcí.
V podstatě je to všechno svým způsobem pravda. Ale to jsou jen poslední praktiky, které máme. Než přejdeme k těmto postupům, doporučuji podívat se na tento snímek, který ukazuje 3 fáze implementace metodologie Dev-Ops ve vašem projektu ve vaší společnosti.
Tento snímek má i druhý neoficiální název. Můžete hledat online a zjistit, co jsou 3 mušketýři DevOps. Je možné, že tento článek najdete. Proč 3 mušketýři? Pod ním se píše: lidé, procesy a produkty, tzn. PPP – Porthos, Porthos a Porthos. Zde jsou 3 mušketýři z DevOps. Tento článek podrobněji popisuje, proč je to důležité a co to obnáší.
Když začnete implementovat kulturu DevOps, je velmi důležité, aby byla implementována v následujícím pořadí.
Zpočátku musíte mluvit s lidmi. A musíte lidem vysvětlit, co to je a jak z toho mohou získat nějaké výhody.
Naše konference se jmenuje DotNet Fest. A jak mi organizátoři řekli, pozvali jsme sem hlavně publikum vývojářů, takže doufám, že většina lidí v sále se podílí na vývoji.
Budeme mluvit o lidech, budeme mluvit o tom, co chtějí vývojáři každý den dělat. Co chtějí nejvíc? Chtějí napsat nějaký nový kód, používat nové rámce, vytvářet nové funkce. Co chtějí vývojáři nejméně? Opravte staré chyby. Doufám, že se mnou souhlasíte. To je to, co vývojáři chtějí. Chtějí psát nové funkce, nechtějí opravovat chyby.
Počet chyb, které konkrétní vývojář vyprodukuje, závisí na tom, jak rovné má paže a jak moc mu rostou z ramen, a ne z kapes na zadku. Ale přesto, když máme velký projekt, občas se stane, že není možné vše sledovat, takže by bylo fajn, kdybychom použili nějaké přístupy, které nám pomohou napsat stabilnější a kvalitnější kód.
Co QA chtějí nejvíce? Nevím, jestli jsou v hale. Je pro mě těžké říct, že chci QA, protože jsem jím nikdy nebyl. A bez urážky chlapům, bude řečeno, že doufám, že nikdy nebudu. Ale ne z toho důvodu, že bych jejich práci považoval za nesmyslnou a zbytečnou, ale proto, že se nepovažuji za člověka, který by tuto práci dokázal dělat efektivně, tak se o to ani nebudu snažit. Ale z toho, co jsem pochopil, to, co se QA nejvíc nelíbí, je to, že ráno začne fungovat, neustále spouští nějaké regresní testy, šlape na stejné chyby, které nahlásili vývojářům před 3 sprinty, a říkáte: „Kdy budete , Monsieur D 'Artagnane, opravte tuto chybu.' A monsieur D'Artagnan mu odpovídá: "Ano, ano, ano, už jsem to opravil." A jak se to stane, že jsem opravil jednu chybu a udělal 5 po cestě.
Lidé, kteří toto řešení podporují ve výrobě, chtějí, aby toto řešení fungovalo bez chyb, aby nemuseli restartovat server každý pátek, kdy všichni normální lidé jdou do baru. Vývojáři nasadili v pátek, administrátoři sedí až do soboty a snaží se toto nasazení zprovoznit a opravit.
A když lidem vysvětlíte, že jsou zaměřeni na řešení stejných problémů, můžete přejít k formalizaci procesů. Je to velmi důležité. Proč? Protože když říkáme „formalizace“, je důležité, abyste alespoň někde na ubrousku popsali, jak vaše procesy probíhají. Musíte pochopit, že pokud například nasazujete do prostředí QA nebo produkčního prostředí, děje se to vždy v tomto pořadí, v těchto fázích spouštíme například automatické testy jednotek a testy uživatelského rozhraní. Po nasazení zkontrolujeme, zda nasazení proběhlo dobře nebo špatně. Ale už máte jasný seznam akcí, které se musí při nasazení do výroby stále znovu a znovu opakovat.
A teprve když jsou vaše procesy formalizované, začnete vybírat produkty, které vám pomohou tyto procesy automatizovat.
Bohužel velmi často vidím, že se to děje obráceně. Jakmile někdo uslyší slovo „DevOps“, okamžitě navrhne instalaci Jenkins, protože věří, že jakmile nainstaluje Jenkins, bude mít DevOps. Nainstalovali si Jenkinse, přečetli si články „Jak na to“ na webu Jenkins, pokusili se do těchto článků nacpat procesy a pak přišli k lidem a sklonili je s tím, že kniha říká, že to musíte udělat takto, takže to děláme takto.
Není to tak, že by Jenkins byl špatný nástroj. Tím to v žádném případě nechci říct. Ale to je jen jeden z produktů. A jaký produkt použijete, by mělo být vaším posledním rozhodnutím a v žádném případě ne prvním. Váš produkt by neměl být řízen implementací kultury a přístupů. Tomu je velmi důležité porozumět, a proto trávím na tomto snímku tolik času a tak dlouho to vše vysvětluji.
Pojďme se bavit o postupech DevOps obecně. Co jsou? Jaký je rozdíl? Jak je vyzkoušet? Proč jsou důležité?
První praxe, o které jste možná slyšeli, se nazývá průběžná integrace. Možná někdo na projektu má kontinuální integraci (CI).
Největší problém je, že nejčastěji, když se člověka zeptám: „Máte na projektu CI?“ a on říká: „Ano,“ a když se zeptám, co dělá, popíše mi absolutně celý proces automatizace. Není to tak úplně pravda.
Ve skutečnosti je praxe CI zaměřena pouze na integraci kódu, který píší různí lidé, do jakési jediné kódové základny. To je vše.
Spolu s CI jsou obvykle na cestě i další postupy – jako je Continuous Deployment, Release Management, ale o tom si povíme později.
Samotné CI nám říká, že kód píší různí lidé a tento kód musí být nepřetržitě integrován do jediné kódové základny.
Co nám to dává a proč je to důležité? Pokud máme DotNet, tak je to dobré, je to kompilovaný jazyk, můžeme naši aplikaci zkompilovat. Pokud se zkompiluje, je to již dobré znamení. To ještě nic neznamená, ale je to první dobré znamení, že můžeme alespoň zkompilovat.
Pak můžeme spustit nějaké testy, což je také samostatná praxe. Všechny testy jsou zelené – to je druhé dobré znamení. Ale zase to nic neznamená.
Ale proč bys to dělal? Všechny praktiky, o kterých dnes budu mluvit, mají přibližně stejnou hodnotu, tedy přibližně stejné výhody a jsou také přibližně stejně měřeny.
Za prvé, umožňuje urychlit doručení. Jak vám to umožňuje urychlit doručení? Když provedeme nějaké nové změny v naší kódové základně, můžeme se okamžitě pokusit s tímto kódem něco udělat. Nečekáme, až přijde čtvrtek, protože ve čtvrtek to uvolníme do prostředí QA Environment, děláme to přímo tady a přímo tady.
Povím vám jeden smutný příběh ze svého života. Bylo to dávno, když jsem byl ještě mladý a pohledný. Nyní jsem již mladá, krásná a chytrá a skromná. Před časem jsem byl v projektu. Měli jsme velký tým asi 30 vývojářů. A měli jsme velký, velký Enterprise projekt, který se vyvíjel asi 10 let. A měli jsme různé pobočky. V úložišti jsme měli větev, ve které vývojáři chodili. A byla tam větev, která zobrazovala verzi kódu, která je ve výrobě.
Produkční větev byla 3 měsíce za větví, která byla k dispozici vývojářům. Co to znamená? To znamená, že jakmile mám někde chybu, která jde do výroby vinou vývojářů, protože to povolili, a vinou QA, protože se na to podívali, tak to znamená, že pokud dostanu úkol pro hotfix pro produkci, pak musím vrátit změny kódu před 3 měsíci. Musím si vzpomenout, co jsem měl před 3 měsíci a zkusit to tam opravit.
Pokud jste tuto zkušenost ještě neměli, můžete ji vyzkoušet na svém domácím projektu. Hlavní věc je, nezkoušejte to na komerčním. Napište pár řádků kódu, zapomeňte na ně na šest měsíců a pak se vraťte a zkuste rychle vysvětlit, o čem tyto řádky kódu jsou a jak je můžete opravit nebo optimalizovat. Je to velmi, velmi vzrušující zážitek.
Pokud máme praxi kontinuální integrace, pak nám to umožňuje zkontrolovat ji pomocí řady automatizovaných nástrojů přímo tady a právě teď, jakmile napíšu svůj kód. Možná mi to neposkytne úplný obrázek, ale přesto to odstraní alespoň některá rizika. A pokud existuje nějaká potenciální chyba, budu o ní vědět hned teď, tedy doslova za pár minut. Nebudu se muset vrátit o 3 měsíce zpět. Budu se muset vrátit o 2 minuty zpět. Dobrý kávovar ani nestihne uvařit kávu za 2 minuty, takže je to docela cool.
To má tu hodnotu, že se to může opakovat čas od času na každém projektu, tzn. nejen ten, na kterém jste jej nastavili. Můžete opakovat jak samotnou praxi, tak i samotná CI se bude opakovat při každé nové změně, kterou v projektu provedete. To vám umožní optimalizovat zdroje, protože váš tým pracuje efektivněji. Už se vám nestane, že by vám přišla chyba z kódu, se kterým jste pracovali před 3 měsíci. Už nebudete mít přepínání kontextu, když budete sedět a první dvě hodiny se snažit pochopit, co se tehdy stalo, a dostat se do podstaty kontextu, než začnete něco opravovat.
Jak můžeme měřit úspěch nebo neúspěch této praxe? Pokud nahlásíte velkému šéfovi, co jsme na projektu CI implementovali, slyší bla bla bla. Zavedli jsme to, dobře, ale proč, co nám to přineslo, jak to měříme, jak správně nebo špatně to zavádíme?
První je, že díky CI můžeme nasazovat stále častěji a častěji právě proto, že náš kód je potenciálně stabilnější. Stejně tak se nám zkracuje čas na nalezení chyby a zkracuje se čas na opravu této chyby právě z toho důvodu, že právě tady a právě teď dostáváme od systému odpověď, co je v našem kódu špatně.
Další praxí, kterou máme, je praxe Automation Testing, která nejčastěji přichází s praxí CI. Jdou ruku v ruce.
Co je zde důležité pochopit? Je důležité pochopit, že naše testy jsou odlišné. A každý automatizovaný test je zaměřen na řešení vlastních problémů. Máme například unit testy, které nám umožňují testovat modul samostatně, tzn. Jak to funguje ve vakuu? To je dobré.
Máme také integrační testy, které nám umožňují pochopit, jak se různé moduly vzájemně integrují. Je to také dobré.
Můžeme mít testy automatizace uživatelského rozhraní, které nám umožní zkontrolovat, jak dobře práce s uživatelským rozhraním splňuje určité požadavky stanovené zákazníkem atd.
Konkrétní testy, které spouštíte, mohou ovlivnit, jak často je spouštíte. Jednotkové testy jsou obvykle psány krátké a malé. A mohou být spuštěny pravidelně.
Pokud mluvíme o testech automatizace uživatelského rozhraní, pak je dobré, pokud je váš projekt malý. Vaše testy automatizace uživatelského rozhraní mohou nějakou dobu trvat. Ale obvykle je test automatizace uživatelského rozhraní něco, co u velkého projektu trvá několik hodin. A je dobré, když je to pár hodin. Jediná věc je, že nemá smysl je spouštět pro každé sestavení. Má smysl je provozovat v noci. A když ráno všichni přišli do práce: testeři i vývojáři, dostali nějaké hlášení, že jsme v noci spustili autotest uživatelského rozhraní a dostali jsme tyto výsledky. A zde bude hodina práce serveru, který zkontroluje, zda váš produkt splňuje nějaké požadavky, mnohem levnější než hodina práce stejného QA inženýra, i když je to Junior QA inženýr, který pracuje za jídlo a díky. Přesto vyjde hodina provozu stroje levněji. Proto má smysl do něj investovat.
Mám další projekt, na kterém pracuji. Na tomto projektu jsme měli dvoutýdenní sprinty. Projekt byl velký, důležitý pro finanční sektor a nemohlo dojít k chybě. A po dvoutýdenním sprintu následoval vývojový cyklus testovací proces, který trval další 4 týdny. Zkuste si představit rozsah tragédie. Píšeme kód dva týdny, pak to uděláme ala CodeFreeze, zabalíme to do nové verze aplikace a předáme testerům. Testeři to testují ještě 4 týdny, tzn. Zatímco to testují, máme čas pro ně připravit další dvě verze. Tohle je opravdu smutný případ.
A řekli jsme jim, že pokud chcete být produktivnější, má pro vás smysl implementovat postupy automatického testování, protože to je to, co vás bolí právě tady a právě teď.
Procvičte si kontinuální nasazení. Skvělé, dokončili jste stavbu. To už je dobré. Váš kód se zkompiloval. Nyní by bylo hezké nasadit toto build na nějakém prostředí. Řekněme v prostředí pro vývojáře.
Proč je to důležité? Nejprve se můžete podívat na to, jak jste úspěšní se samotným procesem nasazení. Setkal jsem se s podobnými projekty, když se zeptám: „Jak nasadíte novou verzi aplikace?“, kluci mi řeknou: „Smontujeme to a zabalíme do zip archivu. Pošleme to adminovi poštou. Správce stáhne a rozšíří tento archiv. A celá kancelář se začíná modlit, aby server vyzvedl novou verzi.“
Začněme něčím jednoduchým. Například zapomněli vložit CSS do archivu nebo zapomněli změnit hashtag v názvu souboru java-script. A když odešleme požadavek na server, prohlížeč si myslí, že tento soubor java-script již má, a rozhodne se jej nestahovat. A byla tam stará verze, něco tomu chybělo. Obecně může být mnoho problémů. Praxe Continuous Deployment vám proto umožňuje alespoň vyzkoušet, co by se stalo, kdybyste vzali čistý referenční obrázek a nahráli ho do zcela čistého nového prostředí. Můžete vidět, kam to vede.
Také, když mezi sebou integrujete kód, tzn. mezi příkazy, to vám umožní také vidět, jak to vypadá na uživatelském rozhraní.
Jedním z problémů, které se vyskytují tam, kde se používá hodně vanilkového java-scriptu, je to, že dva vývojáři ukvapeně deklarovali proměnnou se stejným názvem v objektu okna. A pak, podle vašeho štěstí. Čí soubor java-script je vytažen jako druhý, přepíše změny druhého. Je to také velmi vzrušující. Přijdete: jedna věc funguje na jednoho člověka, jiná nefunguje na druhého. A je to „úžasné“, když to všechno vyjde ve výrobě.
Další postup, který máme, je postup automatického obnovení, konkrétně návrat k předchozí verzi aplikace.
Proč je to důležité pro vývojáře? Stále se najdou tací, kteří pamatují vzdálená, vzdálená 90. léta, kdy byly počítače velké a programy malé. A jediná cesta k vývoji webu byla přes PHP. Není to tak, že by PHP byl špatný jazyk, i když je.
Problém byl ale jiný. Když jsme nasadili novou verzi našeho php webu, jak jsme ji nasadili? Nejčastěji jsme otevírali Far Manager nebo něco jiného. A nahrál tyto soubory na FTP. A najednou jsme si uvědomili, že máme nějakou malou malou chybu, například jsme zapomněli dát středník nebo zapomněli změnit heslo k databázi a existuje heslo k databázi, které je na místním hostiteli. A rozhodneme se rychle připojit k FTP a upravit soubory přímo tam. Tohle je jen oheň! To bylo populární v 90. letech.
Ale pokud jste se nepodívali do kalendáře, 90. léta byla téměř před 30 lety. Nyní se vše děje trochu jinak. A zkuste si představit rozsah tragédie, když vám řeknou: „Nasadili jsme do výroby, ale něco se tam pokazilo. Zde je vaše přihlašovací jméno a heslo FTP, připojte se k produkci a rychle to tam opravte.“ Pokud jste Chuck Norris, bude to fungovat. Pokud ne, riskujete, že pokud opravíte jednu chybu, uděláte dalších 10. To je přesně důvod, proč vám tato praxe návratu k předchozí verzi umožňuje dosáhnout hodně.
I kdyby se něco špatného nějak dostalo do produktu, pak je to špatné, ale ne fatální. Můžete se vrátit k předchozí verzi, kterou máte. Říkejte tomu záloha, pokud je snazší to v této terminologii vnímat. Můžete se vrátit k této předchozí verzi a uživatelé budou moci s vaším produktem nadále pracovat a vy budete mít dostatek času ve vyrovnávací paměti. To vše můžete v klidu beze spěchu vzít a lokálně otestovat, opravit a poté nahrát novou verzi. Opravdu to má smysl dělat.
Nyní zkusme obě předchozí praktiky nějak spojit dohromady. Dostaneme třetí s názvem Release Management.
Když mluvíme o Continuous Deployment v jeho klasické podobě, říkáme, že musíme vytáhnout kód z nějaké větve z úložiště, zkompilovat ho a nasadit. Je dobré, když máme stejné prostředí. Pokud máme několik prostředí, znamená to, že musíme kód stáhnout pokaždé, dokonce i ze stejného potvrzení. Pokaždé to vytáhneme, pokaždé postavíme a nasadíme do nového prostředí. Za prvé je to čas, protože postavit projekt, pokud ho máte velký a pocházíte z 90. let, může trvat několik hodin.
Kromě toho je tu další smutek. Když stavíte, byť na stejném stroji, budete stavět stejné zdroje, stále nemáte žádnou záruku, že tento stroj je ve stejném stavu, jako byl při posledním sestavení.
Řekněme, že někdo přišel a aktualizoval DotNet za vás, nebo se naopak někdo rozhodl něco smazat. A pak máte kognitivní disonanci, že z tohoto odevzdání před dvěma týdny jsme stavěli sestavení a všechno bylo v pořádku, ale teď to vypadá jako stejný stroj, stejný odevzdání, stejný kód, který se snažíme sestavit, ale nefunguje to . Budete se s tím potýkat dlouho a není pravda, že na to přijdete. Minimálně si hodně zkazíte nervy.
Proto praxe správy vydání navrhuje zavést další abstrakci nazývanou úložiště artefaktů nebo galerie nebo knihovna. Můžete tomu říkat, jak chcete.
Hlavní myšlenkou je, že jakmile tam máme nějaký commit, řekněme, v pobočce, kterou jsme připraveni nasadit do našich různých prostředí, shromáždíme aplikace z tohoto commitu a vše, co pro tuto aplikaci potřebujeme, zabalíme to do archivu zip a uložte jej na nějaké spolehlivé úložiště. A z tohoto úložiště můžeme kdykoli získat tento zip archiv.
Poté jej vezmeme a automaticky nasadíme do vývojového prostředí. Závodíme tam, a pokud je vše dobré, tak se nasadíme na jeviště. Pokud je vše v pořádku, nasadíme do produkce stejný archiv, stejné binární soubory, zkompilované přesně jednou.
Navíc, když máme takovou galerii, pomáhá nám to také řešit rizika, která jsme řešili na posledním snímku, když jsme mluvili o návratu k předchozí verzi. Pokud jste omylem nasadili něco špatně, můžete vždy vzít jakoukoli jinou předchozí verzi z této galerie a stejným způsobem ji zrušit nasazení do těchto prostředí. To vám umožní snadno se vrátit k předchozí verzi, pokud se něco pokazí.
Existuje další skvělá praxe. Vy i já všichni chápeme, že když vrátíme naše aplikace zpět na předchozí verzi, může to znamenat, že potřebujeme také infrastrukturu předchozí verze.
Když mluvíme o virtuální infrastruktuře, mnoho lidí si myslí, že je to něco, co nastavili administrátoři. A pokud potřebujete, řekněme, získat nový server, na kterém chcete otestovat novou verzi své aplikace, musíte napsat lístek administrátorům nebo vývojářům. Devops to zabere 3 týdny. A po 3 týdnech vám řeknou, že jsme pro vás nainstalovali virtuální stroj s jedním jádrem, dvěma gigabajty RAM a Windows serverem bez DotNetu. Říkáte: "Ale já jsem chtěl DotNet." Oni: "Dobře, vrať se za 3 týdny."
Myšlenka je taková, že používáním Infrastructure as Code praktiky můžete svou virtuální infrastrukturu považovat pouze za další zdroj.
Možná, pokud někdo z vás vyvíjí aplikace na DotNet, možná už slyšel o knihovně Entity Framework. A možná jste dokonce slyšeli, že Entity Framework je jedním z přístupů, které Microsoft aktivně prosazuje. Pro práci s databází se jedná o přístup nazvaný Code First. To je, když v kódu popíšete, jak chcete, aby vaše databáze vypadala. A pak aplikaci nasadíte. Připojí se k databázi, sama určí, které tabulky tam jsou a které ne, a vytvoří vše potřebné.
Totéž můžete udělat se svou infrastrukturou. Není rozdíl mezi tím, zda potřebujete databázi pro projekt nebo zda potřebujete Windows server pro projekt. Je to jen zdroj. A můžete automatizovat vytváření tohoto zdroje, můžete automatizovat konfiguraci tohoto zdroje. Proto pokaždé, když budete chtít otestovat nějaký nový koncept, nějaký nový přístup, nebudete muset psát lístek do devops, můžete si jednoduše nasadit izolovanou infrastrukturu pro sebe z hotových šablon, z hotových skriptů a implementovat ji tam jsou všechny vaše experimenty. Můžete to smazat, získat nějaké výsledky a dále o tom hlásit.
Další praxí, která také existuje a je také důležitá, ale kterou málokdo používá, je monitorování výkonu aplikací.
O sledování výkonu aplikací jsem chtěl říci pouze jednu věc. Co je na této praxi nejdůležitější? To je Sledování výkonu aplikací asi to samé jako oprava bytu. Toto není konečný stav, je to proces. Musíte to dělat pravidelně.
V dobrém slova smyslu by bylo dobré provádět sledování výkonu aplikací na téměř každém sestavení, i když, jak jistě chápete, to není vždy možné. Minimálně však musí být provedeno pro každé vydání.
Proč je to důležité? Protože pokud náhle zaznamenáte pokles výkonu, musíte jasně pochopit proč. Pokud má váš tým řekněme dvoutýdenní sprinty, pak alespoň jednou za dva týdny byste měli nasadit vaši aplikaci na nějaký samostatný server, kde máte jasně fixovaný procesor, RAM, disky atd. A spouštět ty stejné výkonnostní testy . Dostanete výsledek. Podívejte se, jak se změnil oproti předchozímu sprintu.
A pokud zjistíte, že čerpání šlo někde prudce dolů, bude to znamenat, že to bylo jen kvůli změnám, ke kterým došlo za poslední dva týdny. To vám umožní identifikovat a vyřešit problém mnohem rychleji. A opět se jedná o zhruba stejné metriky, pomocí kterých můžete měřit, jak úspěšně jste to udělali.
Další praxí, kterou máme, je praxe Configuration Management. Je velmi málo těch, kteří to berou vážně. Ale věřte mi, je to ve skutečnosti velmi vážná věc.
Nedávno se stala vtipná historka. Kluci za mnou přišli a řekli: "Pomozte nám provést bezpečnostní audit naší aplikace." Dlouho jsme se spolu dívali na kód, řekli mi o aplikaci, kreslili schémata. A plus minus vše bylo logické, srozumitelné, bezpečné, ale bylo tu jedno ALE! Ve zdrojovém ovládání měli konfigurační soubory, včetně těch z výroby s IP databází, s přihlašovacími údaji a hesly pro připojení k těmto databázím atd.
A já říkám: „Kluci, dobře, uzavřeli jste své produkční prostředí firewallem, ale už to, že máte přihlašovací jméno a heslo k produkční databázi přímo v kontrole zdroje a může si to přečíst každý vývojář, je už obrovské bezpečnostní riziko. . A bez ohledu na to, jak super bezpečná je vaše aplikace z hlediska kódu, pokud ji necháte pod kontrolou zdroje, nikdy nikde neprojdete žádným auditem.“ To je to, o čem mluvím.
Správa konfigurace. V různých prostředích můžeme mít různé konfigurace. Například můžeme mít různá přihlašovací jména a hesla pro databáze pro QA, demo, produkční prostředí atd.
Tato konfigurace může být také automatizována. Vždy by měl být oddělený od samotné aplikace. Proč? Protože jste aplikaci sestavili jednou a pak už je aplikaci jedno, zda se připojíte k SQL serveru přes takovou a takovou IP nebo takovou a takovou IP, mělo by to fungovat stejně. Pokud tedy náhle jeden z vás stále pevně kóduje připojovací řetězec v kódu, pak si pamatujte, že vás najdu a potrestám, pokud se ocitnete na stejném projektu se mnou. To je vždy umístěno v samostatné konfiguraci, například ve web.config.
A tato konfigurace je již spravována odděleně, tedy přesně v tomto okamžiku mohou přijít vývojář a administrátor a sedět ve stejné místnosti. A vývojář může říci: „Podívejte, tady jsou binární soubory mé aplikace. Oni pracují. Aplikace potřebuje ke svému fungování databázi. Zde vedle binárních souborů je soubor. V tomto souboru je toto pole zodpovědné za přihlášení, toto je heslo, toto je IP. Nasaďte to kamkoli." A pro administrátora je to jednoduché a jasné. Správou této konfigurace jej může nasadit opravdu kdekoli.
A poslední praxe, o které bych chtěl mluvit, je praxe, která velmi, velmi souvisí s mraky. A maximální efekt přináší, pokud pracujete v cloudu. Toto je automatické odstranění vašeho prostředí.
Vím, že na této konferenci je několik lidí z týmů, se kterými pracuji. A se všemi týmy, se kterými pracuji, tuto praxi používáme.
Proč? Samozřejmě by bylo skvělé, kdyby každý vývojář měl virtuální stroj, který by fungoval 24/7. Ale možná je to pro vás novinka, možná jste tomu nevěnovali pozornost, ale samotný vývojář nefunguje 24/7. Vývojář obvykle pracuje 8 hodin denně. I když přijde do práce brzy, má velký oběd, během kterého jde do posilovny. Ať je to 12 hodin denně, kdy vývojář tyto prostředky skutečně využívá. Podle naší legislativy máme 5 ze 7 dnů v týdnu, které jsou považovány za pracovní dny.
Ve všední dny by tedy tento stroj neměl pracovat 24 hodin, ale pouze 12, a o víkendech by tento stroj neměl fungovat vůbec. Zdálo by se, že je vše velmi jednoduché, ale co je důležité zde říci? Zavedením tohoto jednoduchého postupu do tohoto základního plánu vám umožní snížit náklady na údržbu těchto prostředí o 70 %, tj. vezmete cenu svého vývoje, QA, demo, prostředí a vydělíte ji 3.
Otázkou je, co se zbytkem peněz? Vývojáři by si například měli koupit ReSharper, pokud tak ještě neučinili. Nebo uspořádejte koktejlový večírek. Pokud jste dříve měli jedno prostředí, ve kterém se pásli jak vývojáři, tak QA, a to je vše, nyní můžete vytvořit 3 různá prostředí, která budou izolovaná a lidé se nebudou navzájem rušit.
Co se týče snímku s průběžným měřením výkonu, jak můžeme porovnávat výkon, když jsme v projektu měli v databázi 1 záznamů, o dva měsíce později je jich milion? Jak pochopit, proč a jaký je smysl měření výkonu?
To je dobrá otázka, protože byste měli vždy měřit výkon na stejných zdrojích. To znamená, že zavedete nový kód, změříte výkon na novém kódu. Například potřebujete otestovat různé scénáře výkonu, řekněme, že chcete otestovat, jak si aplikace vede při malé zátěži, kde je 1 000 uživatelů a velikost databáze je 5 gigabajtů. Změřili jste to a získali čísla. Dále vezmeme další scénář. Například 5 000 uživatelů, velikost databáze 1 terabajt. Získali jsme výsledky a zapamatovali si je.
Co je zde důležité? Důležité zde je, že v závislosti na scénáři, objemu dat, počtu současně pracujících uživatelů atd. můžete narazit na určité limity. Například na limit síťové karty, nebo na limit pevného disku nebo na limit možností procesoru. To je to, co je důležité, abyste pochopili. V různých scénářích narazíte na určité limity. A musíte rozumět číslům, když je trefíte.
Mluvíme o měření výkonu ve speciálním testovacím prostředí? To znamená, že to není výroba?
Ano, toto není produkční, toto je testovací prostředí, které je vždy stejné, abyste jej mohli porovnat s předchozími měřeními.
Rozumím díky!
Pokud nejsou žádné otázky, myslím, že můžeme skončit. Děkuji!
Zdroj: www.habr.com