Bevezetés a DevOps Szemléletbe

DevO s

Bevezetés a DevOps szemléletbe a Visual Studio 2015 segítségével!

Bevezetés Egy jó rendszer, alkalmazás elkészítése nem fejeződik be azon a ponton, amikor annak kódja elkészül, és mindenki örömmel veszi tudomásul, hogy az elvárásoknak megfelelően működik. Nemcsak, hogy nem fejeződik be, de gyakran a munka nehezebb része csak ekkor kezdődik! Egy rendszer felhasználói számára — főleg, ha üzleti felhasználókról van szó — az igazi értéket nem az a kód  jelenti, amelyet a fejlesztő előállít, még akkor sem, ha jó minőségű kódról van szó. Az értéket az éles körülmények között működő alkalmazás képviseli, amely a felhasználó kat elvárásaiknak megfelelően segíti céljaik elérésében és előttük álló akadályok leküzdésében. Fejlesztőként felhasználói szemmel kell nézned az általad készített rendszerekre, alkalmazásokra: Alkalmazásod felhasználóknak készül. Azoknak a céloknak az elérésében, azoknak a problémáknak a megoldásában kell segítenie őket, amelyekkel munkájuk, élethelyzetük során találkoznak. Az alkalmazásnak éles környezetben kell működnie ! Hiába készítettél el egy jó rendszert, annak a nálad működő változata az ügyfél számára legfeljebb ígéretet jelent. Akkor tekinti azt hasznosnak, ha az abban az éles környezetben működik, ahol folyamatosan használhatja. A változás az alkalmazás életének szerves része. Egy jól megtervezett és elkészített rendszer használata során a felhasználók újabb ötletekkel, elképzelésekkel állhatnak elő — vagy akár hibákat is jelezhetnek feléd. Alkalmazásodat ennek megfelelően kell módosítanod, és elérhetővé tenned. Gyorsnak kell lenned és jó minőséget kell szállítanod ! Felhasználóid számára komoly jelentőséggel bír az, hogy az ötleteiket, igényeiket gyorsan megvalósítod, a talált hibákat azonnal javítod, és az így módosított alkalmazást/rendszert birtokba vehetik. Tanulnod kell a tapasztalatokból! Minden felhasználói visszajelzést, hibáidat, sikereidet és megfigyeléseidet fel kell használnod, hogy azokból tanulva még értékesebb rendszert készíthess! Ebben az írásban egy népszerű szemléletmóddal, a DevOps-szal DevOps-szal ismerkedhetsz meg. Ezt egyre több szoftverfejlesztéssel foglalkozó cég, szervezet használja azért, hogy az üzleti működéséhez kapcsolódó szoftvereket készítsen , és biztosítsa azok folyamatos használatá t. A DevOps szemléletet — annak egyes rés zeit —  nagyon sok eszköz támogatja. A piacon elérhető kevés teljeskörű támogatást kínáló eszközök közül az egyik a Visual Studio Team Services. Ez a Visual Studio IDE I DE és a Microsoft Azure kapcsolódó szolgáltatásaival szol gáltatásaival együtt minden fontos képességet biztosí t, amellyel a DevOps megközelítési módot sikerre viheted.

Szoftver követelmények 

Tartalom ........................................ ........................... .......................... .......................... .......................... ........................... ......................... ........... 2 Bevezetés .......................... ........................................ .......................... ........................... ........................... ............... .. 4 1. Üzleti környezet és DevOps ........................... ...................................... .......................... ........................... ........................... ............. 8 2. A DevOps alapelvek és a felhő ......................... ...................................... .......................... ................ ... 13 3. A Visual Studio Team Services és a DevOps ......................... 4. Folyamatos üzleti tervezés .......................... ........................................ ........................... .......................... .......................... ................ ... 17 ....................................... ........................... .......................... ............. 22 5. Együttműködésen alapuló fejlesztés ......................... ....................................... .......................... ........................... ........................... .......................... ............. 27 6. Folyamatos tesztelés .......................... ....................................... .......................... ........................... .................. .... 32 7. Folyamatos kibocsátás és élesítés .......................... 8. Folyamatos mon itorozás ......................... ...................................... ........................... ........................... .......................... .................... ....... 37 ....................................... ........................... ........................ ........... 41 9. Visszacsatolások folyamatos kezelése ......................... ........................................ ........................... .......................... .......................... .......................... ........................... ....................... ......... 43 Összegzés..........................

1. Üzleti környezet és DevOps A szoftverfejlesztés a számítógépek és az első programok megjelenése óta folyamatosan jelen van a vállalatok, vállalkozások és szervezetek életében. Amíg néhány évtizeddel ezelőtt ez csak a nagyobb, tőkeerős szervezetek privilégiuma volt, napjainkban a z ilyen szoftveralkalmazások — azok fejlesztése és értékesítése — már egy induló „garázscég” számára is könnyen hozzáférhetővé vált. Az alkalmazások jelentős része üzleti környezetben működik. Felhasználókat, ügyfeleket segítenek céljaik elérésében, adott problémáik megoldásában. Az informatika és az eszközök egyre közelebb kerülnek a felhasználókhoz, fogyasztókhoz. Az üzleti környezet fogalmát egy szoftver kapcsán ma már nemcsak egy cég belső üzleti folyamata kapcsán értelmezhetjük , hanem a fogyasztók kiszolgálásának kontextusában is. Egy mobiltelefonon működő online játék, egy felhasználói csoport tagjai közt beszélgetést biztosító alkalmazás környezete éppen úgy üzleti környezetet jelenthet , mint egy bank folyószámla -nyilvántartó rendszeréé.

Szoftver követelmények Amíg a szoftverfejlesztés hajnalán a legtöbb rendszer alapvetően az adatok kezelése és feldolgozása köré csoportosult, ma a fogyasztók, felhasználók igényei nek kiszolgálása, problémá ik megoldása van a középpontban. Az adatok kezelése és feldolgozása ma már csupán eszköz. Ez az átalakulás radikális hatást gyakorolt a szoftverfejlesztésre: a szoftver követelmények napjainkban nagyon hamar elavulnak. Az 1-1 ábra egy   2012-ben végzett kutatás eredményét mutatja be, amelyben a University of Missouri kutatói valós üzleti környezetben végzett szoftverfejlesztési projekteken vizsgálták azt, hogy a követelmények milyen gyorsan avulnak el.

1-1 ábra: A szoftverkövetelmények felezési idejének változása

Az ábra üzenete nagyon fontos: ha ma olyan szoftver fejlesztésébe kezd egy cég/szervezet, amely három hónapnál hosszabb időtartamot vesz igénybe, számolnia kell azzal, hogy az eredeti követelmények jelentős része már elavulttá válhat a projekt végére!

Hatékonyság

Hatékonyság Nagyon sok szoftverfejlesztési projekt  fullad kudarcba, de legalábbis erőteljesen megoszlanak a vélemények abban a tekintetben, hogy azok sikeresek- e. A problémák látható része a költségek túllépése, az időkeretből való kicsúszás, de gyakran más nehézségek is társulnak ezekhez. Az üzleti szervezetek jelentős része hagyományos módszerekkel — elsősorban a vízesés-életciklus (waterfall life cycle) szemléletének használatával — nem tud megfelelő hatékonysággal választ adni a szoftverfejlesztés kihívásaira. Gyakran egy üzleti feladatot megoldó szoftver elkészülésekor már az eredeti probléma is átalakul és maga a megoldás is elavulttá válik. Ezen a nehézségen azok a szervezetek tudtak legelőször átlépni, amelyek felismerték, ho gy egy szoftver fejlesztése nem egyszerűen IT képesség, hanem maga is egy fontos fo ntos üzleti folyamat.

DevOps A DevOps  DevOps  mint fogalom 2009-ben kezdett el terjedni , és a nevéből felismerhetően a szoftverfejlesztés (Development ) és az IT üzemeltetéssel foglalkozó szakterület ( Operations) nevének összeolvasztásából állt

elő. Mára a név már szemléletmódot, kultúrát, gyakorlatot jelent, amely az agilis szoftverfejlesztés értékeit, elveit, gyakorlati technikáit használva ad választ az üzleti környezetben végzett szoftverfejlesztés kihívásaira. A DevOps lényege, hogy a szoftverfejlesztésre üzleti folyamatként tekint. Ennek szellemében a nnak egészére — a probléma felmerülésétől, elemzésétől a megoldást biztosító szoftvertermék szo ftvertermék élesítéséig és követéséig — ad hatékonyságot biztosító szemléletmódot. A DevOps szemlélet az agilis elemeket olyan módon építi be a gyakorlatába, hogy azokat különböző méretű szervezetek, az egészen kicsiktől akár a nagyvállalatokig alkalmazhassák. A megközelítésmód négy fontos alapelvre épül: Az éles környezethez hasonló, azzal jelentősen megegyező környezetben végezzük a fejlesztést és tesztelést!  Ennek célja az, hogy a fejlesztés és tesztelés ne egy feltételezett, a valóságot radikálisan leegyszerűsítő környezetben történjen. Már a megvalósítás korai fázisában fel kell ismerni azokat a korlátozásokat, viselkedési formákat, amelyek az éles környezet sajátosságaiból fakadnak, hogy a fejlesztési folyamat során ehhez igazodva lehessen egy jól működő alkalmazást kialakítani. Az alkalmazás élesítése gyors, megismételhető és megbízható eljárással történjen ! Nagyon sok üzleti probléma megoldásának az értékét a rövid átfutási idő biztosítása adja — akár még megnövekedett ráfordítások mellett is. Hiába gyors egy szoftver kifejlesztése, ha annak élesítése hosszú időt vesz igénybe, vagy bosszantó hibajelenségekkel jár. Egy megfelelő —és megbízható — élesítési eljárás ezt a ciklus t  jelentősen felgyorsíthatja, biztosítva azt, hogy értékes termékképességek önállóan, nagy gyakorisággal is élesíthetők. Folyamatosan monitorozzuk és ellenőrizzük a rendszer működésének minőségét!  A legtöbb szervezet kiváló eszközökkel rendelkezik a már élesített rendszereinek vizsgálatára, a működés folyamatos monitorozására. Ezek elsősorban a rendszer minőségi jellemzőire fókuszálnak, de hasznos ellenőrzési eljárások is vannak, amelyek a működésbeli helyesség követését is lehetővé teszik. Ezeknek az eszközöknek a használata már a fejlesztés és a tesztelés során jelentősen javíthatja a folyamat hatékonyságát és a termék minőségét. Tegyük gyakoribbá a visszacsatolási ciklusokat! A DevOps szemlélet hatékonyságát jelentősen javítja az, hogy a szervezet folyamatosan tanul a hibáiból, még jobban megismeri azt az üzleti környezetet, amely ben egy adott szoftveres megoldást fejleszt. A gyakori visszacsatolások segítségével gyorsan változtathatók a fejlesztés prioritásai, az ütemtervek és a kibocsátások: hamarabb válaszolhatunk a környezet változásaira.

Minőség Bár a DevOps megnevezés csak a fejlesztésre és üzemeltetésre utal, a szemléletmód harmadik alapvető pillére — amint az a fenti alapelvekből is kiderül — a minőség biztosítása. Minden egyes alapelv azt hangsúlyozza, hogy az üzleti célok elérésének fontos része a funkcionális elvárások mellett a minőségi

