Nepārtrauktas piegādes apmācība - nepārtrauktas piegādes cauruļvada izveide, izmantojot Jenkins

Nepārtraukta piegāde:

Nepārtraukta piegāde ir process, kurā koda izmaiņas tiek automātiski izveidotas, pārbaudītas un sagatavotas izlaišanai ražošanai.Es ceru, ka jūs esat izbaudījis manu Šeit es runāšu par šādām tēmām:

• Kas ir nepārtraukta piegāde?
• Programmatūras testēšanas veidi
• Atšķirība starp nepārtrauktu integrāciju, piegādi un ieviešanu
• Kāda ir nepārtrauktas piegādes nepieciešamība?
• Hands-on, izmantojot Jenkins un Tomcat

Ļaujiet mums ātri saprast, kā darbojas nepārtraukta piegāde.

Kas ir nepārtraukta piegāde?

Tas ir process, kurā programmatūru veidojat tā, lai to jebkurā laikā varētu izlaist ražošanā.Apsveriet šo diagrammu:

Ļaujiet man paskaidrot iepriekš minēto diagrammu:

• Automātiski veidoti skripti atklās izmaiņas pirmkodu pārvaldībā (SCM), piemēram, Git.
• Tiklīdz izmaiņas ir atklātas, pirmkods tiks izvietots īpašā būvēšanas serverī, lai pārliecinātos, ka būvēšana neizdodas un vai visas testa klases un integrācijas testi darbojas labi.
• Pēc tam būvēšanas lietojumprogramma tiek izvietota testa serveros (pirmsražošanas serveros) lietotāju pieņemšanas testam (UAT).
• Visbeidzot, programma tiek manuāli izvietota ražošanas serveros izlaišanai.

Pirms es turpināšu, būs tikai godīgi, es jums izskaidrošu dažādos testēšanas veidus.

Programmatūras testēšanas veidi:

Kopumā ir divu veidu testi:

• Blackbox testēšana: Tā ir testēšanas tehnika, kas ignorē sistēmas iekšējo mehānismu un koncentrējas uz ģenerēto izvadi pret jebkuru sistēmas ievadi un izpildi. To sauc arī par funkcionālo testēšanu. To galvenokārt izmanto programmatūras validēšanai.
• Whitebox testēšana: ir testēšanas tehnika, kurā tiek ņemts vērā sistēmas iekšējais mehānisms. To sauc arī par strukturālo testēšanu un stikla kastes testēšanu. To galvenokārt izmanto programmatūras pārbaudei.

Whitebox testēšana:

Šajā kategorijā ietilpst divu veidu testi.

• Vienības testēšana: Tas ir atsevišķas vienības vai saistītu vienību grupas pārbaude. Programmētājs to bieži veic, lai pārbaudītu, vai vienība, kuru viņš / viņa ir ieviesis, rada paredzamo produkciju pret doto ievadi.
• Integrācijas testēšana: Tas ir pārbaudes veids, kurā ietilpst sastāvdaļu grupakopā, lai iegūtu produkciju. Arī programmatūras un aparatūras mijiedarbība tiek pārbaudīta, ja programmatūras un aparatūras komponentiem ir kāda saistība. Uz to var attiecināt gan baltās kastes, gan melnās kastes testēšanu.

Blackbox testēšana:

Šajā kategorijā ietilpst vairāki testi. Es pievērsīšosdaži, kas jums ir svarīgi zināt, lai saprastu šo emuāru:

• Funkcionālā / pieņemšanas pārbaude: Tas nodrošina, ka darbojas sistēmas prasībās norādītā funkcionalitāte. Tas tiek darīts, lai pārliecinātos, ka piegādātais produkts atbilst prasībām un darbojas tā, kā klients gaidīja
• Sistēmas testēšana: Tas nodrošina, ka, programmatūru ievietojot dažādās vidēs (piemēram, operētājsistēmās), tā joprojām darbojas.
• Stresa testēšana: Tas novērtē, kā sistēma izturas nelabvēlīgos apstākļos.
• Beta testēšana: To veic galalietotāji, komanda, kas nav izstrāde, vai publiski izlaiž pilnu produkta iepriekšēju versiju, kas pazīstama kābeta versijaversija. Beta testēšanas mērķis ir aptvert neparedzētas kļūdas.

