Pideva kohaletoimetamise õpetus - pideva kohaletoimetamise torujuhtme ehitamine Jenkinsi abil

Pidev kohaletoimetamine:

Pidev kohaletoimetamine on protsess, kus koodimuudatused ehitatakse automaatselt üles, testitakse ja valmistatakse tootmiseks väljaandmiseks ette.Loodan, et olete mulle meeldinud Siin räägin järgmistest teemadest:

• Mis on pidev kohaletoimetamine?
• Tarkvara testimise tüübid
• Erinevus pideva integreerimise, edastamise ja juurutamise vahel
• Mis on pideva kohaletoimetamise vajadus?
• Praktiline Jenkinsi ja Tomcati kasutamine

Andke meile kiiresti aru, kuidas pidev kohaletoimetamine töötab.

Mis on pidev kohaletoimetamine?

See on protsess, mille käigus ehitate tarkvara nii, et seda saab igal ajal tootmisse lubada.Vaatleme järgmist skeemi:

Lubage mul selgitada ülaltoodud skeemi:

• Automatiseeritud ehituskriptid tuvastavad muudatused lähtekoodihalduses (SCM) nagu Git.
• Kui muudatus on tuvastatud, paigutatakse lähtekood spetsiaalsesse koostamise serverisse, et veenduda, et ehitis ei ebaõnnestuks ning kõik testiklassid ja integreerimistestid töötavad hästi.
• Seejärel juurutatakse rakendusrakendus kasutajate aktsepteerimise testi (UAT) testiserveritesse (eelproduktsiooniserverid).
• Lõpuks juurutatakse rakendus käsitsi tootmise serveritesse vabastamiseks.

Enne kui jätkan, on õiglane, kui selgitan teile erinevaid testimistüüpe.

Tarkvara testimise tüübid:

Laias laastus on kahte tüüpi testimist:

• Blackboxi testimine: See on testimistehnika, mis ignoreerib süsteemi sisemist mehhanismi ja keskendub süsteemi sisendi ja täitmise suhtes loodud väljundile. Seda nimetatakse ka funktsionaalseks testimiseks. Põhimõtteliselt kasutatakse seda tarkvara kinnitamiseks.
• Whiteboxi testimine: on testimistehnika, mis võtab arvesse süsteemi sisemist mehhanismi. Seda nimetatakse ka struktuurikatestuseks ja klaaskarbi testimiseks. Põhimõtteliselt kasutatakse seda tarkvara kontrollimiseks.

Whiteboxi testimine:

Sellesse kategooriasse kuulub kahte tüüpi teste.

• Üksuse testimine: See on üksiku üksuse või seotud üksuste rühma testimine. Programmeerija teeb seda sageli selleks, et testida, kas tema rakendatud üksus toodab antud sisendi suhtes oodatavat väljundit.
• Integreerimise testimine: See on teatud tüüpi testimine, milles komponentide rühm onväljundi tootmiseks kombineeritult. Samuti testitakse tarkvara ja riistvara vastastikust mõju, kui tarkvara ja riistvara komponentidel on mingisugune seos. See võib kuuluda nii valge kasti kui ka musta kasti testimise alla.

Blackboxi testimine:

Sellesse kategooriasse kuulub mitu katset. Ma keskendun sellelemõni, mida on oluline teada, et sellest blogist aru saada:

• Funktsionaalne / aktsepteerimise testimine: See tagab, et süsteeminõuetes nõutav määratletud funktsionaalsus töötab. Seda tehakse veendumaks, et tarnitud toode vastab nõuetele ja töötab nii, nagu klient eeldas
• Süsteemi testimine: See tagab, et tarkvara eri keskkondadesse (nt operatsioonisüsteemidesse) paigutades see ikkagi töötab.
• Stressitestimine: Hinnatakse süsteemi käitumist ebasoodsates tingimustes.
• Beetaversioon: Seda teevad lõpptarbijad, arenduseväline meeskond või avalikustades toote täieliku eelversiooni, mis on tuntud kuibeetaversioon. Beetatestimise eesmärk on katta ootamatud vead.

Praegu on minu jaoks õige aeg selgitada vahet pideva integreerimise, edastamise ja juurutamise vahel.

Erinevused pideva integreerimise, edastamise ja juurutamise vahel:

Visuaalne sisu jõuab inimese ajju kiiremini ja arusaadavamalt kui tekstiline teave. Alustan skeemiga, mis selgitab erinevust selgelt:

Pidevas integreerimisel on iga koodi sidumine koostatud ja testitud, kuid see pole vabastamiseks vajalikus seisukorras. Ma mõtlen, et ehitusrakendust ei kasutata testiserverites automaatselt, et seda valideerida, kasutades erinevat tüüpi Blackboxi testimist, näiteks - kasutajate aktsepteerimise testimine (UAT).

