Folyamatos kézbesítési oktatóanyag - Folyamatos szállítási csővezeték kiépítése Jenkins segítségével

Folyamatos szállítás:

A folyamatos kézbesítés egy olyan folyamat, ahol a kódváltozásokat automatikusan felépítik, tesztelik és előkészítik a gyártásba való kiadásra.Remélem, hogy élvezted az enyémet Itt a következő témákról fogok beszélni:

• Mi a folyamatos szállítás?
• A szoftver tesztelésének típusai
• Különbség a folyamatos integráció, kézbesítés és telepítés között
• Mi a szükség a folyamatos szállításra?
• Praktikus Jenkins és Tomcat használatával

Gyorsan megértsük, hogyan működik a folyamatos kézbesítés.

Mi a folyamatos szállítás?

Ez egy olyan folyamat, amely során a szoftvert úgy készíti, hogy bármikor kiadható legyen a termelésben.Vegye figyelembe az alábbi ábrát:

Hadd magyarázzam el a fenti ábrát:

• Az automatizált build szkriptek észlelik a forráskód-kezelés (SCM), például a Git változásait.
• Miután észlelte a változást, a forráskódot egy dedikált build-kiszolgálóra telepítenék, hogy megbizonyosodjon arról, hogy a build nem hibás-e meg, és minden tesztosztály és az integrációs teszt jól működik-e.
• Ezután a build alkalmazás telepítésre kerül a tesztkiszolgálókon (gyártás előtti kiszolgálók) a felhasználói elfogadási teszt (UAT) számára.
• Végül az alkalmazást manuálisan telepítik a termelési kiszolgálókra kiadás céljából.

Mielőtt folytatom, csak igazságos lesz, ha elmagyarázom Önnek a különböző típusú teszteket.

Szoftvertesztelés típusai:

Általánosságban kétféle teszt létezik:

• Blackbox tesztelés: Ez egy olyan tesztelési technika, amely figyelmen kívül hagyja a rendszer belső mechanizmusát, és a kimenetre összpontosít, szemben a rendszer bármilyen bemenetével és végrehajtásával. Funkcionális tesztnek is nevezik. Alapvetően a szoftver hitelesítésére használják.
• Whitebox tesztelés: olyan tesztelési technika, amely figyelembe veszi a rendszer belső mechanizmusát. Szerkezeti tesztelésnek és üvegdoboz-tesztnek is nevezik. Alapvetően a szoftver ellenőrzésére szolgál.

Whitebox teszt:

Kétféle tesztelés létezik, amelyek ebbe a kategóriába tartoznak.

uborka java szelén webdriver példa

• Egység tesztelése: Ez egy egyedi egység vagy a kapcsolódó egységek csoportjának tesztelése. A programozó gyakran azt teszteli, hogy az általa megvalósított egység az adott bemenettel szemben várható kimenetet produkál-e.
• Integrációs tesztelés: Ez egy olyan típusú teszt, amelyben az összetevők egy csoportja vankombinálva állítják elő a kimenetet. A szoftver és a hardver kölcsönhatását akkor is teszteljük, ha a szoftver és a hardver alkatrészei kapcsolatban állnak egymással. Lehet, hogy mind a fehér doboz, mind a fekete doboz teszt alá tartozik.

Blackbox tesztelés:

Több teszt is tartozik ebbe a kategóriába. Erre fogok koncentrálninéhány, amelyeket fontos ismernie a blog megértése érdekében:

• Funkcionális / elfogadási teszt: Biztosítja, hogy a rendszerkövetelményekben megkövetelt meghatározott funkciók működjenek. Annak érdekében, hogy megbizonyosodjon arról, hogy a leszállított termék megfelel-e a követelményeknek, és úgy működik-e, ahogyan azt a vásárló elvárta
• Rendszer tesztelés: Biztosítja, hogy azáltal, hogy a szoftvert különböző környezetekbe (pl. Operációs rendszerek) helyezi, továbbra is működik.
• Stressz teszt: Értékeli, hogy a rendszer hogyan viselkedik kedvezőtlen körülmények között.
• Béta tesztelés: Végfelhasználók, egy fejlesztésen kívüli csapat végzi el, vagy nyilvánosan kiadja a termék teljes előzetes verzióját, amely néven ismertbétaváltozat. A bétatesztelés célja a váratlan hibák fedése.

