Vodič za kontinuiranu isporuku - Izgradnja cjevovoda za kontinuiranu isporuku pomoću Jenkinsa

Kontinuirana isporuka:

Kontinuirana isporuka je postupak u kojem se promjene koda automatski grade, testiraju i pripremaju za puštanje u proizvodnju.Nadam se da ste uživali u mojoj Ovdje ću govoriti o sljedećim temama:

• Što je kontinuirana dostava?
• Vrste testiranja softvera
• Razlika između kontinuirane integracije, isporuke i primjene
• Koja je potreba za kontinuiranom isporukom?
• Praktično korištenje Jenkinsa i Tomcata

Dopustite nam da brzo shvatimo kako funkcionira kontinuirana isporuka.

Što je kontinuirana dostava?

To je postupak u kojem gradite softver na takav način da ga možete u bilo kojem trenutku pustiti u proizvodnju.Razmotrite donji dijagram:

Dopustite mi da objasnim gornji dijagram:

• Automatizirane skripte za izgradnju otkrivat će promjene u upravljanju izvornim kodom (SCM), poput Gita.
• Jednom kada se otkrije promjena, izvorni bi se kôd rasporedio na namjenski poslužitelj gradnje kako bi se osiguralo da gradnja ne uspije i da sve klase ispitivanja i integracijski testovi rade u redu.
• Zatim se aplikacija za izgradnju ugrađuje na testne poslužitelje (pretprodukcijski poslužitelji) za test prihvaćanja korisnika (UAT).
• Konačno, aplikacija se ručno postavlja na proizvodne poslužitelje radi objavljivanja.

Prije nego što nastavim, samo će biti pošteno objasniti vam različite vrste testiranja.

Vrste testiranja softvera:

Općenito govoreći, postoje dvije vrste testiranja:

• Testiranje blackbox-a: To je tehnika ispitivanja koja zanemaruje unutarnji mehanizam sustava i usredotočuje se na izlaz koji se generira u odnosu na bilo koji ulaz i izvršenje sustava. Naziva se i funkcionalnim ispitivanjem. U osnovi se koristi za provjeru valjanosti softvera.
• Whitebox testiranje: je tehnika ispitivanja koja uzima u obzir unutarnji mehanizam sustava. Također se naziva ispitivanje konstrukcija i ispitivanje staklenih kutija. U osnovi se koristi za provjeru softvera.

Testiranje bijele kutije:

Postoje dvije vrste ispitivanja koja spadaju u ovu kategoriju.

• Jedinstveno testiranje: To je ispitivanje pojedine jedinice ili skupine srodnih jedinica. Programer to često radi kako bi testirao da jedinica koju je implementirao daje očekivani izlaz u odnosu na zadani ulaz.
• Ispitivanje integracije: To je vrsta ispitivanja u kojem je skupina komponenatakombinirano za proizvodnju rezultata. Također, interakcija između softvera i hardvera testira se ako softverske i hardverske komponente imaju bilo kakve veze. Može spadati i u testiranje bijele kutije i u crnu kutiju.

Testiranje blackbox-a:

Postoji više testova koji spadaju u ovu kategoriju. Usredotočit ću se nanekoliko, koje je važno da znate kako biste razumjeli ovaj blog:

• Ispitivanje funkcionalnosti / prihvaćanja: Osigurava da navedena funkcija potrebna u zahtjevima sustava funkcionira. To je učinjeno kako bi se osiguralo da isporučeni proizvod udovoljava zahtjevima i radi onako kako je kupac očekivao
• Testiranje sustava: Osigurava da stavljanjem softvera u različita okruženja (npr. Operativni sustavi) i dalje radi.
• Ispitivanje naprezanja: Ocjenjuje kako se sustav ponaša u nepovoljnim uvjetima.
• Beta testiranje: To rade krajnji korisnici, tim izvan programa za razvoj ili javno objavljuju punu pred-verziju proizvoda koja je poznata kaobetaverzija. Cilj beta testiranja je pokriti neočekivane pogreške.

Sad je pravo vrijeme da objasnim razliku između kontinuirane integracije, isporuke i primjene.

Razlike između kontinuirane integracije, isporuke i primjene:

Vizualni sadržaj dolazi do mozga pojedinca brže i razumljivije od tekstualnih informacija. Stoga ću započeti s dijagramom koji jasno objašnjava razliku:

U kontinuiranoj integraciji, svako urezivanje koda gradi se i testira, ali nije u stanju da bude objavljeno. Mislim, aplikacija za izgradnju ne postavlja se automatski na testne poslužitelje kako bi se provjerila valjanost pomoću različitih vrsta Blackbox testiranja poput - User Acceptance Testing (UAT).

