Jatkuvan toimituksen opas - Jenkinsä rakentaminen jatkuvalle toimitusputkelle

Jatkuva toimitus:

Jatkuva toimitus on prosessi, jossa koodimuutokset rakennetaan, testataan ja valmistellaan julkaisua varten.Toivottavasti olet nauttinut minun Tässä puhun seuraavista aiheista:

• Mikä on jatkuva toimitus?
• Ohjelmistojen testaustyypit
• Ero jatkuvan integroinnin, toimituksen ja käyttöönoton välillä
• Mikä on jatkuvan toimituksen tarve?
• Käytännöllinen Jenkinsin ja Tomcatin avulla

Kerro meille nopeasti, kuinka jatkuva toimitus toimii.

Mikä on jatkuva toimitus?

Se on prosessi, jossa rakennat ohjelmiston siten, että se voidaan julkaista tuotantoon milloin tahansa.Harkitse alla olevaa kaaviota:

Haluan selittää yllä olevan kaavion:

• Automaattiset koontikomentosarjat havaitsevat muutokset lähdekoodihallinnassa (SCM), kuten Git.
• Kun muutos on havaittu, lähdekoodi asennetaan erilliseen koontipalvelimeen varmistaakseen, että koontiversio ei onnistu ja että kaikki testiluokat ja integraatiotestit toimivat hyvin.
• Sitten koontisovellus otetaan käyttöön testauspalvelimille (pre-production-palvelimille) User Acceptance Test (UAT) -testiä varten.
• Lopuksi sovellus asennetaan manuaalisesti tuotantopalvelimiin julkaisua varten.

Ennen kuin jatkan, on vain oikeudenmukaista, että selitän teille erityyppisiä testejä.

Ohjelmistojen testaustyypit:

Testausta on yleisesti ottaen kahta tyyppiä:

• Blackbox-testaus: Se on testaustekniikka, joka jättää huomiotta järjestelmän sisäisen mekanismin ja keskittyy tuotettuun ulostuloon järjestelmän kaikkia syötteitä ja suorituksia vastaan. Sitä kutsutaan myös toiminnalliseksi testaukseksi. Sitä käytetään periaatteessa ohjelmiston validointiin.
• Whitebox-testaus: on testaustekniikka, jossa otetaan huomioon järjestelmän sisäinen mekanismi. Sitä kutsutaan myös rakennetestaukseksi ja lasikotelotestiksi. Sitä käytetään periaatteessa ohjelmiston tarkistamiseen.

Whitebox-testaus:

Tähän luokkaan kuuluu kahden tyyppisiä testauksia.

• Yksikön testaus: Se on yksittäisen yksikön tai siihen liittyvien yksiköiden ryhmän testaus. Ohjelmoija tekee usein testatakseen, että hänen toteuttamansa yksikkö tuottaa odotettua tuottoa annettua tuloa vastaan.
• Integraation testaus: Se on eräänlainen testaus, jossa komponenttiryhmä onyhdistettynä tuotoksen tuottamiseksi. Ohjelmistojen ja laitteistojen välistä vuorovaikutusta testataan myös, jos ohjelmistoilla ja laitteistokomponenteilla on mitään yhteyttä. Se voi kuulua sekä valkoisen laatikon että mustan laatikon testaukseen.

Blackbox-testaus:

Tähän luokkaan kuuluu useita testejä. Keskitynmuutama, jotka ovat sinulle tärkeitä tietääksesi tämän blogin ymmärtämiseksi:

• Toiminnallinen / hyväksyntätestaus: Se varmistaa, että järjestelmävaatimuksissa vaaditut toiminnot toimivat. Se tehdään sen varmistamiseksi, että toimitettu tuote täyttää vaatimukset ja toimii asiakkaan odotusten mukaisesti
• Järjestelmän testaus: Se varmistaa, että asettamalla ohjelmisto eri ympäristöihin (esim. Käyttöjärjestelmät) se toimii edelleen.
• Stressitestit: Se arvioi järjestelmän käyttäytymistä epäsuotuisissa olosuhteissa.
• Beetatestaus: Sen tekevät loppukäyttäjät, kehitystyön ulkopuolinen tiimi tai julkaisemalla tuotteesta julkisesti koko esiversio, joka tunnetaan nimelläbeetaversio. Beetatestauksen tarkoituksena on kattaa odottamattomat virheet.

