Kezdő útmutató az Azure DevOps világához
Röviden bemutatom a Microsoft saját DevOps platformját, amelyet az Azure felhőben hoztak létre. A cél az volt, hogy a DevOps módszertannal dolgozó fejlesztőcsapatoknak ne kelljen saját „szoftvergyárat” építeniük, hanem egy szolgáltatásként bérelhető megoldást (SaaS) használhassanak.
Egy jól működő CI/CD pipeline kiépítése on-premise környezetben vagy egyéb IaaS (Infrastructure as a Service) platformon akár egy évig is eltarthat, ami jelentős idő- és erőforrásigényű feladat. Nem minden vállalat szeretne ennyi energiát fektetni a DevOps bevezetésébe.
Az Azure DevOps viszont egy azonnal használható, előre integrált szolgáltatás, amely a szakértők szerint is az egyik legjobb megoldás a területén. Ha egy csapat gyorsan és hatékonyan szeretne átállni a DevOps módszertanra, akkor ez egy kézenfekvő és megbízható választás.
Mi is a DevOps?
A hivatalos megfogalmazás:
„Együttműködési keretrendszer, hozzáállás, ami azt biztosítja, hogy a fejlesztés, minőségbiztosítás, biztonság, és üzemeltetés, meg tudjon felelni, a mai gyorsan változó üzleti, és ügyfél igényeknek.”
Saját megközelítésemben:
„A szoftverfejlesztés automatizálása jelentősen felgyorsítja a szoftverek szállítását, mivel lehetővé teszi a fejlesztőcsapatok és az üzemeltető mérnökök hatékony együttműködését. Ezt az agilis (rugalmas, gyors alkalmazkodást biztosító) munkafolyamatok és a CI/CD csővezeték (pipeline) alkalmazása teszi lehetővé.”
Lássuk ezt a gyakorlatban!
A modern, automatizált szoftverfejlesztés folyamata úgy kezdődik, hogy a fejlesztők egy forráskódot hoznak létre és kezelnek egy verziókövető rendszerben (például Git). A csapat tagjai párhuzamosan dolgoznak különböző ágakon (branch-eken), amelyek végül egy központi ágba (main branch) kerülnek összeolvasztásra.
Ebből a forráskódból egy szoftver épül („build”), amelyet egy Docker konténerbe csomagolnak. A konténert ezt követően egy tárolóba (pl. Artifact vagy Docker Container Registry) töltik fel, ahol az elkészült szoftververziók elérhetők és tárolhatók.
A build folyamat során különböző tesztek és validációk futnak, amelyek ellenőrzik a biztonságot, sérülékenységeket és egyéb minőségi szempontokat. Ha minden megfelel az elvárásoknak, következik a telepítés (deployment) fázisa, amely során a szoftvert általában egy Kubernetes clusterre helyezik ki. Ennek előnyei közé tartozik a folyamatos működés (leállás nélküli frissítés), az automatikus skálázás, a nagy rendelkezésre állás és még sok más.
A rendszer folyamatos üzemeltetés és monitorozás alatt áll, és ha fejlesztésre vagy hibajavításra van szükség (ami manapság szinte állandó), a teljes folyamat újraindul. Ez olyan, mint egy önmagába visszatérő ciklus – az egész automatizált, a felhasználók pedig észrevétlenül mindig a legújabb verziót használják.
Az Azure Dev Ops ennek egy megvalósítása, ugyan ez földi céges infrastruktúrán futhat nem muszáj felhő hozzá (például Jira, Bitbucket, Nexus, OpenShift-el).
Az Azure DevOps egyes komponensein, fázisain keresztül ismertetem a képsségeit, és azt, hogyan is működik.
A teljes folyamat, forrás: digitalvarys.com
Azure DevOps szolgáltatásai (Services)
Azure Boards
Az Azure Boards egy fejlett ticketing tool, amely támogatja a tervezést, a hibák nyomon követését és a feladatkezelést. Lehetővé teszi a feladatok hatékony felosztását és új projektek indítását Agile vagy Scrum munkafolyamatokkal (workflows), amelyek a modern szoftverfejlesztés legelterjedtebb módszerei. Az Azure Boards Kanban boardokat használ a feladatok vizuális tervezésére és kezelésére, így biztosítva az átláthatóságot és a hatékony együttműködést a csapatok számára.
On-Premise megfelelője: Jira
Azure Repos
Az Azure Repos egy verziókezelő modul, amely a Git-et használja a fejlesztők közötti hatékony együttműködés biztosítására. A forráskód kezelése Git workflow-k (pl. Pull Request, Pushes, Branches) segítségével történik, lehetővé téve a csapat számára a strukturált és átlátható fejlesztést.
Az Azure Repos nem csupán a forráskód tárolására szolgál, hanem a DevOps életciklus szerves részeként támogatja a közös munkát és a folyamatos integrációt, biztosítva a magas minőségű kód létrehozását.
A fejlesztési folyamat során egy fejlesztő ideiglenes branch-et hoz létre, majd ha elkészült, Pull Requestet indít. A többi fejlesztő áttekintheti, kommentelheti és szükség esetén módosításokat javasolhat. Az iterációk addig folytatódnak, amíg a Pull Request megfelelő minőségű nem lesz, majd végül beolvasztják (merge) a main branch-be, biztosítva a stabil és jól karbantartható kódbázist.
On-premise alternatívái: GitLab (Self-Managed), amely teljes körű Git-alapú verziókezelést biztosít beépített CI/CD támogatással. Egy másik lehetőség a GitHub Enterprise (Self-Hosted), amely a GitHub összes funkcióját kínálja saját infrastruktúrán. Emellett a Bitbucket Server (Atlassian) is népszerű választás, különösen azok számára, akik szoros integrációt keresnek a JIRA-val.
Azure Pipelines
Az Azure Pipelines a CI/CD folyamatokért felelős modul, amely lehetővé teszi automatizált csővezetékek (pipelines) létrehozását. Amikor a main branch-be történő merge megtörténik az Azure Repos-ban, a kódot ki kell adni (release), hogy a végfelhasználók is láthassák a változásokat – például egy hibajavítás eredményét. Más szóval, a kód élesítésre kerül.
A CI (Continuous Integration) során a kódot automatikusan tesztelik és egy artifact-ba csomagolják. Ezt követően a CD (Continuous Deployment/Delivery) szakaszban az artifact továbbításra kerül, majd telepítik a megfelelő futtatókörnyezetbe.
Az Azure Pipelines teljesen automatizáltan működik, és YAML formátumú fájlokat használ, amelyek steps (lépések) sorozatából épülnek fel, biztosítva az átlátható és hatékony munkafolyamatokat.
Egy szemléletető példa a lépésekre:
- Run tests
- Package application
- Build Docker image
- Push Docker image
Az Azure Pipelines YAML-alapú konfigurációja lépésekből (steps) épül fel, ahol minden step egy adott parancsot hajt végre. Egy YAML fájlban például az első két lépés lehet egy .NET parancs, míg a következő kettő Docker parancs.
Az Azure Pipelines különböző programozási nyelvekhez, például Java, .NET, Python stb., előre definiált YAML sablonokat kínál, amelyeket az adott projekt technológiai stackjéhez igazíthatsz. Ezek a sablonok könnyen integrálhatók a YAML szerkesztőbe, segítve a gyors és hatékony konfigurációt.
A folyamatokat job-ok kezelik, amelyek több step-ből állnak és akár párhuzamosan is futhatnak. Például egy job felelhet a Windows-on futó unit tesztekért, míg egy másik párhuzamosan a Linux-on futó unit tesztekért.
Ezeket a job-okat egy úgynevezett agent hajtja végre, amely az adott infrastruktúrához tartozó agent poolban (Windows, Linux vagy Mac) fut. Ez lehetőséget biztosít a skálázható és rugalmas CI/CD folyamatok kialakítására.
Az Azure Pipelines lehetővé teszi, hogy például a Lint tesztek és Unit tesztek egyszerre, párhuzamosan fussanak több platformon (pl. Windows és Linux), optimalizálva ezzel a tesztelési folyamatot.
- Lint teszt: A kód formázását és stílusát ellenőrzi, biztosítva az egységes kódminőséget.
- Unit teszt: A kód kisebb egységeit (pl. függvényeket) vizsgálja, hogy külön-külön megfelelően működnek-e.
A CD (Continuous Deployment vagy Continuous Delivery) teljesen automatizált folyamat, amely a kódváltozások éles környezetbe állítását végzi, minimalizálva a manuális beavatkozás szükségességét.
A CI/CD pipeline logikailag stage-ekre (szakaszokra) bontható, amelyek meghatározott műveleteket végeznek:
- Build stage: A forráskód lefordítása, tesztelése és artifact-ba csomagolása.
- Deploy stage: A kész artifact telepítése a célkörnyezetbe.
Ez a szétválasztás biztosítja a folyamat átláthatóságát és ellenőrizhetőségét.
A deployment folyamat általában nem közvetlenül az éles környezetbe (Production) történik, hanem fokozatosan, először Development, majd Test, végül Production sorrendben. Ezeket a különböző Deployment Stage-ekbe szervezik a CI/CD pipeline-on belül, biztosítva a lépésenkénti validációt és minimalizálva a kockázatokat.
Az Azure Pipelines lehetőséget biztosít YAML sablonok (templates) létrehozására, amelyek újrafelhasználhatók a különböző pipeline-szakaszokban. Ezáltal a konfiguráció egyszerűbbé és egységesebbé válik, hiszen a YAML fájlban csak hivatkozni kell a meglévő sablonokra.
Sablonok létrehozhatók különböző szinteken:
- Step template – Egyedi lépésekhez (pl. egy adott tesztfutás vagy build parancs).
- Job template – Összetettebb feladatcsoportokhoz (pl. egy teljes tesztfázis).
- Stage template – Teljes Deployment Stage-ekhez, amelyeket több pipeline is használhat (pl. Development, Test, Production).
Ez a módszer segít abban, hogy az automatizálás egységes és hatékony legyen, miközben elkerüli a felesleges ismétlődéseket a YAML beállításokban.
Environmtents:
A Pipelines lehetőséget biztosít különböző környezetek (environments) definiálására, például Development, Test, Production. Ezekre a YAML fájlban egyszerűen lehet hivatkozni, például:
Ezáltal a deployment folyamatai strukturáltabbá és automatizálhatóbbá válnak, biztosítva, hogy a kód a megfelelő környezetbe kerüljön.
Az Azure DevOps UI (felhasználói felület) külön kezeli a Build és Release pipeline-okat, azonban ajánlott a teljes folyamatot YAML fájlban kezelni, mivel ez jobban skálázható, könnyebben verziókövethető és automatizálható, mint a grafikus konfiguráció.
Ha on-premise CI/CD megoldásra van szükség, az Azure Pipelines megfelelője például a Jenkins, amely széles körben elterjedt és rugalmasan konfigurálható. Természetesen számos más alternatíva is létezik, de a Jenkins az egyik legismertebb.
Azure Artifacts
Az Artifacts egy olyan modul, amely lehetővé teszi szoftvercsomagok tárolását és megosztását különböző programozási nyelvek szerint. Használható publikus vagy privát forrásokból, és különböző artifact formátumokban képes tárolni az elkészült csomagokat, például:
- NuGet (.NET)
- npm (JavaScript)
- Maven (Java)
- Python
- Docker image-ek
Mi is az Artifact?
Egy artifact az a kézzelfogható eredmény, amely a forráskódból létrejön – lehet ez egy bináris fájl, egy szoftvercsomag, vagy akár egy Docker image. Az Artifact Repository egy olyan tárhely, ahol ezek a kész termékek tárolódnak és verziókövethetők.
Modern szoftverfejlesztés: Docker-alapú buildelés
Függetlenül attól, hogy milyen programozási nyelvet használunk, a modern fejlesztésben Docker image-ekbe építjük a szoftvert. Ez biztosítja a környezetfüggetlenséget és a könnyű skálázhatóságot. Az elkészült artifact így mindig egy Docker image lesz, amelyet az alábbi platformokon lehet tárolni:
- DockerHub
- Azure Container Registry (ACR)
- Amazon Elastic Container Registry (ECR)
On-premise alternatíva: Ha saját környezetben szeretnél artifact tárolót, akkor az Azure Artifacts egyik on-premise megfelelője a Nexus, amely széles körben használt repository manager. Természetesen más alternatívák is léteznek, de a Nexus az egyik legismertebb megoldás.
Azure Test Plans
Az Test Plans egy böngészőalapú tesztmenedzsment eszköz, amely segíti a fejlesztőket és tesztelőket a szoftverek minőségének biztosításában. A megfelelő tesztelés kiemelten fontos, hiszen közvetlen hatással van a felhasználói elégedettségre és a rendszer megbízhatóságára.
Központi felületet biztosít a tesztesetek létrehozására és kezelésére, lehetővé téve különböző teszttípusok kezelését, például:
- Manuális tesztek – Kézi ellenőrzések, amelyeket a tesztelők hajtanak végre.
- Automatizált tesztek – Futtathatók önállóan vagy az Azure Pipelines részeként.
- Függvénytesztek (Unit Tests) – A kód kis egységeinek helyes működését ellenőrzik.
- UI-tesztek – A felhasználói felület viselkedését vizsgálják.
- API-tesztek – Az alkalmazás backend-kommunikációját tesztelik.
A tesztek csoportosíthatók, futtathatók és az eredmények riportokban tekinthetők meg. Emellett az Azure Boards integrációval a tesztesetek jelölhetők a Kanban boardon, így a csapat könnyedén követheti a tesztelések állapotát.
On-premise alternatíva: Ha helyszíni (on-premise) tesztmenedzsment eszközre van szükség, az Azure Test Plans egyik jól ismert megfelelője a TestRail, amely hasonló funkciókat kínál a manuális és automatizált tesztelések kezelésére.