1. Üzleti környezet és DevOps

elvárások teljesülése is. Az éleshez közel álló fejlesztői és teszt környezet, a megismételhető és megbízható telepítés, a folyamatos monitorozás, a gyakori visszacsatolások mind ezt a célt szolgálják.

Iterációk A teljes szoftverszállítási életciklust a DevOps folyamatos iterációk sorozataként kezeli, ahol az egyes iterációk életszerűen rövidek: lehetőséget adnak arra, hogy az üzleti környezet és a követelmények változását folyamatosan kezeljük. Az 1 -2 ábra az iterációk fő elemeit mutatja be.

1-2- ábra: A DevOps iterációk elemei

Az iterációs elemek mindegyike a folyamatos fol yamatos tanulásra, az üzleti környezethez való alkalmazkodásra épül (az angol terminológiában adoption path néven hivatkoznak csak rájuk). Az iterációkat áthatja a folyamatos visszacsatolás, amely hat alapvető technikára épül: Folyamatos üzleti tervezés Együttműködésen alapuló fejlesztés Folyamatos tesztelés Folyamatos kibocsátás és élesítés Folyamatos monitorozás Ügyfelek visszajelzésének folyamatos kezelése Az iterációk ezeket a technikákat az alábbi módon használják: Tervezés. Az üzleti célok kialakítása és igazítása folyamatosan, a felhasználók és ügyfelek visszacsatolása alapján történik. A tervezés során cél, hogy az ügyfelek gyorsan hozzájussanak azokhoz a termékképességekhez, amelyek számukra fontosak. Ez a megközelítés szem előtt t artja azt, hogy a visszacsatolások eredményeit azonnal be kell építeni az üzleti tervekbe, és ennek megfelelően változtatni az egyes termékképességek prioritásán. Fejlesztés és tesztelés. A termékképességek létrehozása során a fejlesztés és a tesztelés is ún. keresztfunkcionális csapatokkal történik, vagyis az üzleti elemzők, fejlesztők, tesztelők és minden más olyan kompetencia képviselője ott van a csapatban, akik együttesére szükség van az adott képesség előállításához. A termék megvalósításáért felelős csapat pontosan tisztában van azzal, hogy milyen elvárásoknak kell

Iterációk 

megfelelnie, és ezek mentén — beleértve az üzleti, funkcionális és minőségieket is —  folyamatosan teszteli az elkészítés alatt álló munkadarabokat. Élesítés. Csak azok a termékképességek t ermékképességek nyújtanak értékeket az ügyfeleknek, amelyek nemcsak elkészülnek, hanem azok élesítésre is kerülnek abban a környezetben, ahol azokat felhasználják. A DevOps szemlélettel dolgozó csapatok olyan automatizált telepítési eljárásokkal dolgoznak, amelyek segítik a termék gyors és megbízható továbbítását a fejlesztői környezetből a tesztelést és minőségbiztosítást végző környezetekbe éppen úgy, mint az éles üzleti működést biztosítóba. Üzemeltetés. Nemcsak a rendszer folyamatos üzemelésének — a szolgáltatás elvárt szintjének — biztosítása a cél, hanem az is, hogy a felhasználók és érintettek viselkedésének figyelésével olyan információt gyűjtsünk, amely segítségével a rendszer egyre jobbá tehető. Ez lehet szűk keresztmetszetek, gyakori problémák, ergonómiai hiányosságok stb. keresése éppen úgy, mint a folyamatok átalakítási lehetőségeinek, gyorsítási lehetőségeinek észlelése. Az üzemeltetés során gyűjtött információk a folyamatos üzleti tervezésen keresztül beépülve segítik a termék fejlődését. Bár az 1-2 ábra alapján úgy tűnhet, hogy egy -egy iteráció során a négy alapvető fázis egymást követi, a valóságban ezek párhuzamosan, egymást átfedve zajlanak. Miközben a csapat egy új termékváltozatot fejleszt, az üzleti tervezés az élesített rendszer monitorozásából nyert információra és visszacsatolások ra alapozva már újabb változatok kialakításán dolgozik.

2. A DevOps alapelvek és a felhő Nem véletlen, hogy a DevOps fogalom és szemlélet megjelenése nagyjából egy időbe esik a felhőszolgáltatások népszerűvé válásával. A felhő és a DevOps kölcsönösen katalizálják és értékessé teszik egymást. Ebben a fejezetben megismerheted, hogyan hatnak egymásra, hogyan segít hetnek együtt egy szervezetet a hatékony szoftverfejlesztésben.

Szűk keresztmetszet: környezetek A szoftverfejlesztési folyamat során egy termékképesség kifejlesztésének átfutási idejét leggyakrabban a hozzá kapcsolódó minőségbiztosítás, az ehhez szükséges fejlesztői és tesztelői környezet kialakításának időigénye — lassúsága — határozza meg. Ha egy olyan termékképességet tesztelünk, amelyhez szükség  van egy néhány gépből álló önálló környezetre, számtalan megoldandó feladat van, amelyek hagyományos módon (saját fizikai vagy virtuális vir tuális infrastruktúrával) nem mindig kezelhetők hatékonyan: Szükség lehet új hardverek beszerzésére (még virtuális környezetben is), ez akár heteket is igénybe vehet. A fizikai vagy virtuális gépek telepítéséhez üzemeltetési erőforrásokra van szükség, akik nem biztos, hogy pillanatnyilag rendelkezésre állnak. A fejlesztőcsapat ezt a tevékenységet általában —  jogosultságok érthető hiányában — nem végezheti el önállóan. Az eszközök és a fejlesztés alatt álló alkalmazás konfigurálása párbeszédet kíván a fejlesztést végző csapat és az infrastruktúrát üzemeltetők között, és ez a kommunikáció néha sok időt vesz igénybe . Nem lehet mindig hatékonyan felhasználni egy tesztrendszer felszabaduló erőforrásait —  a rendszer esetleg tétlenül áll, amikor éppen nem folyik a tesztelés. A folyamat egésze (beszerzéstől a környezet létrehozásáig, felszámolásáig) általában nem automatizálható teljesen — vagy legalábbis nem költséghatékonyan.

Felhő: költséghatékonyság, agilitás A felhőszolgáltatások segítségével ez a szűk keresztmetszet gyorsan, költséghatékonyan szüntethető meg: A környezet kialakításához szükséges erőforrások percek alatt beszerezhetők (a felhőben létrehozhatók). A telepítést — a környezet „felhúzását” — akár a fejlesztőcsapat is elvégezheti, hiszen ezzel a szervezet helyi infrastruktúráját érintetlenül hagyja. A telepítés szkriptek segítségével automatizálható, megismételhetővé tehető: adott tesztelési környezet így bármikor — akár több példányban is — létrehozható, majd ha szükségtelenné válik, lebontható. A környezet és a rajta futó alkalmazás konfigurálását önállóan (üzemeltetők bevonása nélkül) is elvégezheti a fejlesztőcsapat. A tesztkörnyezet használatánál csak a ténylegesen igénybe vett erőforrások után k ell fizetni. Egy éppen nem használt környezet percek alatt leállítható , így az inaktív időszakokban — éjszaka, illetve amikor éppen nem folyik a tesztelés —  ez nem jelent extra költségeket. Egy feleslegessé vált környezet percek alatt lebontható. A folyamat akár a beszerzéstől a környezet létrehozásán át annak felszámolásáig automatizálható.

 A felhő hatása a DevOps folyamatokra

A felhő hatása a DevOps folyamatokra A DevOps szemlélet egyik alapelve így szól: az éles környezethez hasonló, azzal jelentősen megegyező környezetben végezzük a fejlesztést és tesztelést !

A fejlesztést végző csapat el tudja készíteni az éles környezet megfelelőjét a felhőben. A legtöbb felhőplatform lehetőséget ad az így elkészült konfiguráció elmentésére, automatizált sokszoro zására. Ennek segítségével a DevOps szemléletet követő csapat olyan lehetőségekhez jut, amely jelentősen növelhetik napi működési hatékonyságát — a hagyományos fizikai környezetek létrehozásánál lévő felesleges várakozások kiküszöbölésével: A fejlesztői környezet saját maga is a felhőbe helyezhető a verziótártól a kódépítést biztosító eszközökön át egészen a fejlesztés során használt háttérrendszerekig (szolgáltatások, adatbázisok). Az automatizált környezetépítés segítségé vel a párhuzamos fejlesztési ágakon dolgozó csapatok  gyorsan saját, önálló fejlesztői környezethez juthatnak . Ez  jelentősen csökkenti a párhuzamos fejlesztések közös rendszeren való osztozásából származó kockázatot . Azzal, hogy a fejlesztői környezet automatikusan létrehozható, egyszerűvé válik a tesztelés és a felhasználói oktatás során használt környezetek megteremtése, éppen úgy, mint az éles üzemben használté. A fentiekből az is nyilvánvaló, hogy a felhő használatával így a DevOps szemlélet egy másik fontos alapelvét is alkalmazzuk: az alkalmazás élesítése gyors, megismételhető és megbízható eljárással történjen!

A felhőszolgáltatások a DevOps szemléletet még több képességgel is támogatják . Olyan — automatikusan beépített és konfigurálható —   infrastrukturális eszközöket tartalmaznak, amelyek segíti a felhőben lévő rendszerek működésének követését: egyszerűvé téve a DevOps folyamatos monitorozásra vonatkozó alapelvének követését.

