Jenkins nélkül bizonyosan hiányos. Jenkins és Git egy csodálatos kombináció. Tehát ebben a cikkben a Jenkins Git integrációjáról és annak előnyeiről fogok beszélni. A mutatók, amelyekre kitérünk, a következők:
Kezdjük tehát az első témánkkal.
Mi a Git - miért Git A létezésbe jött? 
Mindannyian tudjuk, hogy „a szükség minden találmány anyja”. Hasonlóképpen a Git felmerült bizonyos szükségletek kielégítésére, amelyekkel a fejlesztők a Git előtt szembesültek. Tehát tegyünk egy lépést hátra, hogy mindent megtudjunk a verziókezelő rendszerekről (VCS) és arról, hogy a Git hogyan jött létre.
Verziókezelés a dokumentumok, számítógépes programok, nagy weboldalak és egyéb információgyűjtések változásainak kezelése.
Kétféle VCS létezik:
Központosított verzióellenőrző rendszer (CVCS)
Elosztott verziókezelő rendszer (DVCS)
Központosított VCS
A központi verziókezelő rendszer (CVCS) egy központi szervert használ az összes fájl tárolására, és lehetővé teszi a csapat együttműködését. Egyetlen táron működik, ahova a felhasználók közvetlenül hozzáférhetnek egy központi szerverhez.
Kérjük, olvassa el az alábbi ábrát a CVCS jobb megismeréséhez:
A fenti diagram adattára egy helyi vagy távoli központi szervert jelöl, amely közvetlenül kapcsolódik a programozó egyes munkaállomásaihoz.
Minden programozó kinyerheti ill frissítés munkaállomásukat a tárban lévő adatokkal. Módosíthatják az adatokat, ill elkövetni a tárolóba. Minden műveletet közvetlenül a táron hajtanak végre.
Annak ellenére, hogy nagyon kényelmesnek tűnik egyetlen tárház fenntartása, van néhány fő hátránya. Néhány közülük:
Ez nem helyben elérhető, vagyis a műveletek végrehajtásához mindig csatlakoznia kell egy hálózathoz.
Mivel minden központosítva van, a központi szerver összeomlása vagy sérülése esetén a projekt teljes adatának elvesztése következik be.
Itt oldja meg a problémát az Elosztott VCS.
Elosztott VCS
Ezek a rendszerek nem feltétlenül támaszkodnak egy központi szerverre a projektfájl összes verziójának tárolásához.Az elosztott VCS-ben minden közreműködő rendelkezik a fő adattár helyi példányával vagy „klónjával”. Itt mindenki fenntart egy saját helyi adattárat, amely tartalmazza a fő adattárban található összes fájlt és metaadatot.
Jobban meg fogja érteni, ha az alábbi diagramra hivatkozik:
Amint a fenti ábrán látható, minden programozó önállóan fenntart egy helyi adattárat, amely valójában a merevlemezükön lévő központi adattár másolata vagy klónja. Minden beavatkozás nélkül elkötelezhetik és frissíthetik a helyi adattárukat.
java hogyan kell használni az iterátort
Frissíthetik a helyi adattárakat a központi szerverről érkező új adatokkal a „ Húzni ”És befolyásolják a fő adattár változásait egy„ nyom ”A helyi adattárukból.
Most próbáljunk meg többet megtudni a Git definíciójáról.
A Git egy elosztott verzióvezérlő eszköz, amely támogatja az elosztott nemlineáris munkafolyamatokat azáltal, hogy adatbiztosítást nyújt a minőségi szoftverek fejlesztéséhez. Az olyan eszközök, mint a Git, lehetővé teszik a kommunikációt a fejlesztő és az operációs csapat között.
Normál esetben, amikor egy nagy projektet dolgoz ki, rengeteg munkatársa van. Ezért nagyon fontos a kommunikáció az együttműködők között, miközben változtatnak a projekten.
A Git-ben elkövetett üzenetek nagyon fontos szerepet játszanak a csapat közötti kommunikációban. A kommunikáció mellett a Git használatának legfontosabb oka az, hogy mindig van magával a kód stabil változata.
Ezért Git létfontosságú szerepet játszik a DevOps sikerében.
Mi az a Jenkins?
A Jenkins egy Java-ban írt, nyílt forráskódú automatizálási eszköz, folyamatos beépítés céljából beépített beépülő modulokkal. A Jenkins a szoftverprojektjeinek folyamatos felépítésére és tesztelésére szolgál, megkönnyítve a fejlesztők számára a projektbe történő változtatások integrálását, és megkönnyítve a felhasználók számára az új verziók beszerzését. Ez lehetővé teszi szoftverének folyamatos szállítását is, számos tesztelési és telepítési technológiával integrálva.
A Jenkins segítségével a szervezetek az automatizálás révén felgyorsíthatják a szoftverfejlesztési folyamatot. A Jenkins mindenféle integrálja a fejlesztés életciklus-folyamatait, beleértve az összeállítást, a dokumentumot, a tesztet, a csomagot, a szakaszot, a telepítést, a statikus elemzést és még sok minden mást.
Jenkins a beépülő modulok segítségével eléri a folyamatos integrációt. A beépülő modulok lehetővé teszik a különböző DevOps szakaszok integrálását. Ha integrálni akar egy adott eszközt, telepítenie kell az adott eszköz pluginjeit. Például Git, Maven 2 projekt, Amazon EC2, HTML kiadó stb.
A Jenkins előnyei:
Ez egy nyílt forráskódú eszköz, nagy közösségi támogatással.
Túl könnyű telepíteni.
Több mint 1000 beépülő modul rendelkezik a munka megkönnyítésére. Ha nem létezik beépülő modul, kódolhatja és megoszthatja a közösséggel.
Ez ingyenes.
Java-val készült, és így hordozható az összes főbb platformra.
Most már tudja, hogy a Jenkins hogyan küzdi le a hagyományos SDLC hiányosságokat. Az alábbi táblázat a „Jenkins előtt és után” összehasonlítását mutatja.
| Jenkins előtt | Jenkins után |
|---|---|
| A teljes forráskódot felépítették, majd tesztelték. A hibák felkutatása és kijavítása összeépítés és teszt hiba esetén nehéz volt és időigényes, ami viszont lelassítja a szoftver szállítási folyamatát. | A forráskódban végrehajtott minden elkötelezettség felépül és tesztelésre kerül. Tehát a teljes forráskód ellenőrzése helyett a fejlesztőknek csak egy adott elkötelezettségre kell összpontosítaniuk. Ez gyakran új szoftverkiadásokhoz vezet. |
| A fejlesztőknek meg kell várniuk a teszt eredményeit | A fejlesztők a futás során ismerik a forráskódban végrehajtott minden elkötelezettség teszt eredményét. |
| Az egész folyamat manuális | Csak neked kellvégezzen változtatásokat a forráskódban, és a Jenkins automatizálja a folyamat további részét az Ön számára. |
Miért használják együtt Jenkins-t és Git-et?
Amint arról korábban beszéltünk, Megy forrásvezérlő. Itt tárolja a forráskódot az összes idővel bekövetkező kódváltozás nyomon követéséhez, és a verziók kiindulásához, amikor azok készen állnak a kiadásra.
Jenkins másrészt folyamatos integrációs megoldás. Úgy tervezték, hogy automatizálja azokat a feladatokat, amelyeket a fejlesztőnek el kell végeznie egy új alkalmazás fejlesztése közben (kódminőség-ellenőrzés, építés, build-műtárgyak archiválása, integrációs tesztelés, telepítés különböző környezetekbe stb.) CI-megoldás nélkül egy fejlesztő sok időt kell töltenie ezen ismétlődő, nem produktív feladatok elvégzésével.
Előnyök:
- Git és Jenkins egyaránt nagyon erősek, de nagy erővel nagy felelősség is jár. Elég gyakori a felesleges mennyiség igazolása komplikáció egy építési csővezetékben egyszerűen azért, mert lehet.
- Míg Jenkinsnek sok ügyes trükk van a hüvelyében, könnyű kihasználni a Git funkcióit, mivel ez kiadáskezelést és a hibakeresés lényegesen könnyebb túlóra.
- Ezt úgy tehetjük meg, hogy vigyázunk a létrehozott kód verzióira, és megfelelő módon megcímkézzük őket. Ez megmarad a kiadáshoz kapcsolódó információk a kód közelében , szemben azzal, hogy Jenkins építési számokra vagy más monikerekre támaszkodunk.
- Git ágak védelme csökkenti az emberi tévedés kockázatát , és a lehető legtöbb feladat automatizálása csökkenti azt az időtartamot, amikor gyakran meg kell bosszankodnunk (vagy várni) ezekre az emberekre.
Példa:
Vegyünk egy webalkalmazás új szolgáltatásának példáját. Egy fejlesztőt azonosítanak és hozzárendelnek a feladathoz, kiveszi a meglévő kódbázist a Forrás vezérlőből - mondjuk Git, elvégzi a változtatásokat, elvégzi az egység tesztelését, manuálisan biztosítja a kód minőségét, és visszaellenőrzi az új kódot a Gitbe.
Ezután meg kell építenie a kódot, telepítenie kell az integrációs példányba, futtatnia kell az integrációs tesztelést, és ha a változás kielégítőnek tűnik, fel kell terjesztenie a termelési telepítés iránti kérelmet. Ha csak lenne egy csatlósunk, aki gondoskodna erről a tesztelési, építési, minőség-ellenőrzési és telepítési szakaszokról, akkor a szegény fejlesztő jobban összpontosíthatott volna azokra a dolgokra, amelyekben igazán jó - a funkció logikájának megvalósítására és fejlesztésére.
Ez a csatlós Jenkins. Orkestrátorként működik mindezen tevékenységek futtatására, amint a változás ellenőrzése a forrásirányításba (Git) történik, és így gyors visszajelzést ad a fejlesztőnek arról, hogy az általa végrehajtott változtatások elég jók-e a termelés telepítéséhez vagy sem.Rendkívül rugalmas, nyílt forráskódú, és rengeteg plugint tartalmaz, amelyek szinte bármit megtehetnek, amit csak kíván.
Demó
Itt megtudjuk, hogyan lehet integrálni Git Jenkins-szel. 5 lépést kell követnie:
1. Hozzon létre egy minta programot:
Létrehozhat bármilyen kívánt programot, például Java vagy Python vagy bármely más program. Itt írunk egy egyszerűt Python program az kinyomtatja Helló, Világ!
2. Hozzon létre egy Jenkins-munkát:
Először itt kell indítsa el Jenkins-t a parancssor használatával.
Ehhez először el kell navigálnia a rendszer Jenkins helyére, és használni kell a parancsot java -jar jenkins.war
A parancs futtatása után nyissa meg a webböngészőt, és a link használatával lépjen Jenkins kezdőlapjára helyi gazda: 8080 . Ez az alapértelmezett portszám.
Nyissa meg a Jenkins honlapját megadva a felhasználónevet és a jelszót.
A projekt létrehozásához kattintson a gombra Új elem és írja be a Projekt neve és válassza ki Freestyle projekt . Kattintson az OK gombra.
3. Adja hozzá ezt a programot a Githubhoz:
Nyissa meg a git bash-t a rendszerén. Hajózik programjának helyére. Inicializáljon egy üres adattárat a paranccsal git init .
Használja a parancsot git add. hogy a fájlt hozzáadja a munka könyvtárból az átmeneti területhez.
Most adja hozzá a fájlt a helyi adattárhoz a parancs használatával git kötelezettség -m “demo.py fájl hozzáadva” .
Most meg kell nyom ezt a fájlt a távoli adattárba. Ehhez lépjen a GitHub-fiókjába, és hozzon létre egy új nyilvános adattárat. Most másolja ki ennek a tárolónak a helyét, és lépjen a git bash terminálhoz. Itt írja be a parancsot git távoli eredet hozzáadása . Mivel most csatlakozott a távoli adattárhoz, most a parancs segítségével oda tolhatja a kódot git push -u eredetű mester. Ennek ellenőrzéséhez lépjen a GitHub fiókba, és frissítse az oldalt. Látni fogja az ott hozzáadott fájlt.
4. Adja hozzá a Git plugint a Jenkins-be:
Jenkins honlapján menjen a Jenkins kezelése .
mi leng a java-ban
Ezután kattintson a gombra A bővítmények kezelése . Itt ellenőrizze a Git plugint a telepített részben. Ha itt nem érhető el, keresse meg az elérhető részben és töltse le.
5. Konfigurálja a Jenkins feladatot az összeállítás elindításához:
Lépjen a jenkins-i projekthez, amelyet a 2. lépésben hoztunk létre. Itt, a Forráskód-kezelés részben, válasszon git és írja be a 3. lépésben létrehozott nyilvános adattár linkjét. Ezután a Build Triggers szakasz , kattintson Poll SCM opció . Itt, az Ütemezés részben, öt csillagot kell megadni szóközzel elválasztva. Ez nem más, mint a cron szintaxis a munkádhoz. Ez azt jelenti, hogy a Jenkins percenként ellenőrzi, hogy a forráskód nem változott-e meg, és ha van változás, akkor elindítja a Jenkins összeállítását.
Kattintson Alkalmaz majd tovább Mentés . Ezután kattintson a projekt kezdőlapján a gombra Építsd most . Ez futtatja a projektet, és a konzol kimenetében láthatja a program kimenetét a Jenkins-job állapotát. Ha minden rendben van, akkor a következőképpen jelenik meg Siker .
Tehát így történik a Jenkins Git integráció. Ezzel a Jenkins Git Integration című cikkünk végére értünk. Remélem, élvezték ezt a cikket.
Most, hogy megértette, mit Jenkins Git integráció azaz nézze meg ezt az Edureka, egy megbízható online tanulási vállalat, amelynek több mint 250 000 elégedett tanulóval rendelkező hálózata elterjedt az egész világon. Az Edureka DevOps tanúsító tanfolyam segít a tanulóknak megérteni, mi a DevOps, és szert kell szerezni a különféle DevOps folyamatok és eszközök, például a Báb, a Jenkins, a Nagios, az Ansible, a Chef, a Saltstack és a GIT számára az SDLC több lépésének automatizálásához.
Van egy kérdésünk? Kérjük, említse meg a megjegyzések részben, és mi kapcsolatba lépünk Önnel