Man ir īstais laiks, lai izskaidrotu atšķirību starp nepārtrauktu integrāciju, piegādi un ieviešanu.

Atšķirības starp nepārtrauktu integrāciju, piegādi un ieviešanu:

Vizuālais saturs cilvēka smadzenēs nonāk ātrāk un saprotamāk nekā teksta informācija. Tāpēc es sākšu ar diagrammu, kas skaidri izskaidro atšķirību:

Nepārtrauktā integrācijā katrs koda apņemšanās tiek veidots un pārbaudīts, taču tas nav tādā stāvoklī, lai to varētu izlaist. Es domāju, ka būvēšanas lietojumprogramma netiek automātiski izvietota testa serveros, lai to validētu, izmantojot dažādus Blackbox testēšanas veidus, piemēram - User Acceptance Testing (UAT).

Nepārtrauktā piegādē lietojumprogramma tiek nepārtraukti izvietota UAT testa serveros. Vai arī varat teikt, ka lietojumprogramma ir gatava izlaišanai jebkurā laikā. Tātad, acīmredzot, nepārtrauktai piegādei ir nepieciešama nepārtraukta integrācija.

Nepārtraukta izvietošana ir nākamais solis pāri nepārtrauktai piegādei, kur jūs izveidojat ne tikai izvietojamu paketi, bet faktiski to izvietojat automatizēti.

Ļaujiet man apkopot atšķirības, izmantojot tabulu:

Vienkārši sakot, nepārtraukta integrācija ir gan nepārtrauktas piegādes, gan nepārtrauktas ieviešanas sastāvdaļa. Nepārtraukta izvietošana ir kā nepārtraukta piegāde, izņemot to, ka izlaišana notiek automātiski.

Uzziniet, kā izveidot CI / CD cauruļvadus, izmantojot Jenkins On Cloud

Bet jautājums ir, vai pietiek ar nepārtrauktu integrāciju.

Kāpēc mums nepieciešama nepārtraukta piegāde?

Ļaujiet mums to saprast ar piemēru.

Iedomājieties, ka pie liela projekta strādā 80 izstrādātāji. Viņi izmanto nepārtrauktas integrācijas cauruļvadus, lai atvieglotu automatizētu būvēšanu. Mēs zinām, ka uzbūve ietver arī vienības testēšanu. Kādu dienu viņi nolēma testa vidē izvietot jaunāko versiju, kas bija izturējusi vienības testus.

Tam jābūt ilgstošai, bet kontrolētai pieejai izvietošanai, ko veica viņu vides speciālisti. Tomēr šķiet, ka sistēma nedarbojās.

Kāds varētu būt acīmredzamais neveiksmes cēlonis?

Pirmais iemesls, kāpēc lielākā daļa cilvēku domās, ir tāds, ka konfigurācijā ir problēmas. Tāpat kā lielākajai daļai cilvēku, arī viņi tā domāja.Viņi pavadīja daudz laika, mēģinot atrast to, kas ir nepareizi vides konfigurācijā, taču nevarēja atrast problēmu.

Viens uztverošs izstrādātājs izmantoja gudru pieeju:

Tad viens no vecākajiem izstrādātājiem izmēģināja lietojumprogrammu savā izstrādes mašīnā. Arī tur tas nedarbojās.

Viņš atkāpās no iepriekšējās un iepriekšējās versijas, līdz atklāja, ka sistēma pārtrauca darboties trīs nedēļas agrāk. Sīkā, neskaidra kļūda bija kavējusi sistēmas pareizu palaišanu. Lai gan projektam bija labs vienības testa pārklājums.Neskatoties uz to, 80 izstrādātāji, kuri parasti veica tikai testus, nevis pašu lietojumprogrammu, trīs nedēļas neredzēja problēmu.

Problēmas izklāsts:

Neveicot pieņemšanas testus produkcijai līdzīgā vidē, viņi neko nezina ne par to, vai lietojumprogramma atbilst klienta specifikācijām, ne arī to, vai to var izvietot un izdzīvot reālajā pasaulē. Ja viņi vēlas savlaicīgu atgriezenisko saiti par šīm tēmām, viņiem jāpaplašina nepārtraukta integrācijas procesa diapazons.