IaaS és PaaS A felhőben lévő rendszereket többfajta modellben is létrehozhatjuk, annak megfelelően, hogy a felhő platform által kínált szolgáltatások közül melyek kezelését, felügyeletét szeretnénk magunk végezni, és melyeket bízzuk rá a platform szolgáltatójára. szol gáltatójára. Az Infrastructure-as-a-Service Infrastructure-as-a-Service (IaaS  (IaaS) modellben alapvetően virtuális gépeket hozunk létre a felhőben, amelyre mi magunk telepítjük az operációs rendszert és a felette lévő szoftver rétegeket, konfiguráljuk azokat . A Platform-as-a-Service  Platform-as-a-Service  (PaaS) modell alkalmazása esetén kész rendszer - és futásidejű környezet szolgáltatásokat kapunk, amelyekre mi magunk helyezzük el alkalmazásainkat, és csak is azokat kezelhetjük. A 2-1 ábra jól szemlélteti a két modell közötti különbségeket.

 2. A DevOps alapelvek és a felhő 

2-1 ábra: Felügyelet az IaaS és PaaS modellekben

Azok a DevOps csapatok, amelyek hosszabb múltra visszatekintő termékek fejlesztésével foglalkoznak, leggyakrabban az IaaS modellt használják, mert ez biztosít ja számunkra a legnagyobb szabadságot a környezetek előállítására és konfigurálására. Gyakran a múltból örökölt kód és eszközök csak ennek a modellnek a használatát teszik ésszerűvé. Azok a DevOps csapatok, akik elsősorban webes és mobil alkalmazásokat fejlesztenek, a PaaS modell használatával lehetnek leghatékonyabbak, ez ugyanis sokkal kevesebb telepítési és konfigurálási feladatot ró rájuk.

elhő Hibrid f elhő A felhő minden előnye mellett nagyon gyakoriak az olyan rendszerek, ahol biztosági, jogi, műszaki vagy egyéb okokból nem lehetséges egy rendszer összes komponensének a felhőben lévő környezetekbe mozgatása. A legtöbb felhőszolgáltató biztosítja az ún. hibrid felhő (hybrid cloud ) kialakítását, amely a bemutatott IaaS és PaaS modellnél összetettebb lehetősége l ehetősége ket biztosít: A felhő (virtualizált) és a fizikai infrastruktúra egymás mellett él. A fizikai és a virtuális infrastruktúra elemei úgy kommunikálhatnak egymással, mintha ugyanazon a fizikai helyen, például a vállalat adatközpontjában lennének. A felhőben lévő szolgáltatások éppen úgy elérhetik a „földi” szolgáltatásokat, mint ahogyan azok beszélgethetnek a felhőben lévő komponensekkel. Privát, virtuális privát és publikus felhő. A felhő infrastrukturális elemei nem feltétlenül kell, hogy a szolgáltató nyílt infrastruktúrájában legyenek (publikus felhő). Azokat a szolgáltató üzemeltetheti a felhőben elkülönített fizikai környezetben (virtuális privát), vagy akár az előfizető saját ( on-premises) adatközpontjában is. Az adatközpontok fejlődésének jelenlegi tendenciája, hogy a felhőben használt virtualizációs technológiákat az egyes szolgáltatók elérhetővé teszik saját ügyfeleik adatközpontjában is.

A Microsoft Azure és a DevOps A Microsoft saját felhőszolgáltatása, a Microsoft Azure, a Gartner elemzése alapján a kiemelkedők közé tartozik. Ezt jelenleg csak az Amazon és a Microsoft mondhatja el magáról, amint azt az 2-2 ábra is jelzi. Ez a két szolgáltató a felhő víziójának teljességével és megvalósítási képességének erejével tudja jelentős en megelőzni versenytársait.

 A Microsoft Azure és a DevOps DevOps

Az Azure képességeinek fejlesztése során a Microsoft folyamatosan szem előtt tartja a DevOps szemléletet, vagyis azt, hogy szolgáltatásával egyre hatékonyabban, egyre nagyobb fokú automatizált infrastruktúrát kínáljon IaaS és PaaS platformként.

2-2 ábra: A felhőszolgáltatások „bűvös négyzete” a Gartner 2015 májusi elemzése alapján

Az alábbi hivatkozások mindegyikén hasznos információt találsz, amelyek segítenek megvilágítani a Microsoft Azure DevOps képességeit:

Virtuális környezetek kialakítása Virtuális gépek létrehozása (IaaS) Virtuális hálózatok létrehozása (IaaS) Nagy rendelkezésre állású adattárak (Azure Storage) Stor age) létrehozása (PaaS) Skálázható relációs adatbázis (SQL Azure) létrehozása (PaaS) Skálázható NoSQL adatbázis (DocumenDB) létrehozása (PaaS) Azure Active Directory létrehozása (PaaS) BizTalk szolgáltatások kezelése (Hibrid) Privát és publikus felhő összekötése (Hibrid)

Fejlesztői szolgáltatások és alkalmazáselemek Visual Studio Team Services (a következő fejezetekben ezt a szolgáltatást részletesebben is bemutatjuk)

Együttműködésen alapuló fejlesztés támogatása az Azure DevLabs -szal Folyamatos monitorozás (Application Insights) Webes alkalmazások kialakítása Mobil alkalmazások kialakítása Kötegelt feldolgozáson alapuló alkalmazások Üzleti folyamatok automatizálása a backend -en (Logic Apps)

 2. A DevOps alapelvek és a felhő 

Alkalmazáshomlokzatok kialakítása Skálázható webes és mobil alkalmazások kialakítása

Adatelemzés SQL adattárház használata Hadoop a felhőben (HDInsights) Skálázható adattranszformációs szolgáltatások (Data Factory) Valós idejű adatok feldolgozása (Stream Analytics) Adatelemzés Machine Learning segítségével Természetesen a fentiek csak az Azure képességeinek egy részére mutatnak rá. A felhőben lévő környezetek kialakítása során alapvető az egyes szolgáltatások költségvonzatának az ismerete. Ezekről az alábbi hivatkozásokon tájékozódhatsz: Az Azure szolgáltatások árazásának részletei Költségkalkulátor környezetek kilakításának árbecsléséhez

3. A Visual Studio Team Services és a DevOps A Microsoft a saját termékei nek fejlesztése során a DevOps szemléletet és az agilis értékeket fo lyamatosan szem előtt tartja. Ennek talá n legjobb példája a Windows 10, az Azure és az Office 365 termékek fejlesztése. Ha ezeket a termékeket DevOps szemlélet nélkül próbálná a Microsoft kialakítani, nem működhetne például a Windows 10 Insider program, ah ol a fejlesztők átlagosan kéthetente (de néha hetente többször is) egy -egy új Windows 10 változathoz jutnak hozzá. Hasonló módon, az Azure és az Office 365 36 5 nem bővülhetne évente több tucat vagy többszáz új képességgel. A Microsoft a saját fejlesztőeszköz -rendszerét is ehhez a szemlélethez igazítja. A zászlóshajót zászló shajót a Visual Studio Team Services jelenti, amely a felhőben lévő fejlesztői szolgáltatások mellett olyan bérleti megoldásokat  is kínál, amellyel egy csapat tagjai havidíj alapon vehetik igénybe a fejlesztői gépükre telepített Visual Studio IDE-t és a kiegészítő eszközöket. Ebben a rövid fejezetben egy átfogó képet kapsz arról, hogy a Visual Studio Team Services (VSTS) milyen módon támogatja a DevOps működési modellt. A további fejezet ekben egyenként ism erheted meg a DevOps hat alapvető technikáját —  azt, hogyan is építhetsz a VSTS eszközkészletére ezek alkalmazása során .

Nyitott szolgáltatások Annak ellenére, hogy a VSTS nevében ott találod a Visual Studiót, a szolgáltatáskészlet semmilyen módon nem köti meg a kezed, meghagyja neked a fejlesztőeszköz és technológia választásának szabadságát. Én gyakran használtam az eszközkészletet az IntelliJ IDEA-val Java alkalmazások fejlesztésére, a WebStorm IDE vel TypeScript-alapú webes alkalmazások készítésére. Vannak olyan ügyfeleim, akik Android és iOS alkalmazások fejlesztése során veszik igénybe ezeket a szolgáltatásokat. sz olgáltatásokat. A VSTS egy jól átgondolt szolgáltatáskeretet kínál, támogatva a DevOps fázisait, az üzleti elemzést, a konstrukciós (fejlesztési és tesztelési ) fázist, az alkalmazások terítését, élesítését éppen úgy,  mint a folyamatos monitorozást és a visszajelzések kezelését. Te magad határozhatod meg, hogy ebből a keretből mit veszel igénybe, illetve annak egyes elemeit milyen tényleges eszközökkel és technológiákkal töltöd fel. A 3-1 ábra A VSTS piacterének egy képernyőjét mutatja be, amelyen a kódépítést támogató — szinte kivétel nélkül ingyenes — eszközök listája található. Ezeket telepítve (ne felejtsd el, ezek a felhőben települnek!) a projekted során használt DevOps környezet újabb eszközökkel bővül. Például, ha Apache Cordova alkalmazásokon dolgozol, a Cordova Build bővítmény olyan eszközkészletet helyez el a projektedben, amelyeket az automatikus kódkészítés során tudsz felhasználni —  kifejezetten Cordova-specifikus feladatok végrehajtására.

 3. A Visual Studio Team Services és a DevOps

3-1 ábra: Kódépítés segítő eszközök a VSTS piacterén

DevOps elemek és eszközök a VSTS-ben A VSTS segítségével fejlesztési (termékfejlesztési) munkáidat projektekbe csoportosíthatod. Egy ilyen projekt gyakorlatilag az együttműködő DevOps csapat összetartozó tevékenységeit és az ehhez szükséges eszközöket, eljárásokat foglalja keretbe. Minden projekt létrehozásakor az alábbi eszköztárat már az induláskor megkapod, és ezeket természetesen a piactéren megtalálható m egtalálható eszközökkel tovább is bővítheted: Feladatlista (backlog). Ez segít az üzleti tervezésben, a csapat feladatainak lebontásában, követésé ben, hibák, problémák és az ügyfelek visszajelzése inek követésében. Ez a feladatlista az alapja a projekt során végzett összes tevékenységednek. t evékenységednek.   vagy Team Verziótár (repository ). ). Minden projekte d indításakor létrehozhatsz egy verziótárat, amely ( Git  vagy Foundation Version Control ) típusú lehet. A későbbiekben projektedhez több verziótárat is hozzáadhatsz , azok típusát egyenként állíthatod. Természetesen külső (GitHub. Bitbucket stb.) tárakat is használhatsz a projekten, illetve vegyítheted azokat a VSTS -ben lévőkkel. A VSTS saját verziótárai szorosan integráltak a feladatlistával. Online kódszerkesztő eszközök. A projektedhez tartozó állományokat akár külön IDE vagy szerkesztőeszköz nélkül is létrehozhatod, módosíthatod a VSTS online felületén — nyilván ezt a lehetőséget folyamatos kódszerkesztésre nem célszerű használni. Kódépítő eszközök. Ezek jelentik az alapot a DevOps legtöbb „folyamatos” technikájához, beleértve az együttműködésen alapuló fejlesztést, tesztelést. Tesztelést segítő eszközök. A saját fejlesztési környezetedben használt automatikus tesztek mellett — amelyeket futtatását természetesen a kódépítés folyamatába illeszthet ed —, olyan eszközöket is kapsz egy

Saját kiterjesztések 

projektben, amelyekkel megtervezheted és végrehajthatod a manuális teszteket, kezelheted a tesztkörnyezeteidet, terheléses teszteket végezhetsz. Kibocsátások kezelése. Meghatározhatod azokat a kódkibocsátási folyamatot, amely az elkészített termékváltozatodat eljuttatja a megfelelő teszt, illetve éles környezetbe. Folyamatos monitorozás . A terméked készítése során használt fejlesztőeszközök és a hosztolást végző környezet (pl. Microsoft Azure) biztosítják azokat az al apvető komponenseket és szolgáltatásokat , amelyek a termék monitorozásához szükségesek.

Saját kiterjesztések Fejlesztőként lehetőséged van arra is, hogy saját tapasztalataidnak, gyakorlatodnak megfelelő eszközökkel bővítsed ki a VSTS -t. A publikus és dokumentált REST API -k segítségével a szolgáltatásokat könnyel elérheted saját eszközeidből. Az ún. Hook API -k lehetőséget adnak arra, hogy saját komponenseidet beilleszthesd a VSTS rendszerébe, pl. az ott zajló eseményekről értesítést kaphass, azokba beleavatkozhass. Olyan weboldalakat is készíthetsz, amelyekkel a VSTS felületét egészítheted ki saját funkciókkal — és mindezeket a kiterjesztéseket a piactéren is publikálhatod.

