Vadnica za neprekinjeno dostavo - gradnja cevovoda za neprekinjeno dostavo z uporabo Jenkinsa

Neprekinjena dostava:

Neprekinjena dostava je postopek, pri katerem se spremembe kode samodejno zgradijo, preizkusijo in pripravijo na sprostitev v proizvodnjo.Upam, da ste uživali v mojem Tukaj bom govoril o naslednjih temah:

• Kaj je neprekinjena dostava?
• Vrste testiranja programske opreme
• Razlika med nenehno integracijo, dostavo in uvajanjem
• Kaj je potrebno za stalno dostavo?
• Praktična uporaba Jenkinsa in Tomcata

Naj hitro razumemo, kako deluje neprekinjena dostava.

Kaj je neprekinjena dostava?

Gre za postopek, pri katerem programsko opremo gradite tako, da jo lahko kadar koli sprostite v proizvodnjo.Upoštevajte spodnji diagram:

Naj pojasnim zgornji diagram:

• Samodejni skripti za gradnjo bodo zaznali spremembe v upravljanju izvorne kode (SCM), kot je Git.
• Ko je sprememba zaznana, se izvorna koda namesti na namenski strežnik za gradnjo, da se prepriča, da gradnja ne uspe in da vsi preizkusni razredi in integracijski testi delujejo dobro.
• Nato je aplikacija za gradnjo nameščena na testnih strežnikih (predprodukcijski strežniki) za uporabniški preizkus (UAT).
• Na koncu je aplikacija ročno nameščena na delovnih strežnikih za izdajo.

Preden nadaljujem, bo pošteno, da vam razložim različne vrste testiranja.

Vrste testiranja programske opreme:

Na splošno obstajata dve vrsti testiranja:

• Testiranje blackbox-a: Gre za preizkusno tehniko, ki ignorira notranji mehanizem sistema in se osredotoča na ustvarjene rezultate glede na kakršen koli vhod in izvedbo sistema. Imenuje se tudi funkcionalno testiranje. V osnovi se uporablja za preverjanje veljavnosti programske opreme.
• Preizkus Whitebox: je preskusna tehnika, ki upošteva notranji mehanizem sistema. Imenuje se tudi strukturno preskušanje in testiranje steklenih škatel. V osnovi se uporablja za preverjanje programske opreme.

Preizkušanje Whitebox:

V to kategorijo spadata dve vrsti testiranja.

• Enotno testiranje: Gre za testiranje posamezne enote ali skupine sorodnih enot. Programer pogosto stori, da preizkusi, ali enota, ki jo je implementiral, ustvarja pričakovane rezultate glede na dani vhod.
• Integracijsko testiranje: To je vrsta testiranja, pri katerem je skupina komponentzdružiti za proizvodnjo. Prav tako se preizkuša interakcija med programsko in strojno opremo, če so komponente programske in strojne opreme v kakršni koli povezavi. Morda spada med testiranje bele škatle in črne škatle.

Testiranje blackbox-a:

V to kategorijo spada več testov. Osredotočil se bom nanekaj, ki jih je pomembno vedeti za razumevanje tega spletnega dnevnika:

• Preizkus funkcionalnosti / sprejemljivosti: Zagotavlja, da določena funkcionalnost, ki jo zahtevajo sistemske zahteve, deluje. Naredimo tako, da zagotovimo, da dobavljeni izdelek izpolnjuje zahteve in deluje tako, kot je pričakovala stranka
• Testiranje sistema: Zagotavlja, da programska oprema v različnih okoljih (npr. Operacijski sistemi) še vedno deluje.
• Testiranje izjemnih situacij: Ocenjuje, kako se sistem obnaša v neugodnih razmerah.
• Beta testiranje: To naredijo končni uporabniki, skupina zunaj razvoja ali javno objavi celotno predhodno različico izdelka, ki je znana kotbetarazličico. Cilj beta testiranja je zajeti nepričakovane napake.

Zdaj je pravi čas, da pojasnim razliko med nenehno integracijo, dostavo in uvajanjem.

Razlike med nenehno integracijo, dobavo in uvajanjem:

Vizualna vsebina doseže posameznikove možgane hitreje in bolj razumljivo kot besedilne informacije. Začel bom torej z diagramom, ki jasno pojasnjuje razliko:

V okviru Neprekinjene integracije se vsako prevzemanje kode gradi in preizkuša, vendar ni v stanju, da bi se sprostilo. Mislim, da aplikacija za izdelavo ni samodejno nameščena na testnih strežnikih, da bi jo lahko preverila z različnimi vrstami preizkušanja Blackboxa, kot je testiranje sprejemljivosti uporabnika (UAT).