Nyt on oikea aika selittää ero jatkuvan integroinnin, toimituksen ja käyttöönoton välillä.

Erot jatkuvan integroinnin, toimituksen ja käyttöönoton välillä:

Visuaalinen sisältö saavuttaa yksilön aivot nopeammin ja ymmärrettävämmin kuin tekstitieto. Joten aloitan kaavalla, joka selittää selvästi eron:

Jatkuvassa integraatiossa jokainen koodinsitoumus rakennetaan ja testataan, mutta se ei ole kunnossa vapautettavaksi. Tarkoitan, että koontisovellusta ei asenneta automaattisesti testipalvelimille sen validoimiseksi käyttämällä erityyppisiä Blackbox-testauksia, kuten - User Acceptance Testing (UAT).

Jatkuvassa toimituksessa sovellus asennetaan jatkuvasti UAT: n testipalvelimille. Tai voit sanoa, että sovellus on valmis vapautettavaksi tuotantoon milloin tahansa. Joten ilmeisesti jatkuva integrointi on välttämätöntä jatkuvalle toimitukselle.

Jatkuva käyttöönotto on seuraava askel jatkuvan toimituksen ohi, jolloin et vain luo käyttöönotettavaa pakettia, vaan otat sen käyttöön automatisoidusti.

Haluan tiivistää erot taulukon avulla:

Yksinkertaisesti sanottuna jatkuva integraatio on osa sekä jatkuvaa toimitusta että jatkuvaa käyttöönottoa. Ja jatkuva käyttöönotto on kuin jatkuva toimitus, paitsi että julkaisut tapahtuvat automaattisesti.

Opi luomaan CI / CD-putkilinjat Jenkins On Cloud -sovelluksella

Mutta kysymys on, riittääkö jatkuva integraatio.

Miksi tarvitsemme jatkuvaa toimitusta?

Ymmärretään tämä esimerkillä.

Kuvittele, että suuressa projektissa työskentelee 80 kehittäjää. He käyttävät jatkuvan integroinnin putkistoja automatisoitujen rakennusten helpottamiseksi. Tiedämme, että koontiversio sisältää myös yksikkötestauksen. Eräänä päivänä he päättivät ottaa käyttöön uusimman rakennetestin, joka oli läpäissyt yksikötestit, testiympäristöön.

Tämän on oltava pitkä, mutta hallittu lähestymistapa käyttöönottoon, jonka heidän ympäristöasiantuntijansa suorittivat. Järjestelmä ei kuitenkaan näyttänyt toimivan.

Mikä voi olla epäonnistumisen ilmeinen syy?

Ensimmäinen syy, jonka useimmat ihmiset ajattelevat, on se, että kokoonpanossa on jokin ongelma. Kuten useimmat ihmiset, jopa he ajattelivat niin.He viettivät paljon aikaa selvittääkseen, mikä oli väärässä ympäristön kokoonpanossa, mutta he eivät löytäneet ongelmaa.

Yksi tarkkaavainen kehittäjä otti älykkään lähestymistavan:

Sitten yksi vanhemmista kehittäjistä kokeili sovellusta kehityskoneellaan. Se ei toiminut sielläkään.

Hän kävi läpi aikaisempia ja aikaisempia versioita, kunnes huomasi, että järjestelmä oli lakannut toimimasta kolme viikkoa aiemmin. Pieni, epäselvä vika oli estänyt järjestelmää käynnistymästä oikein. Vaikka projektilla oli hyvä yksikkötestin kattavuus.Tästä huolimatta 80 kehittäjää, jotka yleensä suorittivat vain testit itse sovelluksen sijasta, eivät nähneet ongelmaa kolmen viikon ajan.

Ongelma:

Ilman hyväksymiskokeita tuotantomaisessa ympäristössä he eivät tiedä mitään siitä, täyttääkö sovellus asiakkaan vaatimukset, eikä siitä, voidaanko sitä ottaa käyttöön ja selviytyä tosielämässä. Jos he haluavat oikea-aikaista palautetta näistä aiheista, heidän on laajennettava jatkuvan integrointiprosessinsa aluetta.

Haluan tiivistää saadut kokemukset tarkastelemalla yllä olevia ongelmia:

• Yksikkötestit testaa vain kehittäjän näkökulman ongelman ratkaisuun. Heillä on vain rajallinen kyky todistaa, että sovellus tekee käyttäjien näkökulmasta sen, mitä sen pitäisi. Ne eivät riitätunnistaa todelliset toiminnalliset ongelmat.
• Sovelluksen käyttöönotto testiympäristössä on monimutkainen, manuaalisesti intensiivinen prosessi, joka oli melko altis virheille.Tämä tarkoitti, että jokainen käyttöönottoyritys oli uusi kokeilu - manuaalinen, virheiden altis prosessi.

Ratkaisu - Jatkuva toimitusputki (automatisoitu hyväksyntätesti):

He ottivat jatkuvan integroinnin (jatkuva toimitus) seuraavaan vaiheeseen ja esittivät pari yksinkertaista, automatisoitua hyväksyntätestiä, jotka osoittivat, että sovellus toimi ja pystyi suorittamaan perustavanlaatuisimman tehtävänsä.Suurin osa hyväksymistestausvaiheessa suoritettavista testeistä on toiminnallisia hyväksyntätestejä.

Pohjimmiltaan he rakensivat jatkuvan toimituksen putken varmistaakseen, että sovellus asennetaan saumattomasti tuotantoympäristöön varmistamalla, että sovellus toimii hyvin, kun se asennetaan testauspalvelimelle, joka on tuotantopalvelimen kopio.

Tarpeeksi teoriasta, näytän nyt, kuinka luoda jatkuva toimitusputki Jenkinsin avulla.

Jenkinsä käyttävä jatkuva toimitusputki:

Täällä käytän Jenkinsin avulla jatkuvan toimituksen putkilinjaa, joka sisältää seuraavat tehtävät:

c ++ miten nimitiloja käytetään

Demoon liittyvät vaiheet:

• Haetaan koodia GitHubista
• Lähdekoodin kokoaminen
• Yksikkötestaus ja JUnit-testiraporttien luominen
• Pakkaamalla sovellus WAR-tiedostoon ja asentamalla se Tomcat-palvelimelle

Edellytykset:

• CentOS 7-kone
• Jenkins 2.121.1
• Satamatyöläinen
• Tomcat 7

Vaihe - 1 Lähdekoodin kokoaminen:

Aloitetaan luomalla ensin Freestyle-projekti Jenkinsissä. Harkitse alla olevaa kuvakaappausta:

Anna projektillesi nimi ja valitse Freestyle-projekti:

Kun vierität alaspäin, löydät vaihtoehdon lisätä lähdekoodivaraston, valita git ja lisätä arkiston URL-osoite, siinä arkistossa on pom.xml-sakko, jota käytämme rakentamaan projektiamme. Harkitse alla olevaa kuvakaappausta:

Nyt lisäämme Build Trigger. Valitse kyselyn SCM-vaihtoehto, periaatteessa konfiguroimme Jenkinsin kyselemään GitHub-arkistoa 5 minuutin välein koodin muutosten varalta. Harkitse alla olevaa kuvakaappausta:

Ennen kuin jatkan, haluan antaa teille pienen esittelyn Maven-rakennussyklistä.

Kukin rakennuksen elinkaarista on määritelty eri luettelolla rakennusvaiheita, jolloin rakennusvaihe edustaa vaihetta elinkaaressa.

Seuraava on luettelo rakennusvaiheista:

• validate - validoi projekti on oikea ja kaikki tarvittavat tiedot ovat saatavilla
• kääntää - koota projektin lähdekoodi
• testi - testaa käännetty lähdekoodi sopivalla yksikötestauskehyksellä. Nämä testit eivät saisi edellyttää koodin pakkaamista tai käyttöönottoa
• paketti - ota käännetty koodi ja pakkaa se jakelukelpoiseen muotoonsa, kuten JAR.
• tarkista - suorita kaikki integraatiotestien tulokset, jotta varmistetaan, että laatukriteerit täyttyvät
• asenna - asenna paketti paikalliseen arkistoon käytettäväksi riippuvuutena muissa paikallisesti toteutettavissa projekteissa
• käyttöönotto - tehty rakennusympäristössä, kopioi lopullisen paketin etätietovarastoon jakamista muiden kehittäjien ja projektien kanssa.

Voin suorittaa alla olevan komennon lähdekoodin kokoamiseksi, yksikötestaamiseksi ja jopa sovelluksen pakkaamiseksi sotatiedostoon:

mvn puhdas paketti

Voit myös jakaa rakennustyösi useisiin koontivaiheisiin. Tämä helpottaa rakennusten järjestämistä puhtaissa, erillisissä vaiheissa.

Joten aloitamme kokoamalla lähdekoodin. Napsauta rakennus-välilehdessä kutsua ylätason maven-kohteita ja kirjoita seuraava komento:

koota

Harkitse alla olevaa kuvakaappausta:

Tämä vetää lähdekoodin GitHub-arkistosta ja myös kääntää sen (Maven Compile Phase).

Napsauta Tallenna ja suorita projekti.

Napsauta nyt konsolin lähtöä nähdäksesi tuloksen.

Vaihe - 2 yksikön testaus:

Nyt luomme vielä yhden Freestyle-projektin yksikkötestausta varten.

Lisää sama arkiston URL-osoite lähdekoodin hallinta -välilehteen, kuten teimme edellisessä työssä.

Napsauta sitten 'Buid Trigger' -välilehdessä 'build jälkeen, kun muut projektit on rakennettu'. Kirjoita siellä edellisen projektin nimi, johon olemme laatimassa lähdekoodia, ja voit valita minkä tahansa seuraavista vaihtoehdoista:

• Käynnistä vain, jos koontiversio on vakaa
• Käynnistä, vaikka koontiversio olisi epävakaa
• Käynnistä, vaikka koontiversio epäonnistuu

Mielestäni yllä olevat vaihtoehdot ovat melko itsestään selviä, joten valitse jokin. Harkitse alla olevaa kuvakaappausta:

Napsauta Rakennus-välilehdessä kutsu ylätason maven-kohteita ja käytä alla olevaa komentoa:

testata

Jenkins tekee myös hienoa työtä auttaakseen sinua näyttämään testituloksia ja testitulosten trendejä.

Testausraportoinnin tosiasiallinen standardi Java-maailmassa on XML-muoto, jota JUnit käyttää. Tätä muotoa käyttävät myös monet muut Java-testaustyökalut, kuten TestNG, Spock ja Easyb. Jenkins ymmärtää tämän muodon, joten jos rakennuksesi tuottaa JUnit XML -testituloksia, Jenkins voi luoda mukavia graafisia testiraportteja ja tilastotietoja testituloksista ajan myötä ja antaa sinun myös tarkastella mahdollisten testivirheiden yksityiskohtia. Jenkins seuraa myös kuinka kauan testien suorittaminen kestää sekä maailmanlaajuisesti että testiä kohti - tämä voi olla hyödyllistä, jos sinun on löydettävä suorituskykyongelmat.

Joten seuraava asia, joka meidän on tehtävä, on saada Jenkins pitämään välilehtiä yksikkötesteissämme.

Siirry Post-build Actions -osioon ja valitse Julkaise JUnit-testitulosraportti -valintaruutu. Kun Maven suorittaa yksikkötestejä projektissa, se luo automaattisesti XML-testiraportit hakemistoon nimeltään surefire-reports. Kirjoita '** / target / surefire-reports / *. Xml' 'Test report XMLs' -kenttään. Polun alussa olevat kaksi tähteä (“**”) ovat paras tapa tehdä kokoonpanosta hieman vankempi: ne antavat Jenkinsin löytää kohdehakemiston riippumatta siitä, miten olemme määrittäneet Jenkinsin tarkistamaan lähdekoodin.

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