Csapatmunka, csapatmunka, csapatmunka! Magányos farkasokkal a DevOps nem működik. Az erejét éppen a csapat és az együttműködés adja, ezek nélkül elveszik a hatékonyság és az agilitás  is. A VSTS minden ízében ilyen csapatmunka megközelítésre épül. A projekt gazdája (létrehozója) definiálhatja a csapaton belüli szerepköröket, kialakíthatja az ehhez kapcsolódó jogosultságokat. A VSTS igen rugalmas ebben a tekintetben: egy rendkívül agilis modell („mindenki mindenhez hozzáférhet, minden tevékenységet végezhet”) éppen úgy kialakítható, mint a nagyvállaltokra jellemző erősen kötött, kifinomult szerepkör alapú  jogosultsági rendszer — akár címtár integrációval. A folyamatos együttműködést segítő eszközök támogatják a nyílt forráskódú fejlesztést végző közösségek folyamatmodelljeit (pl. (pl. pull  pull request ek ek kezelésének folyamata). Még egy hasznos dolog: ötfős vagy annál kisebb csapatok számára a VSTS legtöbb funkciója ingyenes. Ha egy kis létszámmal induló csapat átlépi ezt a határt, plusz licenceket vásárolhat a bővülő csapat új tagjainak.

Integráció a fejlesztőeszközökkel A VSTS erejét az adja, hogy szolgáltatásainak jelentős része közvetlenül elérhető a Visual Studio 2015 -ből, természetesen annak ingyenes változatából, a Visual Studio Community 2015 -ből is. Rengeteg fejlesztőcsapat használja a VSTS -t nem Microsoft alapú eszköz, IDE segítségével. A projektekhez tartozó Git verziótárakhoz gyakorlatilag bármilyen git klienssel — beleértve a parancssori eszközöket is — azonnal hozzáférhetsz. A VSTS előzékenyen viselkedik: automatikusan felkínálja azokat a kiegészítőket, bővítményeket, amelyekkel az integrációt megteremtheted, ahogyan ezt a 3 -2 ábra is illusztrálja a verziótár elérése ( git clone) során. Természetesen ez csak egyetlen példa. Ha az integrációs lehetőségekről szeretnél tájékozódni, érdemes meglátogatnod a VSTS piactér weboldalát .

 3. A Visual Studio Team Services és a DevOps

3-2 ábra: A VSTS felkínálja a kiegészítőket, bővítményeket

4. Folyamatos üzleti tervezés A DevOps — mint üzleti folyamat — hatékonyságának szempontjából kiemelt szerepe van az üzleti

tervezésnek. Ma a szoftver termékek fejlesztésében a legnagyobb kihívást az üzleti tervezés és a követelményelemzés jelenti. Ezek megalapozatlansága, a projektkörnyezet gyors változásai nak figyelmen kívül hagyása rengeteg feleslege s munkát — és nyilván ezzel együtt felesleges költségeket is jelenthet. j elenthet. A DevOps szemlélet a folyamatos üzleti tervezés segítségével kívánja ezt a problémát orvosolni. Ehhez a terméknek egy olyan gazdára (termékgazda, termékmenedzser, projektmendzser, bárhogyan is nevezzük ) van szüksége, aki  jól ismeri a fejlesztés alatt álló terméket; figyel a felhasználók és érdekeltek visszajelzésére; képes a termékképességek megfelelő megvalósítási sorrendjét sor rendjét kialakítani,  folyamatosan hangolni;  jelenlétével, tudásával segíteni a DevOps csapatot a fejlesztéshez kapcsolódó többi „folyamatos” technika alkalmazásában. Ebben a fejezetben megismerheted a Visual Studio Team Services (VSTS) legfontosabb eszközeit és szolgáltatásait, amelyek a folyamatos üzleti tervezésben segíte nek.

Feladatlista – backlog A VSTS központi eleme a termékhez tartozó feladatlista ( product backlog), amit gyakran „hátraléklistának” is fordítanak — én inkább a „ feladatlista” megnevezésnél maradok. Ez a feladatlista különböző méretű elemeket tartalmaz, amelyek két - vagy háromszintű hierarchiába szervezhetők (4 -1 ábra).

4-1 ábra: A feladatlista hierarchia szintjei

4. Folyamatos üzleti tervezés

A legkisebb méretű feladatok a Backlog items  (munkadarabok) szinten találhatók. Optimális esetben a fejlesztést végző DevOps csapat a tényleges tevékenységét mindig munkadarabokhoz — és nem a magasabb szinten található feladatokhoz — kapcsolódóan végzi. A Features (termékképességek) szint azokat a munkadarabokat fogja össze, amelyek egy termékképesség megvalósításához szükségesek. Az Epics (eposzok) szint nagyméretű, a továbbiakban definiálandó, pontosítandó feladatokat, termékképességeket termékképességeket fog össze. A 4-2 ábrán egy ilyen hierarchiát láthatunk.

4-2 ábra: Hierarchiku s feladatlista

A VSTS megengedi, hogy ezeket a szinteket önállóan kezeljük (vagyis például legyen olyan munkadarabunk, amelyet nem soroltunk be egyetlen termékképesség alá sem), azonban a folyamatos üzleti tervezést segíti, ha élünk a hierarchia kialakításának lehetőségével.

Kibocsátások és iterációk A DevOps alapelvei közé tartozik az, hogy gyakori visszacsatolásokat kérünk a termékkel kapcsolatosan. Ez a gyakorlatban azt jelenti, hogy gyakran érkezünk olyan mérföldkövekhez, amikor a termék adott pontig elkészült képességeit szembesítjük az érintettekkel. A VSTS iterációnak nevezi azt az időintervallumot, amelynek végén a terméknek egy olyan változata áll elő, amelyben az előre meghatározott termékképességek bemutathatók, azok működése kapcsán visszacsatolások gyűjthetők. Megjegyzés : az egyes módszertanok eltérhetnek abban, hogy mit is neveznek iterációnak. A Scrum agilis keretrendszer például sprint nek nek nevezi a termékképességek előállítására használt időkeretet.

Minél rövidebb az iterációkhoz használt időke ret, annál gyakoribbak a visszacsatolások. Természetesen a folyamatos üzleti tervezés során figyelembe kell venni az iterációk méretét, és ehhez megfelelő méretű munkadarabokat, termékképességeket választani az ok céljaként. A VSTS lehetővé teszi, hogy iterációkat hierarchikusan definiáljunk. Minden iterációnak nevet adhatunk, és meghatározhatjuk az időtartamát. A 4 -3 ábra egy ilyen tervezés eredményét mutatja be.

Munkadarabok meghatározása

4-3 ábra: Kibocsátások és közbenső mérföldkövek

A tervezés során kialakított iterációkat ebben a példában úgy határoztuk meg, hogy azok belső mérföldköveket (Sprint 1, …, Sprint 5) és a kibocsátási időpontokat is meghatározzanak. Az üzleti tervezést akkor végezzük helyesen, ha a belső mérföldköveket is úgy határozzuk meg, hogy azokra a termékképességek elvileg leszállítható formában, visszacsatolás gyűjtésére alkalmas állapotban készüljenek el. A kibocsátáshoz tartozó mérföldköveknél a fejlesztés alatt álló terméket az éles környezetbe kell tudnunk telepíteni. Nagyon fontos, hogy a folyamatos üzleti tervezés ezzel a visszacsatolás -centrikus szemlélettel készüljön! A DevOps alapvető elveit sérti, ha ugyan rövid iterációkat használunk, de csak azokhoz tudunk valós visszacsatolási lehetőséget teremteni, amelyek már a kibocsátásokhoz ki bocsátásokhoz kapcsolódnak.

Munkadarabok meghatározása A folyamatos üzleti tervezés akkor működik megfelelő hatékonysággal és rugalmassággal, ha jól választj uk meg azoknak a munkadaraboknak a méretét, amelyeket az együttműködésen alapuló fejlesztés segítségével a csapat ki fog alakítani. Minden iteráció során van bizonyos kockázata annak, hogy valamilyen technikai vagy egyéb akadály miatt nem sikerül minden munkadarabot a megfelelő minőségben, visszacsatolásra alkalmas állapotban elkészíteni. Ha egy iterációba két -három munkadarab fér csak bele, már egyetlen befejezetlen munkadarab is jelentősen ronthatja a hatékonyságot. Ha 10 -15 munkadarab közül nem készül el egy, az kisebb veszteséget jelent. Ugyanakkor, ha túl sok munkadarabot kezelünk egy iterációban, erősen megosztjuk a csapat figyelmét, és a feladatok állapotának követése , az egy-egy munkadarabra rakódó fix költség — még ha alacsony is — ronthatja a megvalósítás hatékonyságát. A VSTS egy adott munkadarabhoz sok olyan információt tud hozzárendelni, amely segíthet a megfelelő méret kiválasztásában. Ezek közül az egyik legfontosabb az elfogadási kritériumok összegyűjtése, amint azt a 4-4 ábra is szemlélteti.

4. Folyamatos üzleti tervezés

4-4 ábra: Elfogadási kritériumok felsorolása

Az elfogadási kritériumok összegyűjtése sokat segít a munkadarabok méretének becslésénél, különösen a nagyméretűek felismerésében. Intő jel, ha 5 -6 vagy akár annál több elfogadási kritérium tartozik egy munkadarabhoz: lehet, az túl nagy, és célszerű c élszerű lenne kisebb egységekre bontani. A DevOps technikákat — főleg a fejlesztés és tesztelés hatékonyságát — segíti, ha az elfogadási kritériumok mellett tesztelési forgatókönyveket is definiálunk egy munkadarabhoz (4 -5 ábra).

4-5 ábra: Tesztelési forgatókönyv az elfogadási kritériumokhoz

In medias res — egy  — egy kis tesztelés

Ennek jelentőségét az adja, hogy a forgatókönyvek segítik a fejlesztést végző szakemberek munkáját azzal, hogy még jobban megértsék, mit is az elvárás az adott munkadarab megvalósításával kapcsolatosan. Gyakori hiba a fejlesztési feladatok erőforrásbecslésénél az, hogy a fejlesztőcsapat nem számol megfelelően azokkal a tevékenységekkel, amelyek az adott munkadarab fejlesztői teszteléséhez tartozik. A 4-4 és 4-5 ábrán vázolt munkadarabnál (folyamatos számlasorszám biztosítása) jól látszik, hogy a tesztelés —  vagyis a helyes működés ellenőrzése, demonstrálása — akár komolyabb ráfordítást igényelhet, mint a feladat tárgyának megvalósítása. Természetesen — és ez a DevOps alapelvekből is következik — egy ilyen feladatot csak akkor tekinthetünk megvalósítottnak, ha annak helyes működése ellenőrizhető is.

In medias res — egy kis tesztelés A folyamatos üzleti tervezés nem működhet jól anélkül, hogy ne ejtenénk szót a tesztelés fontosságáról. A szükségletek Maslow -féle hierarchiájához hasonlóan a tesztelés hierarchiájának piramisát is definiálhatjuk, amint azt a 4- 6 ábra mutat ja.

4-6 ábra: A tesztelés hierarchiája

A DevOps szemléletének megfelelő folyamatos üzleti tervezés akkor lehet sikeres, sik eres, ha a termékképességek és munkadarabok tervezése során szem előtt tartjuk a piramis három felső rétegében lévő kritériumok fontosságát. Ha csak a piramis alapját képező két réteget vesszük figyelembe — és sajnos ez nagyon gyakori a szoftverfejlesztési projektek során —, olyan jól működő terméket állíthatunk elő, amely vagy nem kell a felhasználóknak (nem használható , nem elég hasznos), vagy ezek mellett még veszteséges is az elkészítése . Ilyen körülmények között nem boldogíthat bennünket a tudat, hogy egyébként a termék jól működik…

5. Együttműködésen alapuló

fejlesztés A DevOps szemlélet hatékonyságát meghatározza, hogy a z — üzleti értelemben —  jól megtervezett termékképességeket termékképességeket a csapat milyen gyorsan és milyen jó minőségben készíti el. Ahhoz, A hhoz, hogy a kifejlesztett munkadarabok a termékbe integrálva az elvárt képességeket valósítsák meg, több szakmai területnek is együtt kell működnie: üzleti elemzőknek, dizájnereknek, fejlesztőknek, tesztelőknek, adatbázis szakembereknek, infrastruktúra - és biztonsági szakértőknek, marketing szakembereknek, gyakran  jogászoknak, és még más, a termékhez termékhez kapcsolódó üzleti tudást képviselőknek.

Együttműködés Az együttműködésen alapuló fejlesztés lényege, hogy az összes olyan kompetencia megjelenik a DevOps csapatban, amely a termék képességeinek kialakításához szükséges. A szakemberek legtöbbjének bevonására az üzleti tervezés és a visszacsatolások kezelése során van szükség. A fejlesztési tevékenységhez közel álló csapattagok (fejlesztők, tesztelők, a munkájukat segítő szakértők) általában a munkadarabok kidolgozása során — ez az amit kódolásnak, fejlesztésnek tekintünk — kapcsolódnak a munkába. A DevOps túllép azon a hagyományos felfogáson, hogy „mindenki csinálja azt, amihez ért”. Természetesen nem abban az értelemben, hogy olyan feladatokat is a csapattagokra toljanak, amely meghaladja a szakértelmüket, képességeiket. A DevOps a csapat egészét arra ösztönö zi, hogy sajátítsa el a fejlesztés során használt folyamatokat, mindenki rendelkezzen azokkal az alapvető ismeretekkel, amelyek segítenek a csapat együttműködésében. egészének együttműködésében. Minden csapat esetében ezek az ismeretek más-más konkrétumot jelentenek . A DevOps hatékony működéséhez azonban minden csapattagnak tovább kell látnia a saját szakterületén kívül : Az üzleti tervezést végzőknek tudniuk kell, hogyan is működik a fejlesztési -tesztelési-élesítési ciklus a megvalósítási fázis során, azért, hogy ennek megfelelő módon készíthessék elő a feladatlistákat. A fejlesztést végző szakembereknek ismerniük kell a termékhez tartozó üzleti entitásokat, folyamatokat, alapelveket legalább olyan szinten, hogy hatékonyan tudjanak kommunikálni az üzleti tervezést végzőkkel. Megjegyzés: a DevOps csapat tagjainak nyitottnak kell lenniük a kommunikációra, a többi csapattag megértésére, közös nyelv kialakítására és használatára. Ezek nélkül az e gyüttműködés nem lehet hatékony .

Együttműködési területek A fent megfogalmazott formában az együttműködés egy szép elvnek hangzik. A DevOps megközelítésmódjában ez sok formában nyilvánulhat meg. Itt egy rövid lista — távol áll a teljestől — , amely segít ezt jobban megérteni: Az üzleti tervezésbe a fejlesztő és tesztelő szakemberek is bekapcsolódnak. A kommunikáció során jobban megértik a feladatokat, a kihívásokat, segíthetnek a kapcsolódó kockázatok összegyűjtésében, ráfordításbecslések készítésében. Az üzleti tervezés során a fejlesztési szakértők segítenek a megfelelő feladatméret kialakításában — különös azért, hogy a túl nagy méretű munkadarabokat elkerülhessék. A fejlesztési tevékenységek során az elemzők folyamatosan jelen vannak, hogy az üzleti folyamatokhoz kapcsolódó kérdésekben azonnal segíteni tudjanak.

Csapatmunka a VSTS segítségével

Az infrastruktúra és biztonsági szakértők folyamatosan részt vesznek a fejlesztési és tesztelési munkában, biztosítják azt, hogy az elkészített termékképességek a minőségi elvárásoknak megfelelően készülnek el.

Csapatmunka a VSTS segítségével A Visual Studio Team Services a terméket az együttműködés, csapatmunka támogatása hívta életre. Célja az, hogy olyan eszközöket és szolgáltatásokat biztosítson, amelyekkel a csapatok hatékonyan tudnak jó minőségű szoftvertermékeket elkészíteni. A VSTS egyik legfontosabb eszköze — amint az előző fejezetben azt már megismerhetted — a feladatlista. Ezt természetesen nemcsak a feladatok nyilvántartására, de annak követésére is használja a DevOps csapat. A tevékenységek követésére használt legfontosabb eszköz az előrehaladást jelző tábla (5 -1 ábra). S okan ezt Kanban-táblaként ismerik.

5-1 ábra: A feladatok követéséhez használt tábla

Nyilván minden csapat másképp alakíthatja ki folyamatait. A táblát a csapatok saját működésükhöz igazíthatják (5 -2 ábra), annak oszlopai t a mögöttük lévő folyamatokhoz illeszkedve állíthatják össze.  A tábla kezelésénél a VSTS támogatja az ún WIP limit (Work -In-Progress) -In-Progress) beállítását, amely a Kanban egyik fontos eleme.