U kontinuiranoj isporuci, aplikacija se kontinuirano postavlja na testne poslužitelje za UAT. Ili možete reći da je aplikacija spremna za puštanje u proizvodnju u bilo kojem trenutku. Dakle, očito je kontinuirana integracija neophodna za kontinuiranu isporuku.

Kontinuirano postavljanje sljedeći je korak pored Kontinuirane isporuke, gdje ne stvarate samo paket koji se može implementirati, već ga zapravo automatizirate.

Dopustite mi da rezimiram razlike pomoću tablice:

Jednostavno rečeno, kontinuirana integracija dio je kontinuirane isporuke i kontinuirane implementacije. I kontinuirano postavljanje je poput kontinuirane isporuke, osim što se izdanja događaju automatski.

Saznajte kako stvoriti CI / CD cjevovode pomoću Jenkinsa u oblaku

Ali pitanje je je li dovoljna kontinuirana integracija.

Zašto nam je potrebna kontinuirana dostava?

Razumijemo to na primjeru.

Zamislite da 80 programera radi na velikom projektu. Koriste cjevovode kontinuirane integracije kako bi olakšali automatizirane izrade. Znamo da gradnja uključuje i jedinstveno testiranje. Jednog dana odlučili su najnoviju verziju koja je prošla jedinstvene testove implementirati u testno okruženje.

Ovo mora biti dugotrajan, ali kontroliran pristup rasporedu koji su provodili njihovi stručnjaci za zaštitu okoliša. Međutim, čini se da sustav nije funkcionirao.

Što bi mogao biti očiti uzrok neuspjeha?

Pa, prvi razlog zbog kojeg će većina ljudi pomisliti je taj što postoji neki problem s konfiguracijom. Kao i većina ljudi, čak su i oni tako mislili.Proveli su puno vremena pokušavajući otkriti što nije u redu s konfiguracijom okoliša, ali nisu uspjeli pronaći problem.

Jedan perceptivni programer primijenio je pametan pristup:

Tada je jedan od starijih programera isprobao aplikaciju na svom razvojnom stroju. Ni tamo nije uspjelo.

Vratio se kroz ranije i ranije verzije dok nije ustanovio da je sustav prestao raditi tri tjedna ranije. Sićušna, nejasna greška spriječila je pravilno pokretanje sustava. Iako je projekt imao dobru pokrivenost jediničnim testom.Unatoč tome, 80 programera, koji su obično provodili testove, a ne samu aplikaciju, tri tjedna nisu vidjeli problem.

Izjava o problemu:

Bez izvođenja testova prihvaćanja u proizvodnom okruženju, oni ne znaju ništa o tome zadovoljava li aplikacija korisničke specifikacije, niti može li se implementirati i opstati u stvarnom svijetu. Ako žele pravovremene povratne informacije o tim temama, moraju proširiti opseg svog kontinuiranog procesa integracije.

Dopustite mi da rezimiram naučene lekcije gledajući gore navedene probleme:

• Jedinstveni testovi testiraju samo razvojnu perspektivu rješenja problema. Imaju samo ograničenu sposobnost da dokažu da aplikacija čini ono što treba iz perspektive korisnika. Nisu dovoljni zaprepoznati stvarne funkcionalne probleme.
• Razmještanje aplikacije u testnom okruženju složen je, ručno intenzivan postupak koji je bio prilično sklon pogreškama.To je značilo da je svaki pokušaj implementacije bio novi eksperiment - ručni postupak podložan pogreškama.

Rješenje - Cjevovod za kontinuiranu isporuku (automatizirani test prihvaćanja):

Prešli su na kontinuiranu integraciju (kontinuirana isporuka) do sljedećeg koraka i uveli nekoliko jednostavnih, automatiziranih testova prihvaćanja koji su dokazali da je aplikacija pokrenuta i da može obavljati svoju najosnovniju funkciju.Većina testova koji se izvode tijekom faze provjere prihvatljivosti su testovi funkcionalne prihvatljivosti.

U osnovi su izgradili cjevovod kontinuirane isporuke, kako bi osigurali da aplikacija neprimjetno bude postavljena u proizvodnom okruženju, osiguravajući da aplikacija dobro funkcionira kada je postavljena na testnom poslužitelju koji je replika proizvodnog poslužitelja.

primjer statičkog bloka u javi

Dosta teorije, sada ću vam pokazati kako stvoriti cjevovod kontinuirane isporuke pomoću Jenkinsa.

Cjevovod za kontinuiranu isporuku pomoću Jenkinsa:

Ovdje ću koristiti Jenkins za stvaranje cjevovoda za kontinuiranu isporuku, koji će uključivati ​​sljedeće zadatke:

Koraci uključeni u demonstraciju:

• Dohvaćanje koda s GitHub-a
• Kompiliranje izvornog koda
• Jedinstveno testiranje i generiranje izvještaja o testiranju JUnit
• Pakiranje aplikacije u WAR datoteku i njeno postavljanje na Tomcat poslužitelj

Preduvjeti:

• Stroj CentOS 7
• Jenkins 2.121.1
• Lučki radnik
• Tomcat 7

Korak - 1 Sastavljanje izvornog koda:

Počnimo s tim da prvo napravimo Freestyle projekt u Jenkinsu. Razmotrite donju snimku zaslona:

Dajte ime svom projektu i odaberite Freestyle Project:

Kada se pomaknete prema dolje, pronaći ćete opciju za dodavanje spremišta izvornog koda, odabir git-a i dodavanje URL-a spremišta, u tom spremištu nalazi se pom.xml fine koji ćemo koristiti za izgradnju našeg projekta. Razmotrite donju snimku zaslona:

Sada ćemo dodati okidač za izgradnju. Odaberite opciju SCM za anketu, u osnovi ćemo konfigurirati Jenkinsa da anketira GitHub spremište nakon svakih 5 minuta zbog promjena u kodu. Razmotrite donju snimku zaslona:

Prije nego što nastavim, dopustiću vam mali uvod u Mavenov ciklus gradnje.

Svaki od životnih ciklusa izrade definiran je različitim popisom faza izrade, pri čemu faza izrade predstavlja fazu u životnom ciklusu.

Slijedi popis faza izrade:

• potvrditi - provjeriti je li projekt točan i dostupne su sve potrebne informacije
• compile - kompajliranje izvornog koda projekta
• test - testirajte sastavljeni izvorni kod koristeći prikladni okvir za jedinstveno testiranje. Ova ispitivanja ne bi trebala zahtijevati da se kôd zapakira ili primijeni
• paket - uzmite kompajlirani kôd i pakirajte ga u njegov format koji se može distribuirati, kao što je JAR.
• provjeriti - pokrenuti bilo kakve provjere rezultata integracijskih testova kako bi se osiguralo da su ispunjeni kriteriji kvalitete
• install - instalirajte paket u lokalno spremište, za lokalnu upotrebu kao ovisnost u drugim projektima
• implementacija - izvršena u okruženju gradnje, kopira konačni paket u udaljeno spremište za dijeljenje s drugim programerima i projektima.

Mogu pokrenuti donju naredbu za sastavljanje izvornog koda, jedinično testiranje, pa čak i pakiranje aplikacije u ratnu datoteku:

mvn čist paket

Svoj posao gradnje također možete rastaviti na brojne korake izrade. To olakšava organizaciju izrada u čistim, odvojenim fazama.

Stoga ćemo započeti sastavljanjem izvornog koda. Na kartici gradnje kliknite na poziv maven ciljeva najviše razine i upišite donju naredbu:

sastaviti

Razmotrite donju snimku zaslona:

To će povući izvorni kod iz GitHub spremišta i također će ga kompilirati (Maven Compile Phase).

Kliknite Spremi i pokrenite projekt.

Sada kliknite izlaz konzole da biste vidjeli rezultat.

Korak - 2 Jedinstveno testiranje:

Sada ćemo stvoriti još jedan Freestyle projekt za jedinstveno testiranje.

Dodajte isti URL spremišta na karticu za upravljanje izvornim kodom, kao što smo to učinili u prethodnom poslu.

Sada, na kartici 'Buid Trigger' kliknite na 'build after other projects are built'. Tamo upišite ime prethodnog projekta u kojem sastavljamo izvorni kod i možete odabrati bilo koju od sljedećih opcija:

• Okidač samo ako je gradnja stabilna
• Okidač čak i ako je gradnja nestabilna
• Okidač čak i ako izrada ne uspije

Mislim da su gornje opcije prilično razumljive, pa odaberite bilo koju. Razmotrite donju snimku zaslona:

Na kartici Izgradnja kliknite na poziv maven ciljeva najviše razine i upotrijebite donju naredbu:

test

Jenkins također sjajno radi pomažući vam u prikazivanju rezultata ispitivanja i trendova rezultata ispitivanja.

De facto standard za izvještavanje o testovima u svijetu Jave je XML format koji koristi JUnit. Ovaj format koriste i mnogi drugi alati za testiranje Java, kao što su TestNG, Spock i Easyb. Jenkins razumije ovaj format, pa ako vaša izrada proizvodi rezultate JUnit XML testa, Jenkins može generirati lijepa grafička izvješća o testiranju i statistiku rezultata testova tijekom vremena, a također vam omogućuje pregled detalja svih neuspjeha na testu. Jenkins također prati koliko dugo traju vaši testovi, kako globalno, tako i po testu - to može dobro doći ako trebate pronaći probleme s izvedbom.