Tallenna se uudelleen ja napsauta Rakenna nyt.

Nyt JUnit-raportti kirjoitetaan / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

Jenkinsin kojelaudassavoit myös huomata testitulokset:

Vaihe - 3 WAR-tiedoston luominen ja käyttöönotto Tomcat-palvelimella:

Seuraava vaihe on pakata sovelluksemme WAR-tiedostoon ja asentaa se Tomcat-palvelimelle User Acceptance -testiä varten.

Luo vielä yksi freestyle-projekti ja lisää lähdekoodivaraston URL-osoite.

Valitse sitten rakennuksen käynnistysvälilehdessä koontiversio, kun muita projekteja rakennetaan, ota huomioon seuraava kuvakaappaus:

mitä iteraattori tekee java

Pohjimmiltaan testityön jälkeen käyttöönottovaihe alkaa automaattisesti.

Valitse koontiversiossa komentotulkki. Kirjoita seuraava komento pakataksesi sovelluksen WAR-tiedostoon:

mvn-paketti

Seuraava askel on asentaa tämä WAR-tiedosto Tomcatiinpalvelin. Valitse Rakennuksen jälkeiset toimet -välilehdessä aseta sota / korva konttiin. Anna tälle sotatiedoston polku ja anna kontekstipolku. Harkitse alla olevaa kuvakaappausta:

Valitse Tomcat-kirjautumistiedot ja huomaa yllä oleva kuvakaappaus. Lisäksi sinun on annettava Tomcat-palvelimen URL-osoite.

Jos haluat lisätä tunnistetiedot Jenkinsiin, napsauta kirjautumistiedot-vaihtoehtoa Jenkinsin hallintapaneelissa.

Napsauta Järjestelmä ja valitse yleiset tunnistetiedot.

Sitten löydät vaihtoehdon lisätä tunnistetiedot. Napsauta sitä ja lisää tunnistetiedot.

Lisää Tomcat-tunnistetiedot, harkitse alla olevaa kuvakaappausta.

Napsauta OK.

Lisää nyt projektikokoonpanoon edellisessä vaiheessa lisäämäsi tomcat-tunnistetiedot.

Napsauta Tallenna ja valitse sitten Rakenna nyt.

Siirry tomcat-URL-osoitteeseesi kontekstipolun kanssa, minun tapauksessani se on http: // localhost: 8081. Lisää nyt kontekstipolku loppuun, harkitse alla olevaa näyttökuvaa:

Linkki - http: // localhost: 8081 / gof

Toivon, että olet ymmärtänyt kontekstipolun merkityksen.

Luo nyt putkistonäkymä, ota huomioon seuraava kuvakaappaus:

Luo uusi näkymä napsauttamalla plus-kuvaketta.

Määritä putki haluamallasi tavalla, ota huomioon seuraava kuvakaappaus:

En muuttanut mitään lukuun ottamatta alkuperäisen työn valitsemista. Joten putkilinjani alkaa kääntää. Perustuen tapaan, jolla olen määrittänyt muita töitä, testauksen jälkeen tapahtuu käyttöönotto.

Lopuksi voit testata putkea napsauttamalla RUN. Jos lähdekoodissa tapahtuu muutoksia viiden minuutin välein, koko putki suoritetaan.

Joten pystymme jatkuvasti asentamaan sovelluksemme testipalvelimelle käyttäjien hyväksyntätestiä (UAT) varten.

Toivottavasti olet nauttinut tämän viestin lukemisesta jatkuvassa toimituksessa. Jos sinulla on epäilyksiä, laita ne vapaasti alla olevaan kommenttiosioon ja saan vastauksen aikaisintaan.

CI / CD-putkilinjojen rakentamiseksi sinun on hallittava laaja valikoima taitoja Hallitse tarvittavat DevOps-taidot nyt