CI/CD - folyamatos integrációs tesztelés- és fejlesztés-támogatás

Már micro-service platformon is

A TCD keretrendszer egy olyan standardizált folyamatot biztosít, amely végig kíséri és automatizálja az alkalmazás életciklusának lépéseit a fejlesztéstől kezdve a tesztelésen át egészen a „deploy”-olási és élesítési feladatokig, beleértve a minőség biztosítási (TQG, Telvice Quality Gate) vizsgálatot is.

TELVICE CONTINUOUS DELIVERY PLATFORM

Célkitűzés

Nagyvállalati IT alkalmazások fejlesztési, tesztelési és éles telepítési folyamatainak teljeskörű automatizálása, illetve a folyamatos minőség kontroll biztosítása, konténeres és monolitikus környezetben.

Az implementáció során a DevOps szakértőink átadják a használathoz szükséges tudást, know-how-t, így az ügyfeleink képessé válnak külső segítség nélkül is kezelni a kialakított rendszert.

Eszközök

Jenkins, Docker, Ansible, Kubernetes, OpenShift, SonarQube, GIT, GitFlow, Dynatrace, Maven, Nexus, JMeter, Selenium, Katalon Studio, JUnit, Gitea

A keretrendszert minden esetben illesztjük az ügyfél adott környezetéhez és a használt eszközökhöz.

TCD – TELVICE CONTINUOUS DELIVERY

A TCD keretrendszer egy olyan standardizált folyamatot biztosít, amely végig kíséri és automatizálja az alkalmazás életciklusának lépéseit a fejlesztéstől kezdve a tesztelésen át egészen a „deploy”-olási és élesítési feladatokig, beleértve a minőség biztosítási (TQG, Telvice Quality Gate) vizsgálatot is az alábbi alapelemekkel:

Statikus kód ellenőrzés: Több ezer beépített szabály segítségével a SonarQube képes kimutatni a tipikus kódolási problémákat a forráskódot és byte kódot elemezve.

Automatizált tesztek: A kialakított integrációs egységben performancia és felületi tesztek segítségével mérjük az előre definiált metrikákat és biztosítjuk a hibamentességet.

Alkalmazás Teljesítmény Management (APM): Az integrált APM megoldásunk a Dynatrace, ami lézer pontossággal rámutat a problémák gyökér okaira, a funkcionális hibákra, illetve anomáliákra, legyen szó éles, teszt, vagy fejlesztői környezetről.

A Kubernetes és OpenShift eszközöket használjuk az alkalmazások éles környezeti menedzseléséhez: auto scaling, zero down-time deployment, load balancing, routing képességekkel. A konténerizált platform lehetővé teszi a monolitikus és mikroszervíz alapú appok egységes kezelését.

Referenciák

• Raiffeisen Bank
• Új Világ Nonprofit Szolgáltató Kft.
• KH Bank
• Generali Biztosító
• Nemzeti Útdíjfizetési Szolgáltató Zrt
• Központi Statisztikai hivatal
• Közigazgatási és Elektronikus Közszolgáltatások Központi Hivatala

Automatizált DEVOPS platform AGILIS MEGKÖZELÍTÉSBEN

Napjainkban elsődlegesen elvárt követelmény, hogy az IT képes legyen gyorsan reagálni az új igényekre és a gyakori változásokra, legyen szó akár a specifikációs követelményekről, akár az új fejlesztési igényekről. Természetesen nem elég csupán a gyorsaság, épp olyan fontos szempont, hogy a minőségi elvárásoknak is maximálisan eleget tegyünk. Ezen igényeket csak egy módon lehet teljesíteni, az alkalmazás életciklus folyamatok automatizálásával, amely biztosítja a standardok mentén történő fejlesztést, tesztelést és release-elést valamint folyamatosan ellenőrzi a minőségi követelményeknek való megfelelést is. Az automatizációval öndokumentálóvá váló folyamataink nemcsak teljesen átláthatók és érthetőek lesznek, hanem minimális emberi erőforrás ráfordítással is karbantarthatóvá válnak. Ahhoz, hogy a fenti igényeknek a TCD maximálisan eleget tegyen, az ipari standardokra épülő és széles körben elterjedt, hivatalos támogatással is rendelkező open-source eszközöket integráltunk egymással.

