Výukový program pro kontinuální doručování - Vytváření kanálu kontinuálního doručování pomocí Jenkinse

Kontinuální dodávka:

Kontinuální dodávka je proces, při kterém se změny kódu automaticky vytvářejí, testují a připravují na vydání do výroby.Doufám, že se vám moje líbilo Zde budu hovořit o následujících tématech:

• Co je to průběžné doručování?
• Druhy testování softwaru
• Rozdíl mezi kontinuální integrací, dodávkou a nasazením
• Co je potřeba pro průběžné doručování?
• Praktické používání Jenkins a Tomcat

Pojďme rychle pochopit, jak kontinuální doručování funguje.

Co je to průběžné doručování?

Jedná se o proces, při kterém vytváříte software takovým způsobem, aby jej bylo možné kdykoli uvolnit do výroby.Zvažte následující diagram:

Vysvětlím výše uvedený diagram:

• Automatizované sestavovací skripty detekují změny ve správě zdrojového kódu (SCM), jako je Git.
• Jakmile je změna detekována, zdrojový kód by byl nasazen na vyhrazený server sestavení, aby se ujistil, že sestavení neselhává a všechny testovací třídy a integrační testy fungují dobře.
• Poté je aplikace sestavení nasazena na testovací servery (předprodukční servery) pro User Acceptance Test (UAT).
• Nakonec je aplikace ručně nasazena na produkční servery k vydání.

Než budu pokračovat, bude fér, vysvětlím vám různé typy testování.

Typy testování softwaru:

Obecně řečeno existují dva typy testování:

• Blackbox Testování: Jedná se o testovací techniku, která ignoruje vnitřní mechanismus systému a zaměřuje se na výstup generovaný proti jakémukoli vstupu a provedení systému. Také se tomu říká funkční testování. V zásadě se používá k ověření softwaru.
• Whitebox Testování: je testovací technika, která bere v úvahu vnitřní mechanismus systému. Také se tomu říká strukturální testování a testování skleněných boxů. V zásadě se používá k ověření softwaru.

Whitebox testování:

Do této kategorie spadají dva typy testování.

• Testování jednotky: Jedná se o testování jednotlivé jednotky nebo skupiny souvisejících jednotek. Programátor často provádí testování, že jednotka, kterou implementoval, produkuje očekávaný výstup oproti danému vstupu.
• Testování integrace: Jedná se o typ testování, ve kterém je skupina komponentkombinovat k produkci výstupu. Interakce mezi softwarem a hardwarem se také testuje, pokud mají softwarové a hardwarové komponenty nějaký vztah. Může spadat pod testování bílé skříňky i testování černé skříňky.

Blackbox Testování:

Do této kategorie spadá několik testů. Zaměřím se natrochu, které je důležité znát, abyste porozuměli tomuto blogu:

• Funkční / přejímací zkoušky: Zajišťuje, že zadaná funkce požadovaná v systémových požadavcích funguje. Dělá se to proto, aby se zajistilo, že dodaný produkt splňuje požadavky a funguje podle očekávání zákazníka
• Testování systému: Zajišťuje, že umístěním softwaru do různých prostředí (např. Operační systémy) bude stále fungovat.
• Stresové testování: Vyhodnocuje, jak se systém chová za nepříznivých podmínek.
• Beta testování: Dělají to koncoví uživatelé, tým mimo vývoj nebo veřejně vydávají plnou před verzi produktu, která je známá jakobetaverze. Cílem beta testování je pokrýt neočekávané chyby.

Nyní je ten správný čas, abych vysvětlil rozdíl mezi průběžnou integrací, dodávkou a nasazením.

Rozdíly mezi nepřetržitou integrací, dodávkou a nasazením:

Vizuální obsah zasahuje mozek jednotlivce rychleji a srozumitelněji než textové informace. Začnu tedy diagramem, který jasně vysvětlí rozdíl:

V kontinuální integraci je každé potvrzení kódu sestaveno a testováno, ale není ve stavu, který má být vydán. Myslím tím, že aplikace pro sestavení není automaticky nasazena na testovacích serverech, aby ji ověřila pomocí různých typů testování Blackboxu jako - User Acceptance Testing (UAT).

V Continuous Delivery je aplikace nepřetržitě nasazována na testovacích serverech pro UAT. Nebo můžete říci, že aplikace je připravena k vydání do výroby kdykoli. Pro kontinuální doručování je tedy zjevně nutná nepřetržitá integrace.