installige php Windows 8-le

Pideva edastamise korral juurutatakse rakendus pidevalt UAT-i testiserveritesse. Või võite öelda, et rakendus on igal ajal tootmisse lubamiseks valmis. Seega on pideva edastamise jaoks ilmselgelt vajalik pidev integreerimine.

Pidev juurutamine on järgmine samm pideva edastamise kohal, kus te ei loo lihtsalt juurutatavat paketti, vaid juurutate seda ka automatiseeritud viisil.

Lubage mul kokku võtta erinevused tabeli abil:

Lihtsamalt öeldes on pidev integreerimine osa nii pidevast edastamisest kui ka pidevast juurutamisest. Ja pidev juurutamine on nagu pidev edastamine, välja arvatud see, et väljalasked toimuvad automaatselt.

Siit saate teada, kuidas luua CI / CD torujuhtmeid Jenkins On Cloudi abil

Kuid küsimus on selles, kas piisab pidevast integratsioonist.

Miks me vajame pidevat kohaletoimetamist?

Mõistame seda ühe näitega.

Kujutage ette, et suure projekti kallal töötab 80 arendajat. Automaatse ehitamise hõlbustamiseks kasutavad nad pideva integreerimise torujuhtmeid. Me teame, et ehitis sisaldab ka üksuste testimist. Ühel päeval otsustasid nad testikeskkonda paigutada uusima komponendi testide läbinud järgu.

See peab olema pikaajaline, kuid kontrollitud lähenemisviis kasutuselevõtule, mida nende keskkonnaspetsialistid teostasid. Näis, et süsteem ei tööta.

Mis võib olla ebaõnnestumise ilmne põhjus?

Esimene põhjus, mida enamik inimesi arvab, on see, et konfiguratsioonis on mingi probleem. Nagu enamik inimesi, isegi nemad arvasid nii.Nad veetsid palju aega, et leida, mis on keskkonna konfiguratsioonis valesti, kuid nad ei leidnud probleemi.

Üks mõistlik arendaja kasutas nutikat lähenemist:

Siis proovis üks vanemarendaja rakendust oma arendusmasinas. See ei töötanud ka seal.

Ta vaatas läbi varasemate ja varasemate versioonide, kuni leidis, et süsteem on kolm nädalat varem lakanud töötamast. Pisike, ebaselge viga oli takistanud süsteemi õiget käivitamist. Ehkki projektil oli ühikutestide katvus hea.Vaatamata sellele ei näinud 80 arendajat, kes tavaliselt töötasid ainult teste, mitte rakendust ennast, kolme nädala jooksul probleemi.

Probleemipüstituses:

Ilma et aktsepteerimisteste korraldataks tootmisesarnases keskkonnas, ei tea nad midagi selle kohta, kas rakendus vastab kliendi spetsifikatsioonidele ega sellest, kas seda saab reaalses maailmas juurutada ja ellu jääda. Kui nad soovivad nendel teemadel õigeaegset tagasisidet, peavad nad laiendama oma pideva integratsiooniprotsessi ulatust.

Lubage mul teha kokkuvõte ülaltoodud probleemidest õppides:

• Üksustestid testivad arendaja perspektiivi ainult probleemi lahendamisele. Neil on ainult piiratud võimalus tõestada, et rakendus teeb kasutaja perspektiivist seda, mida peaks. Neist ei piisateha kindlaks tegelikud funktsionaalsed probleemid.
• Rakenduse juurutamine testikeskkonda on keeruline, käsitsi intensiivne protsess, mis oli üsna altid vigadele.See tähendas, et iga kasutuselevõtu katse oli uus katse - käsitsi tehtud ja vigadele kalduv protsess.

Lahendus - pideva kohaletoimetamise torujuhe (automatiseeritud vastuvõtutest):

Nad viisid järgmise sammu juurde pideva integreerimise (pidev kohaletoimetamine) ja tutvustasid paari lihtsat, automatiseeritud vastuvõtutesti, mis tõestasid, et rakendus käitus ja suudab täita oma põhifunktsiooni.Suurem osa aktsepteerimistesti etapis toimuvatest testidest on funktsionaalsed aktsepteerimise testid.

Põhimõtteliselt ehitasid nad pideva tarnimise torujuhtme, et veenduda rakenduse sujuvas juurutamises tootmiskeskkonnas, tagades, et rakendus töötab testiserverisse juurutatuna, mis on tootmisserveri koopia.

Piisavalt teooriast, näitan teile nüüd, kuidas Jenkinsit kasutades luua pideva tarnimise torujuhe.

