Tutorial för kontinuerlig leverans - Bygga en kontinuerlig leveransrörledning med Jenkins

Kontinuerlig leverans:

Kontinuerlig leverans är en process där kodändringar automatiskt byggs, testas och förbereds för släpp till produktion.Jag hoppas att du har haft min Här kommer jag att prata om följande ämnen:

• Vad är kontinuerlig leverans?
• Typer av programvarutestning
• Skillnaden mellan kontinuerlig integration, leverans och distribution
• Vad är behovet av kontinuerlig leverans?
• Praktisk användning av Jenkins och Tomcat

Låt oss snabbt förstå hur kontinuerlig leverans fungerar.

Vad är kontinuerlig leverans?

Det är en process där du bygger programvara på ett sådant sätt att den kan släppas till produktion när som helst.Tänk på diagrammet nedan:

Låt mig förklara ovanstående diagram:

• Automatiserade byggskript kommer att upptäcka ändringar i källkodshantering (SCM) som Git.
• När ändringen har upptäckts kan källkoden distribueras till en dedikerad build-server för att säkerställa att build inte misslyckas och att alla testklasser och integrationstester fungerar bra.
• Sedan distribueras byggapplikationen på testservrarna (förproduktionsservrar) för UAT (User Acceptance Test).
• Slutligen distribueras applikationen manuellt på produktionsservrarna för release.

Innan jag fortsätter kommer det bara att vara rättvist att jag förklarar för dig olika typer av tester.

Typer av programvarutestning:

I stort sett finns det två typer av tester:

• Blackbox-testning: Det är en testteknik som ignorerar systemets interna mekanism och fokuserar på den utmatning som genereras mot eventuell inmatning och körning av systemet. Det kallas också funktionstestning. Den används i grunden för att validera programvaran.
• Whitebox-testning: är en testteknik som tar hänsyn till ett systems interna mekanism. Det kallas också strukturtestning och glasboxtestning. Den används i grunden för att verifiera programvaran.

Whitebox-testning:

Det finns två typer av tester som faller under denna kategori.

• Enhetstestning: Det är testningen av en enskild enhet eller grupp av relaterade enheter. Det görs ofta av programmeraren för att testa att den enhet han / hon har implementerat producerar förväntad produktion mot given ingång.
• Integrationstestning: Det är en typ av testning där en grupp av komponenter finnskombineras för att producera produktionen. Samspelet mellan programvara och hårdvara testas också om programvara och hårdvarukomponenter har någon relation. Det kan falla under både vitlåda och svartlåda.

Blackbox-testning:

Det finns flera tester som faller under denna kategori. Jag kommer att fokusera pånågra, som är viktiga för dig att veta, för att förstå den här bloggen:

gurka java selen webdriver exempel

• Funktionell / acceptantestning: Det säkerställer att den angivna funktionaliteten som krävs i systemkraven fungerar. Det görs för att säkerställa att den levererade produkten uppfyller kraven och fungerar som kunden förväntade sig
• Systemtestning: Det säkerställer att det fortfarande fungerar genom att placera programvaran i olika miljöer (t.ex. operativsystem).
• Stresstestning: Den utvärderar hur systemet beter sig under ogynnsamma förhållanden.
• Betatestning: Det görs av slutanvändare, ett team utanför utvecklingen eller genom att offentliggöra en fullständig förversion av produkten som kallasbetaversion. Målet med betatestning är att täcka oväntade fel.

Nu är det rätt tid för mig att förklara skillnaden mellan kontinuerlig integration, leverans och distribution.

Skillnader mellan kontinuerlig integration, leverans och distribution:

Visuellt innehåll når en individs hjärna på ett snabbare och mer förståeligt sätt än textinformation. Så jag ska börja med ett diagram som tydligt förklarar skillnaden:

I kontinuerlig integration byggs och testas varje kodförpliktelse men är inte i ett skick att släppas. Jag menar att byggapplikationen inte automatiskt distribueras på testservrarna för att validera den med hjälp av olika typer av Blackbox-test som - User Acceptance Testing (UAT).