Ļaujiet man apkopot gūtās mācības, aplūkojot iepriekš minētās problēmas:

• Vienības testi pārbauda tikai izstrādātāja viedokli par problēmas risinājumu. Viņiem ir tikai ierobežotas iespējas pierādīt, ka lietojumprogramma no lietotāja viedokļa dara to, kas tam paredzēts. Ar tiem nepietiekidentificēt reālās funkcionālās problēmas.
• Lietotnes izvietošana testa vidē ir sarežģīts, manuāli intensīvs process, kas bija diezgan pakļauts kļūdām.Tas nozīmēja, ka katrs izvietošanas mēģinājums bija jauns eksperiments - manuāls, kļūdām pakļauts process.

Risinājums - nepārtrauktas piegādes cauruļvads (automatizēts pieņemšanas tests):

Viņi pārņēma nepārtrauktu integrāciju (nepārtraukta piegāde) uz nākamo soli un ieviesa pāris vienkāršus, automatizētus pieņemšanas testus, kas pierādīja, ka lietojumprogramma darbojās un varēja veikt visbūtiskāko funkciju.Lielākā daļa testu, kas tiek veikti pieņemšanas testa posmā, ir funkcionālie pieņemšanas testi.

Būtībā viņi izveidoja nepārtrauktas piegādes cauruļvadu, lai pārliecinātos, ka lietojumprogramma tiek vienmērīgi izvietota ražošanas vidē, pārliecinoties, ka lietojumprogramma darbojas labi, ja tā tiek izvietota testa serverī, kas ir ražošanas servera kopija.

Pietiekami daudz no teorijas, tagad es jums parādīšu, kā izveidot nepārtrauktas piegādes cauruļvadu, izmantojot Jenkins.

Nepārtrauktas piegādes cauruļvads, izmantojot Jenkins:

Šeit es izmantošu Jenkins, lai izveidotu nepārtrauktas piegādes cauruļvadu, kas ietvers šādus uzdevumus:

Demonstrācijā iesaistītie soļi:

• Notiek koda iegūšana no GitHub
• Avota koda sastādīšana
• Vienības testēšana un JUnit testa ziņojumu ģenerēšana
• Pakotnes iesaiņošana WAR failā un izvietošana Tomcat serverī

Priekšnosacījumi:

• CentOS 7 mašīna
• Dženkinss 2.121.1
• Dokers
• Runcis 7

1. darbība. Avota koda apkopošana:

Sāksim, vispirms izveidojot projektu Freestyle Dženkinsā. Apsveriet šo ekrānuzņēmumu:

Piešķiriet savam projektam nosaukumu un atlasiet Freestyle Project:

kas ir instances mainīgais Java

Ritinot uz leju, jūs atradīsit iespēju pievienot pirmkodu krātuvi, atlasīt git un pievienot krātuves URL, šajā krātuvē ir naudas sods pom.xml, kuru mēs izmantosim, lai izveidotu savu projektu. Apsveriet šo ekrānuzņēmumu:

Tagad mēs pievienosim veidošanas aktivizētāju. Izvēlieties opciju aptaujas SCM. Būtībā mēs konfigurēsim Jenkins, lai pēc katrām 5 minūtēm veiktu GitHub repozitorija aptauju par izmaiņām kodā. Apsveriet šo ekrānuzņēmumu:

Pirms es turpinu, ļaujiet man jums iepazīstināt ar Maven Build ciklu.

Katru no būvēšanas dzīves cikliem nosaka atšķirīgs būvniecības fāžu saraksts, kur būvēšanas fāze ir dzīves cikla posms.

Šis ir būvniecības fāžu saraksts:

• apstiprināt - apstiprināt, ka projekts ir pareizs, un ir pieejama visa nepieciešamā informācija
• kompilēt - sastādīt projekta pirmkodu
• tests - pārbaudiet apkopoto pirmkodu, izmantojot piemērotu vienības testēšanas sistēmu. Šiem testiem nevajadzētu prasīt koda iesaiņošanu vai izvietošanu
• pakete - paņemiet apkopoto kodu un iesaiņojiet to izplatāmajā formātā, piemēram, JAR.
• pārbaudīt - veikt visas integrācijas testu rezultātu pārbaudes, lai pārliecinātos, ka tiek izpildīti kvalitātes kritēriji
• instalēt - instalējiet pakotni vietējā repozitorijā, lai to izmantotu kā atkarību no citiem lokāliem projektiem
• izvietot - izdarīts būvēšanas vidē, kopē galīgo pakotni uz attālo repozitoriju, lai koplietotu ar citiem izstrādātājiem un projektiem.

Es varu izpildīt šo komandu avota koda apkopošanai, vienības testēšanai un pat lietojumprogrammas iesaiņošanai kara failā:

mvn tīrs iepakojums

Varat arī sadalīt būvēšanas darbu vairākos būvēšanas posmos. Tas atvieglo būvju organizēšanu tīros, atsevišķos posmos.

Tātad mēs sāksim ar avota koda apkopošanu. Cilnē Izveidot noklikšķiniet uz izsaukt augstākā līmeņa savainotos mērķus un ierakstiet zemāk esošo komandu:

sastādīt

Apsveriet šo ekrānuzņēmumu:

Tas izvilks avota kodu no GitHub repozitorija un arī to kompilēs (Maven Compile Phase).

Noklikšķiniet uz Saglabāt un palaidiet projektu.

Tagad noklikšķiniet uz konsoles izejas, lai redzētu rezultātu.

2. solis - vienības pārbaude:

Tagad mēs izveidosim vēl vienu Freestyle projektu vienību testēšanai.

Cilnē avota koda pārvaldība pievienojiet to pašu krātuves URL, tāpat kā mēs to darījām iepriekšējā darbā.

Tagad cilnē “Buid Trigger” noklikšķiniet uz “veidot pēc citu projektu izveides”. Tur ierakstiet iepriekšējā projekta nosaukumu, kurā mēs apkopojam pirmkodu, un jūs varat izvēlēties jebkuru no šīm opcijām:

• Aktivizēt tikai tad, ja uzbūve ir stabila
• Aktivizēt pat tad, ja uzbūve ir nestabila
• Aktivizēt pat tad, ja būvēšana neizdodas

Es domāju, ka iepriekš minētās iespējas ir diezgan pašsaprotamas, tāpēc atlasiet jebkuru. Apsveriet šo ekrānuzņēmumu:

Cilnē Izveidot noklikšķiniet uz izsaukt augstākā līmeņa savainotos mērķus un izmantojiet zemāk esošo komandu:

pārbaude

Jenkins arī lieliski strādā, palīdzot jums parādīt testa rezultātus un testa rezultātu tendences.

De facto testa pārskatu standarts Java pasaulē ir XML formāts, ko izmanto JUnit. Šo formātu izmanto arī daudzi citi Java testēšanas rīki, piemēram, TestNG, Spock un Easyb. Jenkins saprot šo formātu, tādēļ, ja jūsu būvējums rada JUnit XML testa rezultātus, Jenkins laika gaitā var ģenerēt jaukus grafiskos testu pārskatus un statistiku par testa rezultātiem, kā arī ļaut jums apskatīt detalizētu informāciju par visām testēšanas kļūmēm. Jenkins arī seko tam, cik ilgi jūsu testi jāveic, gan visā pasaulē, gan katrā testā - tas var būt noderīgi, ja jums jānoskaidro veiktspējas problēmas.

Tāpēc nākamā lieta, kas mums jādara, ir panākt, lai Jenkins uzturētu cilnes mūsu vienību testos.

Atveriet sadaļu Post-build Actions un atzīmējiet izvēles rūtiņu “Publicēt JUnit testa rezultātu pārskatu”. Kad Maven izpilda vienības testus projektā, tas automātiski ģenerē XML testa ziņojumus direktorijā, ko sauc par surefire-reports. Tāpēc laukā “Test report XMLs” ievadiet “** / target / surefire-reports / *. Xml”. Divas zvaigznītes ceļa sākumā (“**”) ir labākā prakse, lai konfigurāciju padarītu mazliet izturīgāku: tie ļauj Jenkinsam atrast mērķa direktoriju neatkarīgi no tā, kā mēs esam konfigurējuši Jenkins, lai pārbaudītu avota kodu.

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

