DevOps

Jótanács

Ez a tartalom a „Az Azure-hoz készült natív felhőalapú .NET-alkalmazások tervezése” című eBookból egy részlet, amely elérhető a .NET Docs oldalán, vagy ingyenesen letölthető PDF fájlként, amely offline módban is olvasható.

PDF letöltése

A szoftvertanácsadók kedvenc mantraja, hogy válaszoljon a "Ez függ" kérdésre. Nem azért, mert a szoftvertanácsadók szeretik, ha nem foglalnak állást. Ennek az az oka, hogy a szoftveres kérdésekre nincs igaz válasz. Nincs abszolút helyes és helytelen, hanem az ellentétek közötti egyensúly.

Vegyük például a webalkalmazások fejlesztésének két fő iskoláját: az egyoldalas alkalmazásokat (SLA-kat) és a kiszolgálóoldali alkalmazásokat. Egyrészt a felhasználói élmény általában jobb az SPAs esetében, és a webkiszolgáló felé irányuló forgalom mennyisége minimalizálható, így lehetséges őket akár olyan egyszerű megoldásra is telepíteni, mint a statikus tárhely. Másrészt az SLA-k általában lassabban fejlődnek, és nehezebben tesztelhetők. Melyik a megfelelő választás? Nos, ez a helyzetedtől függ.

A natív felhőalkalmazások nem immunisak ugyanerre a dichotómára. A fejlődés gyorsasága, a stabilitás és a méretezhetőség szempontjából egyértelmű előnyeik vannak, de kezelésük meglehetősen nehezebb lehet.

Évekkel ezelőtt nem volt ritka, hogy egy alkalmazás fejlesztésből éles környezetbe való áthelyezésének folyamata egy hónapot vagy még több hónapot vesz igénybe. A vállalatok 6 havonta vagy évente adtak ki szoftvert. A Microsoft Windows jó példával szolgál a kiadások ritmusára, amelyek még elfogadhatóak voltak a Windows 10 örökzöld korszakát megelőzően. Öt év telt el a Windows XP és a Vista között, majd további három év a Vista és a Windows 7 között.

Mára már elég jól bizonyított, hogy a szoftverek gyors kiadásának lehetővé teszi a gyorsan mozgó vállalatok számára a hatalmas piaci előnyt a lajhárszerű versenytársakkal szemben. Ezért a Windows 10 fő frissítései körülbelül hathavonta jelennek meg.

Azokat a mintákat és eljárásokat, amelyek lehetővé teszik a gyorsabb és megbízhatóbb kiadásokat, hogy értéket nyújtsanak a vállalatnak, együttesen DevOps néven ismertek. Ezek számos olyan ötletből állnak, amelyek a teljes szoftverfejlesztési életciklusra kiterjednek, az alkalmazás megadásától egészen az alkalmazás biztosításáig és működtetéséig.

A DevOps a mikroszolgáltatások előtt jelent meg, és valószínű, hogy a kisebb, célhoz jobban illő szolgáltatások felé való elmozdulás nem lett volna lehetséges anélkül, hogy a DevOps egyszerűbbé tenné a kiadást és az üzemeltetést, nem csupán egy, hanem számos éles környezetben futó alkalmazást.

10–1. ábra – DevOps és mikroszolgáltatások.

A jó DevOps gyakorlatok révén a felhőalapú alkalmazások előnyeit anélkül lehet kihasználni, hogy elnyomja a munkát, amely az alkalmazások üzemeltetéséhez szükséges.

A DevOpsban nincs arany kalapács. Senki sem tud teljes körű és átfogó megoldást kínálni a kiváló minőségű alkalmazások kiadására és üzemeltetésére. Ennek az az oka, hogy minden alkalmazás teljesen különbözik a többitől. Vannak azonban olyan eszközök, amelyek a DevOps-t sokkal kevésbé ijesztővé tehetik. Az egyik ilyen eszköz az Azure DevOps.

Azure DevOps

Az Azure DevOps hosszú törzskönyvvel rendelkezik. Visszakövetheti a gyökereit, amikor a Team Foundation Server először online állapotba került, és a különböző névváltozások révén: Visual Studio Online és Visual Studio Team Services. Az évek során azonban sokkal több lett, mint elődei.

Az Azure DevOps öt fő összetevőből áll:

10–2. ábra – Azure DevOps.

Azure Repos – Forráskódkezelés, amely támogatja a megbízható Team Foundation verziókövetést (TFVC) és az iparági kedvenc Gitet. A lekéréses kérelmek lehetővé teszik a közösségi kódolást azáltal, hogy elősegítik a módosítások megvitatását.

Azure Boards – Probléma- és munkaelem-követő eszközt biztosít, amely arra törekszik, hogy a felhasználók a számukra legmegfelelőbb munkafolyamatokat válasszák ki. Számos előre konfigurált sablont tartalmaz, köztük a SCRUM és Kanban fejlesztési stílusokat támogató sablonokat is.

Azure Pipelines – Olyan build- és kiadáskezelési rendszer, amely támogatja az Azure-ral való szoros integrációt. A buildek különböző platformokon futtathatók a Windowstól a Linuxon át a macOS-en. Buildügynökök telepíthetők a felhőben vagy a helyszínen.

Azure Test Plans – A tesztcsomagok funkció által kínált tesztkezelési és feltáró tesztelési támogatással egyetlen minőségbiztosítási személy sem marad hátra.

Azure Artifacts – Olyan összetevőcsatorna, amely lehetővé teszi a vállalatok számára a NuGet, az npm és mások saját, belső verzióinak létrehozását. Kettős célt szolgál a felsőbb rétegbeli csomagok gyorsítótáraként, ha egy központosított adattár meghibásodik.

Az Azure DevOps legfelső szintű szervezeti egysége projektként ismert. Az egyes projekteken belül a különböző összetevők, például az Azure Artifacts be- és kikapcsolhatók. Ezen összetevők mindegyike különböző előnyöket biztosít a natív felhőbeli alkalmazások számára. A három leghasznosabb az adattárak, táblák és csővezetékek. Ha a felhasználók egy másik adattárban( például a GitHubon) szeretnék kezelni a forráskódjukat, de továbbra is kihasználják az Azure Pipelines és más összetevők előnyeit, ez tökéletesen lehetséges.

Szerencsére a fejlesztői csapatok számos lehetőséget választhatnak az adattárak kiválasztásakor. Az egyik a GitHub.

GitHub-műveletek

A 2009-ben alapított GitHub egy széles körben népszerű webes adattár projektek, dokumentációk és kódok üzemeltetéséhez. Számos nagy technológiai vállalat, például az Apple, az Amazon, a Google és a mainstream vállalatok használják a GitHubot. A GitHub alapjaként a Git nevű nyílt forráskódú, elosztott verziókövetési rendszert használja. Ezután hozzáadja a saját funkcióit, beleértve a hibakövetést, a funkció- és lekéréses kérelmeket, a feladatkezelést és a wikiket az egyes kódbázisokhoz.

A GitHub fejlődése során devOps-funkciókat is hozzáad. Például a GitHub saját folyamatos integrációs/folyamatos kézbesítési (CI/CD) folyamatával rendelkezik, amelynek neve GitHub Actions. A GitHub Actions egy közösségi alapú munkafolyamat-automatizálási eszköz. Lehetővé teszi, hogy a DevOps-csapatok integrálják a meglévő eszközeiket, új termékeket keverjenek össze és egyezzenek meg, és csatlakozhassanak a szoftver életciklusához, beleértve a meglévő CI/CD-partnereket is."

A GitHub több mint 40 millió felhasználóval rendelkezik, így ez a legnagyobb forráskód a világon. 2018 októberében a Microsoft megvásárolta a GitHubot. A Microsoft ígéretet tett arra, hogy a GitHub nyitott platform marad, amelyet bármely fejlesztő csatlakoztathat és kiterjeszthet. Továbbra is független vállalatként működik. A GitHub nagyvállalati, csapat-, professzionális és ingyenes fiókokat kínál.

Forrásvezérlő

A natív felhőbeli alkalmazások kódjának rendszerezése kihívást jelenthet. Egyetlen óriásalkalmazás helyett a natív felhőbeli alkalmazások általában egy kisebb, egymással beszélgető alkalmazásokból álló webből készülnek. A számítástechnikához hasonlóan a kód legjobb elrendezése is nyitott kérdés marad. Vannak példák a különböző elrendezéseket használó sikeres alkalmazásokra, de úgy tűnik, hogy két változat a legnagyobb népszerűségnek örvend.