Pri stalni dostavi se aplikacija neprekinjeno uvaja na testnih strežnikih za UAT. Lahko pa rečemo, da je aplikacija kadar koli pripravljena na sprostitev v uporabo. Torej je za neprekinjeno dostavo očitno potrebna stalna integracija.

Neprekinjena razmestitev je naslednji korak pred neprekinjeno dostavo, kjer ne ustvarjate samo paketa, ki ga je mogoče uvesti, ampak ga dejansko uvajate avtomatizirano.

Naj povzamem razlike z uporabo tabele:

Preprosto povedano, stalna integracija je del tako stalne dostave kot neprekinjene uvajanja. In nenehna uvajanje je kot neprekinjena dostava, le da se izdaje zgodijo samodejno.

Naučite se ustvariti CI / CD cevovode z uporabo Jenkinsa v oblaku

Vprašanje pa je, ali je nenehna integracija dovolj.

Zakaj potrebujemo stalno dostavo?

Razumimo to na primeru.

Predstavljajte si, da 80 razvijalcev dela na velikem projektu. Za lažje avtomatizirane gradnje uporabljajo cevovode za kontinuirano integracijo. Vemo, da build vključuje tudi preskušanje enot. Nekega dne so se odločili, da bodo najnovejšo različico, ki je opravila preizkuse enote, postavili v testno okolje.

To mora biti dolgotrajen, a nadzorovan pristop k uvajanju, ki so ga izvedli njihovi okoljski strokovnjaki. Vendar se zdi, da sistem ni deloval.

Kaj je lahko očiten vzrok za neuspeh?

No, prvi razlog, da si bo večina ljudi mislila, je ta, da obstaja nekaj težav s konfiguracijo. Kot večina ljudi je tudi oni mislili tako.Veliko časa so poskušali ugotoviti, kaj je narobe s konfiguracijo okolja, vendar težave niso našli.

En dojemljiv razvijalec se je odločil za pameten pristop:

Nato je eden od starejših razvijalcev preizkusil aplikacijo na svojem razvojnem stroju. Tudi tam ni šlo.

Korakal je skozi prejšnje in prejšnje različice, dokler ni ugotovil, da je sistem prenehal delovati tri tedne prej. Drobna, nejasna napaka je preprečila pravilno zagon sistema. Čeprav je imel projekt dobro pokritost z enotami.Kljub temu 80 razvijalcev, ki so navadno izvajali le teste in ne samo aplikacijo, tri tedne ni videlo težave.

Izjava o težavi:

Brez izvajanja sprejemnih testov v okolju, podobnem proizvodnji, ne vedo ničesar o tem, ali aplikacija ustreza specifikacijam stranke, niti tega, ali jo je mogoče uvesti in preživeti v resničnem svetu. Če želijo pravočasno povratne informacije o teh temah, morajo razširiti obseg svojega nenehnega procesa integracije.

Naj povzamem naučene lekcije s preučevanjem zgornjih težav:

• Preizkusi enot preizkušajo samo perspektivo razvijalca glede rešitve težave. Imajo le omejeno sposobnost dokazovanja, da aplikacija z vidika uporabnikov počne tisto, kar bi morala. Niso dovoljprepoznati resnične funkcionalne težave.
• Razmestitev aplikacije v testnem okolju je zapleten, ročno intenziven postopek, ki je bil precej nagnjen k napakam.To je pomenilo, da je bil vsak poskus uvajanja nov poskus - ročni postopek, ki je nagnjen k napakam.

Rešitev - cevovod za neprekinjeno dobavo (samodejni sprejemni test):

Neprekinjeno integracijo (neprekinjeno dostavo) so izvedli do naslednjega koraka in uvedli nekaj preprostih, avtomatiziranih preizkusov sprejemljivosti, ki so dokazali, da je aplikacija delovala in lahko opravlja svojo najbolj temeljno funkcijo.Večina preskusov, ki se izvajajo v fazi sprejemnega preizkusa, je funkcionalnih sprejemnih testov.

V bistvu so zgradili cevovod za neprekinjeno dostavo, da bi zagotovili, da je aplikacija nemoteno nameščena v produkcijskem okolju, in sicer tako, da aplikacija deluje dobro, ko je nameščena na testnem strežniku, ki je kopija produkcijskega strežnika.

Dovolj teorije, zdaj vam bom pokazal, kako z Jenkinsom ustvariti cevovod za neprekinjeno dostavo.

Cevovod za neprekinjeno dobavo z uporabo Jenkinsa:

Tu bom z Jenkinsom ustvaril cevovod za neprekinjeno dostavo, ki bo vključeval naslednje naloge:

Koraki v predstavitvi:

• Pridobivanje kode iz GitHub
• Prevajanje izvorne kode
• Enotno testiranje in ustvarjanje poročil o preskusih JUnit
• Pakiranje aplikacije v datoteko WAR in njeno razmestitev na strežniku Tomcat

Predpogoji:

java program za preverjanje palindroma -

• Stroj CentOS 7
• Jenkins 2.121.1
• Docker
• Tomcat 7

Korak - 1 Sestavljanje izvorne kode:

Začnimo s tem, da najprej ustvarimo projekt Freestyle v Jenkinsu. Upoštevajte spodnji posnetek zaslona:

Poimenujte svoj projekt in izberite Freestyle Project:

Ko se pomaknete navzdol, boste našli možnost, da dodate repozitorij izvorne kode, izberete git in dodate URL repozitorija, v tem repozitoriju je pom.xml fin, ki ga bomo uporabili za izdelavo našega projekta. Upoštevajte spodnji posnetek zaslona:

Zdaj bomo dodali sprožilec gradnje. Izberite možnost SCM za anketo, v bistvu bomo Jenkinsa konfigurirali tako, da bo vsakih 5 minut anketiral skladišče GitHub za spremembe kode. Upoštevajte spodnji posnetek zaslona:

Preden nadaljujem, naj vam predstavim majhen uvod v Maven Build Cycle.

Vsak življenjski cikel gradnje je opredeljen z drugačnim seznamom faz gradnje, pri čemer faza gradnje predstavlja stopnjo v življenjskem ciklu.

Sledi seznam faz gradnje:

• validate - potrdite, da je projekt pravilen in so na voljo vse potrebne informacije
• compile - prevedite izvorno kodo projekta
• test - preizkusite sestavljeno izvorno kodo z uporabo ustreznega okvira za preskušanje enot. Ti testi ne bi smeli zahtevati pakiranja ali uvajanja kode
• paket - vzemite prevedeno kodo in jo zapakirajte v njeno distribucijsko obliko, kot je JAR.
• preverite - zaženite kakršne koli preglede rezultatov integracijskih testov, da zagotovite, da so izpolnjena merila kakovosti
• namestite - namestite paket v lokalno repozitorij za lokalno uporabo kot odvisnost pri drugih projektih
• razmestitev - izvedeno v gradbenem okolju, kopira končni paket v oddaljeno repozitorij za skupno rabo z drugimi razvijalci in projekti.

Lahko zaženem spodnji ukaz za sestavljanje izvorne kode, preskušanje enot in celo pakiranje aplikacije v vojno datoteko:

mvn čist paket

Nalogo gradnje lahko razdelite tudi na več korakov gradnje. Tako je enostavneje organizirati gradnje v čistih, ločenih fazah.

Začeli bomo z zbiranjem izvorne kode. Na zavihku gradnje kliknite priklic ciljev najvišje ravni maven in vnesite spodnji ukaz:

sestavi

Upoštevajte spodnji posnetek zaslona:

To bo povleklo izvorno kodo iz skladišča GitHub in jo tudi prevedlo (Maven Compile Phase).

Kliknite Shrani in zaženite projekt.

Zdaj kliknite izhod konzole, da si ogledate rezultat.

Korak - 2 enotno testiranje:

Zdaj bomo ustvarili še en projekt Freestyle za enotno testiranje.

Na zavihek za upravljanje izvorne kode dodajte isti URL repozitorija, kot smo to storili v prejšnjem opravilu.

Zdaj na zavihku »Buid Trigger« kliknite na »build after other projects are built«. Vnesite ime prejšnjega projekta, v katerem zbiramo izvorno kodo, in lahko izberete katero koli od spodnjih možnosti:

• Sproži samo, če je gradnja stabilna
• Sproži tudi, če je gradnja nestabilna
• Sproži tudi, če gradnja ne uspe

Mislim, da so zgornje možnosti precej samoumevne, zato izberite katero koli. Upoštevajte spodnji posnetek zaslona:

Na zavihku Build kliknite priklic ciljev najvišje ravni maven in uporabite spodnji ukaz:

preskus

Jenkins si tudi odlično pomaga, da vam prikaže rezultate testov in trende rezultatov testov.

