Nuolatinio pristatymo pamoka - nuolatinio pristatymo dujotiekio sukūrimas naudojant „Jenkins“

Nuolatinis pristatymas:

Nuolatinis pristatymas yra procesas, kai kodo pakeitimai automatiškai sukuriami, išbandomi ir paruošiami išleidimui į gamybą.Tikiuosi, kad man patiko Čia aš kalbėsiu šiomis temomis:

• Kas yra nuolatinis pristatymas?
• Programinės įrangos testavimo tipai
• Skirtumas tarp nuolatinės integracijos, pristatymo ir diegimo
• Koks yra nuolatinio pristatymo poreikis?
• Praktinis Jenkins ir Tomcat naudojimas

Leiskite mums greitai suprasti, kaip veikia nuolatinis pristatymas.

Kas yra nuolatinis pristatymas?

Tai procesas, kai jūs kuriate programinę įrangą taip, kad ją būtų galima bet kada išleisti į gamybą.Apsvarstykite toliau pateiktą diagramą:

kaip pakeisti skaičių python

Leiskite man paaiškinti aukščiau pateiktą diagramą:

• Automatiniai kūrimo scenarijai aptiks „Source Code Management“ (SCM), pvz., „Git“, pokyčius.
• Aptikus pakeitimą, šaltinio kodas bus dislokuotas dedikuotame kūrimo serveryje, kad įsitikintumėte, jog sukūrimas nepavyksta, o visos bandymų klasės ir integracijos testai veikia gerai.
• Tada kaupiamoji programa yra dislokuota bandomuosiuose serveriuose (išankstinės gamybos serveriuose), kad būtų galima atlikti vartotojo priėmimo testą (UAT).
• Galiausiai, programa išleidžiama rankiniu būdu į gamybos serverius.

Prieš tęsdamas, bus teisinga tik paaiškinti jums skirtingus bandymų tipus.

Programinės įrangos testavimo tipai:

Apskritai yra du bandymų tipai:

• „Blackbox“ testavimas: Tai yra testavimo technika, ignoruojanti sistemos vidinį mechanizmą ir sutelkianti dėmesį į sugeneruotą produkciją, palyginti su bet kokia sistemos įvestimi ir vykdymu. Tai dar vadinama funkciniu testavimu. Iš esmės jis naudojamas programinei įrangai patvirtinti.
• „Whitebox“ testavimas: yra testavimo technika, kurioje atsižvelgiama į sistemos vidinį mechanizmą. Tai taip pat vadinama konstrukciniu bandymu ir stiklo dėžutės testavimu. Iš esmės jis naudojamas programinei įrangai patikrinti.

„Whitebox“ testavimas:

Šiai kategorijai priskiriami dviejų tipų bandymai.

• Vieneto testavimas: Tai atskiro vieneto ar susijusių vienetų grupės testavimas. Programuotojas dažnai tai daro norėdamas patikrinti, ar jo / jos įdiegtas vienetas sukuria laukiamą rezultatą, palyginti su nurodytu įėjimu.
• Integracijos testavimas: Tai yra bandymo tipas, kurio metu yra sudedamųjų dalių grupėkartu gaminant produkciją. Taip pat bandoma programinės ir aparatinės įrangos sąveika, jei programinės ir aparatinės įrangos komponentai turi kokį nors ryšį. Tai gali būti tiek baltos, tiek juodos dėžės bandymai.

„Blackbox“ testavimas:

Šiai kategorijai priskiriami keli bandymai. Aš sutelksiu dėmesįkeletas, kuriuos svarbu žinoti, kad suprastumėte šį tinklaraštį:

• Funkcinis / priimtinumo testavimas: Tai užtikrina, kad veiktų nurodytos sistemos reikalavimams keliamos funkcijos. Tai daroma siekiant įsitikinti, kad pristatytas produktas atitinka reikalavimus ir veikia taip, kaip tikėjosi klientas
• Sistemos testavimas: Tai užtikrina, kad įdėjus programinę įrangą į skirtingas aplinkas (pvz., Operacines sistemas), ji vis tiek veikia.
• Streso testavimas: Vertinama, kaip sistema elgiasi nepalankiomis sąlygomis.
• Beta testavimas: Tai daro galutiniai vartotojai, komanda, kurianti kūrinius, arba viešai išleisdama visą išankstinę produkto versiją, vadinamąbeta versijaversija. Beta testavimo tikslas - apimti netikėtas klaidas.