Kontinuální nasazení je dalším krokem po nepřetržitém doručování, kdy nejen vytváříte nasaditelný balíček, ale ve skutečnosti ho nasazujete automatizovaným způsobem.

Dovolte mi shrnout rozdíly pomocí tabulky:

Jednoduše řečeno, kontinuální integrace je součástí kontinuálního doručování i nepřetržitého nasazování. A Continuous Deployment je jako Continuous Delivery, kromě toho, že k vydání dochází automaticky.

Naučte se, jak vytvořit kanály CI / CD pomocí Jenkins On Cloud

Otázkou však je, zda kontinuální integrace stačí.

Proč potřebujeme nepřetržité doručování?

Pochopme to na příkladu.

Představte si, že na velkém projektu pracuje 80 vývojářů. Používají kanály kontinuální integrace s cílem usnadnit automatizované sestavení. Víme, že build zahrnuje také Unit Testing. Jednoho dne se rozhodli nasadit nejnovější verzi, která prošla testy jednotky, do testovacího prostředí.

Musí to být zdlouhavý, ale kontrolovaný přístup k nasazení, který provedli jejich specialisté na životní prostředí. Zdálo se však, že systém nefunguje.

Co by mohlo být zjevnou příčinou selhání?

Prvním důvodem, který si většina lidí bude myslet, je, že s konfigurací je nějaký problém. Jako většina lidí, i oni si to mysleli.Strávili spoustu času hledáním toho, co je špatně s konfigurací prostředí, ale nemohli najít problém.

Jeden vnímavý vývojář zaujal chytrý přístup:

Poté jeden z vedoucích vývojářů vyzkoušel aplikaci na svém vývojovém stroji. Tam to také nefungovalo.

Krokoval zpět dřívějšími a dřívějšími verzemi, dokud nezjistil, že systém přestal fungovat o tři týdny dříve. Drobná temná chyba zabránila správnému spuštění systému. Přesto měl projekt dobré pokrytí jednotkovými testy.Navzdory tomu 80 vývojářů, kteří obvykle prováděli pouze testy namísto samotné aplikace, neviděli problém po dobu tří týdnů.

Problémové prohlášení:

Bez provádění testů přijetí v produkčním prostředí nevědí nic o tom, zda aplikace splňuje specifikace zákazníka, ani o tom, zda ji lze nasadit a přežít ve skutečném světě. Pokud chtějí včasnou zpětnou vazbu k těmto tématům, musí rozšířit rozsah svého procesu nepřetržité integrace.

Dovolte mi shrnout poučení z výše uvedených problémů:

• Testy jednotek testují pouze perspektivu vývojáře týkající se řešení problému. Mají jen omezenou schopnost prokázat, že aplikace z pohledu uživatelů dělá to, co má. Nestačí na toidentifikovat skutečné funkční problémy.
• Nasazení aplikace do testovacího prostředí je složitý, ručně intenzivní proces, který byl docela náchylný k chybám.To znamenalo, že každý pokus o nasazení byl novým experimentem - manuálním procesem náchylným k chybám.

Řešení - Průběžné dodávkové potrubí (automatický přejímací test):

Vzali Continuous Integration (Continuous Delivery) k dalšímu kroku a představili několik jednoduchých automatizovaných testů přijetí, které prokázaly, že aplikace běžela a mohla vykonávat svoji nejzákladnější funkci.Většina testů probíhajících během fáze Acceptance Test jsou Testy funkční přejímky.

V zásadě vytvořili kanál Continuous Delivery, aby se ujistili, že aplikace je bezproblémově nasazena v produkčním prostředí, tím, že se ujistí, že aplikace funguje dobře při nasazení na testovacím serveru, který je replikou produkčního serveru.

Dost teorie, teď vám ukážu, jak vytvořit potrubí Continuous Delivery pomocí Jenkinse.

Průběžné doručování pomocí Jenkinse:

Tady použiji Jenkins k vytvoření kanálu nepřetržitého doručování, který bude zahrnovat následující úkoly:

Kroky zapojené do ukázky:

• Načítání kódu z GitHubu
• Kompilace zdrojového kódu
• Testování jednotek a generování protokolů o testování JUnit
• Zabalení aplikace do souboru WAR a její nasazení na server Tomcat