Itt az ideje, hogy elmagyarázzam a különbséget a folyamatos integráció, a kézbesítés és a telepítés között.

Különbségek a folyamatos integráció, a szállítás és a telepítés között:

A vizuális tartalom gyorsabban és érthetőbben jut el az egyén agyáig, mint a szöveges információ. Tehát egy ábrával kezdem, amely világosan megmagyarázza a különbséget:

A folyamatos integráció során minden kód-elkötelező felépül és tesztelésre kerül, de nincs olyan állapotban, hogy kiadható legyen. Úgy értem, hogy a build alkalmazás nem kerül automatikusan telepítésre a tesztkiszolgálókon annak érdekében, hogy érvényesítsék azt különböző típusú Blackbox tesztelésekkel, például - Felhasználói elfogadás tesztelése (UAT).

A Folyamatos kézbesítés során az alkalmazást folyamatosan telepítik az UAT tesztkiszolgálóira. Vagy azt is mondhatja, hogy az alkalmazás bármikor készen áll a gyártásra történő kiadásra. Tehát nyilvánvaló, hogy a folyamatos szállításhoz folyamatos integrációra van szükség.

A folyamatos telepítés a következő lépés a Folyamatos kézbesítés mellett, ahol nem csak telepíthető csomagot hoz létre, hanem valójában automatizált módon is telepíti.

Hadd foglaljam össze a különbségeket egy táblázat segítségével:

Egyszerűbben fogalmazva, a folyamatos integráció a folyamatos szállítás és a folyamatos telepítés része. A folyamatos telepítés pedig olyan, mint a folyamatos kézbesítés, azzal a különbséggel, hogy a kiadások automatikusan történnek.

Ismerje meg, hogyan hozhat létre CI / CD csővezetékeket a Jenkins On Cloud használatával

De kérdés, hogy elegendő-e a folyamatos integráció.

Miért van szükségünk folyamatos szállításra?

Értsük meg ezt egy példával.

Képzelje el, hogy 80 fejlesztő dolgozik egy nagy projekten. Folyamatos integrációs csővezetékeket használnak az automatizált építések megkönnyítése érdekében. Tudjuk, hogy a build magában foglalja az egység tesztelését is. Egy nap úgy döntöttek, hogy a legújabb, az egység tesztjein átesett verziót telepítik egy tesztkörnyezetbe.

Ennek hosszú, de ellenőrzött megközelítésnek kell lennie a telepítéshez, amelyet környezetvédelmi szakembereik végeztek. Úgy tűnt azonban, hogy a rendszer nem működik.

Mi lehet a kudarc nyilvánvaló oka?

Nos, az első ok, amit a legtöbb ember gondolni fog, az, hogy a konfigurációval van valami probléma. Mint a legtöbb ember, még ők is így gondolták.Sok időt töltöttek azzal, hogy megtalálják, mi a baj a környezet konfigurálásával, de nem találták meg a problémát.

Egy észlelő fejlesztő intelligens megközelítést alkalmazott:

Ezután az egyik vezető fejlesztő kipróbálta az alkalmazást a fejlesztőgépén. Ott sem működött.

Visszalépett a korábbi és korábbi verziók között, amíg megállapította, hogy a rendszer három héttel korábban leállt. Egy apró, homályos hiba megakadályozta a rendszer megfelelő indítását. Bár a projekt jó teszt-lefedettséggel rendelkezett.Ennek ellenére 80 fejlesztő, akik általában csak a teszteket futtatták, nem pedig magát az alkalmazást, három hétig nem látták a problémát.

Probléma nyilatkozat:

Az Acceptance Tests termelésszerű környezetben történő futtatása nélkül semmit sem tudnak arról, hogy az alkalmazás megfelel-e az ügyfél specifikációinak, és arról sem, hogy telepíthető-e és túlélhető-e a való világban. Ha időben visszajelzést akarnak kapni ezekről a témákról, ki kell terjeszteniük folyamatos integrációs folyamatuk körét.

Hadd összegezzem a tanulságokat a fenti problémák vizsgálatával:

• Az egységtesztek csak a fejlesztő perspektíváját tesztelik a probléma megoldásában. Csak korlátozottan képesek bizonyítani, hogy az alkalmazás a felhasználók szemszögéből azt csinálja, amit elvárnak. Nem elégazonosítsa a valódi funkcionális problémákat.
• Az alkalmazás telepítése a tesztkörnyezetre egy összetett, manuálisan intenzív folyamat, amely hajlamos volt a hibákra.Ez azt jelentette, hogy minden telepítési kísérlet új kísérlet volt - kézi, hibára hajlamos folyamat.

Megoldás - Folyamatos szállítási csővezeték (automatizált átvételi teszt):

Folytatták a folyamatos integrációt (folyamatos szállítás) a következő lépéshez, és bevezettek pár egyszerű, automatizált elfogadó tesztet, amelyek bebizonyították, hogy az alkalmazás fut, és képes ellátni legalapvetőbb funkcióját.Az elfogadási teszt szakaszában futó tesztek többsége funkcionális elfogadási teszt.

Alapvetően folyamatos szállítási folyamatot építettek annak biztosítása érdekében, hogy az alkalmazást zökkenőmentesen telepítsék a termelési környezetbe, biztosítva, hogy az alkalmazás jól működjön, amikor a tesztkiszolgálóra telepítik, amely a termelési kiszolgáló másolata.

Elég az elméletből, most megmutatom, hogyan lehet létrehozni egy folyamatos szállítási folyamatot a Jenkins segítségével.

Folyamatos szállítási csővezeték a Jenkins használatával:

Itt a Jenkins segítségével fogok létrehozni egy folyamatos szállítási csővezetéket, amely a következő feladatokat tartalmazza:

A bemutatóban szereplő lépések:

• A kód lekérése a GitHub-ból
• A forráskód összeállítása
• Az egység tesztelése és a JUnit tesztjelentések létrehozása
• Az alkalmazás csomagolása WAR fájlba, és telepítése a Tomcat szerverre

Előfeltételek:

• CentOS 7 gép
• Jenkins 2.121.1
• Dokkmunkás
• Tomcat 7

1. lépés - A forráskód összeállítása:

Kezdjük azzal, hogy először létrehozunk egy Freestyle projektet Jenkins-ben. Vegye figyelembe az alábbi képernyőképet:

Adjon nevet a projektjének, és válassza a Freestyle Project lehetőséget:

Amikor lefelé görget, talál egy lehetőséget a forráskód-tárház hozzáadására, a git kiválasztására és a tárhely URL-jének hozzáadására. Ebben a tárolóban van egy pom.xml bírság, amelyet a projektünk felépítéséhez fogunk használni. Vegye figyelembe az alábbi képernyőképet:

Most hozzáadunk egy Build Trigger-t. Válassza ki a poll SCM opciót. Alapvetően úgy konfiguráljuk a Jenkins-t, hogy 5 percenként lekérdezze a GitHub adattárat a kód változásai miatt. Vegye figyelembe az alábbi képernyőképet:

Mielőtt továbblépnék, hadd adjak egy kis bevezetést a Maven Build Cycle-ból.

A gyártási életciklusok mindegyikét a készítési fázisok különböző listája határozza meg, ahol a felépítési szakasz az életciklus egyik szakaszát jelenti.

Az alábbiakban felsoroljuk az építési fázisokat:

• validálás - a projekt validálása helyes és minden szükséges információ rendelkezésre áll
• fordítás - a projekt forráskódjának összeállítása
• teszt - tesztelje a lefordított forráskódot megfelelő egység tesztelési keretrendszerrel. Ezeknek a teszteknek nem kell megkövetelniük a kód csomagolását vagy telepítését
• csomag - vegye le a lefordított kódot, és csomagolja elosztható formátumában, például JAR-ban.
• ellenőrizze - végezzen minden ellenőrzést az integrációs tesztek eredményein a minőségi kritériumok teljesülésének biztosítása érdekében
• install - a csomag telepítése a helyi adattárba, más helyi projektek függőségeként történő használatra
• telepítés - a build környezetben megtörtént, az utolsó csomagot a távoli adattárba másolja, hogy megossza más fejlesztőkkel és projektekkel.

Futtathatom az alábbi parancsot a forráskód összeállításához, az egység teszteléséhez és az alkalmazás háborús fájlba csomagolásához is:

mvn tiszta csomag

Az építési feladatot számos építési lépésre is felbonthatja. Ez megkönnyíti az építések tiszta, külön szakaszokban történő szervezését.

Tehát a forráskód összeállításával kezdjük. A build lapon kattintson a legfelső szintű maven célok meghívására, és írja be az alábbi parancsot:

összeállítani

Vegye figyelembe az alábbi képernyőképet:

Ez lekéri a forráskódot a GitHub adattárból, és lefordítja azt is (Maven Compile Phase).

Kattintson a Mentés és a projekt futtatása gombra.

Most kattintson a konzol kimenetére az eredmény megtekintéséhez.

2. lépés - Egység tesztelése:

Most létrehozunk még egy Freestyle projektet az egység teszteléséhez.

Adja hozzá ugyanazt a lerakat URL-jét a forráskód-kezelő lapon, mint az előző munkában.

Most kattintson a „Buid Trigger” fülön a „build után más projektek épülnek” elemre. Írja be az előző projekt nevét, ahol a forráskódot állítjuk össze, és kiválaszthatja az alábbi lehetőségek bármelyikét:

• Csak akkor indítsa el, ha az összeállítás stabil
• Akkor indítsa el, ha az összeállítás instabil
• Akkor is indítsa el, ha az összeállítás meghiúsul

Úgy gondolom, hogy a fenti lehetőségek eléggé magától értetődőek, ezért válasszon egyet. Vegye figyelembe az alábbi képernyőképet:

A Build fülön kattintson a legfelső szintű maven célok meghívására, és használja az alábbi parancsot:

teszt

A Jenkins nagyszerű munkát végez abban is, hogy segítsen megjeleníteni a teszt eredményeit és a teszt eredményeinek trendjeit.

A tesztjelentések de facto szabványa a Java világban egy XML formátum, amelyet a JUnit használ. Ezt a formátumot számos más Java tesztelő eszköz is használja, például a TestNG, a Spock és az Easyb. A Jenkins megérti ezt a formátumot, így ha a builded JUnit XML teszt eredményeket hoz, akkor a Jenkins szép grafikus tesztjelentéseket és statisztikákat generálhat a teszt eredményeiről az idő múlásával, és lehetővé teszi a teszthibák részleteinek megtekintését is. A Jenkins azt is figyelemmel kíséri, hogy a tesztek mennyi idő alatt futnak, mind globálisan, mind tesztenként - ez jól jöhet, ha fel kell derítenie a teljesítményproblémákat.

Tehát a következő dolog, amit meg kell tennünk, hogy rákényszerítsük Jenkins-t, hogy tartsa a füleket az egység tesztjeinken.

Lépjen az Építés utáni műveletek szakaszba, és jelölje be a „JUnit teszt eredményjelentésének közzététele” jelölőnégyzetet. Amikor Maven egységteszteket futtat egy projektben, automatikusan létrehozza az XML tesztjelentéseket a surefire-reports nevű könyvtárban. Tehát írja be a „** / target / surefire-reports / *. Xml” kifejezést a „Test report XMLs” mezőbe. Az útvonal elején lévő két csillag (“**”) a legjobb gyakorlat a konfiguráció kissé robusztusabbá tételéhez: lehetővé teszik Jenkins számára, hogy megtalálja a célkönyvtárat, függetlenül attól, hogy mi konfiguráltuk Jenkins-t a forráskód megtekintésére.