Dabar man tinkamas laikas paaiškinti skirtumą tarp nuolatinės integracijos, pristatymo ir diegimo.

Nuolatinės integracijos, pristatymo ir diegimo skirtumai:

Vaizdinis turinys individo smegenis pasiekia greičiau ir suprantamiau nei tekstinė informacija. Taigi aš pradėsiu nuo diagramos, kurioje aiškiai paaiškinamas skirtumas:

Vykdant nuolatinę integraciją, kiekvienas kodo įsipareigojimas yra sukurtas ir išbandytas, tačiau nėra tokios būklės, kad jį būtų galima išleisti. Aš turiu omenyje, kad kaupiamoji programa nėra automatiškai diegiama bandomuosiuose serveriuose, norint ją patvirtinti naudojant įvairius „Blackbox“ testavimo tipus, pvz., „Vartotojo priėmimo testavimas“ (UAT).

Nuolatinio pristatymo metu programa nuolat diegiama UAT bandomuosiuose serveriuose. Arba galite pasakyti, kad paraiška yra parengta bet kada išleisti į gamybą. Taigi, akivaizdu, kad nepertraukiamam pristatymui būtina nuolatinė integracija.

Nuolatinis diegimas yra kitas žingsnis už nuolatinio pristatymo, kai kuriate ne tik diegiamą paketą, bet iš tikrųjų jį diegiate automatizuotai.

Leiskite apibendrinti skirtumus naudodamasis lentele:

Paprasčiau tariant, nuolatinė integracija yra tiek nuolatinio pristatymo, tiek nuolatinio diegimo dalis. Nuolatinis diegimas yra panašus į nuolatinį pristatymą, išskyrus tai, kad leidimai vyksta automatiškai.

Sužinokite, kaip sukurti CI / CD vamzdynus naudojant „Jenkins On Cloud“

Tačiau kyla klausimas, ar pakanka nuolatinės integracijos.

Kodėl mums reikia nuolatinio pristatymo?

Supraskime tai su pavyzdžiu.

Įsivaizduokite, kad prie didelio projekto dirba 80 kūrėjų. Jie naudojasi nuolatinės integracijos vamzdynais, kad palengvintų automatizuotą statybą. Mes žinome, kad „build“ apima ir „Unit Testing“. Vieną dieną jie nusprendė įdiegti naujausią versiją, kuri išlaikė vieneto testus, į bandymų aplinką.

Tai turi būti ilgas, bet kontroliuojamas požiūris į dislokavimą, kurį atliko jų aplinkos specialistai. Tačiau panašu, kad sistema neveikė.

Kokia gali būti akivaizdi gedimo priežastis?

Na, pirmoji priežastis, dėl kurios dauguma žmonių pagalvos, yra ta, kad yra tam tikrų konfigūracijos problemų. Kaip ir dauguma žmonių, net jie taip manė.Jie praleido daug laiko, bandydami išsiaiškinti, kas yra neteisinga aplinkos konfigūracijoje, tačiau negalėjo rasti problemos.

Vienas suvokiantis kūrėjas pasirinko protingą požiūrį:

Tada vienas iš vyresniųjų kūrėjų išbandė programą savo kūrimo mašinoje. Tai neveikė ir ten.

Jis grįžo prie ankstesnių ir ankstesnių versijų, kol nustatė, kad sistema nustojo veikti trimis savaitėmis anksčiau. Maža, neaiški klaida neleido sistemai tinkamai paleisti. Nors projektas turėjo gerą bandymo aprėptį.Nepaisant to, 80 kūrėjų, kurie paprastai vykdė tik testus, o ne pačią programą, problemos nematė tris savaites.

Problemos pareiškimas:

Nevykdydami priėmimo testų į gamybą panašioje aplinkoje, jie nieko nežino nei apie tai, ar programa atitinka kliento specifikacijas, nei apie tai, ar ją galima įdiegti ir išgyventi realiame pasaulyje. Jei jie nori laiku gauti atsiliepimų šiomis temomis, jie turi išplėsti savo nuolatinio integracijos proceso diapazoną.

