A jelentés néhány DevOps-gyakorlatról fog beszélni, de fejlesztői szemszögből. Általában minden mérnök, aki csatlakozik a DevOps-hoz, már több éves adminisztratív tapasztalattal rendelkezik. De ez nem jelenti azt, hogy itt nincs helye a fejlesztőnek. A fejlesztők leggyakrabban „a nap következő sürgősen kritikus hibájának” kijavításával vannak elfoglalva, és arra sincs idejük, hogy egy pillantást vetjenek a DevOps mezőre. A szerző felfogása szerint a DevOps először is a józan ész. Másodszor, ez egy lehetőség a hatékonyabb működésre. Ha Ön fejlesztő, van józan esze, és hatékonyabb szeretne lenni csapatjátékosként, akkor ez a jelentés neked szól.
Hadd mutatkozzam be, teljes mértékben elismerem, hogy vannak olyan emberek a teremben, akik nem ismernek. A nevem Anton Boyko, a Microsoft Azure MVP-je vagyok. Mi az az MVP? Ez a Model-View-Presenter. A Model-View-Presenter pontosan én vagyok.
Ezen kívül jelenleg a Ciklum megoldástervezői pozícióját töltöm be. Nemrég vettem magamnak egy ilyen gyönyörű domaint, és frissítettem az e-mailemet, amit általában bemutatókon mutatok meg. Írhatsz nekem a következő címre: me [kutya] byokoant.pro. Kérdéseivel e-mailben fordulhat hozzám. Általában válaszolok rájuk. Az egyetlen dolog, hogy nem szeretnék e-mailben olyan kérdéseket kapni, amelyek két témára vonatkoznak: politikára és vallásra. Minden másról írhatsz nekem emailben. Eltelik egy kis idő, válaszolok.
Pár szó magadról:
- 10 éve vagyok ezen a területen.
- A Microsoftnál dolgoztam.
- Alapító atyja vagyok az ukrán Azure közösségnek, amelyet valahol 2014-ben alapítottunk. És még mindig megvan és fejlesztjük.
- Édesapja vagyok az Azure konferencia alapítójának is, amelynek Ukrajnában adunk otthont.
- A Global Azure Bootcamp szervezésében is segítek Kijevben.
- Mint mondtam, a Microsoft Azure MVP-je vagyok.
- Gyakran beszélek konferenciákon. Nagyon szeretek konferenciákon felszólalni. Az elmúlt évben körülbelül 40 alkalommal léphettem fel. Ha elhalad Ukrajna, Fehéroroszország, Lengyelország, Bulgária, Svédország, Dánia, Hollandia, Spanyolország mellett, vagy ad vagy vesz el egy másik európai országot, akkor nagyon is lehetséges, hogy amikor egy olyan konferenciára megy, amelynek felhőtémája van, láthatsz engem a felszólalók listáján.
- Én is Star Trek rajongó vagyok.
Beszéljünk egy kicsit az Agendáról. Napirendünk nagyon egyszerű:
- Beszélni fogunk arról, hogy mi az a DevOps. Beszéljük meg, miért fontos ez. Korábban a DevOps kulcsszó volt, amit az önéletrajzodba írtál, és azonnal kapott +500 dollár fizetést. Most például a blokkláncot kell beírnod az önéletrajzodba, hogy +500 dollár legyen a fizetésed.
- Aztán, ha egy kicsit megértjük, mi ez, beszélünk arról, hogy mik a DevOps gyakorlatok. De nem annyira általában a DevOps kontextusában, hanem azokról a DevOps gyakorlatokról, amelyek érdekesek lehetnek a fejlesztők számára. Elmondom, miért érdekelhetik Önt. Elmondom, miért kell ezt egyáltalán megtenned, és hogyan segíthet kevesebb fájdalmat tapasztalni.
Hagyományos kép, amit sokan mutatnak. Sok projektben ez történik. Ilyenkor vannak fejlesztési és üzemeltetési részlegeink, amelyek támogatják szoftvereinket. És ezek a részlegek nem kommunikálnak egymással.
Talán, ha nem éreznéd ezt olyan tisztán a DevOps és az üzemeltetési osztályokon, akkor analógiát vonhatsz a Fejlesztői és Minőségbiztosítási részleggel. Vannak, akik szoftvereket fejlesztenek, és vannak, akik a fejlesztők szemszögéből rossz minőségűek. Például lekötöm a csodálatos kódomat a repository-ba, és ott ül valami gazember, aki visszaküldi nekem ezt a kódot, és azt mondja, hogy rossz a kódod.
Mindez azért történik, mert az emberek nem kommunikálnak egymással. És átdobnak egymásnak néhány csomagot, valamilyen alkalmazást a félreértések falán, és megpróbálnak velük valamit kezdeni.
Pontosan ezt a falat hivatott lerombolni a DevOps kultúra, azaz. rákényszeríteni az embereket, hogy kommunikáljanak egymással, és legalább megértsék, mit csinálnak a projektben részt vevő különböző személyek, és miért fontos a munkájuk.
És amikor a DevOps-ról beszélünk, valaki azt fogja mondani, hogy a DevOps az, amikor a projekt folyamatos integrációval rendelkezik; valaki azt fogja mondani, hogy a DevOps az, ha a projekt megvalósítja az „infrastruktúra mint kód” gyakorlatot; valaki azt fogja mondani, hogy a DevOps első lépése a funkciók elágazása, a funkciójelzők.
Lényegében ez mind igaz a maga módján. De ezek csak a legvégső gyakorlataink. Mielőtt továbblépne ezekre a gyakorlatokra, javaslom, hogy nézze meg ezt a diát, amely bemutatja a Dev-Ops módszertan megvalósításának 3 szakaszát a projektben, az Ön vállalatában.
Ennek a diának van egy második nem hivatalos neve is. Keresgélhet az interneten, hogy megtudja, mi az a 3 DevOps testőr. Lehetséges, hogy megtalálja ezt a cikket. Miért 3 testőr? Alul ez áll: emberek, folyamatok és termékek, i.e. PPP – Porthos, Porthos és Porthos. Íme a DevOps 3 muskétása. Ez a cikk részletesebben leírja, miért fontos ez, és mit jelent.
Amikor elkezdi a DevOps kultúra megvalósítását, nagyon fontos, hogy a következő sorrendben kerüljön bevezetésre.
Kezdetben beszélned kell az emberekkel. És el kell magyaráznod az embereknek, hogy mi ez, és hogyan szerezhetnek hasznot belőle.
Konferenciánk a DotNet Fest nevet viseli. És ahogy a szervezők elmondták, elsősorban fejlesztői közönséget hívtunk ide, így remélem, hogy a teremben a legtöbben részt vesznek a fejlesztésben.
Beszélni fogunk az emberekről, beszélni fogunk arról, hogy a fejlesztők mindennap mit szeretnének csinálni. Mit akarnak a legjobban? Új kódot akarnak írni, újszerű keretrendszereket akarnak használni, új funkciókat szeretnének létrehozni. Mire vágynak a legkevésbé a fejlesztők? Javítsa ki a régi hibákat. Remélem egyetért velem. Ezt akarják a fejlesztők. Új funkciókat akarnak írni, nem hibákat akarnak javítani.
Egy adott fejlesztő által termelt hibák száma attól függ, mennyire egyenesek a karjai, és mennyire nőnek ki a vállától, és nem a fenékzsebétől. Ennek ellenére, amikor egy nagy projektünk van, néha előfordul, hogy lehetetlen mindent nyomon követni, ezért jó lenne, ha olyan megközelítéseket alkalmaznánk, amelyek segítségével stabilabb és jobb minőségű kódokat írhatunk.
Mire vágynak leginkább a QA-k? Nem tudom, hogy az előszobában vannak-e. Nehéz azt mondani, hogy minőségbiztosítást szeretnék, mert soha nem voltam az. És ne sértődj meg a srácokon, azt fogják mondani, hogy remélem soha nem fogom. De nem azért, mert értelmetlennek és haszontalannak tartom a munkájukat, hanem mert nem tartom magam olyan embernek, aki ezt a munkát hatékonyan el tudná végezni, ezért meg sem kísérlem. De amennyire én megértem, amit a QA a legtöbb nem szeret, az az, hogy reggelente dolgozik, állandóan valamilyen regressziós tesztet futtat, ugyanazokat a hibákat lépteti fel, amelyeket 3 sprinttel ezelőtt jelentettek a fejlesztőknek, és azt mondják: „Mikor fogsz , Monsieur D 'Artagnan, javítsa ki ezt a hibát.' És Monsieur D'Artagnan válaszol neki: "Igen, igen, igen, már javítottam." És hogyan történik, hogy kijavítottam egy hibát, és közben csináltam 5-öt.
Azok, akik ezt a megoldást élesben támogatják, azt szeretnék, hogy ez a megoldás hibamentesen működjön, hogy ne kelljen minden pénteken újraindítani a szervert, amikor minden normális ember a bárba megy. A fejlesztők pénteken telepítették, az adminisztrátorok szombatig ülnek, és megpróbálják felállítani és javítani ezt a telepítést.
És amikor elmagyarázza az embereknek, hogy ugyanazokat a problémákat kívánják megoldani, akkor továbbléphet a folyamatok formalizálására. Ez nagyon fontos. Miért? Mert amikor azt mondjuk, hogy „formalizálás”, akkor fontos, hogy leírd, hogyan zajlanak le folyamataid legalább valahol egy szalvétán. Meg kell értenie, hogy ha például egy minőségbiztosítási környezetbe vagy egy éles környezetbe telepít, akkor az mindig ebben a sorrendben történik; ezekben a szakaszokban például automatikus egységteszteket és felhasználói felület teszteket futtatunk. A telepítés után ellenőrizzük, hogy a telepítés jól vagy rosszul sikerült-e. De már van egy világos listája azokról a műveletekről, amelyeket újra és újra meg kell ismételni az éles üzembe helyezéskor.
És csak a folyamatok formalizálása után kezdi el kiválasztani azokat a termékeket, amelyek segítenek automatizálni ezeket a folyamatokat.
Sajnos nagyon gyakran látom, hogy ez fordítva történik. Amint valaki meghallja a „DevOps” szót, azonnal a Jenkins telepítését javasolja, mert úgy gondolják, hogy amint telepíti a Jenkinst, lesz DevOps. Telepítették a Jenkinst, elolvasták a „Hogyan” cikkeket a Jenkins webhelyén, megpróbáltak folyamatokat beletömni ezekbe a How to cikkekbe, majd odajöttek az emberekhez, és lehajolták az embereket, mondván, hogy a könyv szerint ezt így kell csinálni. szóval mi így csináljuk.
Nem arról van szó, hogy Jenkins rossz eszköz. Semmiképpen nem akarom ezt mondani. De ez csak egy a termékek közül. És hogy melyik terméket használja, az legyen az utolsó döntése, és semmi esetre sem az első. Termékét nem a kultúra és megközelítések megvalósítása vezérelheti. Ezt nagyon fontos megérteni, ezért töltök annyi időt ezen a dián és magyarázom mindezt oly sokáig.
Beszéljünk a DevOps gyakorlatokról általában. Kik ők? Mi a különbség? Hogyan lehet felpróbálni őket? Miért fontosak?
Az első gyakorlat, amelyről talán hallott, a folyamatos integráció. Talán valaki a projektben rendelkezik folyamatos integrációval (CI).
A legnagyobb probléma az, hogy leggyakrabban, amikor megkérdezem egy személytől: „Van CI a projektben?” és azt mondja: „Igen”, majd amikor megkérdezem, mit csinál, leírja nekem a teljes automatizálási folyamatot. Ez nem teljesen igaz.
Valójában a CI gyakorlata csak arra irányul, hogy a különböző emberek által írt kódot valamilyen egységes kódbázisba integrálja. Ez minden.
A CI mellett általában más gyakorlatok is léteznek – például a folyamatos üzembe helyezés, a kiadáskezelés, de erről később fogunk beszélni.
A CI maga azt mondja, hogy különböző emberek írnak kódot, és ezt a kódot folyamatosan integrálni kell egyetlen kódbázisba.
Mit ad ez nekünk, és miért fontos? Ha van DotNetünk, akkor az jó, ez egy fordított nyelv, le tudjuk fordítani az alkalmazásunkat. Ha összeáll, az már jó jel. Ez még nem jelent semmit, de ez az első jó jel, amit legalább összeállíthatunk.
Ezután lefuttathatunk néhány tesztet, ami szintén külön gyakorlat. A tesztek mind zöldek – ez a második jó jel. De ez megint nem jelent semmit.
De miért tennéd ezt? Az összes gyakorlat, amelyről ma beszélni fogok, megközelítőleg azonos értékű, azaz megközelítőleg ugyanolyan előnyökkel jár, és hozzávetőlegesen ugyanúgy mérik őket.
Először is lehetővé teszi a kézbesítés felgyorsítását. Hogyan teszi lehetővé ez a kézbesítés felgyorsítását? Amikor néhány új módosítást végzünk a kódbázisunkban, azonnal megpróbálhatunk valamit kezdeni ezzel a kóddal. Nem várjuk meg, amíg eljön a csütörtök, mert csütörtökön adjuk ki a QA Environment számára, itt és itt tesszük meg.
Elmesélek egy szomorú történetet az életemből. Nagyon régen volt, amikor még fiatal és jóképű voltam. Most már fiatal vagyok, szép és okos, és szerény. Nemrég részt vettem egy projektben. Nagy, körülbelül 30 fős fejlesztői csapatunk volt. És volt egy nagy, nagy Enterprise projektünk, amely körülbelül 10 évig fejlődött. És különböző ágaink voltak. Az adattárban volt egy fiókunk, amelyben a fejlesztők jártak. És volt egy ág, amely megjelenítette a kód éles verzióját.
A termelési ág 3 hónappal lemaradt a fejlesztők számára elérhető ág mögött. Mit is jelent ez? Ez azt jelenti, hogy amint van valahol egy bug, ami a fejlesztők hibájából gyártásba megy, mert ők megengedték, és a QA hibájából, mert megnézték, akkor ez azt jelenti, hogy ha kapok egy feladat az éles gyorsjavításhoz, akkor vissza kell vonnom a 3 hónappal ezelőtti kódmódosításaimat. Emlékeznem kell arra, ami 3 hónappal ezelőtt volt, és meg kell próbálnom ott javítani.
Ha még nem élte át ezt a tapasztalatot, kipróbálhatja otthoni projektjében. A lényeg az, hogy ne kereskedelmi forgalomban próbáld. Írjon néhány sor kódot, felejtse el őket hat hónapra, majd térjen vissza, és próbálja meg gyorsan elmagyarázni, miről szólnak ezek a kódsorok, és hogyan javíthatja vagy optimalizálhatja őket. Nagyon-nagyon izgalmas élmény.
Ha van egy Folyamatos integrációs gyakorlatunk, akkor ez lehetővé teszi, hogy számos automatizált eszközzel ellenőrizzük itt és most, amint megírtam a kódomat. Lehet, hogy ez nem ad teljes képet számomra, de ennek ellenére legalább néhány kockázatot kiküszöböl. És ha van esetleges hiba, azonnal, szó szerint pár perc múlva tudni fogok róla. Nem kell visszahúznom 3 hónapot. Csak 2 percet kell visszatekernem. Egy jó kávéfőzőnek még 2 perc alatt sem lesz ideje lefőzni a kávét, szóval ez nagyon klassz.
Ennek megvan az az értéke, hogy minden projektnél időről időre megismételhető, pl. nem csak az, amelyiken beállítottad. Megismételheti magát a gyakorlatot, és magát a CI-t is meg kell ismételni a projekten végrehajtott minden új változtatásnál. Ez lehetővé teszi az erőforrások optimalizálását, mivel csapata hatékonyabban dolgozik. Többé nem lesz olyan helyzet, amikor hiba érkezik a kódból, amellyel 3 hónappal ezelőtt dolgozott. Nem lesz többé kontextusváltásod, amikor leülsz és az első két órát azzal töltöd, hogy megértsd, mi történt akkor, és belemerülj a kontextus lényegébe, mielőtt valamit javítani kezdesz.
Hogyan mérhetjük ennek a gyakorlatnak a sikerét vagy kudarcát? Ha beszámol a nagyfőnöknek, hogy mit valósítottunk meg a CI-projektben, azt hallja, bla bla bla. Megvalósítottuk, oké, de miért, mit hozott nekünk, hogyan mérjük, mennyire helyesen vagy helytelenül valósítjuk meg?
Az első az, hogy a CI-nek köszönhetően egyre gyakrabban telepíthetjük, és éppen azért gyakrabban, mert potenciálisan stabilabb a kódunk. Ugyanígy csökken a hibakeresési időnk és a hiba kijavítására fordított idő éppen amiatt, hogy itt és most kapunk választ a rendszertől, hogy mi a baj a kódunkkal.
Egy másik gyakorlatunk az Automation Testing gyakorlat, amely leggyakrabban a CI gyakorlattal együtt jár. Kéz a kézben járnak.
Mit fontos itt megérteni? Fontos megérteni, hogy tesztjeink különböznek egymástól. És minden automatizált teszt a saját problémáinak megoldására irányul. Vannak például egységtesztjeink, amelyek lehetővé teszik egy modul külön tesztelését, pl. Hogyan működik vákuumban? Ez jó.
Vannak integrációs tesztjeink is, amelyek segítségével megérthetjük, hogy a különböző modulok hogyan integrálódnak egymással. Az is jó.
Rendelkezhetnek UI automatizálási tesztekkel, amelyek lehetővé teszik annak ellenőrzését, hogy a felhasználói felülettel végzett munka mennyire felel meg bizonyos, az ügyfél által támasztott követelményeknek stb.
A futtatott konkrét tesztek befolyásolhatják a futtatás gyakoriságát. Az egységtesztek általában rövidek és kicsik. És rendszeresen indíthatók.
Ha UI automatizálási tesztekről beszélünk, akkor jó, ha kicsi a projektje. A felhasználói felület automatizálási tesztjei eltarthatnak egy ideig. De általában egy felhasználói felület automatizálási tesztje több órát vesz igénybe egy nagy projektnél. És jó, ha néhány óra. Az egyetlen dolog, hogy nincs értelme minden buildnél futtatni őket. Érdemes éjszaka futtatni őket. És amikor reggel mindenki munkába állt: a tesztelők és a fejlesztők is, valamiféle jelentést kaptak arról, hogy éjszaka lefuttattuk a felhasználói felület automatikus tesztjét, és ezeket az eredményeket kaptuk. És itt sokkal olcsóbb egy óra munka egy kiszolgálónak, aki ellenőrzi, hogy az Ön terméke megfelel-e bizonyos követelményeknek, mint ugyanazon minőségbiztosítási mérnök egy óra munkája, még akkor is, ha ő junior minőségbiztosítási mérnök, aki élelmiszerért és köszönetért dolgozik. Mindazonáltal olcsóbb lesz egy óra gépkezelés. Ezért van értelme ebbe befektetni.
Van még egy projektem, amin dolgozom. Két hetes sprintünk volt ezen a projekten. A projekt nagy volt, fontos a pénzügyi szektor számára, és nem lehetett hibát elkövetni. Kéthetes sprint után pedig a fejlesztési ciklust egy tesztelési folyamat követte, ami további 4 hetet vett igénybe. Próbáld elképzelni a tragédia mértékét. Két hétig írunk kódot, majd a CodeFreeze alatt megcsináljuk, becsomagoljuk az alkalmazás új verziójába, és kiadjuk a tesztelőknek. A tesztelők még 4 hétig tesztelik, i.e. Amíg tesztelik, van időnk még két verziót elkészíteni számukra. Ez egy igazán szomorú eset.
És elmondtuk nekik, hogy ha produktívabb szeretnél lenni, akkor ésszerű az automatizált tesztelési gyakorlatok alkalmazása, mert ez az, ami most itt és most fáj.
Folyamatos telepítés gyakorlása. Remek, elkészült az építkezés. Ez már jó. A kódot lefordították. Most jó lenne ezt az építményt valamilyen környezetben telepíteni. Mondjuk egy fejlesztői környezetben.
Miért fontos? Először is megnézheti, mennyire sikeres magával a telepítési folyamattal. Találkoztam már ilyen projektekkel, amikor megkérdezem: „Hogyan lehet telepíteni az alkalmazás új verzióját?”, a srácok azt mondják: „Összeállítjuk és becsomagoljuk egy zip archívumba. Postán elküldjük az adminnak. Az adminisztrátor letölti és kibontja ezt az archívumot. És az egész iroda imádkozni kezd, hogy a szerver vegye fel az új verziót.”
Kezdjük valami egyszerűvel. Például elfelejtették behelyezni a CSS-t az archívumba, vagy elfelejtették megváltoztatni a hashtaget a java-script fájlnévben. Amikor pedig kérést intézünk a szerverhez, a böngésző úgy gondolja, hogy már rendelkezik ezzel a java-script fájllal, és úgy dönt, hogy nem tölti le. És volt egy régi verzió, valami hiányzott. Általában sok probléma adódhat. Ezért a folyamatos üzembe helyezés gyakorlata lehetővé teszi, hogy legalább tesztelje, mi történne, ha tiszta referenciaképet készítene, és feltöltené egy teljesen tiszta új környezetbe. Láthatod, hová vezet ez.
Illetve, amikor kódot integrálsz egymás közé, pl. a parancs között, ez azt is lehetővé teszi, hogy megnézze, hogyan néz ki a felhasználói felületen.
Az egyik probléma, amely sok vanília java-script használatánál előfordul, az az, hogy két fejlesztő elgondolkodva deklarált egy azonos nevű változót az ablakobjektumban. Aztán a szerencsédtől függően. Akinek a java-script fájlját másodikként húzza ki, az felülírja a másik módosításait. Ez is nagyon izgalmas. Bejössz: az egyiknek egy dolog működik, a másiknak a másik nem. És „csodálatos”, amikor mindez megjelenik a gyártásban.
A következő gyakorlatunk az automatikus visszaállítás gyakorlata, nevezetesen az alkalmazás előző verziójára való visszagörgetés.
Miért fontos ez a fejlesztők számára? Még mindig vannak, akik emlékeznek a távoli, távoli 90-es évekre, amikor a számítógépek nagyok, a programok kicsik voltak. És a webfejlesztés egyetlen módja a PHP-n keresztül volt. Nem arról van szó, hogy a PHP rossz nyelv, pedig az.
De a probléma más volt. Amikor telepítettük a php webhelyünk új verzióját, hogyan helyeztük üzembe? Leggyakrabban a Far Managert vagy valami mást nyitottunk. És feltöltötte ezeket a fájlokat FTP-re. És hirtelen rájöttünk, hogy van valami apró, apró hibánk, például elfelejtettünk pontosvesszőt tenni, vagy elfelejtettük megváltoztatni az adatbázis jelszavát, és van egy jelszó az adatbázishoz, ami a helyi gazdagépen van. És úgy döntünk, hogy gyorsan csatlakozunk az FTP-hez, és ott szerkesztjük a fájlokat. Ez csak tűz! Ez volt népszerű a 90-es években.
De ha nem nézte a naptárat, a 90-es évek majdnem 30 évvel ezelőtt voltak. Most minden egy kicsit másképp történik. És próbáld elképzelni a tragédia mértékét, amikor azt mondják: „Áthelyeztük a termelést, de ott valami elromlott. Itt van FTP-bejelentkezési neve és jelszava, csatlakozzon az éles hálózathoz, és gyorsan javítsa ki a problémát." Ha te Chuck Norris vagy, ez működni fog. Ha nem, akkor azt kockáztatja, hogy ha kijavít egy hibát, akkor még 10-et csinál. Pontosan ez az oka annak, hogy az előző verzióra való visszatérés gyakorlata sok eredményt tesz lehetővé.
Még ha valahol valami rossz bekerült is a prod-ba, akkor az rossz, de nem végzetes. Visszatérhet az előző verzióhoz. Nevezzük tartaléknak, ha könnyebben értelmezhető ebben a terminológiában. Visszatérhet az előző verzióra, és a felhasználók továbbra is dolgozhatnak a termékkel, és elegendő pufferidővel rendelkezik. Nyugodtan, kapkodás nélkül veheti mindezt és tesztelheti helyben, javíthatja, majd feltöltheti az új verziót. Ennek tényleg van értelme.
Most próbáljuk meg valahogyan ötvözni a két korábbi gyakorlatot. Kapunk egy harmadikat is, Release Management néven.
Amikor a folyamatos üzembe helyezésről beszélünk a klasszikus formájában, azt mondjuk, hogy ki kell húznunk a kódot valamelyik ágból a tárolóból, le kell fordítanunk és telepítenünk kell. Jó, ha egyforma a környezetünk. Ha több környezetünk van, ez azt jelenti, hogy minden alkalommal ki kell húznunk a kódot, még ugyanabból a véglegesítésből is. Minden alkalommal kihúzzuk, minden alkalommal megépítjük és új környezetbe helyezzük. Először is itt az ideje, mert egy projekt felépítése, ha van egy nagy, és a 90-es évekből származik, akkor több órát is igénybe vehet.
Ezen kívül van még egy szomorúság. Amikor ugyanarra a gépre építed, ugyanazokat a forrásokat fogod készíteni, még mindig nincs garancia arra, hogy ez a gép ugyanolyan állapotban van, mint az utolsó build során.
Tegyük fel, hogy valaki belépett, és frissítette a DotNetet, vagy éppen ellenkezőleg, valaki úgy döntött, hogy töröl valamit. És akkor van egy kognitív disszonanciád, hogy ebből a két héttel ezelőtti commitból egy buildet építettünk, és minden rendben volt, de most úgy tűnik, hogy ugyanaz a gép, ugyanaz a véglegesítés, ugyanaz a kód, amit megpróbálunk építeni, de nem működik. . Sokáig fogsz ezzel foglalkozni, és nem tény, hogy rájössz. Legalább nagyon elrontod az idegeidet.
Ezért a kiadáskezelési gyakorlat egy további absztrakció bevezetését javasolja, amelyet műterméktárnak, galériának vagy könyvtárnak neveznek. Nevezheted, ahogy akarod.
A fő ötlet az, hogy amint van valamilyen commit ott, mondjuk egy fiókban, amelyet készen állunk arra, hogy telepítsük a különböző környezeteinkbe, összegyűjtjük az alkalmazásokat ebből a véglegesítésből és mindent, ami ehhez az alkalmazáshoz kell, csomagoljuk. egy zip archívumba, és mentse el valamilyen megbízható tárhelyre. Ebből a tárolóból pedig bármikor megkaphatjuk ezt a zip archívumot.
Ezután vesszük, és automatikusan telepítjük a fejlesztői környezetbe. Ott versenyzünk, és ha minden rendben van, akkor kiállunk a színpadra. Ha minden rendben van, akkor ugyanazt az archívumot telepítjük az élesre, ugyanazokat a binárisokat, pontosan egyszer lefordítva.
Ezen túlmenően, ha van egy ilyen galériánk, az segít kezelni azokat a kockázatokat is, amelyekkel az utolsó dián foglalkoztunk, amikor az előző verzióra való visszaállításról beszéltünk. Ha véletlenül valamit rosszul telepített, bármikor átvehet bármely másik korábbi verziót ebből a galériából, és ugyanúgy visszaállíthatja ezekre a környezetekre. Ez lehetővé teszi, hogy könnyen visszaállítsa az előző verziót, ha valami elromlik.
Van még egy nagyszerű gyakorlat. Ön és én mindannyian megértjük, hogy amikor visszaállítjuk alkalmazásainkat egy korábbi verzióra, ez azt jelentheti, hogy szükségünk lesz az előző verzió infrastruktúrájára is.
Amikor a virtuális infrastruktúráról beszélünk, sokan azt gondolják, hogy ezt az adminisztrátorok állítják be. És ha mondjuk új szervert kell szerezned, amelyen tesztelni szeretnéd az alkalmazásod új verzióját, akkor írnod kell egy jegyet az adminoknak vagy a devopoknak. A Devopsnak ehhez 3 hétre lesz szüksége. És 3 hét múlva elmondják, hogy telepítettünk egy virtuális gépet, egy maggal, két gigabájt RAM-mal és egy Windows szerverrel DotNet nélkül. Azt mondod: "De én DotNetet akartam." Ők: "Rendben, gyere vissza 3 hét múlva."
Az ötlet az, hogy az infrastruktúra kódolási gyakorlatként való használatával virtuális infrastruktúráját csak egy másik erőforrásként kezelheti.
Talán, ha valaki közületek fejleszt alkalmazásokat a DotNeten, akkor hallott már az Entity Framework nevű könyvtárról. És talán még azt is hallottad, hogy az Entity Framework egyike azon megközelítéseknek, amelyeket a Microsoft aktívan szorgalmaz. Az adatbázisokkal való munkához ez a Code First nevű megközelítés. Ekkor leírja a kódban, hogyan szeretné kinézni az adatbázisát. Ezután telepítse az alkalmazást. Csatlakozik az adatbázishoz, maga határozza meg, hogy mely táblák vannak és melyek nincsenek, és létrehoz mindent, amire szüksége van.
Ugyanezt megteheti infrastruktúrájával. Nincs különbség aközött, hogy adatbázisra van szüksége egy projekthez, vagy Windows szerverre van szüksége egy projekthez. Ez csak egy erőforrás. És automatizálhatja ennek az erőforrásnak a létrehozását, automatizálhatja ennek az erőforrásnak a konfigurációját. Ennek megfelelően minden alkalommal, amikor valamilyen új koncepciót, új megközelítést szeretne tesztelni, nem kell jegyet írnia a devops-hoz, egyszerűen telepíthet magának egy izolált infrastruktúrát kész sablonokból, kész szkriptekből és implementálhatja azt. ott az összes kísérleted. Ezt törölheti, eredményeket kaphat, és további jelentéseket készíthet róla.
A következő gyakorlat, ami szintén létezik és szintén fontos, de kevesen alkalmazzák, az Alkalmazásteljesítmény-figyelés.
Csak egy dolgot akartam mondani az Alkalmazásteljesítmény-felügyeletről. Mi a legfontosabb ebben a gyakorlatban? Ez az, amit az Alkalmazásteljesítmény-figyelés körülbelül ugyanaz, mint egy lakás javítása. Ez nem végleges állapot, ez egy folyamat. Rendszeresen kell csinálni.
Jó értelemben jó lenne szinte minden builden végrehajtani az Alkalmazásteljesítmény-figyelést, bár, mint tudod, ez nem mindig lehetséges. De legalább minden kiadásnál végre kell hajtani.
Miért fontos? Mert ha hirtelen teljesítménycsökkenést tapasztal, akkor világosan meg kell értenie, miért. Ha a csapatnak mondjuk kéthetes sprintje van, akkor legalább kéthetente egyszer telepítse az alkalmazást valamilyen külön szerverre, ahol egyértelműen rögzített processzor, RAM, lemezek stb. vannak. És futtassa le ugyanazokat a teljesítményteszteket. . Megkapod az eredményt. Nézze meg, hogyan változott az előző sprinthez képest.
És ha megtudja, hogy a lehívás valahol meredeken csökkent, az azt jelenti, hogy ez csak az elmúlt két hétben bekövetkezett változások miatt történt. Ez lehetővé teszi a probléma sokkal gyorsabb azonosítását és megoldását. És még egyszer, ezek nagyjából ugyanazok a mérőszámok, amelyekkel mérheti, hogy mennyire sikerült.
A következő gyakorlatunk a konfigurációkezelési gyakorlat. Nagyon kevesen vannak, akik ezt komolyan veszik. De hidd el, ez valójában nagyon komoly dolog.
Nemrég volt egy vicces történet. A srácok odajöttek hozzám, és azt mondták: „Segítsen alkalmazásunk biztonsági auditálásában.” Sokáig nézegettük együtt a kódot, meséltek az alkalmazásról, rajzoltak diagramokat. És plusz-mínusz minden logikus, érthető, biztonságos, de volt egy DE! Konfigurációs fájlok voltak a forrásvezérlőjükben, beleértve az IP-adatbázissal rendelkező éles verziójúakat is, bejelentkezési nevekkel és jelszavakkal az adatbázisokhoz való csatlakozáshoz stb.
Én pedig azt mondom: „Srácok, oké, tűzfallal lezártátok az éles környezetet, de az a tény, hogy az éles adatbázis bejelentkezési neve és jelszava közvetlenül a forrásvezérlőben van, és bármelyik fejlesztő el tudja olvasni, már óriási biztonsági kockázatot jelent. . És nem számít, mennyire biztonságos az alkalmazás kód szempontjából, ha a forrásvezérlésben hagyja, akkor soha nem fog átmenni semmilyen auditon sehol.” Erről beszélek.
Konfiguráció-menedzsment. Különböző környezetekben eltérő konfigurációkkal rendelkezhetünk. Például különböző bejelentkezési neveink és jelszavaink lehetnek a minőségbiztosítási, demó-, termelési környezet stb. adatbázisaihoz.
Ez a konfiguráció automatizálható is. Mindig külön kell lennie magától az alkalmazástól. Miért? Mivel egyszer elkészítette az alkalmazást, és akkor az alkalmazásnak mindegy, hogy ilyen és olyan IP-n keresztül csatlakozik-e az SQL szerverhez, vagy olyan és olyan IP-n keresztül, ugyanúgy működnie kell. Ezért, ha hirtelen egyikőtök még mindig keményen kódolja a kapcsolódási karakterláncot a kódban, akkor ne feledje, hogy megkereslek és megbüntetlek, ha ugyanazon a projekten találja magát velem. Ez mindig egy külön konfigurációba kerül, például a web.config fájlba.
Ezt a konfigurációt pedig már külön kezelik, vagyis pontosan ez az a pillanat, amikor egy teremben ülhet egy fejlesztő és egy rendszergazda. A fejlesztő pedig azt mondhatja: „Nézd, itt vannak az alkalmazásom binárisai. Dolgoznak. Az alkalmazás működéséhez adatbázisra van szükség. Itt a binárisok mellett van egy fájl. Ebben a fájlban ez a mező felelős a bejelentkezésért, ez a jelszóért, ez az IP-ért. Telepítse bárhol." És ez egyszerű és világos az adminisztrátor számára. Ennek a konfigurációnak a kezelésével valóban bárhol telepítheti.
És az utolsó gyakorlat, amelyről szeretnék beszélni, egy olyan gyakorlat, amely nagyon-nagyon kapcsolódik a felhőkhöz. És maximális hatást hoz, ha felhőben dolgozik. Ez a környezet automatikus eltávolítása.
Tudom, hogy többen is részt vesznek ezen a konferencián azon csapatokból, akikkel együtt dolgozom. És az összes csapatnál, akikkel dolgozom, ezt a gyakorlatot alkalmazzuk.
Miért? Természetesen jó lenne, ha minden fejlesztőnek lenne egy virtuális gépe, amely éjjel-nappal működne. De lehet, hogy ez újdonság számodra, talán nem figyeltél, de maga a fejlesztő nem dolgozik éjjel-nappal. Egy fejlesztő általában napi 24 órát dolgozik. Még ha korán jön is dolgozni, van egy nagy ebédje, amely alatt edzőterembe megy. Legyen napi 7 óra, amikor a fejlesztő ténylegesen használja ezeket az erőforrásokat. Jogszabályaink szerint egy héten 24 napból 7 munkanapnak számít.
Ennek megfelelően hétköznap ez a gép ne 24 órát, hanem csak 12 órát, hétvégén pedig egyáltalán ne működjön. Úgy tűnik, hogy minden nagyon egyszerű, de mit kell itt mondani? Ha ezt az egyszerű gyakorlatot ezen az alapütemezésen hajtja végre, lehetővé teszi, hogy 70%-kal csökkentse ezeknek a környezeteknek a fenntartási költségeit, azaz a fejlesztő, a minőségbiztosítás, a demó, a környezet árát elosztotta 3-mal.
A kérdés az, hogy mit kezdjünk a maradék pénzzel? Például a fejlesztőknek meg kell vásárolniuk a ReSharpert, ha még nem tették meg. Vagy egy koktélpartit. Ha korábban volt egy környezeted, amelyben a dev és a QA is legeltetett, és ennyi, most 3 különbözőt készíthetsz, amelyek elszigetelődnek, és az emberek nem zavarják egymást.
A folyamatos teljesítményméréses dia kapcsán hogyan tudnánk összehasonlítani a teljesítményt, ha a projektben 1 rekord volt az adatbázisban, két hónappal később millió? Hogyan lehet megérteni, hogy miért és mi a célja a teljesítmény mérésének?
Ez jó kérdés, mert mindig ugyanazon az erőforrásokon kell mérni a teljesítményt. Azaz új kódot dob ki, és az új kódon méri a teljesítményt. Például különböző teljesítményforgatókönyveket kell tesztelni, tegyük fel, hogy szeretné tesztelni, hogyan teljesít az alkalmazás kis terhelés mellett, ahol 1 felhasználó van, és az adatbázis mérete 000 gigabájt. Megmérted és megkaptad a számokat. Ezután egy másik forgatókönyvet veszünk. Például 5 felhasználó, az adatbázis mérete 5 terabájt. Megkaptuk az eredményeket és emlékeztünk rájuk.
Mi itt a fontos? Itt az a fontos, hogy a forgatókönyvtől, az adatmennyiségtől, az egyidejű felhasználók számától stb. függően bizonyos korlátokba ütközhet. Például egy hálózati kártya határáig, vagy egy merevlemez határáig, vagy a processzor képességeinek határáig. Ez az, amit fontos megértened. Különböző forgatókönyvek esetén bizonyos korlátokba ütközik. És meg kell értened a számokat, amikor eltalálod őket.
Arról beszélünk, hogy speciális tesztkörnyezetben mérjük a teljesítményt? Vagyis ez nem termelés?
Igen, ez nem termelés, ez egy tesztkörnyezet, ami mindig ugyanaz, hogy össze lehessen hasonlítani a korábbi mérésekkel.
Értem köszi!
Ha nincs kérdés, azt hiszem, befejezhetjük. Köszönöm!
Forrás: will.com