A TCD keretrendszer támogatást nyújt már az első lépésektől kezdve, amikor is egy új fejlesztési igény érkezik. A követelmény teljesítéséhez kapcsolódó automatizációhoz hozzá tartozik az elkészült kódok minőségének vizsgálata statikus és dinamikus vonatkozásban, kiegészítve a tesztekkel és APM alapú mérésekkel. Az elkészült kódok mellett azokat a teljes alkalmazásba integrálva is tesztelni és vizsgálni kell. Az igény utolsó lépése, amikor is élesítésre kerül. Az alkalmazást ekkor sem szabad magára hagyni, olyan standard eszközökkel kell az üzemeltetési feladatokat kezelni, ami nemcsak az adminisztrációs feladatokat (skálázás, routing), hanem a folyamatos monitorozást és visszacsatolást is lehetővé teszi!

Pontosan ezen igények miatt született meg a TCD platform

Az ügyfeleinknél történtő implementációt egy felmérés előz meg, amely során megvizsgáljuk a jelenlegi folyamatokat, eszközöket és a környezet érettségét a bevezetési folyamat kialakításához. A bevezetés lépéseit az ügyfeleinknél iteratív módon végezzük el, miközben a rendszer használatához kapcsolódó know-how-t átadjuk.

A keretrendszer elemei egy fix alapot képeznek a végleges implementáció elkészítéséhez, amely során több tekintetben alkalmazkodunk a felhasználói környezethez, testre szabjuk az alkalmazást és a módszer reprezentációját.

A megoldásunk tipikusa JAVA környezetben használatos, de egyéb technológiai környezetekben is implementálható.

TCD működése a gyakorlatban

Egy javítandó hiba (bug) vagy fejlesztendő funkció (feature) rögzítésekor az adott projekthez kapcsolódó ticketing rendszerben (Jira, Redmine, Gitea) egy „issue” keletkezik, majd ezzel párhuzamosan a GIT verzió kezelőben egy új feature branch is létrejön a development ágból, amely keretében az issue-hoz rendelt fejlesztő el kezdhet dolgozni a feladaton.

A fejlesztők GIITflow alapú workflow szerint fejlesztenek, ami alapján az új fejlesztések a development branch-ből ágaznak le, mint feature branch-ek. Amikor a programozó befejezte a fejlesztést, egy „merge request” kéréssel jelzi, hogy a development ágba integrálható a kódja, melyet a vezető fejlesztő átnéz és jóváhagy (code review). Az elvégzett feladathoz kötődő feature branch ezzel megszűnik.

 Miután a projekt tervben meghatározott fejlesztések (milestone) átkerültek a development ágba és release-elhető az alkalmazás, a vezető fejlesztő létrehoz egy release branch-et, amelyen már csak az adott release-hez kapcsolódó hibajavítások kerülhetnek be, új feature nem! Amint a hibák javításra kerülnek, a release ág bekapcsolódik a master ágba (merge-elésre kerül), és a vezető fejlesztő ellátja egy verziószám tag-gel. A release branch ezután merge-elésre kerül a development ágba is, és megszüntethető! A hotfix branch-eket az azonnali, éles alkalmazás gyors pach-elésére használhatjuk, melyeket mindig vissza kell vezetni a development ágba is. A GIT workflow stratégia mindig az ügyféllel közösen kerül kialakításra és egyeztetésre a meglévő release folyamataik felmérését követően.

A Jenkins multi-branch pipeline használatával minden egyes GIT ágon (master, development, release, feture) az alábbi ábrán látható lépéssor automatizáltan (egy gomb megnyomására, ütemezetten vagy GIT kommit hatására) elindítható. Fontos, hogy a Deploy Container és a Test Runs lépések más-más jelentéssel bírnak az egyes GIT ágakon, amelyek az alábbiakban részletezésre kerülnek.

A BUILD fázis során a forráskódból létrejön a telepíthető alkalmazás (tipikusan: JAR, WAR, EAR). A UNIT TEST fázisban megadott egység tesztek indulnak, kizárólag szimulált (mock-olt) szolgáltatásokkal, azért hogy a nagyszámú egység teszt is néhány másodperc alatt lefusson. A STATIC CODE CHECK fázisban SonarQube alapú statikus kód ellenőrzést futtatunk, ami a forráskód és a byte kód vizsgálatával a tipikus fejlesztői hibákat megtalálja (pl. végtelen ciklus, le nem zárt connection, stb…), és javaslatot ad a kijavításra. Ha a unit teszt lépésnél hibára futott valamely teszteset, esetleg a statikus kód-ellenőrzés során blokkoló hibát talált a rendszer, a lépéssor (pipeline) leállításra kerül, és a fejlesztő visszajelzést kap e-mail-ben erről. Ha eddig minden rendben lefutott, akkor a CREATE AND STORE IMAGE fázisban a Dockerfile alapján létrehozza a rendszer azt a Docker image-et, amely környezet független módon akár a teszt, akár az éles környezetbe is telepíthető, majd a létrehozott image eltárolásra kerül a Nexus artifact repository-ba