I kontinuerlig leverans distribueras applikationen kontinuerligt på testservrarna för UAT. Eller så kan du säga att applikationen är redo att släppas till produktion när som helst. Så det är uppenbart att kontinuerlig integration är nödvändig för kontinuerlig leverans.

Kontinuerlig distribution är nästa steg efter kontinuerlig leverans, där du inte bara skapar ett distribuerbart paket utan bara distribuerar det automatiskt.

Låt mig sammanfatta skillnaderna med hjälp av en tabell:

Enkelt uttryckt är kontinuerlig integration en del av både kontinuerlig leverans och kontinuerlig distribution. Och kontinuerlig distribution är som kontinuerlig leverans, förutom att utgåvor sker automatiskt.

Lär dig hur du skapar CI / CD-rörledningar med Jenkins On Cloud

Men frågan är om det är tillräckligt med kontinuerlig integration.

Varför behöver vi kontinuerlig leverans?

Låt oss förstå detta med ett exempel.

Tänk dig att det finns 80 utvecklare som arbetar med ett stort projekt. De använder kontinuerliga integrationsrörledningar för att underlätta automatiserade byggnader. Vi vet att build också inkluderar enhetstestning. En dag bestämde de sig för att distribuera den senaste versionen som passerat enhetstesterna i en testmiljö.

Detta måste vara ett långt men kontrollerat tillvägagångssätt för implementering som deras miljöspecialister utförde. Systemet verkade dock inte fungera.

Vad kan vara den uppenbara orsaken till misslyckandet?

Tja, den första anledningen till att de flesta kommer att tro är att det finns något problem med konfigurationen. Som de flesta trodde även de.De tillbringade mycket tid på att försöka hitta vad som var fel med konfigurationen av miljön, men de kunde inte hitta problemet.

En uppfattande utvecklare tog en smart metod:

Då försökte en av seniorutvecklarna applikationen på sin utvecklingsmaskin. Det fungerade inte heller.

Han gick igenom tidigare och tidigare versioner tills han upptäckte att systemet hade slutat fungera tre veckor tidigare. Ett litet, dunkelt fel hade hindrat systemet från att starta korrekt. Även om projektet hade god enhetstesttäckning.Trots detta såg 80 utvecklare, som vanligtvis bara körde testerna snarare än själva applikationen, inte problemet på tre veckor.

Problemförklaring:

Utan att köra Acceptance Tests i en produktionsliknande miljö vet de ingenting om huruvida applikationen uppfyller kundens specifikationer och inte heller om den kan distribueras och överleva i den verkliga världen. Om de vill ha återkoppling i rätt tid om dessa ämnen måste de utöka intervallet för deras kontinuerliga integrationsprocess.

Låt mig sammanfatta lärdomarna genom att titta på ovanstående problem:

• Enhetstester testar bara utvecklarens perspektiv på lösningen på ett problem. De har endast en begränsad förmåga att bevisa att applikationen gör vad den ska utifrån ett användarperspektiv. De räcker inte tillidentifiera de verkliga funktionella problemen.
• Att distribuera applikationen i testmiljön är en komplex, manuellt intensiv process som var ganska benägen för fel.Detta innebar att varje försök till distribution var ett nytt experiment - en manuell, felbenägen process.

Lösning - Kontinuerlig leveransrörledning (Automated Acceptance Test):

De tog kontinuerlig integration (kontinuerlig leverans) till nästa steg och introducerade ett par enkla, automatiserade acceptattester som bevisade att applikationen kördes och kunde utföra sin mest grundläggande funktion.Majoriteten av de tester som körs under Acceptance Test-steget är Functional Acceptance Tests.

I grund och botten byggde de en kontinuerlig leveransrörledning för att säkerställa att applikationen distribueras sömlöst i produktionsmiljön genom att se till att applikationen fungerar bra när den distribueras på testservern, som är en kopia av produktionsservern.

Tillräckligt med teorin, jag ska nu visa dig hur du skapar en pipeline för kontinuerlig leverans med Jenkins.

Kontinuerlig leveransrörledning med Jenkins:

Här kommer jag att använda Jenkins för att skapa en kontinuerlig leveransrörledning, som kommer att innehålla följande uppgifter:

Steg involverade i demo:

• Hämtar koden från GitHub
• Kompilera källkoden
• Enhetstestning och generering av JUnit-testrapporterna
• Packa applikationen i en WAR-fil och distribuera den på Tomcat-servern

Förutsättningar:

• CentOS 7-maskin
• Jenkins 2.121.1
• Hamnarbetare
• Tomcat 7

Steg - 1 Sammanställning av källkoden:

Låt oss börja med att först skapa ett Freestyle-projekt i Jenkins. Tänk på skärmdumpen nedan:

Ge ditt projekt ett namn och välj Freestyle Project:

När du rullar ner hittar du ett alternativ för att lägga till källkodsförvar, välj git och lägg till förvarets URL, i det förvaret finns en pom.xml-böter som vi kommer att använda för att bygga vårt projekt. Tänk på skärmdumpen nedan:

Nu lägger vi till en Build Trigger. Välj SCM-alternativet, i princip kommer vi att konfigurera Jenkins för att undersöka GitHub-förvaret efter var femte minut för ändringar i koden. Tänk på skärmdumpen nedan:

Innan jag fortsätter, låt mig ge dig en liten introduktion till Maven Build Cycle.

Var och en av bygglivscyklerna definieras av en annan lista över byggfaser, varvid en byggfas representerar ett steg i livscykeln.

Följande är listan över byggfaser:

• validera - validera projektet är korrekt och all nödvändig information finns tillgänglig
• kompilera - kompilera källkoden för projektet
• test - testa den sammanställda källkoden med hjälp av en lämplig enhetstestram. Dessa tester bör inte kräva att koden packas eller distribueras
• paket - ta den sammanställda koden och paketera den i dess distribuerbara format, till exempel en JAR.
• verifiera - kör alla kontroller av resultaten av integrationstester för att säkerställa att kvalitetskriterierna uppfylls
• install - installera paketet i det lokala förvaret, för att användas som ett beroende i andra projekt lokalt
• distribuera - gjort i byggmiljön, kopierar det slutliga paketet till fjärrförvaret för delning med andra utvecklare och projekt.

Jag kan köra kommandot nedan för att kompilera källkoden, testa enheter och till och med packa applikationen i en krigsfil:

mvn rent paket

Du kan också dela upp ditt byggjobb i ett antal byggsteg. Detta gör det lättare att organisera byggnader i rena, separata steg.

Så vi börjar med att kompilera källkoden. På fliken bygga klickar du på åberopa toppnivå maven-mål och skriver kommandot nedan:

sammanställa

Tänk på skärmdumpen nedan:

Detta kommer att hämta källkoden från GitHub-förvaret och kommer också att kompilera den (Maven Compile Phase).

Klicka på Spara och kör projektet.

Klicka nu på konsolutgången för att se resultatet.

Steg - 2 Enhetstestning:

Nu ska vi skapa ytterligare ett Freestyle-projekt för enhetstestning.

Lägg till samma förvarets URL på källkodshanteringsfliken, som vi gjorde i föregående jobb.

Klicka nu på fliken 'Buid Trigger' på 'bygg efter att andra projekt har byggts'. Skriv där namnet på det föregående projektet där vi sammanställer källkoden och du kan välja något av följande alternativ:

• Trigger bara om byggnaden är stabil
• Utlös även om byggningen är instabil
• Trigger även om build misslyckas

Jag tycker att alternativen ovan är ganska självförklarande, så välj någon. Tänk på skärmdumpen nedan:

På fliken Bygg klickar du på åberopa toppnivå maven-mål och använder kommandot nedan:

testa

Jenkins gör också ett bra jobb med att hjälpa dig att visa dina testresultat och testresultattrender.

De facto-standarden för testrapportering i Java-världen är ett XML-format som används av JUnit. Detta format används också av många andra Java-testverktyg, som TestNG, Spock och Easyb. Jenkins förstår det här formatet, så om din version ger JUnit XML-testresultat kan Jenkins generera fina grafiska testrapporter och statistik om testresultat över tiden och även låta dig se detaljerna i eventuella testfel. Jenkins håller också reda på hur lång tid det tar för dina tester att köras, både globalt och per test - detta kan vara till nytta om du behöver spåra prestandafrågor.