Leiskite apibendrinti išmoktas pamokas, apžvelgiant pirmiau minėtas problemas:

• „Unit Tests“ išbando tik kūrėjo požiūrį į problemos sprendimą. Jie turi tik ribotas galimybes įrodyti, kad programa iš vartotojo perspektyvos daro tai, ko turėtų. Jų nepakankanustatyti tikrąsias funkcines problemas.
• Programos diegimas bandymo aplinkoje yra sudėtingas, rankiniu būdu intensyvus procesas, kuris buvo gana linkęs į klaidas.Tai reiškė, kad kiekvienas bandymas diegti buvo naujas eksperimentas - rankinis, į klaidas linkęs procesas.

Sprendimas - nuolatinio tiekimo vamzdynas (automatinis priėmimo testas):

Jie žengė nuolatinę integraciją (nuolatinį pristatymą) į kitą žingsnį ir pristatė keletą paprastų, automatizuotų priėmimo testų, kurie įrodė, kad programa veikia ir gali atlikti savo pagrindinę funkciją.Dauguma bandymų, atliekamų priėmimo testo etape, yra funkcinio priėmimo testai.

Iš esmės jie sukūrė nuolatinio pristatymo vamzdyną, siekdami įsitikinti, kad programa yra sklandžiai įdiegta gamybos aplinkoje, įsitikindami, kad programa veikia gerai, kai ji yra įdiegta bandymo serveryje, kuris yra gamybos serverio kopija.

Užteks teorijos, dabar aš jums parodysiu, kaip sukurti nepertraukiamo pristatymo vamzdyną naudojant Jenkins.

Nuolatinio tiekimo dujotiekis naudojant „Jenkins“:

Čia naudosiu „Jenkins“ kurdamas nepertraukiamo pristatymo vamzdyną, kuris apims šias užduotis:

Demonstraciniai veiksmai:

• Gaunamas kodas iš „GitHub“
• Šaltinio kodo sudarymas
• Įrenginių testavimas ir „JUnit“ bandymų ataskaitų generavimas
• Programos supakavimas į WAR failą ir diegimas „Tomcat“ serveryje

Išankstinės sąlygos:

• „CentOS 7“ mašina
• Jenkinsas 2.121.1
• Dokeris
• „Tomcat“ 7

1 veiksmas - šaltinio kodo sudarymas:

Pradėkime pirmiausia sukurdami „Freestyle“ projektą Jenkins. Apsvarstykite toliau pateiktą ekrano kopiją:

Pavadinkite savo projektą ir pasirinkite „Freestyle Project“:

Slinkdami žemyn rasite galimybę pridėti šaltinio kodo saugyklą, pasirinkti git ir pridėti saugyklos URL, toje saugykloje yra bauda pom.xml, kurią naudosime kurdami savo projektą. Apsvarstykite toliau pateiktą ekrano kopiją:

Dabar pridėsime „Build Trigger“. Pasirinkite apklausos SCM parinktį. Iš esmės sukonfigūruosime „Jenkins“ kas 5 minutes apklausiant „GitHub“ saugyklą, jei pasikeis kodas. Apsvarstykite toliau pateiktą ekrano kopiją:

Prieš tęsdamas, leiskite jums šiek tiek supažindinti su „Maven Build Cycle“.

Kiekvieną kūrimo gyvavimo ciklą apibrėžia skirtingas kūrimo etapų sąrašas, kur komponavimo etapas reiškia gyvenimo ciklo etapą.

Toliau pateikiamas kūrimo etapų sąrašas:

• patvirtinti - patvirtinti, kad projektas yra teisingas ir yra visa reikalinga informacija
• kompiliuoti - sudaryti projekto šaltinio kodą
• testas - išbandykite sukurtą šaltinio kodą naudodami tinkamą vieneto testavimo sistemą. Šiems bandymams nereikėtų reikalauti, kad kodas būtų supakuotas ar įdiegtas
• paketas - paimkite sukompiliuotą kodą ir supakuokite jį platinamu formatu, pvz., JAR.
• patikrinkite - atlikite bet kokius integracijos testų rezultatų patikrinimus, kad įsitikintumėte, jog laikomasi kokybės kriterijų
• įdiegti - įdiekite paketą į vietinę saugyklą, kad galėtumėte naudoti kaip priklausomybę kitiems projektams vietoje
• dislokuoti - atlikta kūrimo aplinkoje, nukopijuoja galutinį paketą į nuotolinę saugyklą, kad būtų galima dalytis su kitais kūrėjais ir projektais.