Jenkinsit kasutava pideva kohaletoimetamise torujuhe:

Siin kasutan Jenkinsit pideva kohaletoimetamise torujuhtme loomiseks, mis sisaldab järgmisi ülesandeid:

Demos osalevad sammud:

• Koodi toomine GitHubist
• Lähtekoodi koostamine
• Üksuse testimine ja JUniti testiaruannete genereerimine
• Pakkige rakendus WAR-faili ja juurutage see Tomcati serverisse

Eeltingimused:

• CentOS 7 masin
• Jenkins 2.121.1
• Docker
• Tomcat 7

1. samm - lähtekoodi koostamine:

Alustame kõigepealt Jenkinsis projekti Freestyle loomisega. Mõelge allpool olevale ekraanipildile:

Pange oma projektile nimi ja valige Freestyle Project:

Alla kerides leiate võimaluse lisada lähtekoodihoidla, valida git ja lisada hoidla URL. Selles hoidlas on trahv pom.xml, mida kasutame oma projekti ülesehitamiseks. Mõelge allpool olevale ekraanipildile:

Nüüd lisame järkjärgulise käivitamise. Valige küsitluse SCM valik. Põhimõtteliselt konfigureerime Jenkinsi GitHubi hoidla küsitlemiseks iga 5 minuti järel koodi muudatuste korral. Mõelge allpool olevale ekraanipildile:

Enne kui jätkan, lubage mul teile väike sissejuhatus Maven'i ehitustsüklist.

Iga ehituse elutsükkel on määratletud erineva ehitusfaaside loendiga, kusjuures ehitamisetapp tähistab elutsükli etappi.

Järgnevas loendis on koostamise etapid:

• valideerima - valideerima projekt on õige ja kogu vajalik teave on olemas
• kompileeri - kompileeri projekti lähtekood
• test - kompileeritud lähtekoodi testimine sobiva ühikutestimise raamistiku abil. Need testid ei tohiks nõuda koodi pakendamist ega juurutamist
• pakett - võtke kompileeritud kood ja pakkige see levitatavas vormingus, näiteks JAR.
• kontrollima - kontrollima integreerumistestide tulemusi, et tagada kvaliteedikriteeriumide täitmine
• install - installige pakett kohalikku hoidlasse, et kasutada seda sõltuvalt teistest projektidest
• juurutamine - tehtud ehituskeskkonnas, kopeerib lõpliku paketi kaughoidlasse teiste arendajate ja projektidega jagamiseks.

Ma saan käivitada alloleva käsu lähtekoodi koostamiseks, üksuse testimiseks ja isegi rakenduse pakkimiseks sõjafaili:

mvn puhas pakend

Samuti saate oma ehitustöö jaotada mitmeks järkuks. See hõlbustab järkude korraldamist puhtates ja eraldi etappides.

Nii alustame lähtekoodi koostamisest. Klõpsake vahekaardil Ehitamine käsku ülemise taseme maven-sihtmärkide kutsumine ja tippige järgmine käsk:

koostama

Mõelge allpool olevale ekraanipildile:

See tõmbab lähtekoodi GitHubi hoidlast ja kompileerib selle ka (Maven Compile Phase).

Klõpsake nuppu Salvesta ja käivita projekt.

Nüüd klõpsake tulemuse nägemiseks konsooli väljundil.

2. samm - üksuse testimine:

Nüüd loome üksuse testimiseks veel ühe Freestyle'i projekti.

Lisage vahekaardile lähtekoodi haldamise sama hoidla URL, nagu me tegime eelmises töös.

Klõpsake vahekaardil „Buid Trigger” nuppu „Koosta pärast teiste projektide ehitamist”. Seal sisestage eelmise projekti nimi, kus me lähtekoodi koostame, ja saate valida mis tahes järgmistest valikutest:

• Käivitage ainult siis, kui järk on stabiilne
• Käivitage isegi siis, kui järk on ebastabiilne
• Käivitage ka siis, kui ehitamine ebaõnnestub

Ma arvan, et ülaltoodud valikud on üsna iseenesestmõistetavad, nii et valige üks neist. Mõelge allpool olevale ekraanipildile:

Klõpsake vahekaardil Ehitamine käsku ülemise taseme maven-sihtmärkide kutsumine ja kasutage järgmist käsku:

test

Jenkins teeb ka suurepärast tööd, aidates kuvada oma testitulemusi ja testitulemuste suundumusi.