Az együttműködés során a folyamatos tervezési, tesztelési tevékenységek és a visszacsatolások további feladatokat eredményezhetnek, amelyeket a DevOps csapat elhelyez a feladatlistában. A csapat — a termékgazda irányításával — rendszeresen áttekinti a feladatokat, rendszerezi és sorrendezi azokat, hogy a fontos feladatok a lista elejére kerülhessenek.  Az 5-3 ábra azt mutatja be, hogy a tesztelés során talált hibát a csapat annyira fontosnak érzi, hogy a feladatlista elejére helyezi.

 5. Együttműködésen alapuló fejlesztés

5-2 ábra: A tábla oszlopainak testreszabása

5-3 ábra: A feladatlistára kerülő hiba kijavítása a csapat legfontosabb teendője

A feladatlista kezelése A DevOps csapatok működésének hatékonyságát a feladatlista, annak minősége és állapota alapvetően meghatározza. Hiába áll  olyan jó szakemberekből a csapat, akik saját területük szakmai csúcsát képviselik , a feladatlista helytelen vagy hanyag kezelésé még egy jó gárda mellett is sok probléma forrása lehet.  Minden ilyen hiba rossz irányába mozdíthatja a csapatot — eltávolítva azt valódi fókuszától — , és értékes erőforrások pazarlásával jár. A leggyakrabban az alábbi jelenségek okoz nak nehézségeket: Rosszul megfogalmazott, tisztázatlan feladatok Átgondolatlan feladatméret Többértelműen definiált feladatok Elfogadási kritériumok hiánya Rosszul priorizált feladatok A feladatok rendszeres áttekintésének hiánya A VSTS rengeteg funkcióval segíti a feladatlisták kezelését. Ezekből néhány fontos: Portfóliókezelés

 A feladatlista elérése

Hierarchikus feladatlista létrehozása és kezelése Munkadarabok címkézése Munkadarab lekérdezések összeállítása Munkadarabok követése Agilis táblák (Kanban -tábla) megjelenítése és kezelése Iterációk és csapatkapacitás tervezése Értesítések a munkadarabok változásairól Állapotkövetés

A feladatlista elérése A feladatlistát nemcsak a VSTS portál felületén érheted el, hanem a Visual Studio IDE használatával is (5 -4 ábra), illetve akár Microsoft Excelben (5 -5 ábra). A Visual Studio IDE segítségével módosíthatod is a munkadarabok állapotát, illetve olyan saját (vagy csapatszintű) lekérdezéseket hozhatsz létre, amely a feladatok követésében segíthet.

5-4 ábra: Feladatlista a Visual Studio IDE -ben

 5. Együttműködésen alapuló fejlesztés

5-5 ábra: Feladatlista mentése Excel munkalapba

6. Folyamatos tesztelés Ma folyamatos tesztelés nélkül nem lehet megfelelő minőségű és értékű terméket fejleszteni. Az még mindenki számára világos, hogy rendszeresen, gyakran kell tesztelni, de az üzleti folyamat egészének követését már csak kevesen tekintik a folyamatosság fol yamatosság egyik fontos dimenziójának.

Mitől folyamatos a tesztelés? A folyamatos üzleti tervezést bemutató fejezetben már megismerkedhettél a tesztelés hierarchiájával, annak minőségi szintjeivel (6-1 ábra).

6-1 ábra: A tesztelés minőségi szintjei

Nagyon fontos ezeknek a szinteknek s zinteknek a megértése. Alulról felfelé haladva ezek a következők:

Alapvető funkciók működnek? Leszállítható a termék? Ezek a tesztelésnek azok a „kötelező táncai” , amelyek nélkül elvileg egyetlen fejlesztő/tesztelő sem engedhet ki egy munkadarabot a kezéből. A DevOps szemlélet tükrében arra törekszünk, hogy lehetőség szerint az összes ilyen teszt automatizálható legyen. l egyen. Jól működik? A termékek nemcsak funkcionális, de minőségiekkel elvárásokkal is rendelkeznek. Ezek ellenőrzése — beleértve a teljesítményt, rendelkezésre állást, biztonságot stb.— szerves részei a termék minőségbiztosításának. A DevOps szellemében ezeket a teszteket is rendszeresen el kell végeznünk, a lehetőségeknek megfelelően automatizálva. Használható? Attól, hogy egy termék jól működik, még nem biztos, hogy jól (optimális an) használható, vagyis megfelel a kényelem, ergonómia, egyértelműség, felfedezhetőség, egységesség — és egyéb hasonló szempontok — elvárásainak. Már az üzleti tervezés során gondoskodni kell arról, hogy az így meghatározott használhatóságot ellenőrizni tudjuk. Bár jó lenne, ha ezt is automatizáltan tudnánk tesztelni, de ma még csak kézi tesztek — a felhasználóktól érkező visszajelzések, teszt laboratóriumok stb. — segíthetnek bennünket.

6. Folyamatos tesztelés Hasznos? Ha már használható egy termék, akkor valóban megoldja azokat a problémákat, amelyeket

megcélzunk vele? A tesztelésnek ez a szintje már általában a termékhipotézisek kialakításáról és ellenőrzéséről szól. Sikeres? Valószínűleg egyetlen szervezetnek sem célja a ráfizetéses szoftverfejlesztés — akár közvetlen, akár közvetett megtérülésről beszélünk. Az üzleti tervezés fontos eleme a „siker” ilyen értelemben vett meghatározása. A folyamatos tesztelést a DevOps szellemében úgy kell értelmeznünk, hogy az a termék készít ésének összes fázisát lefedi az üzleti tervezéstől a megvalósításon át egészen a visszajelzések gyűjtéséig, azok kezeléséig.