Mielőtt belefogunk a tényleges forráskövetésbe, érdemes eldönteni, hogy hány projekt megfelelő. Egyetlen projekten belül több adattár és építési folyamat támogatása is elérhető. A táblák egy kicsit bonyolultabbak, de a feladatok könnyen hozzárendelhetők több csapathoz egy projekten belül. Egyetlen Azure DevOps-projektből több száz, akár több ezer fejlesztőt is támogathat. Ez valószínűleg a legjobb megközelítés, mivel egyetlen helyet biztosít minden fejlesztő számára, hogy ki tudja használni, és csökkenti az egyetlen alkalmazás megtalálásának zavarát, amikor a fejlesztők nem biztos abban, hogy melyik projektben található.

A mikroszolgáltatások kódjának felosztása az Azure DevOps-projektben valamivel nagyobb kihívást jelenthet.

10–3. ábra – Egy és több adattár.

Tárhely mikroszolgáltatásonként

Első pillantásra ez a megközelítés tűnik a mikroszolgáltatások forráskódjának felosztásának leglogikusabb módszerének. Minden adattár tartalmazhatja az egyetlen mikroszolgáltatás létrehozásához szükséges kódot. Ennek a megközelítésnek az előnyei könnyen láthatóak:

1. Az alkalmazás létrehozásának és karbantartásának útmutatása hozzáadható egy README-fájlhoz az egyes adattárak gyökerénél. Az adattárak átlapozásakor könnyen megtalálhatja ezeket az utasításokat, így csökkentve a fejlesztők számára a felpörgetési időt.
2. Minden szolgáltatás egy logikai helyen található, könnyen megtalálható a szolgáltatás nevének ismeretével.
3. A buildek egyszerűen beállíthatók úgy, hogy azok csak akkor aktiválódjanak, ha módosítják a saját adattárat.
4. Az adattárakba érkező módosítások száma korlátozódik a projekten dolgozó kis számú fejlesztőkre.
5. A biztonság egyszerűen beállítható azoknak az adattáraknak a korlátozásával, amelyekhez a fejlesztők olvasási és írási engedélyekkel rendelkeznek.
6. Az adattárszintű beállításokat a tulajdonos csapat módosíthatja, és minimálisan megvitathatja másokkal.

A mikroszolgáltatások egyik fő ötlete, hogy a szolgáltatásokat el kell különíteni egymástól. Ha tartományalapú tervezéssel dönt a szolgáltatások határairól, a szolgáltatások tranzakciós határokként működnek. Az adatbázis-frissítések nem terjednek ki több szolgáltatásra. Ezt a kapcsolódó adatgyűjteményt határos környezetnek nevezzük. Ezt az elképzelést tükrözi a mikroszolgáltatási adatok elkülönítése egy adatbázisra, amely elkülönül a többi szolgáltatástól. Nagyon sok értelme van ennek az ötletnek egészen a forráskódig.

Ez a megközelítés azonban nem nélküle van a problémáinak. Az egyik legkülönlegesebb fejlesztési probléma a függőségek kezelése. Vegye figyelembe az átlagos node_modules könyvtárat alkotó fájlok számát. Egy ilyen új create-react-app telepítés valószínűleg több ezer csomagot hoz magával. A függőségek kezelésének kérdése nehéz kérdés.

Ha egy függőség frissül, akkor az alsóbb rétegbeli csomagoknak is frissíteniük kell ezt a függőséget. Sajnos ez fejlesztési munkát igényel, így a node_modules címtár mindig egyetlen csomag több verziójával végződik, amelyek mindegyike egy másik csomag függősége, amely kissé eltérő ütemben van verziószámmal elkönyvelve. Alkalmazás üzembe helyezésekor a függőség melyik verzióját kell használni? A jelenleg produciós környezetben lévő verzió? Az a verzió, amely jelenleg bétaverzió, de valószínűleg élesben lesz, mire a felhasználó igényli vagy használja. Nehéz problémák, amelyeket nem csak mikroszolgáltatások használatával oldunk meg.