Aš galiu paleisti žemiau pateiktą komandą, kad galėčiau surinkti šaltinio kodą, išbandyti vienetą ir netgi supakuoti programą į karo failą:

mvn švari pakuotė

Taip pat galite suskaidyti kūrimo užduotį į kelis etapus. Tai leidžia lengviau organizuoti kūrimą švariais, atskirais etapais.

Taigi pradėsime nuo šaltinio kodo sukūrimo. Skirtuke „Sukurti“ spustelėkite iškviesti aukščiausio lygio „Maven“ taikinius ir įveskite žemiau esančią komandą:

sudaryti

Apsvarstykite toliau pateiktą ekrano kopiją:

Tai ištrauks šaltinio kodą iš „GitHub“ saugyklos ir taip pat sukompiliuos („Maven Compile Phase“).

Spustelėkite Išsaugoti ir vykdykite projektą.

Dabar spustelėkite konsolės išvestį, kad pamatytumėte rezultatą.

2 žingsnis - vieneto testavimas:

Dabar mes sukursime dar vieną „Freestyle“ projektą, skirtą vienetams išbandyti.

Pridėkite tą patį saugyklos URL šaltinio kodo tvarkymo skirtuke, kaip tai darėme ankstesniame darbe.

Dabar skirtuke „Buid Trigger“ spustelėkite „Build po kitų projektų sukūrimo“. Įveskite ankstesnio projekto, kuriame rengiame šaltinio kodą, pavadinimą ir galite pasirinkti bet kurią iš šių parinkčių:

• Suaktyvinti tik tuo atveju, jei konstrukcija yra stabili
• Suaktyvinkite, net jei komponavimas nestabilus
• Suaktyvinti, net jei nepavyksta sukurti

Manau, kad pirmiau pateikti variantai yra savaime suprantami, todėl pasirinkite bet kurį. Apsvarstykite toliau pateiktą ekrano kopiją:

Skirtuke „Sukurti“ spustelėkite iškviesti aukščiausio lygio „Maven“ taikinius ir naudokite šią komandą:

testas

Jenkins taip pat puikiai dirba padėdamas parodyti bandymų rezultatus ir testų rezultatų tendencijas.

De facto testų ataskaitų teikimo standartas „Java“ pasaulyje yra XML formatas, kurį naudoja „JUnit“. Šį formatą taip pat naudoja daugelis kitų „Java“ testavimo įrankių, tokių kaip „TestNG“, „Spock“ ir „Easyb“. „Jenkins“ supranta šį formatą, taigi, jei jūsų komponavimas sukuria „JUnit“ XML testo rezultatus, „Jenkins“ gali sugeneruoti puikias grafines bandymų ataskaitas ir statistinius duomenis apie bandymų rezultatus laikui bėgant, taip pat leisti jums peržiūrėti išsamią informaciją apie bet kokius bandymo gedimus. Jenkinsas taip pat stebi, kiek laiko reikia atlikti jūsų testus, tiek visame pasaulyje, tiek kiekvieno testo metu - tai gali būti naudinga, jei reikia išsiaiškinti našumo problemas.

Taigi kitas dalykas, kurį turime padaryti, yra priversti Jenkinsą laikyti skirtukus mūsų vieneto bandymuose.

Eikite į skyrių „Post-build Actions“ ir pažymėkite žymimąjį laukelį „Paskelbti„ JUnit “bandymo rezultatų ataskaitą“. Kai Mavenas vykdo vieneto testus projekte, jis automatiškai sugeneruoja XML testų ataskaitas kataloge, vadinamame „surefire-reports“. Taigi lauke „Test report XMLs“ įveskite „** / target / surefire-reports / *. Xml“. Dvi kelio pradžioje pažymėtos žvaigždutės („**“) yra geriausia praktika, kad konfigūracija būtų šiek tiek patikimesnė: jos leidžia Jenkinsui rasti tikslinį katalogą, kad ir kaip sukonfigūravome Jenkinsą patikrinti šaltinio kodą.

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