Předpoklady:

• Stroj CentOS 7
• Jenkins 2.121.1
• Přístavní dělník
• Tomcat 7

Krok - 1 Kompilace zdrojového kódu:

Začněme nejprve vytvořením projektu Freestyle v Jenkins. Zvažte následující snímek obrazovky:

Pojmenujte svůj projekt a vyberte Freestyle Project:

Když přejdete dolů, najdete možnost přidat úložiště zdrojového kódu, vyberte git a přidejte adresu URL úložiště, v tomto úložišti je pokuta pom.xml, kterou použijeme k sestavení našeho projektu. Zvažte následující snímek obrazovky:

Nyní přidáme Build Trigger. Vyberte možnost dotazování SCM, v zásadě nakonfigurujeme Jenkinse, aby po každých 5 minutách provedl dotaz na úložiště GitHub pro změny v kódu. Zvažte následující snímek obrazovky:

Než budu pokračovat, dovolte mi, abych vám představil malý cyklus sestavení Maven.

Každý z životních cyklů sestavení je definován jiným seznamem fází sestavení, přičemž fáze sestavení představuje fázi v životním cyklu.

Následuje seznam fází sestavení:

• ověřit - ověření projektu je správné a jsou k dispozici všechny potřebné informace
• compile - kompilace zdrojového kódu projektu
• test - otestujte zkompilovaný zdrojový kód pomocí vhodného rámce pro testování jednotek. Tyto testy by neměly vyžadovat zabalení nebo nasazení kódu
• balíček - vezměte zkompilovaný kód a zabalte jej v distribuovatelném formátu, například JAR.
• ověřit - proveďte jakékoli kontroly výsledků integračních testů, abyste zajistili splnění kritérií kvality
• install - nainstaluje balíček do místního úložiště pro použití jako závislost v jiných projektech lokálně
• nasadit - provádí se v prostředí sestavení, zkopíruje finální balíček do vzdáleného úložiště pro sdílení s dalšími vývojáři a projekty.

Mohu spustit níže uvedený příkaz pro kompilaci zdrojového kódu, testování jednotky a dokonce i zabalení aplikace do válečného souboru:

čistý balíček mvn

Svou úlohu sestavení můžete také rozdělit do několika kroků sestavení. To usnadňuje organizaci sestavení v čistých samostatných fázích.

Začneme tedy kompilací zdrojového kódu. Na kartě sestavení klikněte na vyvolání cílů nejvyšší úrovně maven a zadejte následující příkaz:

kompilovat

Zvažte následující snímek obrazovky:

Toto vytáhne zdrojový kód z úložiště GitHub a také jej zkompiluje (Maven Compile Phase).

Klikněte na Uložit a spusťte projekt.

volání odkazem c ++

Výsledek zobrazíte kliknutím na výstup z konzoly.

Krok - 2 testování jednotky:

Nyní vytvoříme ještě jeden Freestyle Project pro testování jednotek.

Přidejte stejnou adresu URL úložiště na kartě správy zdrojového kódu, jako jsme to udělali v předchozí úloze.

Nyní na kartě „Buid Trigger“ klikněte na „build after other projects are built“. Zadejte název předchozího projektu, kde kompilujeme zdrojový kód, a můžete vybrat některou z následujících možností:

• Spustit, pouze pokud je sestava stabilní
• Spustí se, i když je sestava nestabilní
• Spustí se, i když sestavení selže

Myslím, že výše uvedené možnosti jsou docela vysvětlující, takže vyberte libovolnou. Zvažte následující snímek obrazovky:

Na kartě Sestavit klikněte na vyvolání cílů nejvyšší úrovně maven a použijte následující příkaz:

test

Jenkins také odvádí skvělou práci, protože vám pomáhá zobrazovat výsledky testů a trendy výsledků testů.

De facto standardem pro testování testů ve světě Java je formát XML používaný JUnit. Tento formát používá také mnoho dalších testovacích nástrojů Java, například TestNG, Spock a Easyb. Jenkins tomuto formátu rozumí, takže pokud vaše sestavení produkuje výsledky testu JUnit XML, může Jenkins generovat pěkné grafické protokoly o testech a statistiky o výsledcích testu v průběhu času a také vám umožní zobrazit podrobnosti o všech selháních testu. Jenkins také sleduje, jak dlouho trvá spuštění testů, a to globálně i podle testu - to se může hodit, pokud potřebujete sledovat problémy s výkonem.