Vannak olyan kódtárak, amelyektől számos projekt függ. A mikroszolgáltatásoknak az egyes adattárak egy-egyével való felosztásával a belső függőségek a legjobban a belső adattár, az Azure Artifacts használatával oldhatók meg. A kódtárak buildjei belső felhasználás céljából leküldik a legújabb verziókat az Azure Artifactsbe. Az alsóbb rétegbeli projektet továbbra is manuálisan kell frissíteni, hogy függőséget vállaljon az újonnan frissített csomagoktól.

Egy másik hátrány a kód szolgáltatások közötti áthelyezésekor jelentkezik. Bár jó lenne azt hinni, hogy az alkalmazás első osztása mikroszolgáltatásokra 100% helyes, a valóság az, hogy ritkán vagyunk olyan előkészületei, hogy nem követünk el szolgáltatásmegosztási hibákat. Így a funkcióknak és az azt meghajtó kódnak át kell lépnie a szolgáltatásról a szolgáltatásra: az adattárról az adattárra. Amikor az egyik adattárból a másikba ugrott, a kód elveszíti az előzményeit. Sok esetben, különösen audit esetén, ahol egy kód teljes előzményei felbecsülhetetlen értékűek.

A végső és legfontosabb hátrány a változások koordinálása. Egy valódi mikroszolgáltatás-alkalmazásban nem lehetnek üzembehelyezési függőségek a szolgáltatások között. Az A, B és C szolgáltatásokat bármilyen sorrendben üzembe kell helyezni, mivel laza összekapcsolásuk van. A valóságban azonban vannak olyan esetek, amikor kívánatos olyan módosítást végezni, amely egyszerre több adattárat keresztez. Ilyen például egy kódtár frissítése egy biztonsági rés bezárásához vagy az összes szolgáltatás által használt kommunikációs protokoll módosítása.

Az adattárak közötti módosításhoz az egyes adattárakra vonatkozó véglegesítést kell végrehajtani egymás után. Az egyes adattárak minden módosítását külön kell lekérni és áttekinteni. Ezt a tevékenységet nehéz lehet koordinálni.

A sok adattár használatának alternatíva az, ha az összes forráskódot egy óriási, mindentudó, egyetlen adattárba helyezi.

Önálló adattár

Ebben a megközelítésben, amelyet monorepositorynak is neveznek, minden szolgáltatás összes forráskódja ugyanabba az adattárba kerül. Elsőre ez a megközelítés egy szörnyű ötletnek tűnik, amely valószínűleg a forráskód kezelésének zavarát kelti. Az ilyen munka azonban jelentős előnyökkel jár.

Az első előnye, hogy könnyebb kezelni a projektek közötti függőségeket. Ahelyett, hogy valamilyen külső artifakt-ellátási forrásra támaszkodnak, a projektek közvetlenül importálhatják egymást. Ez azt jelenti, hogy a frissítések azonnaliak, és az ütköző verziók valószínűleg felismerhetők fordítási időben a fejlesztő munkaállomásának rendszerében. Gyakorlatilag az integrációs tesztelés egy része balra tolódik.

A projektek közötti kódáthelyezési eljárás egyszerűbbé teszi az előzmények megőrzését, mivel a rendszer a fájlok átírása helyett áthelyezettként észleli a fájlokat.

Egy másik előnye, hogy a szolgáltatáshatárok közötti széles körű módosítások egyetlen véglegesítésben is végezhetők. Ez a tevékenység csökkenti annak a többletterhelését, hogy akár több tucat módosítást is egyenként kell áttekinteni.

Számos eszköz képes statikus kódelemzést végezni a nem biztonságos programozási eljárások vagy az API-k problémás használatának észlelésére. A több adattárral rendelkező világban minden adattárat át kell alakítani, hogy megtalálja a bennük lévő problémákat. Az egyetlen adattár lehetővé teszi az elemzés egy helyen történő futtatását.

Az egyetlen adattár megközelítésének számos hátránya is van. Az egyik leginkább aggasztó az, hogy egyetlen adattár használata biztonsági aggályokat vet fel. Ha az adattár tartalma kiszivárog a szolgáltatás-per-adattár modellben, az elveszett kód mennyisége minimális. Egyetlen adattárral a vállalat tulajdonában lévő összes adat elveszhet. A múltban sok példa volt arra, hogy ez történt, ami kisiklatta a teljes játékfejlesztési erőfeszítéseket. A több adattár kevesebb felületet tesz elérhetővé, ami a legtöbb biztonsági gyakorlatban kívánatos tulajdonság.