Dakle, sljedeća stvar koju trebamo učiniti je natjerati Jenkinsa da prati naše jedinične testove.

Idite na odjeljak Post-build Actions i označite potvrdni okvir 'Objavi izvještaj o rezultatu testa JUnit'. Kada Maven pokrene jedinične testove u projektu, on automatski generira XML izvješća o testiranju u direktoriju koji se naziva surefire-reports. Dakle, unesite '** / target / surefire-reports / *. Xml' u polje 'XML-ovi izvještaja o testiranju'. Dvije zvjezdice na početku puta ('**') najbolja su praksa da konfiguraciju učinite malo robusnijom: omogućuju Jenkinsu da pronađe ciljani direktorij bez obzira na to kako smo Jenkins konfigurirali da provjeri izvorni kod.

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

Ponovno ga spremite i kliknite Build Now.

java util logging logger primjer

Sada je izvješće JUnit napisano na / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behaviour.

Na Jenkinsovoj nadzornoj pločitakođer možete primijetiti rezultate testa:

Korak - 3 Stvaranje WAR datoteke i postavljanje na Tomcat poslužitelj:

Sada je sljedeći korak spakiranje naše aplikacije u WAR datoteku i njeno postavljanje na Tomcat poslužitelj za test prihvaćanja korisnika.

Izradite još jedan projekt slobodnog stila i dodajte URL spremišta izvornog koda.

Zatim na kartici okidača gradnje odaberite izgradnju kada se grade drugi projekti, razmotrite donju snimku zaslona:

što je znanost o podacima?

U osnovi, nakon testnog zadatka, faza uvođenja započet će automatski.

Na kartici gradnje odaberite skriptu ljuske. Upišite naredbu u nastavku da biste paket zapakirali u WAR datoteku:

mvn paket

Sljedeći je korak rasporediti ovu WAR datoteku na Tomcatposlužitelju. Na kartici 'Post-Build Actions' odaberite implementaciju war / ear u spremnik. Ovdje dajte put do ratne datoteke i navedite put konteksta. Razmotrite donju snimku zaslona:

Odaberite vjerodajnice za Tomcat i primijetite gornju snimku zaslona. Također, trebate navesti URL vašeg Tomcat poslužitelja.

Da biste dodali vjerodajnice u Jenkinsu, kliknite opciju vjerodajnica na Jenkinsovoj nadzornoj ploči.

Kliknite na Sustav i odaberite globalne vjerodajnice.

Tada ćete pronaći opciju za dodavanje vjerodajnica. Kliknite na nju i dodajte vjerodajnice.

Dodajte vjerodajnice za Tomcat, razmotrite snimak zaslona u nastavku.

Kliknite U redu.

Sada u svoju Konfiguraciju projekta dodajte vjerodajnice tomcat koje ste umetnuli u prethodnom koraku.

Kliknite Spremi, a zatim odaberite Izgradi sada.

Idite na svoj tomcat URL, s kontekstnom stazom, u mom slučaju to je http: // localhost: 8081. Sada dodajte stazu konteksta na kraju, razmotrite donju snimku zaslona:

Link - http: // localhost: 8081 / gof

Nadam se da ste razumjeli značenje kontekstnog puta.

Sada izradite prikaz cjevovoda, razmotrite donju snimku zaslona:

Kliknite ikonu plusa da biste stvorili novi prikaz.

Konfigurirajte cjevovod onako kako želite, razmotrite snimak zaslona u nastavku:

Nisam ništa promijenio osim odabira početnog posla. Dakle, moj će cjevovod početi od prevođenja. Na temelju načina na koji sam konfigurirao druge poslove, nakon kompajliranja dogodit će se testiranje i implementacija.

Napokon, cjevovod možete testirati klikom na RUN. Nakon svakih pet minuta, ako dođe do promjene izvornog koda, izvršit će se cijeli cjevovod.

Tako smo u mogućnosti kontinuirano postavljati našu aplikaciju na testni poslužitelj za test prihvaćanja korisnika (UAT).

Nadam se da ste uživali čitajući ovaj post o Kontinuiranoj isporuci. Ako sumnjate, slobodno ih stavite u odjeljak za komentare u nastavku, a ja ću vam odgovoriti najranije.

Da biste izgradili CI / CD cjevovode, morate svladati široku paletu vještina Svladajte potrebne vještine DevOps-a odmah