Výukový program pre nepretržité doručovanie - Budovanie potrubia pre nepretržité doručovanie pomocou Jenkinsa

Nepretržité dodanie:

Kontinuálne doručovanie je proces, pri ktorom sa zmeny kódu automaticky zostavujú, testujú a pripravujú na vydanie do výroby.Dúfam, že sa vám môj páčil Tu budem hovoriť o nasledujúcich témach:

• Čo je to nepretržité doručovanie?
• Druhy testovania softvéru
• Rozdiel medzi nepretržitou integráciou, dodávkou a nasadením
• Aká je potreba nepretržitého doručovania?
• Praktické používanie Jenkins a Tomcat

Poďme rýchlo pochopiť, ako funguje nepretržité doručovanie.

Čo je to nepretržité doručovanie?

Jedná sa o proces, pri ktorom zostavujete softvér takým spôsobom, aby mohol byť kedykoľvek uvedený do výroby.Zvážte nasledujúci diagram:

Vysvetlím vyššie uvedený diagram:

• Automatizované zostavovacie skripty zistia zmeny v správe zdrojového kódu (SCM), ako je Git.
• Po zistení zmeny by sa zdrojový kód nasadil na dedikovaný server zostavenia, aby sa zabezpečilo, že zostavenie nezlyhá a všetky testovacie triedy a integračné testy fungujú dobre.
• Potom je aplikácia na zostavenie nasadená na testovacie servery (predprodukčné servery) pre test akceptácie používateľov (UAT).
• Nakoniec je aplikácia manuálne nasadená na produkčné servery na vydanie.

Než budem pokračovať, bude spravodlivé, vysvetlím vám rôzne typy testovania.

Typy testovania softvéru:

Všeobecne povedané, existujú dva typy testovania:

• Testovanie blackboxu: Jedná sa o testovaciu techniku, ktorá ignoruje vnútorný mechanizmus systému a zameriava sa na výstup generovaný proti vstupu a spusteniu systému. Hovorí sa mu aj funkčné testovanie. V zásade sa používa na overenie platnosti softvéru.
• Testovanie Whitebox: je testovacia technika, ktorá zohľadňuje vnútorný mechanizmus systému. Hovorí sa mu aj štrukturálne testovanie a testovanie sklenených debničiek. V zásade sa používa na overenie softvéru.

Whitebox testovanie:

Do tejto kategórie spadajú dva typy testovania.

• Testovanie jednotky: Jedná sa o testovanie jednotlivej jednotky alebo skupiny príbuzných jednotiek. Programátor často vykonáva testy, či jednotka, ktorú implementoval, produkuje očakávaný výstup oproti danému vstupu.
• Testovanie integrácie: Je to typ testovania, pri ktorom je skupina komponentovkombinovať na výrobu výstupu. Interakcia medzi softvérom a hardvérom sa tiež testuje, ak majú softvérové ​​a hardvérové ​​komponenty nejaký vzťah. Môže spadať pod testovanie v bielej skrinke aj v čiernej skrinke.

Testovanie blackboxu:

Do tejto kategórie patrí viac testov. Zameriam sa nazopár, ktoré musíte poznať, aby ste pochopili tento blog:

• Funkčné / akceptačné testovanie: Zaisťuje, že zadaná funkčnosť požadovaná v systémových požiadavkách funguje. Robí sa to preto, aby sa ubezpečil, že dodaný produkt spĺňa požiadavky a funguje podľa očakávaní zákazníka
• Testovanie systému: Zaisťuje, že umiestnením softvéru do rôznych prostredí (napr. Operačné systémy) bude stále fungovať.
• Stresové testovanie: Vyhodnocuje, ako sa systém správa za nepriaznivých podmienok.
• Beta testovanie: Robia to koncoví používatelia, tím mimo vývoja alebo verejné vydanie plnej pred-verzie produktu, ktorá je známa akobetaverzia. Cieľom beta testovania je pokryť neočakávané chyby.

Teraz je ten správny čas na to, aby som vysvetlil rozdiel medzi nepretržitou integráciou, dodávkou a nasadením.

Rozdiely medzi nepretržitou integráciou, dodávkou a nasadením:

Vizuálny obsah sa dostane do mozgu jednotlivca rýchlejšie a zrozumiteľnejšie ako textové informácie. Takže začnem diagramom, ktorý jasne vysvetľuje rozdiel:

V kontinuálnej integrácii je každé potvrdenie kódu zostavené a testované, ale nie je v stave na vydanie. Mám na mysli, že zostavovacia aplikácia nie je automaticky nasadená na testovacie servery, aby ju bolo možné overiť pomocou rôznych typov testovania Blackbox ako - User Acceptance Testing (UAT).

