Postman with Newman & Jenkins

A sorozat Postman bemutató tanultunk Postman & Newman és azok jellemzőit. A postás teljes elsajátításához csak még egy elemre van szükségünk a tanfolyam befejezéséhez. Ez az elem Jenkins. Tehát ebben oktatóanyagok fogunk beszélni Postman Newman & Jenkins. Alapvetően Postman nem csak egy szoftver ma. A postás nem Postás, hanem egy csomag Postás, Newman és Jenkins. Ez a csomag segít az automatizált tesztelés körének kitöltésében és jó minőségű szoftverek szállításában. Mivel már tárgyalt az első két elem, mi lesz összpontosítva Jenkins a következő néhány útmutatók, hogy megértsük az előnyeit Postman Newman & Jenkins. Kezdjük azzal, hogy megismerjük.jenkins_Main_Logo

mi az a Jenkins?

a Jenkins egy Java-ban írt nyílt forráskódú automatizálási szerver. A Jenkins-t arra használják, hogy folyamatosan építsenek és teszteljenek, és ezáltal megkönnyítsék a fejlesztő és a tesztelő munkáját a szoftver számára. Ahhoz, hogy ismerős fogalmakat kapjunk, amit tanulmányoztunk, a Jenkins folyamatos integrációt és folyamatos fejlesztést használ a szoftver fejlesztéséhez és telepítéséhez, és mindez megkönnyíti a fejlesztő munkáját. A Jenkins segítségével a szervezetek automatizálással felgyorsíthatják a szoftverfejlesztési folyamatot. A Jenkins mindenféle fejlesztési életciklus-folyamatot integrál, beleértve a build, document, test, package, stage, deploy, static analysis és még sok mást.

ne feledje, az utolsó Bemutató tanulmányoztuk a folyamatos integráció, amely röviden azt jelenti, minden alkalommal, amikor a kódot tolta a repository, néhány teszt esetében automatikusan végrehajtásra kerül a kódot. Ez segít a fejlesztőknek ellenőrizni az építkezést, hogy helyes-e vagy sem. Ha nem végezzük el a folyamatos integrációt “folyamatosan”, de alkalmanként előfordulhat, hogy nem kapjuk meg, hogy melyik build volt sikertelen, és melyik probléma miatt. Jenkins ugyanezt teszi, segíti a fejlesztőt és a tesztelőt a folyamatos integrációval és a build minőségének folyamatos ellenőrzésével. De nem tanultunk a második kifejezésről (folyamatos szállítás), amelyet fent használtunk. Akkor csináljuk most.

mi a folyamatos szállítás?

a folyamatos szállítás a folyamatos integráció tetejére épül, ami azt jelenti, hogy a folyamatos szállítás (CD) nem lehetséges, ha a folyamatos integráció (CI) nincs a helyén. A folyamatos szállítás a folyamatos integráció következő lépéseként működik. A Continuous delivery egy DevOps szoftverfejlesztési gyakorlat, ahol a kódváltozásokat automatikusan felépítik, tesztelik (Unit tesztek), és előkészítik a környezetbe történő kiadásra. Ez a környezet bármi lehet a színpadtól, az előgyártástól vagy a gyártástól kezdve. Bizonyos értelemben a folyamatos integrációt kiterjeszti azáltal, hogy az összes kódváltozást tesztelési környezetbe és/vagy termelési környezetbe telepíti a build szakasz után.

a folyamatos kézbesítés lehetővé teszi a fejlesztők számára, hogy automatizálják a tesztelést az egységteszteken túl, így több dimenzióban ellenőrizhetik az alkalmazásfrissítéseket, mielőtt üzembe helyeznék az ügyfeleket. Ezek a tesztek tartalmazhatnak UI teszteket, Teljesítményteszteket, integrációs teszteket, API teszteket. Mint tudod, hogy az UI vagy más tesztek futtatásához környezetre van szükség, ezért a continuous delivery ténylegesen telepíti az alkalmazást a megadott környezetre, és ahol a többi teszt, például az API & UI végrehajtásra kerül. Ez segít a fejlesztőknek alaposabban érvényesíteni a frissítéseket, és megelőző módon felfedezni a problémákat.

ezért a fejlesztők értesítést kapnak ugyanerről, és manuálisan betolják azt a termelési környezetbe, ahonnan a szoftvert kiadják az ügyfeleknek / ügyfeleknek. A folyamatos szállítás automatizálja a teljes szoftverkiadási folyamatot. Minden végrehajtott felülvizsgálat automatizált folyamatot indít el, amely felépíti, teszteli, majd szakaszolja a frissítést. Az élő termelési környezetbe történő telepítésről szóló végső döntést a fejlesztő váltja ki.