Az önálló adattár mérete valószínűleg gyorsan kezelhetetlenné válik. Ez érdekes teljesítménybeli következményekkel jár. Szükség lehet olyan speciális eszközök használatára, mint a Git virtuális fájlrendszere, amelyet eredetileg a Windows-csapat fejlesztőinek nyújtott élmény javítása érdekében terveztek.

Az egyetlen adattár használatának argumentuma gyakran olyan argumentumra vezethető vissza, amely szerint a Facebook vagy a Google ezt a módszert használja a forráskód-elrendezéshez. Ha a megközelítés elég jó ezeknek a vállalatoknak, akkor biztosan ez a helyes megközelítés minden vállalat számára. Az igazság az, hogy kevés vállalat működik olyan nagyságrendben, mint a Facebook vagy a Google. Az ilyen skálákon előforduló problémák eltérnek azoktól, amelyekkel a legtöbb fejlesztő szembesül. Ami jó a liba számára, az nem jó a gandernek.

Végül bármelyik megoldás használható a mikroszolgáltatások forráskódjának üzemeltetésére. A legtöbb esetben azonban az egyetlen adattárban való üzemeltetés felügyeleti és mérnöki többletterhelése nem éri meg az elenyésző előnyöket. A kód több adattárra való felosztása az aggodalmak jobb elkülönítését és a fejlesztési csapatok autonómiáját ösztönzi.

Standard könyvtárstruktúra

Az egyszintű vagy többszintű adattárakról folytatott vita ellenére minden szolgáltatásnak saját könyvtára lesz. Az egyik legjobb optimalizálás, amely lehetővé teszi a fejlesztők számára, hogy gyorsan mozogjanak a projektek között, a szabványos címtárstruktúra fenntartása.

Ábra 10–4 – Standard könyvtárstruktúra.

Új projekt létrehozásakor a megfelelő struktúrát létrehozó sablont kell használni. Ez a sablon olyan hasznos elemeket is tartalmazhat, mint egy kezdetleges README-fájl és egy azure-pipelines.yml. Bármely mikroszolgáltatás-architektúrában a projektek közötti nagy szórás megnehezíti a szolgáltatások tömeges műveleteit.

Számos olyan eszköz létezik, amely több forráskódkönyvtárat tartalmazó teljes könyvtárhoz biztosít templatálást. A Yeoman népszerű a JavaScript-világban, és a GitHub nemrég kiadott adattársablonokat, amelyek sok azonos funkciót biztosítanak.

Feladatkezelés

A tevékenységek kezelése bármilyen projektben nehéz lehet. Az optimális fejlesztői hatékonyság biztosítása érdekében számos kérdés megválaszolható a munkafolyamatok beállításával kapcsolatban.

A natív felhőalkalmazások általában kisebbek, mint a hagyományos szoftvertermékek, vagy legalábbis kisebb szolgáltatásokra vannak felosztva. A szolgáltatásokkal kapcsolatos problémák és feladatok nyomon követése ugyanolyan fontos marad, mint bármely más szoftverprojekt esetén. Senki sem szeretné elveszíteni a munkaelemek nyomon követését, vagy elmagyarázni egy ügyfélnek, hogy a probléma nem lett megfelelően naplózva. A táblák a projekt szintjén vannak konfigurálva, de minden projekten belül meghatározhatók területek. Ezek lehetővé teszik a problémák több összetevő közötti lebontását. Annak az előnye, hogy a teljes alkalmazás összes munkáját egy helyen tartja, hogy könnyen áthelyezheti a munkaelemeket az egyik csapatból a másikba, mivel jobban megértették őket.

Az Azure DevOps számos előre konfigurált népszerű sablont tartalmaz. A legalapvetőbb konfigurációban mindössze annyit kell tudnia, hogy mi van a hátralékban, min dolgoznak az emberek, és mi a teendő. Fontos, hogy a szoftverkészítés folyamatában ez látható legyen, hogy a munka prioritást és befejezett feladatokat jelentsen az ügyfélnek. Természetesen kevés szoftverprojekt ragaszkodik egy olyan egyszerű folyamathoz, mint to doa , doingés done. Nem tart sokáig, amíg az emberek el nem kezdenek lépéseket, mint például QA vagy Detailed Specification, hozzáadni a folyamathoz.