Tesztelés az üzleti tervezés során Már a termék tervezése során választ kell adni a két legfelső minőségi szint sz int kérdéseire, és e zeket a válaszokat folyamatosan kommunikálni kell a DevOps csapattal. A magas szintű kritériumok — mitől sikeres, illetve hasznos a termék? — ritkán ellenőrizhetők közvetlen formájukban. Sokkal előnyösebb, ha a termékképességek meghatározásába azok az elfogadási feltételek és tesztelési módok kerülnek be, amelyek segítségével ezek a magasabb szintű elvárások ellenőrizhetővé, mérhetővé válnak. Tegyük fel, egy webes keresésen alapuló termékünk hasznosságát az adja, hogy az általa felkínált találati lista li sta elején értékesebb, a felhasználók számára fontosabb találatok helyezkednek el. A képesség megfogalmazásán túl azt is ki kell találnunk, milyen módon mó don tudjuk ezt ellenőrizni — mérni—, és azt igazolni, hogy a mérések segítségével ténylegesen az általunk fontosnak vélt adatokhoz jutunk hozzá. Ez a tevékenység már a tesztelés része! Megjegyzés : Ha a felső két tesztelési szintet rosszul határozzuk meg, legjobb igyekezetünk ellenére sem fogunk tudni valóban hasznos terméket készíteni. készíteni .

Tesztelés a termékkészítés során A t esztelés három alsó minőségi szintjét folyamatosan követnünk kell a termék készítése során. A tesztelés

akkor hatékony, ha rendelkezünk olyan tesztkészlettel, amely gyakran végre tudunk hajtani. A Visual Studio IDE és a VSTS teljes támogatást ad ezekhez a tesztekhez az alábbiak kal: Automatikus tesztek biztosítása (egység tesztek, integrációs tesztek, felhasználói felület tesztek) . Kézi tesztelés, tesztesetek létrehozása és azok végrehajtása. tests ). Az alkalmazások (spontán, tesztesetek nélküli) használatával Felfedező jellegű tesztek ( exploratory tests) tesztesetek létrehozása, hibák jelentése . Terheléses tesztelés

Automatikus tesztelés A Visual Studio IDE már régóta biztosít keretet automatikus tesztek elvégzésé hez. Bár az IDE az egységteszt (unit test ) terminológiát használja a tesztprojektekre, valójában val ójában nem csak egységteszteket, hanem akár kisebb integrációs teszteket is elvégezhetünk ezekkel.  Az egységteszteket a fejlesztők készítik a feladataikhoz tartozó funkcionális munkadarabok kapcsán. Amíg ezek a funkcionális funkcionális munkadarabok az elvárt funkcionalitást valósítják meg, a hozzájuk kapcsolódó egységtesztek azt ellenőrzik, hogy a munkadarabok valóban az elvárásoknak megfelelően készültek készültek -e el, és mind a funkcionális, mind mind  pedig az automatikusan ellenőrizhető ellenőrizhető minőségi követelményeknek követelményeknek megfelelnek -e. -e.

A 6-2 és 6-3 ábrán egy sikeres, illetve ill etve egy sikertelen automatikus teszt eredményét láthatjuk.

Kézi tesztelés

6-2 ábra: Sikeresen végrehajtott automatikus teszt

6-3: Sikertelen automatikus teszt

Az automatikus tesztek erejét egyértelműen a megismételhetőségük adja. Mivel   gyakran lefuttathatjuk azokat — akár minden kisebb kódváltoztatás után is —, így  azok növelik a fejlesztőcsapat magabiztosságát, amatos refaktorálást. refaktorálás t. és kifejezetten elősegítik a DevOps — és agilis — csapatok által gyakran használt foly amatos Természetesen nemcsak a Visual Studio IDE -be épített projekttípusok segítségével lehet automatikus file) is, amely önállóan teszteket készíteni. Tökéletes lehet erre a célra egy kötegelt alkalmazás (batch file) lefuttatható, és a tesztelés végeztével megjeleníti annak eredményét. Az automatikus tesztek szerves részét képezik a DevOps csapat által alkalmazott napi kódépítési és termékkibocsátása technikáknak, amint azt a következő fejezetből megtanulhatod.

Kézi tesztelés Nem tudunk mindent automatikusan tesztelni — de nem is érdemes. Egy alkalmazás számtalan jellemzőjét (pl. megfelelően gyorsan reagál -e, folyamatosak-e az animációk, az elvárt dizájnnak megfelelően jelenik meg

egy dialógus stb.) nem lehet igazán jól önműködően ön működően tesztelni. Hatékonyak csak kézi teszteléssel lehetünk. A VSTS szolgáltatásainak egyike — és ez talán a leginkább kiemeli versenytársai közül a Visual Studio termékcsaládot — a kézi tesztelés támogatása. A DevOps csapat a feladatai kapcsán teszteseteket állíthat össze (6 -4 ábra), leírva annak lépéseit és elvárt eredményét.

6. Folyamatos tesztelés

6-4 ábra: Egy új teszteset összeállítása táblázatban

Az elkészült tesztesetek végrehajtásához VSTS portál aktív segítséget ad: megjeleníti a tesztelési lépéseket, az elvárt eredményt, és lehetőséget ad a tesztelőnek a visszajelzésre. Ezt a folyamatot ábrázolja a 6 -5 ábra, ahol a teszt első két lépése sikeres. Ha a tesztelő hibát, nem várt működést észlel, azonnal azo nnal jelentheti azt (6 -6 ábra), és az bekerül a DevOps csapat feladatlistájába.

6-5 ábra: A tesztelés folyamatban van

Teszkörnyezetek kezelése

6-6 ábra: Hibajegy készítése a nemvárt működés alapján

A hibás termékképesség kijavítása után sikeresen le futó teszt igazolja a sikeres módosítást. A teszt állapota  jól követhető a VSTS portálon (6-7 ábra).

6-7 ábra: A teszt állapotának követése

Teszkörnyezetek kezelése Egy alkalmazás fejlesztése során gyakran lehet szükség több tesztkörnyezetre, többek között az alábbi esetekben is:

Az alkalmazásnak több különböző változata is létezik, és ezek mindegyikét tesztelni kell. Ugyanazt az alkalmazásváltoza tot több különböző infrastruktúra -konfiguráción is ellenőrizni kell. Az alkalmazás fejlesztését több csapat párhuzamosan végzi (pl. termékképességek mentén), mindegyiknek önálló környezetre van szüksége, amelyben a saját változatát ellenőrizheti. Minél több környezetet használ egyidejűleg a DevOps csapat, annál nagyobb munkát jelenthet ezek kialakítása, fenntartása. A VSTS lehetőséget nyújt egy csapat számára, hogy az Azure -ban létrehozott virtuális gépeiből tesztelési környezetet alakítson ki, és azokat az igényeinek megfelelően kezelje.

7. Folyamatos kibocsátás és élesítés Nagyon sok fejlesztőcsapatra jellemző az, hogy néhány óra alatt javítanak programhibákat, egy -két nap alatt lekódolnak egy új termékképességet, de akár több hetet is eltöltenek azzal, hogy a módosított rendszert élesítsék. Általában az élesítésre szánt idő alatt további módosítások at végez a csapat , amelyek beleszólhatnak az élesítési folyamatba — azt újra meg kell változtatni —, és az egész egy ördögi körré válik, amelyből a csapat nehezen tud kiszabadulni. Ezen a módon egy DevOps csapat nem tud működni. Ahhoz, hogy hatékonyak legyenek, bármelyik pillanatban képesnek kell lenniük ellenőrzött módon kibocsátani a terméket: Meggyőződni arról, hogy a termék az ismereteik szerint nem rendelkezik hibákkal —   vagy csak olyan szintűekkel, amely a felhasználókkal kommunikálható k és így kezelhető k. A termék tervezett módon képes az éles környezetbe kerülni — nem okoz ott adatveszteséget, ha szükséges , az ott lévő adatokat transzformálja az új termékképességeknek megfelelően. A felhasználók fennakadás nélkül kezelésbe vehetik a rendszer új változatát. Az élesítési folyamat hibája esetén van megfelelő eljárás a rendszer előző állapotához való visszatéréshez.

Folyamatos termékleszállítás A DevOps — és más agilis keretrendszerek is —  a folyamatos termékleszállítás szemléletén alapulnak : Egy termékképesség csak akkor válik értékké, ha leszállításra kerül. Egy kifejlesztett termékképesség csak akkor van kész, ha az érintettek használatba érintettek használatba is vették.

Ebből az értékszemléletből közvetlenül adódik a DevOps egyik alapelve:  Az alkalmazás élesítése gyors, megismételhető megismételhető és megbízható eljárással történjen!

A fejlesztőcsapatok több technikát alkalmaznak azért, hogy ezt a szemléletmódot fenntartsák, biztosítani tudják a termékképességét gyors kidolgozását, módosítását és élesíthetőségét. Ezek közül a legfontosabbak az alábbiak: Folyamatos integráció Folyamatos terméktelepítés

A folyamatos integráció alapelvei A folyamatos integráció lényege az, hogy a fejlesztőcsapat által végzett módosításokból azok kerüljenek be

a termék kibocsátáshoz használt változatába, amelyek megfelelnek a funkcionális és minőségi elvárásoknak egyaránt. Lényege az, hogy a rendszer kódjának módosítása esetén — amikor az bekerül a verziókezelő rendszerbe —, olyan eljárások futnak le, amelyek azonnal ellenőrzik a módosított termék helyes működését, gyakran a telepíthetőségét  is. A folyamatos integráció legfontosabb alapelvei az alábbiak: Használj forráskód követést! Automatizáld a kódépítést! Tedd a kódépítést önellenőrzővé! Mindenki mindennap legalább egyszer helyezze el a saját kódmódosításait a terméképítés alapágában! Minden visszaírás után végezd el a kódépítést! Az éles környezet egy másolatán tesztelj!

-ben Kódépítés a VSTS -ben

Tedd egyszerűvé a termék utolsó változatához való hozzáférést! Mindenki láthassa a legutóbbi kódépítés eredményét! Automatizáld a telepítést! A folyamatos integráció biztosításához a VSTS minden alapvető szolgáltatást biztosít. Természetesen a folyamat egészét a DevOps csapatnak kell kialakítania.

Kódépítés a VSTS-ben A Visual Studio Team Services szolgáltatásként biztosít a csapatok számára automatikus kódépítési lehetőséget. Ennek az eljárásnak a lépéseit saját magad alakíthatod ki, és mindegyiket a csapatod igényeire szabhatod. Célszerű valamelyik előre elkészített sablonból kiindulni, és azt átalakítani, kibővíteni. A 7 -1 ábra néhány ilyen sablont mutat be.

7-1 ábra: Előre elkészített kódépítés sablonok

A sablonban lévő kódépítési lépések (7-2 ábra), a kód fordítása mellett lefuttatják a teszteket, elkészítik a

nyomkövetéshez használt szimbólumokat, és elérhetővé teszik a termék lefordított változatának elérését.

7. Folyamatos kibocsátás és élesítés

7-2 ábra: A kódépítés lépései

A VSTS-t beállíthatod úgy, hogy a kódépítési folyamat beinduljon minden egyes kódvisszaírás sor án —  vagyis akkor, amikor a kód a verziótárba kerül. Ehhez a Triggers fülön lévő continuous integration opciót kell bekapcsolni, ahogyan azt a 7- 3 ábra mutatja. Ezzel a beállítással a kód módosítása és visszaírása elindítja a

kódépítés folyamatát és annak részeként az automatikus tesztek futtatását.

7-3 ábra: A folyamatos integráció bekapcsolása

A kódépítési folyamat végén a portálon megtekinthető annak állapota és eredménye (7 -4 ábra).