Az utolsó két lépés, a Deploy container és a Test Runs működése szétválik aszerint, hogy melyik GIT ágon futott le a pipeline.

Amikor egy Feature branch-en futtatjuk a pipeline lépéseit, akkor a fejlesztői-teszt környezetbe kerül a konténer deploy-olásra. Ilyen esetben egy rövidebb 5-10 perces integrációs teszt kerül elindításra, ami megmozgatja az alkalmazás kulcsfolyamatait. A teszt futása alatt a Dynatrace APM a beállított metrikák alapján figyeli a dinamikus jellemzőket, mint például a válaszidőket, hotspot-okat, lassú service hívásokat. A feature branch-eken a legfontosabb szempont, hogy a fejlesztő minél hamarabb, 5-10 percen belül egy átfogó visszajelzést kapjon arról, amit elkészített, ezért nem futtatunk ezeken az ágakon hosszabb és kimerítő teszteket.

Amikor a Development branch-en indítjuk el a pipelne-t, akkor a tesztkörnyezetbe kerül a konténer telepítésre. A development ágban naponta többször, ütemezetten (pl. 2-3 óránként) automatizált integrációs, performancia és felületi tesztek futnak, melyek az alkalmazást minél teljesebben letesztelik. Tipikusan az éjjeli órákban a development ágon olyan performancia teszteket futtatunk, ami extrém terhelést produkálva megmutatja, hogy az alkalmazás melyik modulja ”hasal el” először.

Fontos látni, hogy az egyes ágakon azért valósítható meg könnyen a deploy-olás és a teszt futtatások teljeskörű automatizációja, mivel az alkalmazások Docker konténerekben futnak, így a konténerek bármikor megszüntethetők, majd egy kezdeti állapotban elindíthatók. Természetesen az egyes teszt indítások előtt mindent (gyorsan) a kezdeti állapotba vissza kell tudnunk állítani, ahol állapot tárolás történik, pl.: DB.

A master branch-en indított pipeline az éles környezetbe telepíti a konténert, és a tesztfuttatás egy SMOKE tesztet fog jelenteni, ami megvizsgálja, hogy az éles telepítés sikeresen megtörtént-e. Amennyiben az alkalmazás csak más szolgáltatásokkal együtt telepíthető, akkor a Deploy Container és Test Runs fázisok külön is indíthatók, leválasztva ezeket pipeline-ról, ahogy a fenti ábra is mutatja.

Az alkalmazás éles működésének menedzselésére Kubernetes illetve OpenShift eszközöket javasoljuk, melyekhez a kifejlesztett integrációs és automatizációs szkriptek nyújtanak majd segítséget.

TCD előnyei

• A TCD keretrendszer automatizáltan létrehozható lokális vagy cloud környezetben is

• Egységes kezelést és iteratív átállást tesz lehetővé a monolitikus alkalmazás fejlesztésről a mikro szolgáltatás alapú fejlesztésre.

• A monolitikus és mikroszerviz alapú alkalmazásokat is konténerekben futtatjuk, ezáltal standard eszközökkel, egységesen kezeljük, felügyeljük és monitorozzuk őket.

• Nincs szükség telepítési leírásra a deployláshoz, mivel a build lépéssor (pipeline) végén egy Docker image kerül létrehozásra, melyet bármely környezetben egységesen használhatunk.

• Open Source és ingyenes eszközök integrációja a TCD, kiegészítve a Dynatrace APM-mel.

• Identikus és konzisztens környezetek felállítása automatizált szkriptekkel

• Standard eszközkészlet az éles környezeti managementhez: Kubernetes, OpenShift

• Modern, agilis és DevOps alapú rendszer az alkalmazás életciklusának kezeléséhez

• A problémák és anomáliák, a fejlesztési idő korai szakaszában feltárásra és lézer pontos beazonosításra kerülnek a TQG (Telvice Quality Gate) segítségével, ami azt eredményezi, hogy nagyságrendekkel kevesebb erőforrás befektetéssel javíthatók a hibák

• A TCD implementálásakor nemcsak egy keretrendszert, hanem az évek során felhalmozott know-how-t, tapasztalatot is átadjuk az ügyfeleink számára