Java-testide aruandluse de facto standard on XML-vorming, mida JUnit kasutab. Seda vormingut kasutavad ka paljud teised Java testimistööriistad, näiteks TestNG, Spock ja Easyb. Jenkins saab sellest vormingust aru, nii et kui teie ehitis annab JUniti XML-testi tulemused, saab Jenkins aja jooksul genereerida toredaid graafilisi katsearuandeid ja statistikat testitulemuste kohta ning lasta teil vaadata ka kõigi testide tõrkeid. Jenkins jälgib ka seda, kui kaua teie testide käivitamine võtab aega nii kogu maailmas kui ka testi kohta - see võib olla kasulik, kui peate jõudlusprobleemidele jälile jõudma.

Nii et järgmine asi, mida peame tegema, on panna Jenkins hoidma meie üksuste testide vahelehti.

Minge jaotisse Koostamisjärgsed toimingud ja märkige ruut „Avalda JUniti testi tulemuste aruanne”. Kui Maven käivitab projektis üksustestid, genereerib ta XML-testiaruanded kataloogis nimega surefire-reports. Seega sisestage väljale „Test report XMLs” „** / target / surefire-reports / *. Xml”. Kaks tähte tee alguses (“**”) on parim tava konfiguratsiooni natuke kindlamaks muutmiseks: need võimaldavad Jenkinsil leida sihtkataloog olenemata sellest, kuidas oleme Jenkinsit lähtekoodi kontrollimiseks seadistanud.

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

Jällegi salvestage see ja klõpsake nuppu Ehita kohe.

Nüüd on JUniti aruanne kirjutatud kataloogi / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

Jenkinsi armatuurlaualvõite märgata ka testi tulemusi:

Samm - 3 WAR-faili loomine ja Tomcati serveri juurutamine:

Järgmine samm on pakkida meie rakendus WAR-faili ja juurutada see Tomcati serverisse kasutajate aktsepteerimise testimiseks.

Looge veel üks freestyle-projekt ja lisage lähtekoodi hoidla URL.

Seejärel valige ehituse päästiku vahekaardil ehitis, kui muud projektid on koostatud, kaaluge järgmist ekraanipilti:

Põhimõtteliselt algab pärast testimist juurutamisetapp automaatselt.

Valige vahekaardil ehitus shelliskript. Rakenduse WAR-faili pakkimiseks tippige järgmine käsk:

mvn pakett

Järgmine samm on selle WAR-faili juurutamine Tomcatiserver. Vahekaardil „Ehitamise järgsed toimingud” valige konteinerile sõda / kõrv. Siin saate sõjafaili tee ja kontekstitee. Mõelge allpool olevale ekraanipildile:

Valige Tomcati mandaat ja märkage ülaltoodud ekraanipilti. Samuti peate andma oma Tomcati serveri URL-i.

Jenkinsis mandaatide lisamiseks klõpsake Jenkinsi juhtpaneelil valikut Mandaadid.

Klõpsake nuppu Süsteem ja valige globaalsed mandaadid.

Siis leiate mandaatide lisamise võimaluse. Klõpsake seda ja lisage mandaat.

Lisage Tomcati mandaat, kaaluge allolevat ekraanipilti.

Klõpsake nuppu OK.

Nüüd oma projekti konfiguratsioonis lisage eelmises etapis sisestatud kiisu mandaadid.

Klõpsake nuppu Salvesta ja valige seejärel Ehita kohe.

Minge oma kiisu URL-ile koos kontekstiteega, minu puhul on see http: // localhost: 8081. Nüüd lisage lõpuks kontekstitee, kaaluge järgmist ekraanipilti:

Link - http: // localhost: 8081 / gof

Loodan, et olete mõistnud kontekstitee tähendust.

Nüüd looge torujuhtme vaade, kaaluge järgmist ekraanipilti:

Uue vaate loomiseks klõpsake plussikoonil.

Konfigureerige torujuhe soovitud viisil, kaaluge järgmist ekraanipilti:

Ma ei muutnud midagi peale algtöö valimise. Nii et minu torujuhe algab kompileerimisest. Selle põhjal, kuidas olen teisi töid konfigureerinud, toimub pärast kompileerimist testimine ja juurutamine.

Lõpuks saate proovida gaasijuhet, klõpsates käsku RUN. Lähtekoodi muutmise korral viiakse iga viie minuti järel läbi kogu torujuhe.

Seega oleme võimelised oma rakendust pidevalt kasutama testimisserveris kasutajate aktsepteerimise testi (UAT) jaoks.

Loodan, et teile on meeldinud seda postitust pideva kohaletoimetamise kohta lugeda. Kui teil on kahtlusi, pange need julgelt allpool olevasse kommentaaride jaotisesse ja ma saan vastuse tagasi kõige varem.

CI / CD torujuhtmete ehitamiseks peate valdama mitmesuguseid oskusi Nüüd omandage nõutavad DevOps-i oskused