Az Agilis módszertanok egyik legfontosabb része az önbetekintés rendszeres időközönként. Ezek az értékelések betekintést nyújtanak a csapat által tapasztalt problémákba és azok továbbfejlesztéséhez. Ez gyakran azt jelenti, hogy a fejlesztési folyamat során megváltozik a problémák és szolgáltatások folyamata. Tehát tökéletesen egészséges, ha további szakaszokkal bővíti a táblák elrendezését.

A táblákon lévő szakaszok nem az egyetlen szervezeti eszköz. A tábla konfigurációjától függően a munkaelemek hierarchiája létezik. A táblán megjelenő legrészletesebb elem egy feladat. A kereten kívül egy tevékenység tartalmaz egy cím, leírás, prioritás mezőit, a hátralévő munka mennyiségének becslését, valamint az egyéb munkaelemekhez vagy fejlesztési elemekhez (ágakhoz, véglegesítésekhez, lekéréses kérelmekhez, buildekhez stb.) való csatolás lehetőségét. A munkaelemek az alkalmazás különböző területeire és különböző iterációkba (futamokba) sorolhatók, hogy könnyebben megtalálják őket.

10–5. ábra – Feladat az Azure DevOpsban.

A leírás mező támogatja a várt szokásos stílusokat (félkövér, dőlt aláhúzás és áthúzás) és a képek beszúrásának képességét. Ez hatékony eszköz a munka vagy a hibák specifikálására.

A tevékenységek olyan funkciókká alakíthatók, amelyek nagyobb munkaegységet határoznak meg. A funkciók viszont összegyűjthetők epikákba. A feladatok ebbe a hierarchiába való besorolásával sokkal könnyebben megértheti, hogy milyen közel áll egy nagy funkció a bevezetéshez.

10–6. ábra – Munkaelem az Azure DevOpsban.

Az Azure Boards problémáinak különböző nézetei vannak. A még nem ütemezett elemek megjelennek a hátralékban. Innen hozzárendelhetők egy sprinthez. A sprint egy időkeret, amely során várhatóan bizonyos mennyiségű munkát elvégeznek. Ez a munka magában foglalhatja a feladatokat, de a jegyek felbontását is. Miután odaért, a teljes sprint kezelése a sprint tábla szakaszából történhet. Ez a nézet bemutatja, hogyan halad a munka, és tartalmaz egy burndown diagramot, amely folyamatosan frissülő becslést nyújt arról, hogy mennyire sikeres lesz a sprint.

10–7. ábra – Tábla az Azure DevOpsban.

Mostanra nyilvánvalóvá válik, hogy az Azure DevOps táblákban nagy erő rejlik. A fejlesztők számára könnyen áttekinthető, hogy min dolgoznak. A projektmenedzserek betekintést nyernek a közelgő munkafolyamatokba, valamint áttekintést kapnak a meglévő munkáról. A vezetők számára rengeteg jelentés áll rendelkezésre az erőforrások kezeléséről és a kapacitásról. Sajnos nincs semmi varázslatos a natív felhőbeli alkalmazásokban, ami szükségtelenné teszi a munka nyomon követését. Ha azonban nyomon kell követnie a munkát, van néhány hely, ahol a felhasználói élmény jobb, mint az Azure DevOpsban.

CI/CD csővezetékek

A szoftverfejlesztési életciklus szinte semmilyen változása nem volt olyan forradalmi, mint a folyamatos integráció (CI) és a folyamatos teljesítés (CD) megjelenése. Automatizált tesztek készítése és futtatása egy projekt forráskódján, amint módosítást hajtanak végre, lehetővé teszi a hibák korai felismerését. A folyamatos integrációs buildek megjelenése előtt nem ritka, hogy lekérjük a kódot az adattárból, és azt tapasztaljuk, hogy nem felelt meg a teszteknek, vagy nem is sikerült felépíteni. Ez a törés forrásának nyomon követését eredményezte.

A szoftverek éles környezetbe történő hagyományos szállítása kiterjedt dokumentációt és a lépések listáját igényelte. Ezen lépések mindegyikét manuálisan kellett elvégezni egy nagyon hibalehetőségű folyamat során.

10-8. ábra – Ellenőrzőlista.