szkenner osztály használata java-ban

** / target / surefire-reports / *. xml

Ismét mentse el, és kattintson a Build Now gombra.

Most a JUnit jelentést a / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior könyvtárba írja.

A Jenkins műszerfalonészreveheti a teszt eredményeit is:

3. lépés: WAR fájl létrehozása és telepítés a Tomcat szerveren:

A következő lépés az, hogy csomagoljuk az alkalmazásunkat egy WAR fájlba, és telepítsük azt a Tomcat szerverre a Felhasználói elfogadás teszthez.

Hozzon létre még egy freestyle projektet, és adja hozzá a forráskód-tárház URL-jét.

Ezután a build kiváltó fülön válassza ki az építést, amikor más projektek épülnek, vegye figyelembe az alábbi képernyőképet:

Alapvetően a tesztfeladat után a telepítési szakasz automatikusan elindul.

A build lapon válassza ki a shell parancsfájlt. Írja be az alábbi parancsot az alkalmazás WAR fájlba csomagolásához:

mvn csomag

A következő lépés a WAR fájl telepítése a Tomcat-raszerver. Az „Építés utáni műveletek” lapon válassza a war / ear telepítését egy konténerbe. Itt adja meg a háborús fájl elérési útját, és adja meg a kontextus elérési útját. Vegye figyelembe az alábbi képernyőképet:

Válassza ki a Tomcat hitelesítő adatokat, és vegye figyelembe a fenti képernyőképet. Ezenkívül meg kell adnia a Tomcat szerver URL-jét.

A hitelesítő adatok hozzáadásához a Jenkins-ben kattintson a hitelesítő adatok opcióra a Jenkins irányítópultján.

Kattintson a Rendszer elemre, és válassza ki a globális hitelesítő adatokat.

Ezután megtalál egy lehetőséget a hitelesítő adatok hozzáadására. Kattintson rá, és adjon hozzá hitelesítő adatokat.

Adja hozzá a Tomcat hitelesítő adatait, vegye figyelembe az alábbi képernyőképet.

Kattintson az OK gombra.

Most a Projektkonfigurációban adja hozzá az előző lépésben beillesztett tomcat hitelesítő adatokat.

Kattintson a Mentés elemre, majd válassza az Építés most lehetőséget.

Lépjen a tomcat URL-hez a kontextus elérési útjával, esetemben ez a http: // localhost: 8081. Most adja hozzá a kontextus elérési útját a végén, vegye figyelembe az alábbi képernyőképet:

Link - http: // localhost: 8081 / gof

Remélem, megértette a kontextusút jelentését.

Most hozzon létre egy csővezeték nézetet, vegye figyelembe az alábbi képernyőképet:

Új nézet létrehozásához kattintson a plusz ikonra.

Konfigurálja a csővezetéket a kívánt módon, vegye figyelembe az alábbi képernyőképet:

A kezdeti munka kiválasztásán kívül semmit sem változtattam. Tehát a csővezetékem az összeállításból indul. Más feladatok konfigurálásának módja alapján fordítás után tesztelés és telepítés fog történni.

Végül kipróbálhatja a folyamatot a RUN gombra kattintva. Öt percenként, ha változás történik a forráskódban, a teljes folyamat végrehajtásra kerül.

Így képesek vagyunk folyamatosan telepíteni alkalmazásunkat a tesztkiszolgálóra a felhasználói elfogadási teszt (UAT) céljából.

Remélem, hogy élvezettel olvasta ezt a bejegyzést a folyamatos szállításról. Ha kétségei vannak, nyugodtan tegye be az alábbi megjegyzés szakaszba, és leghamarabb válaszolok.

A CI / CD csővezetékek kiépítéséhez sokféle készséget el kell sajátítania Most elsajátítsa a szükséges DevOps készségeket