Vėl išsaugokite ir spustelėkite „Sukurti dabar“.

Dabar „JUnit“ ataskaita rašoma / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

„Jenkins“ prietaisų skydelyjetaip pat galite pastebėti testo rezultatus:

kaip dvigubai paversti int

3 žingsnis. WAR failo sukūrimas ir diegimas „Tomcat“ serveryje:

Kitas žingsnis - supakuoti programą į WAR failą ir įdiegti ją „Tomcat“ serveryje, kad būtų atliktas vartotojo priėmimo testas.

Sukurkite dar vieną „freestyle“ projektą ir pridėkite šaltinio kodo saugyklos URL.

Tada skirtuke „Sukurti paleidiklį“ pasirinkite komponavimą, kai kuriami kiti projektai, apsvarstykite toliau pateiktą ekrano kopiją:

Iš esmės, po bandomojo darbo, diegimo etapas prasidės automatiškai.

Skirtuke kūrimas pasirinkite apvalkalo scenarijų. Įveskite žemiau esančią komandą, kad pakuotumėte programą į WAR failą:

mvn paketas

Kitas žingsnis - įdėti šį WAR failą į „Tomcat“serverio. Skirtuke „Post-Build Actions“ pasirinkite dislokuoti karą / ausį į konteinerį. Čia nurodykite karo bylos kelią ir konteksto kelią. Apsvarstykite toliau pateiktą ekrano kopiją:

Pasirinkite „Tomcat“ kredencialus ir pastebėkite aukščiau pateiktą ekrano kopiją. Be to, turite nurodyti „Tomcat“ serverio URL.

Norėdami pridėti kredencialus „Jenkins“, spustelėkite „Jenkins“ informacijos suvestinėje esančią parinkties parinktį.

perjungti bylą „Java“ pavyzdinėse programose

Spustelėkite Sistema ir pasirinkite visuotinius kredencialus.

Tada rasite galimybę pridėti kredencialus. Spustelėkite jį ir pridėkite kredencialus.

Pridėkite „Tomcat“ kredencialus, apsvarstykite toliau pateiktą ekrano kopiją.

Spustelėkite Gerai.

Dabar savo projekto konfigūracijoje pridėkite „tomcat“ kredencialus, kuriuos įterpėte į ankstesnį veiksmą.

Spustelėkite Išsaugoti ir tada pasirinkite Kurti dabar.

Eikite į savo pokalbio URL su konteksto keliu, mano atveju tai yra http: // localhost: 8081. Dabar galų gale pridėkite konteksto kelią, apsvarstykite toliau pateiktą ekrano kopiją:

Nuoroda - http: // localhost: 8081 / gof

Tikiuosi, kad supratote konteksto kelio prasmę.

Dabar sukurkite dujotiekio rodinį, apsvarstykite toliau pateiktą ekrano kopiją:

Spustelėkite pliuso piktogramą, kad sukurtumėte naują vaizdą.

Konfigūruokite dujotiekį taip, kaip norite, apsvarstykite toliau pateiktą ekrano kopiją:

Aš nieko nekeičiau, išskyrus pradinio darbo pasirinkimą. Taigi mano dujotiekis prasidės nuo kompiliavimo. Atsižvelgiant į tai, kaip sukonfigūravau kitus darbus, po kompiliavimo bus atliktas testavimas ir diegimas.

Galiausiai galite išbandyti dujotiekį spustelėdami Vykdyti. Kas penkias minutes pasikeitus šaltinio kodui, bus vykdomas visas vamzdynas.

Taigi mes galime nuolat diegti savo programą testavimo serveryje, kad galėtume atlikti vartotojo priimtinumo testą (UAT).

Tikiuosi, kad jums patiko skaityti šį įrašą apie nuolatinį pristatymą. Jei turite kokių nors abejonių, nedvejodami įtraukite jas į toliau pateiktą komentarų skiltį, ir aš anksčiausiai grįšiu su atsakymu.

Norint sukurti CI / CD vamzdynus, reikia įvaldyti įvairiausių įgūdžių Įvaldykite reikalingus „DevOps“ įgūdžius dabar