Správa bude hovoriť o niektorých postupoch DevOps, ale z pohľadu vývojárov. Zvyčajne všetci inžinieri, ktorí sa pripájajú k DevOps, už majú za sebou niekoľkoročné administratívne skúsenosti. To ale neznamená, že tu nie je miesto pre developera. Vývojári sú častejšie zaneprázdnení odstraňovaním „ďalšej naliehavo kritickej chyby dňa“ a nemajú čas ani sa rýchlo pozrieť na pole DevOps. Podľa autorovho chápania je DevOps v prvom rade zdravý rozum. Po druhé, je to príležitosť byť efektívnejší. Ak ste vývojár, máte zdravý rozum a chcete byť efektívnejší ako tímový hráč, táto správa je pre vás.
Dovoľte mi predstaviť sa, plne priznávam, že v miestnosti sú ľudia, ktorí ma nepoznajú. Moje meno je Anton Bojko, som Microsoft Azure MVP. čo je MVP? Toto je Model-View-Presenter. Model-View-Presenter som presne ja.
Okrem toho momentálne zastávam pozíciu architekta riešení v spoločnosti Ciklum. A len nedávno som si kúpil takú krásnu doménu a aktualizoval som svoj email, ktorý bežne ukazujem na prezentáciách. Môžete mi napísať na: me [pes] byokoant.pro. S otázkami mi môžete poslať e-mail. Zvyčajne im odpovedám. Jediná vec je, že by som nechcel dostávať e-mailom otázky, ktoré sa týkajú dvoch tém: politiky a náboženstva. O všetkom ostatnom mi môžete napísať na email. Prejde nejaký čas, odpoviem.
Pár slov o sebe:
- V tejto oblasti sa pohybujem už 10 rokov.
- Pracoval som v Microsofte.
- Som zakladateľom ukrajinskej komunity Azure, ktorú sme založili niekde v roku 2014. A stále ho máme a rozvíjame.
- Som tiež otcom zakladateľa konferencie Azure, ktorú organizujeme na Ukrajine.
- Tiež pomáham organizovať Global Azure Bootcamp v Kyjeve.
- Ako som povedal, som Microsoft Azure MVP.
- Na konferenciách hovorím pomerne často. Veľmi rád hovorím na konferenciách. Za posledný rok som mohol vystupovať asi 40-krát. Ak prejdete popri Ukrajine, Bielorusku, Poľsku, Bulharsku, Švédsku, Dánsku, Holandsku, Španielsku alebo dáte alebo vezmete inú krajinu v Európe, je dosť možné, že keď idete na konferenciu, ktorá má v streame cloudovú tému, môžete ma vidieť na zozname rečníkov.
- Tiež som fanúšikom Star Treku.
Povedzme si niečo o Agende. Naša agenda je veľmi jednoduchá:
- Povieme si, čo je DevOps. Povedzme si, prečo je to dôležité. Predtým bolo DevOps kľúčové slovo, ktoré ste si napísali do životopisu a okamžite ste dostali plat +500 $. Teraz si musíte do životopisu napísať napríklad blockchain, aby ste k platu dostali +500 dolárov.
- A potom, keď trochu pochopíme, čo to je, povieme si, čo sú praktiky DevOps. Ale ani nie tak v kontexte DevOps vo všeobecnosti, ale o tých DevOps praktikách, ktoré by mohli byť zaujímavé pre vývojárov. Poviem vám, prečo by vás mohli zaujímať. Poviem vám, prečo by ste to vôbec mali robiť a ako vám to môže pomôcť zažiť menšiu bolesť.
Tradičný obrázok, ktorý ukazuje veľa ľudí. To sa deje v mnohých projektoch. Vtedy máme vývojové a prevádzkové oddelenia, ktoré podporujú náš softvér. A tieto oddelenia spolu nekomunikujú.
Možno, ak ste to nedokázali tak jasne pocítiť v oddeleniach DevOps a operácií, môžete nakresliť analógiu s oddeleniami Dev a QA. Sú ľudia, ktorí vyvíjajú softvér a sú ľudia na kontrolu kvality, ktorí sú z pohľadu vývojárov zlí. Napríklad odovzdám svoj úžasný kód do úložiska a tam sedí nejaký darebák, ktorý mi tento kód vráti a povie, že váš kód je zlý.
To všetko sa deje preto, že ľudia spolu nekomunikujú. A prehadzujú si nejaké balíčky, nejakú aplikáciu cez nejakú stenu nedorozumenia a snažia sa s nimi niečo urobiť.
Presne túto stenu má DevOps kultúra zničiť, t.j. prinútiť ľudí, aby medzi sebou komunikovali a aspoň pochopili, čo rôzni ľudia v projekte robia a prečo je ich práca dôležitá.
A keď hovoríme o DevOps, niekto vám povie, že DevOps je vtedy, keď má projekt nepretržitú integráciu; niekto povie, že DevOps je, ak projekt implementuje prax „infraštruktúra ako kód“; niekto povie, že prvým krokom k DevOps je vetvenie funkcií, príznaky funkcií.
V podstate je to všetko pravda svojím vlastným spôsobom. Ale toto sú len posledné praktiky, ktoré máme. Predtým, ako prejdeme k týmto postupom, navrhujem pozrieť si túto snímku, ktorá ukazuje 3 fázy implementácie metodológie Dev-Ops vo vašom projekte vo vašej spoločnosti.
Táto snímka má aj druhý neoficiálny názov. Môžete hľadať online a zistiť, čo sú 3 mušketieri DevOps. Je možné, že tento článok nájdete. Prečo 3 mušketieri? Pod ním sa píše: ľudia, procesy a produkty, t.j. PPP – Porthos, Porthos a Porthos. Tu sú 3 mušketieri DevOps. Tento článok podrobnejšie popisuje, prečo je to dôležité a čo to obnáša.
Keď začnete implementovať kultúru DevOps, je veľmi dôležité, aby bola implementovaná v nasledujúcom poradí.
Najprv musíte hovoriť s ľuďmi. A musíte ľuďom vysvetliť, čo to je a ako z toho môžu získať nejaké výhody.
Naša konferencia sa volá DotNet Fest. A ako mi povedali organizátori, pozvali sme sem hlavne publikum vývojárov, takže dúfam, že väčšina ľudí v sále sa podieľa na vývoji.
Budeme hovoriť o ľuďoch, budeme hovoriť o tom, čo chcú vývojári robiť každý deň. Čo chcú najviac? Chcú napísať nejaký nový kód, používať nové rámce, vytvárať nové funkcie. Čo chcú vývojári najmenej? Opravte staré chyby. Dúfam, že so mnou súhlasíte. Toto chcú vývojári. Chcú písať nové funkcie, nechcú opravovať chyby.
Počet chýb, ktoré konkrétny vývojár vyprodukuje, závisí od toho, aké má rovné ruky a ako mu vyrastajú z pliec, a nie z vreciek na zadku. Ale napriek tomu, keď máme veľký projekt, niekedy sa stane, že nie je možné všetko odsledovať, preto by bolo fajn, keby sme použili nejaké prístupy, ktoré nám pomôžu napísať stabilnejší a kvalitnejší kód.
Čo QA chcú najviac? Neviem, či sú v hale. Je pre mňa ťažké povedať, že chcem QA, pretože som ňou nikdy nebol. A bez urážky chalanov, povie sa, že dúfam, že nikdy nebudem. Ale nie preto, že by som ich prácu považoval za nezmyselnú a zbytočnú, ale preto, že sa nepovažujem za človeka, ktorý by túto prácu vedel robiť efektívne, tak sa o to ani nebudem snažiť. Ale z toho, čo som pochopil, to, čo QA nemá najradšej, je to, že ráno začne pracovať, neustále spúšťajú nejaké regresné testy, šliapu po tých istých chybách, ktoré nahlásili vývojárom pred 3 sprintmi a hovoria: „Kedy budete , Monsieur D 'Artagnan, opravte túto chybu.' A Monsieur D'Artagnan mu odpovedá: "Áno, áno, áno, už som to opravil." A ako sa to stane, že som jednu chybu opravil a po ceste urobil 5.
Ľudia, ktorí podporujú toto riešenie vo výrobe, chcú, aby toto riešenie fungovalo bez chýb, aby nemuseli reštartovať server každý piatok, keď všetci normálni ľudia idú do baru. Vývojári nasadili v piatok, správcovia sedia do soboty a snažia sa toto nasadenie spustiť a opraviť.
A keď ľuďom vysvetlíte, že sú zamerané na riešenie rovnakých problémov, môžete prejsť k formalizácii procesov. Je to veľmi dôležité. prečo? Pretože keď hovoríme „formalizácia“, je dôležité, aby ste aspoň niekde na obrúsku opísali, ako vaše procesy prebiehajú. Musíte pochopiť, že ak napríklad nasadzujete do prostredia QA alebo produkčného prostredia, deje sa to vždy v tomto poradí, v týchto fázach spúšťame napríklad automatické testy jednotiek a testy používateľského rozhrania. Po nasadení skontrolujeme, či nasadenie prebehlo dobre alebo zle. Ale už máte jasný zoznam akcií, ktoré sa musia pri nasadzovaní do produkcie opakovať znova a znova.
A až keď sú vaše procesy formalizované, začnete vyberať produkty, ktoré vám pomôžu tieto procesy automatizovať.
Bohužiaľ, veľmi často vidím, že sa to deje naopak. Akonáhle niekto začuje slovo „DevOps“, okamžite navrhne inštaláciu Jenkins, pretože veria, že akonáhle si nainštaluje Jenkins, bude mať DevOps. Nainštalovali si Jenkinsa, prečítali si články „Ako na to“ na webovej stránke Jenkins, pokúsili sa do týchto článkov napchať procesy a potom prišli k ľuďom a naklonili sa k nim s tým, že kniha hovorí, že to musíte urobiť takto, tak to robíme takto.
Nie je to tak, že Jenkins je zlý nástroj. V žiadnom prípade to nechcem povedať. Ale toto je len jeden z produktov. A ktorý produkt použijete, by malo byť vaším posledným rozhodnutím a v žiadnom prípade nie prvým. Váš produkt by sa nemal riadiť implementáciou kultúry a prístupov. Toto je veľmi dôležité pochopiť, a preto trávim toľko času na tejto snímke a tak dlho to všetko vysvetľujem.
Poďme sa baviť o postupoch DevOps všeobecne. Čo sú zač? V čom je rozdiel? Ako ich vyskúšať? Prečo sú dôležité?
Prvý postup, o ktorom ste možno počuli, sa nazýva nepretržitá integrácia. Možno má niekto z projektu nepretržitú integráciu (CI).
Najväčší problém je, že najčastejšie, keď sa človeka spýtam: „Máte na projekte CI?“ a on povie: „Áno,“ a keď sa ho opýtam, čo robí, opíše mi úplne celý proces automatizácie. Nie je to celkom pravda.
V skutočnosti je prax CI zameraná len na integráciu kódu, ktorý píšu rôzni ľudia, do akejsi jedinej kódovej základne. To je všetko.
Spolu s CI zvyčajne existujú aj iné postupy – ako napríklad nepretržité nasadzovanie, správa vydaní, ale o tom si povieme neskôr.
Samotné CI nám hovorí, že kód píšu rôzni ľudia a tento kód musí byť neustále integrovaný do jedinej kódovej základne.
Čo nám to dáva a prečo je to dôležité? Ak máme DotNet, tak je to dobré, je to kompilovaný jazyk, môžeme si skompilovať našu aplikáciu. Ak sa skompiluje, je to už dobré znamenie. To ešte nič neznamená, ale je to prvé dobré znamenie, že môžeme aspoň kompilovať.
Potom môžeme spustiť niekoľko testov, čo je tiež samostatná prax. Všetky testy sú zelené – to je druhé dobré znamenie. Ale opäť to nič neznamená.
Ale prečo by ste to robili? Všetky praktiky, o ktorých dnes budem hovoriť, majú približne rovnakú hodnotu, teda približne rovnaké výhody a sú aj merané približne rovnako.
Po prvé, umožňuje vám urýchliť doručenie. Ako vám to umožňuje urýchliť doručenie? Keď urobíme nejaké nové zmeny v našej kódovej základni, môžeme sa okamžite pokúsiť niečo urobiť s týmto kódom. Nečakáme, kým príde štvrtok, pretože vo štvrtok to uvoľníme do prostredia QA Environment, robíme to priamo tu a práve tu.
Poviem vám jeden smutný príbeh z môjho života. Bolo to dávno, keď som bol ešte mladý a pekný. Teraz som už mladý, krásny a šikovný a skromný. Pred časom som bol v projekte. Mali sme veľký tím asi 30 vývojárov. A mali sme veľký, veľký Enterprise projekt, ktorý sa vyvíjal asi 10 rokov. A mali sme rôzne pobočky. V úložisku sme mali pobočku, v ktorej kráčali vývojári. A bola tam pobočka, ktorá zobrazovala verziu kódu, ktorá je vo výrobe.
Produkčná vetva zaostala za pobočkou, ktorá bola k dispozícii vývojárom, o 3 mesiace. Čo to znamená? To znamená, že akonáhle mám niekde chybu, ktorá ide do výroby vinou vývojárov, pretože to povolili, a vinou QA, pretože sa na to pozreli, znamená to, že ak dostanem úlohu pre hotfix pre produkciu, potom musím vrátiť zmeny kódu pred 3 mesiacmi. Musím si spomenúť, čo som mal pred 3 mesiacmi a pokúsiť sa to tam opraviť.
Ak ste túto skúsenosť ešte nemali, môžete si ju vyskúšať na svojom domácom projekte. Hlavná vec je, že to neskúšajte na komerčnom. Napíšte pár riadkov kódu, zabudnite na ne na šesť mesiacov a potom sa vráťte a skúste rýchlo vysvetliť, o čom tieto riadky kódu sú a ako ich môžete opraviť alebo optimalizovať. Je to veľmi, veľmi vzrušujúci zážitok.
Ak máme prax nepretržitej integrácie, potom nám to umožňuje skontrolovať ju pomocou množstva automatizovaných nástrojov priamo tu a práve teraz, hneď ako napíšem svoj kód. Možno mi to nedá úplný obraz, no napriek tomu to odstráni aspoň niektoré riziká. A ak sa vyskytne nejaká potenciálna chyba, budem o nej vedieť hneď teraz, teda doslova za pár minút. Nebudem sa musieť vrátiť o 3 mesiace späť. Budem sa musieť vrátiť o 2 minúty späť. Dobrý kávovar ani nestihne uvariť kávu za 2 minúty, takže je to celkom fajn.
To má tú hodnotu, že sa to môže opakovane opakovať na každom projekte, t.j. nielen ten, na ktorom ste ho nastavili. Môžete zopakovať samotnú prax a samotná CI sa bude opakovať pri každej novej zmene, ktorú v projekte urobíte. To vám umožňuje optimalizovať zdroje, pretože váš tím pracuje efektívnejšie. Už sa vám nestane, že vám príde chyba z kódu, s ktorým ste pracovali pred 3 mesiacmi. Už nebudete mať prepínanie kontextu, keď budete sedieť a prvé dve hodiny sa snažiť pochopiť, čo sa vtedy stalo a dostať sa do podstaty kontextu skôr, ako začnete niečo opravovať.
Ako môžeme merať úspech alebo neúspech tejto praxe? Ak nahlásite veľkému šéfovi, čo sme implementovali na projekte CI, počuje bla bla bla. Zaviedli sme to, dobre, ale prečo, čo nám to prinieslo, ako to meriame, ako správne alebo nesprávne to implementujeme?
Prvým je, že vďaka CI môžeme nasadzovať čoraz častejšie a častejšie práve preto, že náš kód je potenciálne stabilnejší. Tak isto sa nám skracuje čas na nájdenie chyby a skracuje sa čas na opravu tejto chyby práve z toho dôvodu, že práve tu a práve teraz dostávame zo systému odpoveď, čo je v našom kóde zlé.
Ďalšou praxou, ktorú máme, je prax Automation Testing, ktorá sa najčastejšie spája s praxou CI. Idú ruka v ruke.
Čo je tu dôležité pochopiť? Je dôležité pochopiť, že naše testy sú odlišné. A každý automatizovaný test je zameraný na riešenie vlastných problémov. Máme napríklad unit testy, ktoré nám umožňujú testovať modul samostatne, t.j. Ako to funguje vo vákuu? Toto je dobré.
Máme tiež integračné testy, ktoré nám umožňujú pochopiť, ako sa rôzne moduly navzájom integrujú. Je to tiež dobré.
Môžeme mať testy automatizácie používateľského rozhrania, ktoré nám umožňujú skontrolovať, ako dobre práca s používateľským rozhraním spĺňa určité požiadavky stanovené zákazníkom atď.
Konkrétne testy, ktoré spustíte, môžu ovplyvniť, ako často ich spúšťate. Jednotkové testy sú zvyčajne písané krátke a malé. A môžu sa spúšťať pravidelne.
Ak hovoríme o testoch automatizácie používateľského rozhrania, potom je dobré, ak je váš projekt malý. Vaše testy automatizácie používateľského rozhrania môžu trvať určitý čas. Ale zvyčajne je test automatizácie používateľského rozhrania niečo, čo na veľkom projekte trvá niekoľko hodín. A je dobré, ak je to pár hodín. Jediná vec je, že nemá zmysel spúšťať ich pre každú zostavu. Má zmysel ich spúšťať v noci. A keď ráno všetci prišli do práce: testeri aj vývojári, dostali nejaké hlásenie, že sme v noci spustili autotest používateľského rozhrania a dostali sme tieto výsledky. A tu bude hodina práce servera, ktorý skontroluje, či váš produkt spĺňa nejaké požiadavky, oveľa lacnejšia ako hodina práce toho istého QA inžiniera, aj keď ide o Junior QA inžiniera, ktorý pracuje za jedlo a poďakovanie. Napriek tomu bude hodina prevádzky stroja lacnejšia. Preto má zmysel doň investovať.
Mám ďalší projekt, na ktorom som pracoval. Na tomto projekte sme absolvovali dvojtýždňové šprinty. Projekt bol veľký, dôležitý pre finančný sektor a nedala sa urobiť chyba. A po dvojtýždňovom šprinte nasledoval vývojový cyklus testovací proces, ktorý trval ďalšie 4 týždne. Skúste si predstaviť rozsah tragédie. Kód píšeme dva týždne, potom to urobíme ala CodeFreeze, zabalíme ho do novej verzie aplikácie a sprístupníme testerom. Testeri ho testujú ešte 4 týždne, t.j. Kým ho testujú, my máme čas pripraviť pre nich ďalšie dve verzie. Toto je naozaj smutný prípad.
A povedali sme im, že ak chcete byť produktívnejší, má pre vás zmysel implementovať postupy automatického testovania, pretože práve tu a teraz vás to bolí.
Precvičte si nepretržité nasadenie. Skvelé, dokončili ste stavbu. Toto je už dobré. Váš kód sa skompiloval. Teraz by bolo pekné nasadiť túto zostavu na nejaké prostredie. Povedzme v prostredí pre vývojárov.
Prečo je to dôležité? Najprv sa môžete pozrieť na to, ako ste úspešní so samotným procesom nasadenia. Stretol som sa s podobnými projektmi, keď sa opýtam: „Ako nasadíte novú verziu aplikácie?“, chalani mi povedia: „Zložíme to a zabalíme do zip archívu. Pošleme ho adminovi poštou. Správca stiahne a rozšíri tento archív. A celá kancelária sa začne modliť, aby server prevzal novú verziu.“
Začnime niečím jednoduchým. Napríklad zabudli vložiť CSS do archívu alebo zabudli zmeniť hashtag v názve súboru java-script. A keď odošleme požiadavku na server, prehliadač si myslí, že už má tento súbor java-script a rozhodne sa ho nesťahovať. A bola tu stará verzia, niečo tomu chýbalo. Vo všeobecnosti môže byť veľa problémov. Prax Continuous Deployment vám preto umožňuje aspoň otestovať, čo by sa stalo, keby ste urobili čistý referenčný obrázok a nahrali ho do úplne čistého nového prostredia. Môžete vidieť, kam to vedie.
Taktiež, keď medzi sebou integrujete kód, t.j. medzi príkazmi vám to umožňuje tiež vidieť, ako to vyzerá v používateľskom rozhraní.
Jedným z problémov, ktoré sa vyskytujú tam, kde sa používa veľa vanilkového java-scriptu, je, že dvaja vývojári neuvážene deklarovali premennú s rovnakým názvom v objekte okna. A potom, v závislosti od šťastia. Koho súbor java-script vytiahne ako druhý, prepíše zmeny toho druhého. Je to tiež veľmi vzrušujúce. Vstúpte: jedna vec funguje na jednu osobu, iná nefunguje na druhú. A je to „úžasné“, keď to všetko vyjde vo výrobe.
Ďalšou praxou, ktorú máme, je postup automatického obnovenia, konkrétne návrat k predchádzajúcej verzii aplikácie.
Prečo je to dôležité pre vývojárov? Stále sa nájdu takí, ktorí si pamätajú vzdialené, vzdialené 90. roky, keď počítače boli veľké a programy malé. A jediná cesta k vývoju webu bola cez PHP. Nie je to tak, že by PHP bol zlý jazyk, aj keď je.
Ale problém bol iný. Keď sme nasadili novú verziu našej php stránky, ako sme ju nasadili? Najčastejšie sme otvárali Far Manager alebo niečo iné. A nahral tieto súbory na FTP. A zrazu sme si uvedomili, že máme nejakú malú, malú chybu, napríklad sme zabudli dať bodkočiarku alebo zabudli zmeniť heslo k databáze a existuje heslo k databáze, ktoré je na lokálnom hostiteľovi. A rozhodneme sa rýchlo pripojiť k FTP a upravovať súbory priamo tam. Toto je len oheň! Toto bolo populárne v 90. rokoch.
Ale ak ste sa nepozreli do kalendára, 90. roky boli takmer pred 30 rokmi. Teraz sa všetko deje trochu inak. A skúste si predstaviť rozsah tragédie, keď vám povedia: „Nasadili sme do výroby, ale niečo sa tam pokazilo. Tu je vaše FTP prihlasovacie meno a heslo, pripojte sa k produkcii a rýchlo to tam opravte.“ Ak ste Chuck Norris, bude to fungovať. Ak nie, riskujete, že ak opravíte jednu chybu, urobíte ďalších 10. To je presne dôvod, prečo vám táto prax návratu k predchádzajúcej verzii umožňuje dosiahnuť veľa.
Aj keď sa niekde niečo zlé dostalo do produktu, potom je to zlé, ale nie smrteľné. Môžete sa vrátiť k predchádzajúcej verzii, ktorú máte. Nazvite to zálohou, ak je to jednoduchšie pochopiť v tejto terminológii. Môžete sa vrátiť k tejto predchádzajúcej verzii a používatelia budú môcť naďalej pracovať s vaším produktom a budete mať k dispozícii dostatočný čas vyrovnávacej pamäte. Toto všetko môžete pokojne bez zhonu vziať a otestovať lokálne, opraviť a potom nahrať novú verziu. Naozaj to dáva zmysel.
Teraz skúsme nejako spojiť dve predchádzajúce praktiky dohromady. Dostaneme tretí s názvom Release Management.
Keď hovoríme o Continuous Deployment v jeho klasickej podobe, hovoríme, že musíme stiahnuť kód z nejakej vetvy z úložiska, skompilovať ho a nasadiť. Je dobré, ak máme rovnaké prostredie. Ak máme niekoľko prostredí, znamená to, že musíme zakaždým stiahnuť kód, dokonca aj z rovnakého odovzdania. Zakaždým ho vytiahneme, zakaždým postavíme a nasadíme do nového prostredia. Po prvé, toto je čas, pretože postaviť projekt, ak máte veľký a pochádzate z 90. rokov, môže trvať niekoľko hodín.
Okrem toho je tu ďalší smútok. Keď staviate, dokonca aj na tom istom stroji, budete stavať rovnaké zdroje, stále nemáte záruku, že tento stroj je v rovnakom stave ako pri poslednom zostavovaní.
Povedzme, že niekto prišiel a aktualizoval DotNet za vás, alebo naopak, niekto sa rozhodol niečo odstrániť. A potom máte kognitívnu disonanciu, že z tohto odovzdania pred dvoma týždňami sme vytvárali zostavu a všetko bolo v poriadku, ale teraz sa zdá, že je to ten istý stroj, rovnaké odovzdanie, rovnaký kód, ktorý sa snažíme vytvoriť, ale nefunguje to . Budete sa tým zaoberať dlho a nie je pravda, že na to prídete. Minimálne si poriadne pokazíte nervy.
Preto prax správy verzií navrhuje zaviesť ďalšiu abstrakciu nazývanú archív artefaktov alebo galéria alebo knižnica. Môžete to nazvať ako chcete.
Hlavnou myšlienkou je, že akonáhle tam máme nejaký commit, povedzme, v pobočke, ktorú sme pripravení nasadiť do našich rôznych prostredí, zbierame aplikácie z tohto commitu a všetko, čo pre túto aplikáciu potrebujeme, zabalíme to. do archívu zip a uložte ho do nejakého spoľahlivého úložiska. A z tohto úložiska môžeme kedykoľvek získať tento zip archív.
Potom ho vezmeme a automaticky nasadíme do prostredia vývojárov. Pretekáme tam, a ak je všetko dobré, tak sa nasadíme do javiska. Ak je všetko v poriadku, nasadíme do produkcie rovnaký archív, rovnaké binárne súbory, skompilované presne raz.
Navyše, keď máme takúto galériu, pomáha nám to riešiť aj riziká, ktorým sme sa venovali na poslednej snímke, keď sme hovorili o návrate k predchádzajúcej verzii. Ak ste omylom nasadili niečo nesprávne, vždy môžete vziať akúkoľvek inú predchádzajúcu verziu z tejto galérie a rovnakým spôsobom ju vrátiť do týchto prostredí. To vám umožní ľahko sa vrátiť k predchádzajúcej verzii, ak sa niečo pokazí.
Existuje ďalšia skvelá prax. Vy aj ja všetci chápeme, že keď vrátime naše aplikácie na predchádzajúcu verziu, môže to znamenať, že potrebujeme aj infraštruktúru predchádzajúcej verzie.
Keď hovoríme o virtuálnej infraštruktúre, veľa ľudí si myslí, že toto je niečo, čo nastavujú správcovia. A ak potrebujete, povedzme, získať nový server, na ktorom chcete otestovať novú verziu svojej aplikácie, musíte napísať lístok správcom alebo vývojárom. Devops to bude trvať 3 týždne. A po 3 týždňoch vám povedia, že sme pre vás nainštalovali virtuálny stroj s jedným jadrom, dvoma gigabajtmi RAM a serverom Windows bez DotNet. Poviete: "Ale ja som chcel DotNet." Oni: "Dobre, vráť sa o 3 týždne."
Myšlienkou je, že používaním infraštruktúry ako postupov kódovania môžete svoju virtuálnu infraštruktúru považovať len za ďalší zdroj.
Ak niekto z vás vyvíja aplikácie na DotNet, možno ste už počuli o knižnici s názvom Entity Framework. A možno ste už počuli, že Entity Framework je jedným z prístupov, ktoré Microsoft aktívne presadzuje. Pre prácu s databázou ide o prístup s názvom Code First. Toto je, keď v kóde opíšete, ako chcete, aby vaša databáza vyzerala. A potom nasadíte aplikáciu. Pripojí sa k databáze, sám určí, ktoré tabuľky tam sú a ktoré nie a vytvorí všetko potrebné.
To isté môžete urobiť so svojou infraštruktúrou. Nie je rozdiel medzi tým, či potrebujete databázu pre projekt alebo či potrebujete Windows server pre projekt. Je to len zdroj. A môžete automatizovať vytváranie tohto zdroja, môžete automatizovať konfiguráciu tohto zdroja. Preto zakaždým, keď budete chcieť otestovať nejaký nový koncept, nejaký nový prístup, nebudete musieť písať lístok do devops, môžete si jednoducho nasadiť izolovanú infraštruktúru pre seba z hotových šablón, z hotových skriptov a implementovať ju tu sú všetky vaše experimenty. Môžete to odstrániť, získať nejaké výsledky a nahlásiť o tom ďalšie informácie.
Ďalšou praxou, ktorá tiež existuje a je tiež dôležitá, ale málokto ju používa, je Monitorovanie výkonu aplikácií.
Chcel som povedať len jednu vec o monitorovaní výkonu aplikácií. Čo je na tejto praxi najdôležitejšie? To je Monitorovanie výkonu aplikácií približne rovnaké ako oprava bytu. Toto nie je konečný stav, je to proces. Musíte to robiť pravidelne.
V dobrom slova zmysle by bolo dobré vykonávať monitorovanie výkonu aplikácií na takmer každej zostave, aj keď, ako viete, nie je to vždy možné. Musí sa to však vykonať minimálne pri každom vydaní.
Prečo je to dôležité? Pretože ak náhle pocítite pokles výkonu, musíte jasne pochopiť prečo. Ak má váš tím, povedzme, dvojtýždňové sprinty, potom by ste aspoň raz za dva týždne mali nasadiť vašu aplikáciu na nejaký samostatný server, kde máte jasne fixovaný procesor, RAM, disky atď. A spustiť tie isté výkonnostné testy . Dostanete výsledok. Pozrite sa, ako sa zmenil oproti predchádzajúcemu sprintu.
A ak zistíte, že čerpanie išlo niekde prudko dole, bude to znamenať, že to bolo len kvôli zmenám, ktoré sa udiali za posledné dva týždne. To vám umožní identifikovať a vyriešiť problém oveľa rýchlejšie. A opäť ide o približne rovnaké metriky, pomocou ktorých môžete merať, ako úspešne ste to urobili.
Ďalšou praxou, ktorú máme, je prax Configuration Management. Je veľmi málo tých, ktorí to berú vážne. Ale verte mi, toto je v skutočnosti veľmi vážna vec.
Nedávno sa stala vtipná historka. Chlapci prišli za mnou a povedali: "Pomôžte nám vykonať bezpečnostný audit našej aplikácie." Dlho sme sa spolu pozerali na kód, povedali mi o aplikácii, kreslili diagramy. A plus mínus všetko bolo logické, zrozumiteľné, bezpečné, no bolo tu jedno ALE! Vo svojom zdrojovom ovládaní mali konfiguračné súbory, vrátane tých z produkcie s IP databázou, s loginmi a heslami na pripojenie k týmto databázam atď.
A ja hovorím: „Chlapci, dobre, uzavreli ste svoje produkčné prostredie firewallom, ale už to, že máte prihlasovacie meno a heslo do produkčnej databázy priamo v ovládaní zdroja a môže si ho prečítať každý vývojár, je už obrovské bezpečnostné riziko. . A bez ohľadu na to, aká super bezpečná je vaša aplikácia z hľadiska kódu, ak ju necháte pod kontrolou zdroja, nikdy nikde neprejdete žiadnym auditom.“ To je to o čom hovorím.
Správa konfigurácie. V rôznych prostrediach môžeme mať rôzne konfigurácie. Napríklad môžeme mať rôzne prihlasovacie mená a heslá pre databázy pre QA, demo, produkčné prostredie atď.
Táto konfigurácia môže byť tiež automatizovaná. Vždy by mal byť oddelený od samotnej aplikácie. prečo? Pretože ste aplikáciu vytvorili raz a potom je jej jedno, či sa pripojíte na SQL server cez takú a takú IP alebo takú a takú IP, mala by fungovať rovnako. Preto, ak zrazu jeden z vás stále pevne kóduje pripojovací reťazec v kóde, pamätajte, že vás nájdem a potrestám, ak sa so mnou ocitnete na rovnakom projekte. Toto je vždy umiestnené v samostatnej konfigurácii, napríklad v súbore web.config.
A táto konfigurácia je už riadená oddelene, t. j. presne v tomto momente môžu prísť vývojár a administrátor a sadnúť si do jednej miestnosti. A vývojár môže povedať: „Pozri, tu sú binárne súbory mojej aplikácie. Oni pracujú. Aplikácia potrebuje na fungovanie databázu. Tu vedľa binárnych súborov je súbor. V tomto súbore je toto pole zodpovedné za prihlásenie, toto je heslo, toto je IP. Nasaďte ho kdekoľvek." A pre správcu je to jednoduché a jasné. Spravovaním tejto konfigurácie ho dokáže nasadiť naozaj kdekoľvek.
A posledná prax, o ktorej by som chcel hovoriť, je prax, ktorá veľmi, veľmi súvisí s oblakmi. A maximálny efekt prináša, ak pracujete v cloude. Toto je automatické odstránenie vášho prostredia.
Viem, že na tejto konferencii je viacero ľudí z tímov, s ktorými spolupracujem. A so všetkými tímami, s ktorými spolupracujem, používame túto prax.
prečo? Samozrejme, bolo by skvelé, keby mal každý vývojár virtuálny stroj, ktorý by fungoval 24 hodín denne, 7 dní v týždni. Ale možno je to pre vás novinka, možno ste tomu nevenovali pozornosť, ale samotný vývojár nefunguje 24/7. Vývojár zvyčajne pracuje 8 hodín denne. Aj keď príde do práce skôr, má veľký obed, počas ktorého ide do posilňovne. Nech je to 12 hodín denne, kedy vývojár skutočne využíva tieto zdroje. Podľa našej legislatívy máme 5 zo 7 dní v týždni, ktoré sa považujú za pracovné dni.
V súlade s tým by tento stroj nemal počas pracovných dní pracovať 24 hodín, ale iba 12 hodín a cez víkendy by tento stroj nemal fungovať vôbec. Zdalo by sa, že všetko je veľmi jednoduché, ale čo je dôležité tu povedať? Zavedením tohto jednoduchého postupu do tohto základného plánu vám umožňuje znížiť náklady na údržbu týchto prostredí o 70 %, t. j. vzali ste cenu svojho vývoja, kontroly kvality, ukážky, prostredia a vydelili ste ju 3.
Otázkou je, čo so zvyškom peňazí? Napríklad vývojári by si mali kúpiť ReSharper, ak tak ešte neurobili. Alebo urobte koktailovú párty. Ak ste predtým mali jedno prostredie, v ktorom sa pásli vývojári aj QA, a to je všetko, teraz si môžete vytvoriť 3 rôzne prostredia, ktoré budú izolované a ľudia si nebudú navzájom prekážať.
Čo sa týka snímky s priebežným meraním výkonu, ako môžeme porovnávať výkon, ak sme v projekte mali v databáze 1 záznamov, o dva mesiace neskôr je ich milión? Ako pochopiť, prečo a aký je zmysel merania výkonu?
To je dobrá otázka, pretože výkon by ste mali vždy merať na rovnakých zdrojoch. To znamená, že zavádzate nový kód, meriate výkon na novom kóde. Napríklad potrebujete otestovať rôzne výkonové scenáre, povedzme, že chcete otestovať, ako aplikácia funguje pri nízkej záťaži, kde je 1 000 používateľov a veľkosť databázy je 5 gigabajtov. Zmerali ste to a získali čísla. Ďalej vezmeme ďalší scenár. Napríklad 5 000 používateľov, veľkosť databázy 1 terabajt. Dostali sme výsledky a zapamätali si ich.
Čo je tu dôležité? Dôležité tu je, že v závislosti od scenára, objemu dát, počtu simultánnych používateľov atď. môžete naraziť na určité limity. Napríklad na limit sieťovej karty, alebo na limit pevného disku, alebo na limit možností procesora. Toto je dôležité, aby ste pochopili. V rôznych scenároch narazíte na určité limity. A číslam musíte rozumieť, keď ich trafíte.
Hovoríme o meraní výkonu v špeciálnom testovacom prostredí? To znamená, že toto nie je výroba?
Áno, toto nie je výroba, toto je testovacie prostredie, ktoré je vždy rovnaké, aby ste si ho mohli porovnať s predchádzajúcimi meraniami.
Dobrý deň, dobre!
Ak nie sú žiadne otázky, myslím, že môžeme skončiť. Ďakujem!
Zdroj: hab.com