7-4 ábra: A kódépítés eredményének összefoglalása

Folyamatos terméktelepítés

Folyamatos terméktelepítés A folyamatos integráció gondoskodik arról, hogy észleljük azokat a kódolási hibákat, amelyek a stabil minőségű termékhez kapcsolódó elvárásokat megtörik, például funkcionális vagy minőségi hibákat vezetnek be, esetleg akár a kód si keres lefordulását is megakadályozzák. A legtöbb DevOps csapat számára a termék éles környezetbe való telepítése is komoly kihívást jelent.  Ennek legfontosabb oka az, hogy a termékképességek folyamatos változtatása többfajta — és gyakran nem technológiai jellegű — problémát is felvet: A felhasználói felület megváltozik — ez megzavarhatja a felhasználókat és a tesztelőket egyaránt . A korábban kiadott termék szolgáltatáshomlokzatai megváltoznak. A termék mögött lévő adatbázis, illetve ill etve adatbázis -szerkezet megváltozik. A termék konfigurációj a, paraméterei változnak egy új változat kibocsátása során. Több termékváltozatot magában foglaló „ugrás t” kell az éles környezetben végrehajtani. A folyamatos integráció mellett egy DevOps csapatnak figyelnie kell arra, hogy a folyamatos terméktelepítést is megoldja. Hasonlóan az automatikus kódépítési folyamathoz, célszerű automatikus telepítési folyamatot is definiálni — szintén a VSTS kódépítés szolgáltatásával —, amely segít a termék telepítésének ellenőrzésében. A hagyományos kódépítési lépéseket az alábbiakkal célszerű kiegészíteni: A termékhez tartozó telepítő és migrációs készletek előállítása. Üres telepítési teszt környezet ellenőrzése Telepítési teszt környezet létrehozása Telepítési teszt Telepítés helyességének ellenőrzése Migrációs teszt környezet létrehozása — a korábbi termékváltozat valamelyik „élesnek tekintett” környezetéből Telepítési teszt környezet létrehozása Migrációs készlet futtatása Migráció sikerességének ellenőrzése A VSTS automatikus kódépítéshez használt szolgáltatáskészlete minden lehetőséget biztosít ahhoz — beleértve saját virtuális gépek létrehozását, telepítését, parancssori utasítások végrehajtását stb. — , ami a folyamatos terméktelepítéshez szükséges lehet. 











Kibocsátások kezelése Amikor a csapat elkészített egy olyan ellenőrzött termékváltozatot, amely alkalmas az éles használatra,

telepítenie kell azt az éles környezetbe. Ennek a folyamatnak jól kell működnie, mert hiba esetén egy új termékváltozat helyett akár egy működésképtelen rendszer hez is juthatunk. A DevOps csapat életében nagyon fontos, hogy a kibocsátások helyesen legyenek kezelve, automatikus eljárások segítsék egy új termékváltozat élesítését, szükség esetén a visszaállást a korábbi változatra. A Visual Studio Team Services az auto matikus kódépítés folyamatához hasonlóan rendelkezik a kibocsátási folyamat kezelésének képességével. Ezt a Release Management  szolgáltatáscsalád kínálja, amely a kódépítéshez hasonlóan sablonokon alapul (8 -5 ábra)

7. Folyamatos kibocsátás és élesítés

8-5 ábra: Telepítés definíciós sablonok

A telepítések leírására sablont használhatsz, amely lehetővé teszi, hogy meghatározhasd az alábbiakat: artifacts) A telepítéshez tartozó termékkomponensek ( artifacts) environments) A környezetek, amelyekbe a terméket telepíted ( environments) configuration) A telepítés során használt konfiguráció, a konfigurációs paraméterek értékei ( configuration) triggers) A telepítés automatikus elindításához rendelt események ( triggers) A telepítések definícióját össze lehet kötni az automatikus kódépítéssel. Ez azt jelenti, hogy a kódépítés sikeres befejezése után automatikusan elindul a telepítés. Nagyon ritka az olyan DevOps csapat, amely a kódépítés sikere után a terméket azonnal az éles környezetbe telepíti. Egy termékváltozat kibocsátását gyakran több elfogadási lépés előzi meg, amely manuális teszteket és egyéb minőségbiztosítási lépéseket is tartalmaz. Általában a sikeresen elkészített kódot csak egy fejlesztői környezetben telepítik, ahonnan az adott csapat által definiált folyamat segítségével — kézi jóváhagyást igényelve — kerül tesztelői környezetbe a termék, majd a megfelelőséget igazoló ellenőrzések után jut csak az éles környezetbe. A VSTS R elease Management szolgáltatásai lehetővé teszik az automatikus kibocsátás mellett ezeknek a jóváhagyási folyamatoknak a definiálását és kezelését is — a megfelelő jogosultsági rendszer biztosítása mellett.

8. Folyamatos monitorozás A csapat munkája nem érhet véget ott, hogy egy éles termékváltozatott kibocsátott. Valamilyen módon ellenőriznie kell, hogy az új vagy módosított termékképességeket a felhasználók hogyan használják (használhatónak találják -e egyáltalán), illetve azok hasznosnak bizonyulnak-e, vagyis elérik-e a létrehozásuk célját. Természetesen a rendszer működésének egészét is figyelniük kell, ellenőrizve, hogy az a funkció i a minőségi elvárásoknak is megfel elnek-e. A DevOps csapatok ezt a folyamatos monitorozás segítségével biztosítják. Nagyon sokáig egy alkalmazás vagy rendszer működésének követés e a műszaki paraméterek figyelését  jelentette. Napjainkban a felhasználók viselkedésé nek megértése, az alkalmazással való kölcsönhatásuk megismerése egyre fontosabbá válik .

Folyamatosság A folyamatos monitorozás valójában nem az éles üzemmel kezdődik, hanem végigkíséri a termékképességek fejlesztését és tesztelését. Ebben az időszakban kell a DevOps csapatnak megtan ulnia, hogy milyen  jellemzőket és milyen módon érdemes figyelnie azért, hogy hasznos visszacsatolásokat kaphasson a termék működéséről. Ha valami nem elég gyors a fejlesztői és tesztelői környezetben, ha bizonyos hibák gyakran  jelentkeznek ott, akkor ez várhatóan v árhatóan így lesz az éles környezetben is —  de ugyanazok a  jelenségek ott már nagyobb nehézségeket okozhatnak . Egy rendszer kapcsán rengeteg műszaki jellemzőt lehet mérni, figyelni. A rendszer üzemeltetője számára vonzónak tűnhet többszáz vagy legalábbis több tucat paraméter rögzítése, ellenőrzése.  Néha azonban éppen a rengeteg információ akadályozza meg, hogy a hibák valódi okait észr evegyük. A fejlesztés és tesztelés alatti monitorozás segíthet az üzemeltetőknek, hogy figyelmüket azok ra az adatokra összpontosítsák, amelyek valóban „beszédesek”. Így lényegesen gyorsabban felismerhetik, előre jelezhetik  a potenciális üzemzavarokat — és akár meg is előzhetik előzh etik azokat. A folyamatos monitorozásra már az üzleti tervezés során fel kell készülni: elfogadási kritériumként meg kell fogalmazni az ezzel kapcsolatos elvárásokat és az azok ellenőrzési (tesztelési) módját is meg kell határozni.

Mit érdemes figyelemmel kísérni? A DevOps alapelvek és a fent leírtak alapján az alkalmazások monitorozása során célszerű az alábbi területekre fókuszálni: Üzemeltetés nak a gyűjtése, amelyek segítségével el lehet dönteni, hogy a termék Azoknak az adatok nak (annak funkciói, képességei) az elvárt minőségi követelményeknek megfelel -e.  Ezek segítségével rendszeredet optimálisabban üzemeltethe ted, és ez a felhőben forintokra váltható. Ne feledd: ha egy rendszer 20% több erőforrást használ a kelleténél, az 20% -kal több pénzbe fog kerülni! Hibák, meghibásodások naplózása, követése . Ezek segíthetnek egy meghibásodás okának (akár szoftver hiba) kiderítésében, illetve lehetővé teszik, hogy egy hiba tovább terjedését megakadályozhasd. Biztonsági naplózás, fraud  kezelése. A rendszerrel kapcsolatos biztonsági kockázatok kezelése, biztonságot érintő események észlelése az egyik legfontosabb feladat — főleg a felhőben futó alkalmazások kapcsán. Kifejezetten fontos, hogy már a tesztelési és fejlesztési környezetben ellenőrizhető legyen a biztonsági eljárások működése. 





8. Folyamatos monitorozás

Felhasználói viselkedés Felfedezhetőség. Különösen új termékeknél — új felhasználók „gyűjtésénél” — érdemes figyelni, hogy a felhasználók milyen gyorsan haladnak a munkafolyamatokban , egyáltalán milyen funkciókhoz  jutnak el. Ezek az információk segíthetnek az alkalmazás átalakításában, a leggyakrabban használt funkciók elérésének gyorsításában. Üzleti funkciók használata. A termékek kulcsfunkcióit célszerű részletesen elemezhetővé tenni, hogy mérhetővé váljanak azok a pontok, ahol a felhasználók túl sok időt töltenek el (optimalizálási lehetőség), illetve nem az előzetesen feltételezett módon használják az adott termékképességet. Termékképességek használata. használata. Nagyon fontos, hogy a termék képességeinek valós használatáról képet kapjunk: ez segítheti a későbbi döntéseket, a feladatok prioritását. Nyilván előbb szeretnénk egy olyan termékképességet módosítani, amelyet a felhasználók több mint 25%-a használ szemben egy olyannal, amelyet csak 3%. 





Megjegyzés : Természetesen számtalan más dolgot is monitorozhatsz. Fontos, hogy pontosan tudd, milyen elvárásnak szeretnél a monitorozással megfelelni, mit fogsz a begyűjtött információval kezdeni. Csak azért gyűjtögetni, hogy  „egyszer még jó lesz az adat valamire”, valamire”, nem érdemes.

Az Application Insights Az alkalmazások monitorozásának egyik legegyszerűbb eszköze a Microsoft Azure -ban elérhető Application Insights szolgáltatás. Segítségével egyszerű az alkalmazás használatának nyomon követés e, a hibák észlelés e és a szoftverleállások diagnosztizálás a. Amikor a Visual Studio IDE-ben egy új webes projektet hozol létre, bejelölheted, hogy szeretnéd az Application Insights szolgáltatást felhasználni (8 -1 ábra).

8-1 ábra: Az Application Insights könnyen integrálható egy projektbe

Természetesen egy korábban létrehozott projekthez is utólag is hozzáadhat od az Application Insights méréseket (8 -2 ábra).

 Az Application Insights

Az Application Ins ights hozzáadása egy projekthez

Az alkalmazásod kliens és szerver oldali komponenseibe egyaránt beépítheted azokat a diagnosztikai és

üzleti méréseket, amelyek segítenek a működés és a használat követésében. A szükséges interfészek számtalan programozási nyelven érhetők el, a C#, Java, JavaScript, PHP, Python és  Objective-C nyelvek mindegyikében közvetlenül használható az Application Insights. A mérések számos platformon elérhetők, azok előre fel vannak készítve az adott platform specifikus diagnosztikai adatainak összegyűjtésére. Ezen a hivatkozáson részletes listát kaphatsz ezekről: https://azure.microsoft.com/en-us/documentation/articles/app-insights-platforms/ .