Så nästa sak vi behöver göra är att få Jenkins att hålla koll på våra enhetstester.

Gå till avsnittet Efter byggåtgärder och markera kryssrutan ”Publicera JUnit-testresultatrapport”. När Maven kör enhetstest i ett projekt genererar den automatiskt XML-testrapporterna i en katalog som kallas surefire-rapporten. Så skriv in ”** / target / surefire-reports / *. Xml” i fältet “Test report XMLs”. De två asteriskerna i början av sökvägen (“**”) är en bästa metod för att göra konfigurationen lite mer robust: de tillåter Jenkins att hitta målkatalogen oavsett hur vi har konfigurerat Jenkins att kolla in källkoden.

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

Spara den igen och klicka på Bygg nu.

Nu är JUnit-rapporten skriven till / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

skillnaden mellan aws och azure

I Jenkins instrumentpaneldu kan också märka testresultaten:

Steg - 3 Skapa en krigsfil och distribuera på Tomcat-servern:

Nu är nästa steg att paketera vår applikation i en WAR-fil och distribuera den på Tomcat-servern för test av användaracceptans.

Skapa ytterligare ett freestyle-projekt och lägg till källkodsförvarets URL.

Välj sedan build när andra projekt byggs på fliken byggutlösare, överväga nedanstående skärmdump:

I grund och botten, efter testjobbet, kommer distributionsfasen att starta automatiskt.

På skalfliken väljer du skalskript. Skriv kommandot nedan för att paketera programmet i en WAR-fil:

mvn-paket

Nästa steg är att distribuera denna WAR-fil till Tomcatserver. På fliken 'Åtgärder efter byggnad' väljer du distribuera krig / öra till en container. Här ger du sökvägen till krigsfilen och ger kontextvägen. Tänk på skärmdumpen nedan:

Välj Tomcat-referenser och lägg märke till ovanstående skärmdump. Du måste också ange webbadressen till din Tomcat-server.

För att lägga till autentiseringsuppgifter i Jenkins, klicka på alternativet för autentiseringsuppgifter på Jenkins-instrumentpanelen.

Klicka på System och välj globala referenser.

Då hittar du ett alternativ att lägga till referenser. Klicka på den och lägg till referenser.

Lägg till Tomcat-referenser, överväga skärmdumpen nedan.

Klicka på OK.

omvänd ett tal i python

Nu i din projektkonfiguration, lägg till tomcat-referenserna som du har lagt in i föregående steg.

Klicka på Spara och välj sedan Bygg nu.

Gå till din tomcat-URL, med kontextvägen, i mitt fall är det http: // localhost: 8081. Lägg nu till kontextvägen till slut, överväga nedanstående skärmdump:

Länk - http: // localhost: 8081 / gof

Jag hoppas att du har förstått innebörden av kontextvägen.

Skapa nu en pipelevy, överväg nedanstående skärmdump:

Klicka på plusikonen för att skapa en ny vy.

Konfigurera rörledningen som du vill, överväga nedanstående skärmdump:

Jag ändrade ingenting förutom att välja det ursprungliga jobbet. Så min pipeline börjar från kompilering. Baserat på hur jag har konfigurerat andra jobb, efter testning och distribution kommer kompilering att ske.

Slutligen kan du testa rörledningen genom att klicka på KÖR. Om det sker en ändring i källkoden efter fem minuter kommer hela pipelinen att köras.

Så vi kan kontinuerligt distribuera vår applikation på testservern för användaracceptans test (UAT).

Jag hoppas att du gillat att läsa det här inlägget om kontinuerlig leverans. Om du är osäker kan du gärna lägga dem i kommentarfältet nedan så kommer jag tillbaka med ett svar tidigast.

För att bygga CI / CD-rörledningar måste du behärska en mängd olika färdigheter Behärska de nödvändiga DevOps-färdigheterna nu