Dejanski standard za poročanje o preizkusih v svetu Jave je oblika XML, ki jo uporablja JUnit. To obliko uporabljajo tudi številna druga orodja za testiranje Java, kot so TestNG, Spock in Easyb. Jenkins razume to obliko, zato lahko, če vaša zgradba ustvari rezultate preskusa JUnit XML, Jenkins lahko sčasoma ustvari lepa grafična poročila o preskusih in statistične podatke o rezultatih preizkusa ter vam omogoči tudi ogled podrobnosti o morebitnih neuspehih preizkusa. Jenkins tudi beleži, kako dolgo trajajo vaši testi, tako globalno kot na test - to lahko pride v poštev, če morate izslediti težave z zmogljivostjo.

Naslednja stvar, ki jo moramo storiti, je, da Jenkinsa spremljamo naše enote.

Odprite razdelek Dejanja po izdelavi in ​​potrdite polje »Objavi poročilo o rezultatih preskusa JUnit«. Ko Maven zažene preskuse enot v projektu, samodejno ustvari poročila o preskusu XML v imeniku, imenovanem surefire-reports. Torej v polje »XML poročila o preskusu« vnesite »** / target / surefire-reports / *. Xml«. Dve zvezdici na začetku poti (»**«) sta najboljša praksa, da naredite konfiguracijo nekoliko bolj trpežno: Jenkinsu omogočata, da najde ciljni imenik, ne glede na to, kako smo nastavili Jenkinsa, da preveri izvorno kodo.

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

Ponovno ga shranite in kliknite Build Now.

Zdaj je poročilo JUnit zapisano v / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-vedenje.

Na armaturni plošči Jenkinsopazite lahko tudi rezultate testa:

Korak - 3 Ustvarjanje datoteke WAR in razmestitev na strežniku Tomcat:

Naslednji korak je pakiranje naše aplikacije v datoteko WAR in njeno namestitev na strežniku Tomcat za preizkus sprejetja uporabnika.

Ustvarite še en projekt freestyle in dodajte URL repozitorija izvorne kode.

Nato na zavihku sprožilca gradnje izberite gradnjo, ko so zgrajeni drugi projekti, upoštevajte spodnji posnetek zaslona:

V bistvu se po preizkusnem opravilu faza uvajanja začne samodejno.

Na zavihku gradnje izberite skript lupine. Vnesite spodnji ukaz, da aplikacijo zapakirate v datoteko WAR:

mvn paket

Naslednji korak je razmestitev te datoteke WAR v Tomcatstrežnik. Na zavihku »Dejanja po gradnji« izberite razmestitev vojne / ušesa v zabojnik. Tu podajte pot do vojne datoteke in pot konteksta. Upoštevajte spodnji posnetek zaslona:

Izberite poverilnice Tomcat in opazite zgornji posnetek zaslona. Navesti morate tudi URL strežnika Tomcat.

Če želite dodati poverilnice v Jenkins, kliknite možnost poverilnic na nadzorni plošči Jenkins.

Kliknite Sistem in izberite globalne poverilnice.

Nato boste našli možnost dodajanja poverilnic. Kliknite nanjo in dodajte poverilnice.

Dodajte poverilnice Tomcat, upoštevajte spodnji posnetek zaslona.

Kliknite V redu.

Zdaj v Konfiguracijo projekta dodajte poverilnice tomcat, ki ste jih vstavili v prejšnjem koraku.

Kliknite Shrani in izberite Build Now.

Pojdite na svoj URL tomcat s potjo konteksta, v mojem primeru je http: // localhost: 8081. Zdaj na koncu dodajte pot konteksta, upoštevajte spodnji posnetek zaslona:

Povezava - http: // localhost: 8081 / gof

Upam, da ste razumeli pomen kontekstne poti.

Zdaj ustvarite pogled cevovoda, upoštevajte spodnji posnetek zaslona:

Kliknite ikono plus, da ustvarite nov pogled.

Konfigurirajte cevovod tako, kot želite, upoštevajte spodnji posnetek zaslona:

Ničesar nisem spremenil, razen izbire začetne službe. Torej se bo moj cevovod začel s prevajanjem. Glede na način, kako sem konfiguriral druga opravila, se bo po prevajanju zgodilo testiranje in razmestitev.

Na koncu lahko preskusite cevovod s klikom na RUN. Če pride do spremembe izvorne kode po petih minutah, se izvede celoten cevovod.

Tako lahko svojo aplikacijo neprekinjeno namestimo na testni strežnik za test sprejemljivosti uporabnikov (UAT).

Upam, da ste uživali v branju te objave o stalni dostavi. Če imate kakršne koli dvome, jih lahko vstavite v spodnji odsek za komentarje in kmalu se vrnem z odgovorom.

Če želite zgraditi CI / CD cevovode, morate obvladati široko paleto spretnosti Zdaj obvladajte zahtevane spretnosti DevOps