Další věcí, kterou musíme udělat, je přimět Jenkinse, aby udržoval přehled o našich testech jednotek.

Přejděte do sekce Akce po sestavení a zaškrtněte políčko „Publikovat zprávu o výsledku testu JUnit“. Když Maven spouští testy jednotek v projektu, automaticky generuje zprávy o testu XML v adresáři nazvaném surefire-reports. Do pole „Test report XMLs“ tedy zadejte „** / target / surefire-reports / *. Xml“. Dvě hvězdičky na začátku cesty („**“) jsou osvědčeným postupem, aby byla konfigurace trochu robustnější: umožňují Jenkinsovi najít cílový adresář bez ohledu na to, jak jsme nakonfigurovali Jenkins pro kontrolu zdrojového kódu.

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

Znovu jej uložte a klikněte na Vytvořit nyní.

Nyní je sestava JUnit zapsána do / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

Na palubní desce Jenkinsmůžete si také všimnout výsledků testu:

Krok - 3 Vytvoření souboru WAR a nasazení na serveru Tomcat:

Dalším krokem je zabalit naši aplikaci do souboru WAR a nasadit ji na server Tomcat pro test přijetí uživatele.

jak generovat náhodný řetězec v javě

Vytvořte ještě jeden freestylový projekt a přidejte adresu URL úložiště zdrojového kódu.

Pak na kartě aktivační události sestavení vyberte sestavení, když jsou sestaveny další projekty, zvažte následující snímek obrazovky: Then in the build trigger tab, select build when other projects are built, consider the below screenshot:

V podstatě po testovací úloze začne fáze nasazení automaticky.

Na kartě sestavení vyberte shell skript. Chcete-li aplikaci zabalit do souboru WAR, zadejte následující příkaz:

balíček mvn

Dalším krokem je nasazení tohoto souboru WAR do Tomcatserveru. Na kartě „Akce po sestavení“ vyberte nasazení war / ear do kontejneru. Zde uveďte cestu k válečnému souboru a uveďte kontextovou cestu. Zvažte následující snímek obrazovky:

Vyberte pověření Tomcat a všimněte si výše uvedeného snímku obrazovky. Musíte také uvést adresu URL svého serveru Tomcat.

Chcete-li přidat pověření v Jenkins, klikněte na možnost pověření na řídicím panelu Jenkins.

Klikněte na Systém a vyberte globální pověření.

Poté najdete možnost přidat pověření. Klikněte na něj a přidejte pověření.

Přidejte pověření Tomcat, zvažte níže uvedený snímek obrazovky.

Klikněte na OK.

Nyní do Konfigurace projektu přidejte pověření kocoura, která jste vložili v předchozím kroku.

Klikněte na Uložit a poté vyberte Vytvořit nyní.

Přejděte na svou adresu URL kocoura s kontextovou cestou, v mém případě je to http: // localhost: 8081. Na konci přidejte kontextovou cestu, zvažte následující snímek obrazovky:

Odkaz - http: // localhost: 8081 / gof

Doufám, že jste pochopili význam kontextové cesty.

Nyní vytvořte pohled potrubí, zvažte následující snímek obrazovky:

Kliknutím na ikonu plus vytvoříte nové zobrazení.

Nakonfigurujte kanál tak, jak chcete, zvažte následující snímek obrazovky:

Kromě výběru původní práce jsem nic nezměnil. Můj plynovod tedy začne od kompilace. Na základě způsobu, jakým jsem nakonfiguroval další úlohy, dojde po testování kompilace a nasazení.

Nakonec můžete kanál otestovat kliknutím na RUN. Po každých pěti minutách, pokud dojde ke změně ve zdrojovém kódu, bude spuštěn celý kanál.

Takže jsme schopni nepřetržitě nasazovat naši aplikaci na testovacím serveru pro uživatelský akceptační test (UAT).

Doufám, že se vám tento příspěvek o Průběžném doručování líbil. Máte-li jakékoli pochybnosti, neváhejte je vložit do sekce komentářů níže a já vám odpovím nejdříve.

Abyste mohli stavět potrubí CI / CD, musíte zvládnout širokou škálu dovedností Osvojte si nyní požadované dovednosti DevOps