A folyamatos integráció nővére a folyamatos szállítás, amelyben a frissen összeállított csomagok egy adott környezetben kerülnek üzembe helyezésre. A manuális folyamat nem skálázható úgy, hogy megfeleljen a fejlesztés sebességének, így az automatizálás egyre fontosabbá válik. Az ellenőrzőlistákat olyan szkriptek váltják fel, amelyek gyorsabban és pontosabban hajtják végre ugyanazokat a feladatokat, mint bármely ember.

A folyamatos teljesítés célkörnyezete lehet tesztkörnyezet, vagy ahogy azt számos nagy technológiai vállalatnál szokás, az éles környezet. Az utóbbihoz olyan, kiváló minőségű tesztekbe való befektetésre van szükség, amely biztos lehet abban, hogy a változás nem fogja megszakítani a felhasználók termelését. Ugyanúgy, ahogy a folyamatos integráció korán észleli a kódban felmerülő problémákat, a folyamatos kézbesítés korán észleli az üzembe helyezési folyamatban felmerülő problémákat.

A buildelési és kézbesítési folyamat automatizálásának fontosságát a natív felhőbeli alkalmazások hangsúlyozzák. A telepítések gyakrabban és több környezetben történnek, így a manuális telepítés szinte lehetetlen.

Azure-buildek

Az Azure DevOps olyan eszközöket biztosít, amelyekkel minden eddiginél egyszerűbbé teheti a folyamatos integrációt és üzembe helyezést. Ezek az eszközök az Azure Pipelines alatt találhatók. Az első az Azure Builds, amely a YAML-alapú builddefiníciók nagy léptékű futtatására szolgáló eszköz. A felhasználók saját buildelési gépeket is használhatnak (nagyszerű, ha a buildhez aprólékosan be kell állítani a környezetet), vagy használhatnak egy gépet az Azure által üzemeltetett virtuális gépek folyamatosan frissített készletéből. Ezek a üzemeltetett buildügynökök előre telepítve vannak számos fejlesztési eszközzel nem csak .NET-fejlesztéshez, hanem mindenhez, a Java-tól a Pythonon át az iPhone-fejlesztésig.

A DevOps a dobozon kívüli builddefiníciók széles skáláját tartalmazza, amelyek bármilyen buildhez testre szabhatók. A builddefiníciók egy azure-pipelines.yml nevű fájlban vannak definiálva, és fel vannak töltve az adattárba, hogy a forráskóddal együtt verzionálhatók legyenek. Ez sokkal egyszerűbbé teszi a buildelési folyamat módosítását egy ágban, mivel a módosítások csak ebbe az ágba vehetők be. Egy ASP.NET-webalkalmazás teljes keretrendszeren való létrehozására példa azure-pipelines.yml a 10–9. ábrán látható.

name: $(rev:r)

variables:
  version: 9.2.0.$(Build.BuildNumber)
  solution: Portals.sln
  artifactName: drop
  buildPlatform: any cpu
  buildConfiguration: release

pool:
  name: Hosted VisualStudio
  demands:
  - msbuild
  - visualstudio
  - vstest

steps:
- task: NuGetToolInstaller@0
  displayName: 'Use NuGet 4.4.1'
  inputs:
    versionSpec: 4.4.1

- task: NuGetCommand@2
  displayName: 'NuGet restore'
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  displayName: 'Build solution'
  inputs:
    solution: '$(solution)'
    msbuildArgs: '-p:DeployOnBuild=true -p:WebPublishMethod=Package -p:PackageAsSingleFile=true -p:SkipInvalidConfigurations=true -p:PackageLocation="$(build.artifactstagingdirectory)\\"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  displayName: 'Test Assemblies'
  inputs:
    testAssemblyVer2: |
     **\$(buildConfiguration)\**\*test*.dll
     !**\obj\**
     !**\*testadapter.dll
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: CopyFiles@2
  displayName: 'Copy UI Test Files to: $(build.artifactstagingdirectory)'
  inputs:
    SourceFolder: UITests
    TargetFolder: '$(build.artifactstagingdirectory)/uitests'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact'
  inputs:
    PathtoPublish: '$(build.artifactstagingdirectory)'
    ArtifactName: '$(artifactName)'
  condition: succeededOrFailed()

10–9. ábra – azure-pipelines.yml minta