V aplikácii Continuous Delivery je aplikácia neustále nasadená na testovacích serveroch pre UAT. Alebo môžete povedať, že aplikácia je pripravená na vydanie do výroby kedykoľvek. Pre nepretržité doručovanie je teda zjavne nevyhnutná nepretržitá integrácia.

Kontinuálne nasadenie je ďalším krokom po kontinuálnom doručovaní, kedy nielen vytvárate nasaditeľný balík, ale aj ho nasadzujete automatizovaným spôsobom.

Dovoľte mi zhrnúť rozdiely pomocou tabuľky:

Zjednodušene povedané, nepretržitá integrácia je súčasťou nepretržitého doručovania aj nepretržitého nasadzovania. A Continuous Deployment je ako Continuous Delivery, ibaže k vydaniu dochádza automaticky.

Naučte sa, ako vytvoriť kanály CI / CD pomocou Jenkins On Cloud

Otázkou však je, či stačí kontinuálna integrácia.

Prečo potrebujeme nepretržité doručovanie?

Pochopme to na príklade.

Predstavte si, že na veľkom projekte pracuje 80 vývojárov. Na uľahčenie automatizovaného vytvárania používajú kanály kontinuálnej integrácie. Vieme, že build obsahuje aj Unit Testing. Jedného dňa sa rozhodli nasadiť najnovšiu verziu, ktorá prešla testami jednotky, do testovacieho prostredia.

Musí to byť zdĺhavý, ale kontrolovaný prístup k nasadeniu, ktorý vykonali ich špecialisti na životné prostredie. Zdá sa však, že systém nefungoval.

Čo by mohlo byť zjavnou príčinou zlyhania?

Prvý dôvod, ktorý si väčšina ľudí bude myslieť, je ten, že existuje nejaký problém s konfiguráciou. Ako väčšina ľudí, aj si to mysleli.Strávili veľa času hľadaním toho, čo je zlé na konfigurácii prostredia, ale problém nenašli.

Jeden vnímavý vývojár zaujal inteligentný prístup:

Potom jeden zo starších vývojárov vyskúšal aplikáciu na svojom vývojovom stroji. Tam to tiež nefungovalo.

Krokoval späť v starších a starších verziách, až kým nezistil, že systém prestal fungovať o tri týždne skôr. Drobná nejasná chyba zabránila správnemu spusteniu systému. Projekt mal však dobré pokrytie jednotkovými testami.Napriek tomu 80 vývojárov, ktorí zvyčajne spustili iba testy, a nie samotnú aplikáciu, nevidel problém tri týždne.

Vyhlásenie o probléme:

Bez spustenia testov akceptácie v produkčnom prostredí nevedia nič o tom, či aplikácia spĺňa špecifikácie zákazníka, ani o tom, či ju možno nasadiť a prežiť v skutočnom svete. Ak chcú mať k týmto témam včasnú spätnú väzbu, musia rozšíriť rozsah svojho procesu nepretržitej integrácie.

Dovoľte mi zhrnúť získané skúsenosti z vyššie uvedených problémov:

• Testy jednotiek testujú iba perspektívu vývojára týkajúcej sa riešenia problému. Majú iba obmedzenú schopnosť dokázať, že aplikácia z pohľadu používateľov robí to, čo má. Nestačia na toidentifikovať skutočné funkčné problémy.
• Nasadenie aplikácie do testovacieho prostredia je zložitý, manuálne intenzívny proces, ktorý bol dosť náchylný na chyby.To znamenalo, že každý pokus o nasadenie bol novým experimentom - manuálnym procesom náchylným na chyby.

Riešenie - Potrubie kontinuálneho doručovania (automatizovaný test prijatia):

Do ďalšieho kroku posunuli nepretržitú integráciu (Continuous Delivery) a predstavili niekoľko jednoduchých automatizovaných testov prijatia, ktoré dokázali, že aplikácia bežala a mohla vykonávať svoju najzákladnejšiu funkciu.Väčšina testov prebiehajúcich počas fázy prijímacieho testu sú funkčné preberacie testy.

V zásade vytvorili kanál kontinuálneho doručovania, aby sa ubezpečili, že je aplikácia bezproblémovo nasadená v produkčnom prostredí, a to tak, že sa uistili, že aplikácia funguje dobre, keď je nasadená na testovacom serveri, ktorý je replikou produkčného servera.

Dosť na teóriu, teraz vám ukážem, ako vytvoriť potrubie Continuous Delivery pomocou Jenkinsa.

Potrubie kontinuálneho doručovania pomocou Jenkinsa:

Tu budem pomocou Jenkinsa vytvárať kanál kontinuálneho doručovania, ktorý bude obsahovať nasledujúce úlohy:

Kroky zapojené do ukážky:

• Načítava sa kód z GitHubu
• Zostavenie zdrojového kódu
• Testovanie jednotiek a generovanie protokolov o testoch JUnit
• Zbalenie aplikácie do súboru WAR a jej nasadenie na serveri Tomcat

Predpoklady:

• Stroj CentOS 7
• Jenkins 2.121.1
• Docker
• Tomcat 7

Krok - 1 Kompilácia zdrojového kódu:

Začnime najskôr vytvorením projektu Freestyle v Jenkins. Zvážte nasledujúcu snímku obrazovky:

Pomenujte svoj projekt a vyberte Freestyle Project:

Pri rolovaní nadol nájdete možnosť pridať úložisko zdrojových kódov, zvoliť git a pridať URL úložiska, v tomto úložisku je pokuta pom.xml, ktorú použijeme na zostavenie nášho projektu. Zvážte nasledujúcu snímku obrazovky:

Teraz pridáme Build Trigger. Vyberte možnosť prieskumu SCM. V zásade nakonfigurujeme Jenkinsa, aby po každých 5 minútach zisťoval zmeny v kóde v úložisku GitHub. Zvážte nasledujúcu snímku obrazovky:

Než budem pokračovať, dovoľte mi, aby som vám predstavil malý úvod do cyklu zostavovania Maven.

Každý z životných cyklov zostavenia je definovaný iným zoznamom fáz budovania, pričom fáza budovania predstavuje fázu v životnom cykle.

Nasleduje zoznam fáz budovania:

• validovať - ​​validácia projektu je správna a sú k dispozícii všetky potrebné informácie
• compile - skompilovať zdrojový kód projektu
• test - otestujte skompilovaný zdrojový kód pomocou vhodného rámca na testovanie jednotiek. Tieto testy by nemali vyžadovať zabalenie alebo nasadenie kódu
• balíček - vezmite skompilovaný kód a zabalte ho v distribuovateľnom formáte, napríklad JAR.
• overiť - spustiť akékoľvek kontroly výsledkov integračných testov, aby sa zabezpečilo splnenie kritérií kvality
• install - nainštaluje balík do lokálneho úložiska, ktorý sa použije ako závislosť v iných lokálnych projektoch
• nasadiť - vykonáva sa v prostredí zostavenia, skopíruje sa konečný balík do vzdialeného úložiska na zdieľanie s ďalšími vývojármi a projektmi.

Môžem spustiť nasledujúci príkaz na zostavenie zdrojového kódu, testovanie jednotiek a dokonca aj zabalenie aplikácie do vojnového súboru:

mvn čistý balíček

Svoju prácu na zostavení môžete tiež rozdeliť do niekoľkých krokov zostavenia. Toto uľahčuje organizáciu zostavení v čistých, samostatných fázach.

Začneme teda kompiláciou zdrojového kódu. Na karte zostavenie kliknite na vyvolanie cieľov najvyššej úrovne a zadajte nasledujúci príkaz:

zostaviť

Zvážte nasledujúcu snímku obrazovky:

Toto vytiahne zdrojový kód z úložiska GitHub a tiež ho skompiluje (Maven Compile Phase).

Kliknite na Uložiť a spustite projekt.

volať odkazom c ++

Teraz kliknite na výstup z konzoly, aby ste videli výsledok.

Krok - 2 testovanie jednotky:

Teraz vytvoríme ešte jeden Freestyle Project pre testovanie jednotiek.

Pridajte rovnakú adresu URL úložiska na karte správy zdrojového kódu, ako sme to urobili v predchádzajúcej úlohe.

Teraz na karte „Buid Trigger“ kliknite na „zostaviť po vytvorení ďalších projektov“. Tam zadajte názov predchádzajúceho projektu, kde kompilujeme zdrojový kód, a môžete zvoliť ktorúkoľvek z nasledujúcich možností:

• Spustí sa, iba ak je zostava stabilná
• Spustí sa, aj keď je zostava nestabilná
• Spustí sa, aj keď zostavenie zlyhá

Myslím si, že vyššie uvedené možnosti sú úplne vysvetľujúce, takže vyberte ktorúkoľvek z nich. Zvážte nasledujúcu snímku obrazovky:

Na karte Budovanie kliknite na vyvolanie cieľov najvyššej úrovne a použite nasledujúci príkaz:

test

Jenkins tiež odvádza skvelú prácu, pretože vám pomáha zobrazovať výsledky testov a trendy v testovacích výsledkoch.