Atkal saglabājiet to un noklikšķiniet uz Izveidot tūlīt.

Tagad JUnit ziņojums ir rakstīts uz / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

Jenkins informācijas panelījūs varat arī pamanīt testa rezultātus:

3. solis - WAR faila izveide un izvietošana Tomcat serverī:

Nākamais solis ir iesaiņot mūsu lietojumprogrammu WAR failā un izvietot to Tomcat serverī, lai pārbaudītu lietotāju pieņemšanu.

Izveidojiet vēl vienu frīstaila projektu un pievienojiet avota koda repozitorija URL.

Pēc tam cilnē build trigeris atlasiet build, kad tiek veidoti citi projekti, apsveriet šo ekrānuzņēmumu:

Būtībā pēc pārbaudes darba izvietošanas fāze sāksies automātiski.

Cilnē Izveide atlasiet čaulas skriptu. Ierakstiet zemāk esošo komandu, lai programmu iesaiņotu WAR failā:

mvn pakete

Nākamais solis ir šī WAR faila izvietošana Tomcatserveris. Cilnē “Post-Build Actions” atlasiet izvietot war / ear konteinerā. Šeit norādiet ceļu uz kara failu un norādiet konteksta ceļu. Apsveriet šo ekrānuzņēmumu:

Atlasiet Tomcat akreditācijas datus un ievērojiet iepriekš redzamo ekrānuzņēmumu. Turklāt jums jānorāda sava Tomcat servera URL.

Lai pievienotu akreditācijas datus Jenkins, noklikšķiniet uz akreditācijas opcijas Jenkins informācijas panelī.

Noklikšķiniet uz Sistēma un atlasiet globālos akreditācijas datus.

Tad jūs atradīsit iespēju pievienot akreditācijas datus. Noklikšķiniet uz tā un pievienojiet akreditācijas datus.

Pievienojiet Tomcat akreditācijas datus, apsveriet šo ekrānuzņēmumu.

Noklikšķiniet uz Labi.

Tagad projekta konfigurācijā pievienojiet runas akreditācijas datus, kurus esat ievietojis iepriekšējā darbībā.

Noklikšķiniet uz Saglabāt un pēc tam atlasiet Izveidot tūlīt.

Dodieties uz sava runča URL ar konteksta ceļu, manā gadījumā tas ir http: // localhost: 8081. Tagad beigās pievienojiet konteksta ceļu, apsveriet tālāk redzamo ekrānuzņēmumu:

Saite - http: // localhost: 8081 / gof

Es ceru, ka jūs esat sapratis konteksta ceļa nozīmi.

Tagad izveidojiet cauruļvada skatu, apsveriet šo ekrānuzņēmumu:

Noklikšķiniet uz pluszīmes ikonas, lai izveidotu jaunu skatu.

Konfigurējiet cauruļvadu tā, kā vēlaties, apsveriet šo ekrānuzņēmumu:

Es neko nemainīju, izņemot sākotnējā darba izvēli. Tātad mans cauruļvads sāksies no apkopošanas. Pamatojoties uz veidu, kā esmu konfigurējis citus darbus, pēc kompilēšanas notiks testēšana un izvietošana.

Visbeidzot, jūs varat pārbaudīt cauruļvadu, noklikšķinot uz RUN. Pēc avota koda izmaiņām ik pēc piecām minūtēm tiks izpildīts viss cauruļvads.

Tātad mēs varam nepārtraukti izvietot mūsu lietojumprogrammu testa serverī lietotāju pieņemšanas testam (UAT).

Es ceru, ka jums patika lasīt šo ziņu par nepārtrauktu piegādi. Ja jums ir kādas šaubas, nekautrējieties tos ievietot zemāk esošajā komentāru sadaļā, un es atgriezīšos ar atbildi ne ātrāk kā agrāk.

Lai izveidotu CI / CD cauruļvadus, jums jāapgūst dažādas prasmes Apgūt nepieciešamās DevOps prasmes tūlīt