Ez a builddefiníció számos beépített feladatot használ, amelyek olyan egyszerűvé teszik a buildek létrehozását, mint egy Lego-készlet létrehozása (egyszerűbb, mint az óriás Millennium Falcon). A NuGet-feladat például visszaállítja a NuGet-csomagokat, míg a VSBuild feladat meghívja a Visual Studio buildelési eszközeit a tényleges fordítás végrehajtásához. Az Azure DevOpsban több száz különböző feladat érhető el, és több ezer feladatot tart fenn a közösség. Valószínű, hogy függetlenül attól, hogy milyen buildelési feladatokat szeretne futtatni, valaki már készített egyet.

A buildek manuálisan, bejelentkezéssel, ütemezés szerint vagy egy másik build befejezésével indíthatók el. A legtöbb esetben minden bejelentkezésre érdemes építkezni. A buildek szűrhetők, így a különböző buildek az adattár különböző részein vagy különböző ágakon futnak. Ez olyan forgatókönyveket tesz lehetővé, mint a gyors buildelés futtatása a pull requestek korlátozott tesztelésével, és a teljes regressziós tesztcsomag éjszakai futtatása a főágon.

A build végeredménye a buildösszetevők néven ismert fájlok gyűjteménye. Ezek az összetevők átadhatók a buildelési folyamat következő lépéséhez, vagy hozzáadhatók egy Azure Artifacts-hírcsatornához, hogy más buildek is felhasználhassák őket.

Azure DevOps-kiadások

A buildek gondoskodnak a szoftver egy szállítható csomagban való összeállításáról, de az összetevőket továbbra is ki kell küldeni egy tesztelési környezetbe a folyamatos teljesítés befejezéséhez. Ehhez az Azure DevOps egy külön, Releases nevű eszközt használ. A Releases eszköz ugyanazt a feladattárat használja, amely elérhető volt a buildhez, de bevezeti a "szakaszok" fogalmát. A szakasz egy elszigetelt környezet, amelybe a csomag telepítve van. Előfordulhat például, hogy egy termék egy fejlesztési környezetet, egy minőségbiztosítási környezetet és egy éles környezetet használ. A kód folyamatosan a fejlesztési környezetbe kerül, ahol automatizált tesztek futtathatók rajta. Miután ezek a tesztek átjutottak, a kiadás a minőségbiztosítási környezetbe kerül manuális tesztelés céljából. Végül a kód termelési környezetbe kerül, ahol mindenki számára látható.

10–10. ábra – Kiadási csővezeték

A build minden szakasza automatikusan aktiválható az előző fázis befejezésével. Sok esetben azonban ez nem kívánatos. Előfordulhat, hogy a kód éles környezetbe való áthelyezése valamilyen jóváhagyást igényel. A Kiadási eszközök ezt úgy támogatják, hogy engedélyezik a jóváhagyók számára a kiadási folyamat minden lépését. A szabályok úgy állíthatók be, hogy egy adott személynek vagy csoportnak jóvá kell hagynia egy kiadást, mielőtt éles környezetbe kerül. Ezek a kapuk lehetővé teszik a manuális minőségellenőrzést, valamint a gyártásba kerülés szabályozására vonatkozó jogszabályi követelményeknek való megfelelést.

Mindenki kap egy build csővezetéket

Sok buildfolyamat konfigurálásának nincs költsége, ezért előnyös, ha mikroszolgáltatásonként legalább egy buildfolyamatot használ. Ideális esetben a mikroszolgáltatások egymástól függetlenül üzembe helyezhetők bármely környezetben, így tökéletes, ha mindegyik a saját folyamatán keresztül is kibocsátható anélkül, hogy egy nem kapcsolódó kód tömegét bocsátanák ki. Minden folyamat rendelkezhet saját jóváhagyásokkal, amelyek lehetővé teszik az egyes szolgáltatások buildelési folyamatának variációit.

Verziókiadások

A Kiadások funkció használatának egyik hátránya, hogy nem definiálható egy beadott fájlban azure-pipelines.yml . Ennek számos oka lehet az ágonkénti kiadási definícióktól kezdve a kiadási csontváz projektsablonba való belefogalmazásán át. Szerencsére folyamatban van a munka, hogy a támogatás egy részét a Build komponensre áthelyezzék. Ez többfázisú buildként lesz ismert, és az első verzió már elérhető!

ElőzőKövetkező