8-3 ábra: Mérési eredmények az Azure portálon

8. Folyamatos monitorozás

Az alkalmazások indulása után a diagnosztika azonnal működőképes. Az Application Insights a legtöbb platformon automatikusan — extra kódolás nélkül — méri a legfontosabb eseményeket, és ezeket az Azure portálon (8-3 ábra) azonnal megtekintheted. Ahhoz, hogy a felhasználók üzleti funkciókhoz kapcsolódó aktivitását figyeld, saját mérésekre van szükséged, ezeket saját eseményekhez rendelhet ed. A mérések létrehozása az adott platformhoz tartozó SDK segítségével egyszerű, azok részleteit ugyanúgy megtekintheted a portálon (8 -4 ábra), mint a készen kínált mérésekét.

8-4 ábra: Mérési eredmények részletei

Üzleti működés monitorozása Nemcsak az Application Insights, de minden más olyan platform, amely segítségével figyelheted az alkalmazásod működését, alapvetően az infrastruktúrához kapcsolódó méréseket végez —  nem ismerheti az alkalmazásod mögött lévő logikát. Figyelj oda arra, hogy o lyan méréseket határozz meg, amely segítségével a valódi üzleti folyamatokat tudod követni! Ehhez nem elegendő az infrastruktúrához kapcsolódó események követése. Olyan mérési pontokat, eseményeket és eljárásokat kell kitalálnod, amelyek megfigyelésével megismerheted a felhasználók szokásait. Például, ha egy folyamatod négy lépésből áll, és azt szeretnéd mérni, hogy az egyes szakaszokban mennyi időt töltenek el a felhasználók, akkor öt mérési pontra van szükséged: a folyamat kezdetén egyre, és minden egyes lépés végeztével egy újabbra. fontos , hogy egy adott Megjegyzés : Nem lehet elég gyakran hangsúlyozni, tehát álljon itt még egyszer: nagyon fontos , funkció működésének mérési módját a DevOps csapat már az üzleti elemzés során tisztázza.

9. Visszacsatolások folyamatos

kezelése Egy új termék készítése során nagyon hasznos volna, ha minden  egyes termékképességet előre tökéletesen tudnánk kitalálni, és azzal a felhasználók már az első a formájá ban elégedettek lennének. Ez nyilván nem működik így! Sokfajta felhasználó  van — akik más-más módon gondolkodnak és dolgoznak —, ráadásul ők is változnak. A csapat — a legjobb igyekezete ellenére is — ki fog bocsátani olyan termékképességeket, amelyek nem feltétlenül a legjobban sikerültek, a felhasználók más módon fogadják, használják azokat,  mint ahogyan a tervezők feltételezték. A DevOps szemlélet szerves része a tanulási folyamat: a szervezet tanul a hibáiból, még jobban megismeri azt a környezetet, amelyben egy adott szoftveres megoldást fejleszt. Erről szól a DevOps „ Tegyük gyakoribbá a visszacsatolási ciklusokat! ” alapelve. A gyakori visszacsatolások segítségével gyorsan változtathatók a fejlesztés prioritásai, az ütemtervek és a kibocsátások: hamarabb válaszolhatunk a környezet változásaira.

Lehetőségek a visszacsatolásra Egy alkalmazás, rendszer vizsgálata során a visszacsatolás alatt elsősorban a felhasználóktól, a rendszer érintettjeitől érkező jelzéseket értjük. A műszaki adatok figyelése (monitorozás) is fontos, hiszen az így észlelt — akár csak potenciális — problémákat is orvosolni kell. Vonzónak tűnik az a lehetőség, hogy automatikus mérésekkel gyűjtsünk be minden olyan adatot, amelyet felhasználunk a termékképességek javításánál, újak kialakításánál, de ez gyakran félrevezethet bennünket. Semmi nem pótolhatja azokat a valós visszajelzéseket, amelyeket a felhasználókkal beszélgetve, a munkájukat figyelve nyerhetünk. Néhány javasolt módszer a visszacsatolások gyűjtésére: „Fájdalompontok” felismerése. Rendszeresen, a kibocsátások után néhány nappal kérjük   meg a felhasználókat, hogy nevezzék meg a rendszer néhány olyan pontját, amelyen változtatva sokkal szívesen használnák a rendszert! Kérdezzük meg őket, mi az, ami leginkább akadályozza őket! Felhasználói viselkedés vizsgálata. Figyeljük meg éles környezetben, hogyan használják a rendszer adott funkcióit! Hol érzik magabiztosnak magukat? Hol bizonyta lanodnak el? Milyen alkalmazáselemeket használnak könnyedén? Hol lassulnak le? Akkor jó ez a megfigyelés, ha a felhasználók metakommunikációs  jelzéseit (arcmimika, testtartás, érzelmi reakciók stb.) is sikerül észlelnünk. Hasznosság megismerése. Törekedjünk arra, hogy megértsük, egy adott funkció valóban hasznos -e használói számára! Kifejezetten k érdezzünk rá, hogy egy adott folyamatban segíti -e őket a rendszer! Kudarcpontok vizsgálata. Nézzük meg, hogyan viselkednek a felhasználók, ha az alkalmazás működés e során hibaüzenetekkel találkoznak! Megértik azt, hogy mi történt? tört ént? Tovább tudnak haladni vagy elakadnak? A rendszer monitorozásával gyűjtött információ és a közvetlen kommunikáció együttes alkalmazása értékes eredményekhez vezethet. A begyűjtött mérési ad atok — például egy adott folyamatlépésben sok időt töltenek el a felhasználók — segíthet abban, hogy felismerjük milyen funkciók kapcsán érdemes további kérdéseket feltenni. Másfelől, a felhasználók viselkedésének leírását számszerűsít hetik a mért adatok. Az alkalmazás képességeinek módosításánál az újabb mérések segíthetnek a változtatás hatékonyságának ellenőrzésében.

9. Visszacsatolások folyamatos kezelése

A feladatlista bővítése A visszacsatolások csak alapját jelentik annak a munkának, amely a rendszer m inőségének a javítására irányul. A csapat akkor képes a terméket megfelelően módosítani, ha az üzleti tervezés helyesen értelmezi a begyűjtött információt, és megfelelő válaszokat talál azokra. A DevOps csapat a visszacsatolások során begyűjtött ismeretanyagból a feladatlista bővítésével, módosításával képez i le teendő it. A felhasználói vélemények és megfigyelések elemzése nagyon fontos: az ezen a ponton meghozott (üzleti) tervezési döntések jelentős mértékben befolyásolhatják a csapat hatékonyságát, a rendszer hasznosságát és sikerességét. Álljon itt néhány jellemző példa arra — a teljesség igénye nélkül —, hogyan is építhetik be a tapasztalatok eredményét a tervezők a feladatlistába: A sikertelen termékképességeket — amelyeket a felhasználók nem használnak — megszüntetik, vagyis kiveszik a termékből. A felfedezett hibákhoz feladatokat hoznak létre, azok prioritását a hiba hatásait és következményeit vizsgálva állítják be. A rendszert erőteljesen érintő hibák kijavítása szinte mindig megelőzi az újabb termékképességek kialakítását. A pozitív visszajelzések alapján (pl. egy adott típusú adatmegjelenítés szemléletes, hasznos) mintákat készítenek, és a későbbi feladatok meghatározásánál ezekre a mintákra hivatkoznak — akár elfogadási kritériumként is használják őket. A visszajelzések eredményeit beépítik azokba a feladatokba, f eladatokba, amelyek még csak kidolgozás alatt állnak, vagyis a csapat nem kezdett hozzá a megvalósításukhoz. A tapasztalatok alapján — ha szükséges — megváltoztatják a feladatok sorrendjét. Akár törölnek is korábbi feladatokat, illetve azokat több részre —  kisebb feladatokra — szedik szét. Megjegyzés : Nem lehet elég gyakran hangsúlyozni, hogy a visszajelzéseket nem csak a rendszer élesített változatában érdemes csak begyűjteni! Már akár a fejlesztőkörnyezet segítségével végzett demók kapcsán is kapcsán  is olyan értékes véleményeket kaphatunk, amelyek et et a csapat azonnal beépíthet a rendszerbe. Mint a szoftverfejlesztésre általában, itt is igaz, minél hamarabb javítunk ki egy hibát, építjük be egy hasznos visszajelzés eredményét  a termékbe, annál (költség)hatékonyabb lesz a csapat munkája.

A VSTS feladatlistájának használata A Visual Studio Team Services feladatkezelési képességei nagyfokú szabadságot biztosítanak, minden csapat szabadon alkalmazhatja saját, bevált technikáit. Néhány hasznos VSTS funkció használatával a visszacsatolások kezelése egyszerűbbé válik: Címkék kezelése. Minden feladathoz címkéket rendelhetünk. Ezeket ragyogóan használhatjuk a feladatok kategorizálására — akár több szempont alapján is. Célszerű a visszacsatolások begyűjtése után az elemzett eredmények alapján címkéket hozzárendelni az érintett feladatokhoz. Saját lekérdezések összeállítása. A feladat lista elemeiből saját lekérdezéseket állíthatunk össze. A lekérdezéseknél akár a címkéket is felhasználhatjuk, és így í gy könnyen kigyűjthetjük a hasonló feladatokat. item) A feladatlista bővítése taszkokkal és hibajelzésekkel. A feladatlistában lévő elemekhez ( backlog item) azonnal felvehetünk taszkokat és hibajelzéseket ( bug), amelyek közvetlenül az eredeti elemhez tartoznak — hozzárendelt feladatelemként.

Összegzés A DevOps lényege, hogy a szoftverfejlesztésre üzleti folyamatként fol yamatként tekint. Ennek szellemében annak egészére — a probléma felmerülésétől, elemzésétől a megoldást biztosító szoftvertermék szo ftvertermék élesítéséig és követéséig — ad hatékonyságot biztosító szemléletmódot. Négy fontos alapelvre épül: Az éles környezethez hasonló, azzal jelentősen megegyező környezetben végezzük a fejlesztést és tesztelést! Az alkalmazás élesítése gyors, megismételhető és megbízható eljárással történjen! Folyamatosan monitorozzuk és ellenőrizzük a rendszer működésének minőségét! Tegyük gyakoribbá a visszacsatolási ciklusokat! A Visual Studio Team Services a felhőben (Microsoft Azure) olyan szolgáltatásokat kínál, amelyek a DevOps szemlélet és a megvalósításához alkalmazott alkalm azott technikákat elérhetővé teszik a fejlesztők számára — bármilyen platformot is használjanak.

Hogyan tovább? Eszközök és szolgáltatások Visual Studio 





Community. Díjmentes eszköz magánszemélyeknek és kis cégeknek : Visual Studio Community. Tölts le egyet a 90 napos próbaverziók közül. Visual Studio vásárlása: Keresd a magyarországi viszont eladódat. Ismerd meg a licencelési lehetőségeket . Kérdés esetén írj ide: [email protected] o o

o

Visual Studio Team Services 



Termék oldal és díjmentes előfizetés létrehozása. Árazás.

Microsoft Azure 

Azure bevezető .

További tananyagok. 

Get Started Developing in Visual Studio .



Get Started with Visual Studio Team Services. Services .



Ismerkedés az Azure szolgáltatással .