De facto štandardom pre vykazovanie testov vo svete Java je formát XML používaný programom JUnit. Tento formát používajú aj mnohé ďalšie testovacie nástroje Java, napríklad TestNG, Spock a Easyb. Jenkins rozumie tomuto formátu, takže ak vaša zostava poskytuje výsledky testu JUnit XML, môže Jenkins generovať pekné grafické protokoly o testoch a štatistiku výsledkov testov v priebehu času a tiež vám umožní zobraziť podrobnosti všetkých zlyhaní testu. Jenkins tiež sleduje, ako dlho trvá spustenie vašich testov, a to globálne aj podľa jednotlivých testov - to sa vám môže hodiť, ak potrebujete zistiť problémy s výkonom.

Ďalšou vecou, ​​ktorú musíme urobiť, je prinútiť Jenkinsa, aby sledoval naše jednotkové testy.

Prejdite do sekcie Akcie po zostavení a začiarknite políčko „Publikovať správu o výsledku testu JUnit“. Keď Maven spúšťa jednotkové testy v projekte, automaticky generuje správy o testoch XML v adresári s názvom surefire-reports. Takže do poľa „Test XML XML“ zadajte „** / target / surefire-reports / *. Xml“. Najlepšie sú dve hviezdičky na začiatku cesty („**“), vďaka ktorým je konfigurácia trochu robustnejšia: umožňujú Jenkinsovi nájsť cieľový adresár bez ohľadu na to, ako sme nakonfigurovali Jenkinsa na kontrolu zdrojového kódu.

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

Znovu ho uložte a kliknite na Vytvoriť.

Teraz je správa JUnit zapísaná do adresára / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

Na palubnej doske Jenkinsmôžete si tiež všimnúť výsledky testu:

Krok - 3 Vytvorenie súboru WAR a nasadenie na server Tomcat:

Ďalším krokom je zabalenie našej aplikácie do súboru WAR a jej nasadenie na server Tomcat na test prijatia používateľa.

hlboká vs plytká kópia

Vytvorte ešte jeden freestylový projekt a pridajte adresu URL úložiska zdrojového kódu.

Potom na karte spúšťača zostavenia vyberte zostavenie, keď sa vytvárajú ďalšie projekty, zvážte nasledujúcu snímku obrazovky:

V zásade po testovacej úlohe začne fáza nasadenia automaticky.

Na karte zostavenie vyberte príkazový skript. Zadajte nasledujúci príkaz na zabalenie aplikácie do súboru WAR:

balíček mvn

Ďalším krokom je nasadenie tohto súboru WAR do Tomcatserver. Na karte „Post-Build Actions“ vyberte nasadenie war / ear do kontajnera. Tu uveďte cestu k súboru war a uveďte kontextovú cestu. Zvážte nasledujúcu snímku obrazovky:

Vyberte poverenia Tomcat a všimnite si snímku obrazovky vyššie. Musíte zadať aj adresu URL servera Tomcat.

Ak chcete pridať poverenia do servera Jenkins, kliknite na možnosť poverení na paneli nástrojov Jenkins.

Kliknite na Systém a vyberte globálne poverenia.

Potom nájdete možnosť pridať poverenia. Kliknite na ňu a pridajte poverenia.

Pridajte poverenia Tomcat, zvážte nasledujúcu snímku obrazovky.

Kliknite na OK.

Teraz do konfigurácie projektu pridajte poverenia Tomcat, ktoré ste vložili v predchádzajúcom kroku.

Kliknite na Uložiť a potom vyberte Vytvoriť teraz.

Prejdite na svoju Tomcat URL s kontextovou cestou, v mojom prípade je to http: // localhost: 8081. Teraz na konci pridajte kontextovú cestu, zvážte nasledujúcu snímku obrazovky:

Odkaz - http: // localhost: 8081 / gof

Dúfam, že ste pochopili význam kontextu.

Teraz vytvorte zobrazenie potrubia, zvážte nasledujúcu snímku obrazovky:

Kliknutím na ikonu plus vytvoríte nové zobrazenie.

Nakonfigurujte si kanál tak, ako chcete, zvážte nasledujúcu snímku obrazovky:

Okrem výberu pôvodného zamestnania som nič nezmenil. Môj kanál teda začne od kompilácie. Na základe spôsobu, akým som nakonfiguroval ďalšie úlohy, dôjde po testovaní a nasadení kompilácie.

Nakoniec môžete kanál otestovať kliknutím na RUN. Po každých piatich minútach, ak dôjde k zmene zdrojového kódu, sa vykoná celý kanál.

Takže sme schopní neustále nasadzovať našu aplikáciu na testovacom serveri pre používateľský akceptačný test (UAT).

Dúfam, že sa vám páčilo čítanie tohto príspevku o Kontinuálnom doručovaní. Ak máte pochybnosti, neváhajte ich uviesť v sekcii komentárov nižšie a ja vám odpoviem najskôr.

Na vybudovanie potrubí CI / CD musíte ovládať širokú škálu zručností Osvojte si požadované zručnosti DevOps už teraz