mi a folyamatos telepítés?

a folyamatos szállítás és a folyamatos telepítés közötti különbség a kézi jóváhagyás jelenléte a gyártásra való frissítéshez. Folyamatos telepítés esetén a termelési telepítés automatikusan, kifejezett jóváhagyás nélkül történik. Ami azt jelenti, hogy a folyamatos telepítés során az utolsó lépés is automatizált, és a kódot a fejlesztő beavatkozása nélkül automatikusan tolja.

azt is mondhatjuk, hogy ez egy lépés a folyamatos szállításhoz képest, mivel teljesen automatizált. Mivel teljesen automatizált, könnyebb lenne kitalálni, hogy nagyon óvatos környezeti folyamatot igényel,és csak kevés vállalat alkalmazza. Ezek a gondos óvintézkedések magukban foglalják a fejlett megfigyelési kultúrát és a gyors felépülés képességét.

continuous-delivery-vs-continuous-deployment

tehát a Jenkins olyan szoftver, amely automatizálja a teszteket, és folyamatos integrációt és folyamatos szállítást/folyamatos telepítést biztosít. Folytatva ugyanezt, Jenkins további előnyöket nyújt nekünk.

a Jenkins előnyei

a Jenkins folyamatos integrációt ér el a plug-in segítségével, és szó szerint több ezer plugin áll rendelkezésre a Jenkins számára. Minden munkához megtalálható egy plug-in a Jenkins számára, és ha nem, akkor létrehozható. A Plugin lehetővé teszi a különböző DevOps szakaszok integrálását. Ha egy adott eszközt integrálni szeretne, telepítenie kell az eszköz bővítményét. Például: Git, Maven 2 projekt, Amazon EC2, HTML kiadó stb. Eltekintve plug-inek vannak a következő előnyei Jenkins

  • ez egy nyílt forráskódú eszköz nagy közösségi támogatás
  • ez könnyen telepíthető.
  • ingyenes.
  • Java-val épült, ezért hordozható az összes főbb platformon.

ezek az előnyök rendkívül fontosak minden fejlesztő vagy tesztelő számára. És ha valami nem sikerült, összefoglaltuk a következő részben.

Postás Newman & Jenkins

Jenkins ma használják olyan sebességgel, hogy a fejlesztő soha nem gondolta volna. Hamarosan a DevOps motorjává válik. Nem kétséges, hogy Jenkins fő forrása az, hogy plugins. Nincs más konkrét tényező a Jenkins Postás használatához. Sok alternatíva, hogy lehet használni a Postman, de Jenkins előnyös és ajánlott (szintén postman hivatalos honlapján). Tehát azt mondjuk, hogy a Jenkins-t csak azért fogjuk használni, mert nagyobb ereje van, mint más szoftvereknek, és fejlődik is. A Jenkins bővítményeinek köre bárki számára az első választás. Ha ellenőrizni szeretné az alternatívákat, megismerheti őket saját maga keresésével. Ezek Atlassian Bamboo, CircleCI, JetBrains TeamCity, ThoughtWorks Snap, hogy csak néhányat említsünk.

amint azt a fenti szakaszban tárgyaltuk , a folyamatos integráció segít a különböző kódok kombinálásában és a tesztek folyamatos végrehajtásában. A teszteknek és a kódnak ez az ötvözete sikeres a folyamatos integrációnak köszönhetően, amelyet a Postmanben Newman és Jenkins végez. Postman Newman épül, hogy könnyen integrálható a build rendszerek Jenkins. Ezzel a funkcióval a fejlesztők gyors visszajelzést kapnak az API-k teljesítményéről a kód megváltoztatása után. Csakúgy, mint Newman segítségével, integrálódik Jenkins-szel, majd ha bármilyen változtatást tolnak, Jenkins newmannal fogja vezetni a postás gyűjteményeket.

Összegzés

a Jenkins egy folyamatos integrációs szerver. Röviden, Jenkins középső emberként működik a build kód és az adattár között. Ha bármilyen változást talál a kódban, összegyűjti a kódot, és elküldi azokat a build kódjába, ahol automatizált teszteket végeznek. Ha a tesztek rendben vannak, egy kézi push ugyanazt a kódot továbbítja az ügyfélnek folyamatos szállítás esetén, különben ez a folyamat a folyamatos telepítésnek megfelelően automatizálódik. Olyan gyors, egyszerű és megbízható. Remélem, most már tudod, mi az a Jenkins, és miért használjuk. A következő tutorial fogjuk telepíteni Jenkins és fut néhány gyűjtemények.