hudson continuous integration tool tutorial selenium tutorial 25
I de två senaste handledningarna i Selen-serien diskuterade vi de två viktigaste byggverktygen - MYRA och Maven . Vi diskuterade deras betydelse och praktiska betydelse.
I vår tidigare handledning i DevOps-serien lärde vi oss om Integrering av Jenkins med Selen .
I strömmen Selen online-utbildning , vi skulle diskutera en kontinuerligt integrationsverktyg som kallas Hudson .
Läs igenom => Exemplarhandbok för DevOps
Notera: Denna handledning är en del av såväl Selen som DevOps handledningsserier. Klicka på lämpliga länkar för att navigera till berörd serie.
Vi skulle studera dess betydelse och fördelar som vi får ut av alla kontinuerliga integrationsverktyg . Vi skulle titta på Hudson direkt från början, från installationen till dess avancerade inställningar.
Vad du kommer att lära dig:
- Fortsatt integration
- Hudson - kontinuerligt integrationsverktyg
- Hudson Installation
- Hudson-konfiguration
- Konfigurera e-postavisering
- Skapa Hudson-projektet
- Konfigurera Hudson-projektet
- Konfigurera källkodshantering
- Välja bygga utlösare
- Åberopa byggsteg
- Konfigurera åtgärder efter byggnaden
- Slutsats
- Rekommenderad läsning
Fortsatt integration
Många gånger slutar vi arbeta med ett projekt där ett stort gäng utvecklare och testare arbetar tillsammans på olika moduler. Utvecklare och testare arbetar med sina moduler och utvecklar därmed körbara filer. Dessa arbetsprodukter integreras sedan med jämna mellanrum. Varje gång vi skapar en utvecklingskod måste den därför integreras, testas och byggas för att säkerställa att den utvecklade koden inte går sönder eller introducerar fel eller defekter.
Denna process med att bygga och testa det integrerade utvecklingsarbetet med jämna mellanrum kallas Kontinuerlig integration (CI) . Kontinuerlig integration låter dig identifiera och åtgärda defekter eller fel så snart som möjligt i utvecklingslivscykeln, dvs. närmare den tid de introducerades.
Kontinuerligt integrationssystem bygger och testar applikationen så snart den nya / ändrade koden har förpliktats till källkontrollsystemets akronym som SCM. Med sina stora fördelar och påverkan över branscherna har det blivit en integrerad del av programvaruutvecklingens livscykel och praktiseras obligatoriskt.
Hudson - kontinuerligt integrationsverktyg
Kontinuerlig integration kan utföras automatiskt. Hudson är ett av de populärt kända verktygen för att utföra kontinuerlig integration. Hudson är ett Java-baserat open source-verktyg för kontinuerlig integrering. Liksom alla andra kontinuerliga integrationsverktyg ger Hudson teamen att utlösa byggnader och tester med alla förändringar i källkontrollhanteringssystemet.
Hudson stöder ett stort utbud av verktyg och plugins.
Hudson:
- Stöder SCM-verktyg som CVS, Subversion (SVN), Git etc.
- Kan bygga ANT-baserade projekt, Maven-baserade projekt etc.
- Kan utföra skalskript och Windows batch-kommandon
- Kan skicka rapporter, meddelanden etc via e-post, SMS, Skype etc.
Hudson Installation
Förutsättningar
För att kunna använda Hudson behöver vi följande saker vara på plats innan vi börjar:
- Källkodsförvar (SVN / Git / CVS etc.)
- Bygg skript (Ant / Maven etc.)
Installation
Hudson kan enkelt installeras i olika miljöer. Hudson kan installeras på både Linux- och Windows-maskinen. Det distribueras också som ett paket som är specifikt för OS-typen för olika Linux-smaker, vilket gör installationen till några minuters uppgifter. Hudson kan köras som en fristående applikation eller inom Servlet Container. I denna handledning skulle vi förklara Hudson Installation på Windows-maskin. Det finns två olika sätt att installera Hudson.
- Använda WAR-filen
- Använda Native Package
Inbyggda paket finns tillgängliga för Ubuntu / Debian, Oracle Linux, Redhat / Fedora / CentOS och openSUSE.
För den här handledningen skulle vi diskutera installation av WAR-fil. Låt oss diskutera hela processen steg för steg.
Steg 1 : Ladda ner Hudson WAR-filen från Hudsons officiella webbplats - “ http://hudson-ci.org/ ”. Håll krigsfilen på önskad plats i det lokala filsystemet. Denna WAR-fil kan startas direkt via kommandotolken eller kan användas i Servlet Container. WAR är en körbar fil som har en Servlet Container inbäddad i sig.
Steg 2 : Nästa steg är att initiera Hudson webbanvändargränssnitt. För detta måste vi öppna en kommandotolk och gå till mappen där Hudson war hålls.
- Skriv java -jar hudson-3.0.1.war –httpPort = 8099
Ovanstående kommando skulle visa att den ursprungliga installationen krävs på Hudson Dashboard. Se nedanstående skärm.
(Klicka för att förstora bilden)
Obs! Det är tillrådligt att starta Hudson som en tjänst på Windows- eller Linux-maskin.
Steg 3 : För att komma åt Hudson-fönstret, öppna din webbläsare och starta Hudson.
- Skriv “http: // localhost: 8099 /” - Detta öppnar Hudson-fönstret.
(Klicka för att förstora bilden)
Steg 4 : Välj önskade plugins och klicka på Slutför-knappen. Var tålmodig eftersom det troligtvis tar några minuter att installera alla plugins.
Notera : Det finns flera alternativ tillgängliga för att ge support för SCM. Markera SCM-alternativet som du vill använda.
När alla plugins har installerats kan en användare visa Hudson Dashboard.
Hudson-konfiguration
Nu när Hudson Dashboard är klar är nästa steg att konfigurera Hudson. Låt oss återigen diskutera hela processen i steg:
Steg 1 : För att konfigurera Hudson, klicka på länken “Hantera Hudson” som visas i den vänstra menyn.
Steg 2 : Klicka på länken 'Konfigurera system' i nästa steg. Se följande skärmdump.
Steg 3 : Så snart du klickar på länken Konfigurera system, skulle många avsnitt för anslutningsparametrar vara. Lägg till en post i JDK som visas i följande bild. Användaren måste ange namnet på JDK-installationen och platsen där java är installerat. Mer än en Java-instans kan läggas till.
Användaren kan också installera JDK automatiskt genom att markera kryssrutan 'Installera automatiskt'.
Steg 4 : I nästa steg lägger du till en post till Ant som visas i följande bild. Användaren måste ange namnet på Ant-installationen och den plats där Ant installeras lokalt.
Liksom JDK och Ant kan en användare konfigurera andra anslutningsparametrar.
Notera : Kom alltid ihåg att avmarkera kryssrutan 'Installera automatiskt'. Kryssrutan ska vara markerad om du vill ladda ner artefakten från internet.
Konfigurera e-postavisering
Avsnittet om e-postavisering visas i slutet av samma webbsida. Användaren måste konfigurera följande fält:
Klicka på en avancerad knapp för att se alla alternativ relaterade till e-postavisering.
- SMTP-server: SMTP Server lagrar informationen om SMTP Server, dvs. IP-numret eller servernas fullständiga namn. För demonstration: I denna handledning använder vi Gmails SMTP-server.
- Standardanvändarens e-posttillägg : Ett e-postsuffix kan tillhandahållas i det här fältet som kan komma att efterföljas av användarnamnet och kan användas för att skicka e-postmeddelandet.
- Systemadministratörens e-postadress : Admin-e-postadress används som ett avsändar-e-id från vilket alla aviseringar skulle skickas.
- Hudson URL : Om du sannolikt kommer att publicera rapporter eller bygga information inom e-postmeddelandet måste Hudson URL anges. Hudson URL kommer att användas för att komma åt rapporterna. En giltig URL måste anges, men om alla mottagare är anslutna till intranätet kan IP-adressen till den maskin som är värd för Hudson också tillhandahållas.
- Använd SMTP-autentisering : Om du aktiverar det här alternativet kan användarnamn och lösenord visas för autentiseringsändamål.
- Använd SS L: Användaren kan aktivera SSL genom att välja det här alternativet för att ansluta till SMTP-servern.
- SMTP-port: Användaren måste ange portnumret i det här fältet som används för att kommunicera med e-postservern. Om inga portnummer anges, tilldelas standardportnumren.
- Charset : Detta fält specificerar teckenuppsättningen som används för att skriva e-postmeddelanden.
Som vi redan nämnde att vi skulle använda Gmail-e-postservern för att skicka e-postmeddelanden i denna handledning, se följande skärmdumpar och gör nödvändiga ändringar i avsnittet E-postavisering.
Klicka på knappen Spara för att spara alla nyligen gjorda ändringar.
Skapa Hudson-projektet
Nu när vi har installerat och konfigurerat Hudson på våra maskiner ska vi gå vidare och skapa Hudson-projekt. Liksom Hudson-konfiguration har vi flera konfigurationsalternativ för ett Hudson-projekt. I den här handledningen skulle vi belysa de mest användbara och populära alternativ och tillägg.
Följ stegen framåt för att skapa och konfigurera ett nytt Hudson-projekt:
Klicka på alternativet 'Nytt jobb' som visas i menyn till vänster. Följande sida öppnas som visar alternativen relaterade till skapande av projekt och projektstilar.
Det finns många stilar där projektet / jobbet kan skapas. Notera att projekt och jobb kan användas omväxlande eftersom de båda brukar betyda samma sak.
- Bygg en fri programvara jo b: Detta är den vanligaste metoden för att skapa ett nytt Hudson-jobb.
- Bygg jobb med flera konfigurationer : Denna typ av projekt används för att utföra olika jobb.
- Övervaka ett externt jobb : Denna typ av projekt övervakar ett externt jobb.
- Kopiera befintligt jobb : Om vi har ett projekt som liknar ett befintligt projekt kan den här stilen vara till hjälp. Allt du behöver göra är att ange det befintliga jobbets namn och repliken för det här jobbet skulle skapas.
För denna handledning skulle vi dock skapa ett freestyle Hudson-projekt. Skriv in namnet på jobbet du vill skapa och klicka på OK-knappen. Genom att klicka på OK kommer du till Jobbs konfigurationssida enligt nedan:
Konfigurera Hudson-projektet
När vi väl har skapat Hudson-jobbet är det dags att konfigurera det. Liksom Hudson-konfiguration har Hudson Job också olika konfigurationsinställningar. Låt oss diskutera de viktiga här.
För att vara specifik finns det nämligen sex typer av inställningar för att konfigurera ett jobb:
- Allmänna jobbinställningar : Detta avsnitt tillåter användaren att nämna grundläggande information om jobbet. Användaren kan skicka jobbbeskrivningen, inaktivera jobbet, parametrisera jobbet, skräp de äldre byggnaderna och kan utföra mer än en byggnad för samma jobb samtidigt.
- Avancerade jobbalternativ : I det här avsnittet kan användaren konfigurera några avancerade alternativ.
- Källkodshantering : I avsnittet kan du ange inställningar relaterade till källkodshanteringssystemet. Välj ”Ingen” om ingen SCM används. Observera att användaren bara skulle kunna se de SCM-alternativ vars plugin installerades vid installationen av Hudson. För att lägga till mer SCM till Hudson kan en användare besöka sidan Manage Plugins och installera de plugins som krävs.
- Bygg utlösare : I det här avsnittet kan användaren bestämma hur man ska starta byggkörningen.
- Bygga : I det här avsnittet kan användaren tillhandahålla inställningar för byggmekanismen.
- Åtgärder efter byggnaden : I det här avsnittet kan användaren tillhandahålla inställningar för efterbyggda åtgärder som skulle utföras när byggkörningen är klar.
Låt oss ta ett steg framåt och konfigurera jobbet med nödvändiga inställningar. Användaren kan lämna alternativen under 'Allmänna jobbinställningar' och 'Avancerade jobbalternativ' till sitt standardläge.
Konfigurera källkodshantering
Vi har pratat mycket om skapandet av Hudson-projektet i ovanstående avsnitt i denna handledning. Hudson-projekt används vanligtvis med ett verkligt projekt (källkod) som är länkat till ett visst källkodshanteringssystem. Som nämnts i början av denna handledning har Hudson ett stort stöd för en mängd olika SCM. För att nämna några stöder Hudson CVS, Git, SVN etc. I denna handledning kommer vi därför att konfigurera Subversion (SVN) som SCM.
Steg 1 : Välj alternativet 'Subversion'. Så snart användaren väljer Subversion visas följande alternativ.
Steg 2: Nästa steg är att tillhandahålla SVN: s 'Repository URL'. Eftersom jag har skapat en lokal förvaring skulle jag tillhandahålla en lokal förvarings-URL. Ett lokalt arkiv kan skapas med Tortoise SVN.
hur öppnar jag en jar-fil
Behåll alla andra inställningar i detta avsnitt som standard.
Välja bygga utlösare
Nästa steg är att konfigurera build triggers. Hudson låter dig ställa in triggers för att initiera byggkörningsprocessen automatiskt. Användaren kan konfigurera jobbet att bygga automatiskt om något annat projekt / jobb byggs. Alternativt kan användaren också ställa in att build ska köras regelbundet, dvs schemaläggning av build-utförande eller användare kan också schemalägga en build för att leta efter nya åtaganden i SCM och utlösa exekvering om någon av användarna också kan ställa in för att initiera build-körningarna när det finns en uppdatering av mavenberoenden förutsatt att ditt projekt är ett Maven-baserat projekt.
För att ställa in dessa alternativ är allt du behöver göra att välja önskad byggutlösare. Användaren utnyttjas också för att välja mer än ett alternativ åt gången.
När du väljer någon av ovanstående utlösare kan användaren behöva tillhandahålla ytterligare information som är specifik för utlösartypen.
- Bygg efter att andra jobb har byggts: Namnet på de jobb som kan utlösa utförandet av detta jobb bör nämnas.
- Bygg regelbundet: Schemat bör nämnas. Det finns ett specifikt protokoll som måste följas för att nämna schemat. Mer information om schemat visas nedan:
- Poll SCM: Användaren måste ange schemat. Fältet fungerar som 'Bygg periodiskt'.
- Bygg när Maven-beroenden har uppdaterats av Maven 3-integration: Det här avsnittet kräver ingen inmatning.
Mer information finns genom att utöka hjälpikonerna.
Om användaren inte vill ställa in någon av dessa byggutlösare kan han / hon välja att bygga jobbet / projektet manuellt. Allt han / hon behöver göra är att klicka på länken 'Bygg nu' som visas i den vänstra menyn.
Åberopa byggsteg
Nu när vi har sett alla grundläggande steg för att konfigurera ett byggprojekt, låt oss gå vidare och lägga till några fler byggsteg. Detta avsnitt låter användaren definiera sin byggnad med flera byggsteg.
Var och en av byggstegen har sin egen konvention att definiera och åberopa.
Kolla till exempel ANT-anropet nedan:
Konfigurera åtgärder efter byggnaden
Ibland blir det nödvändigt och viktigt att utföra vissa åtgärder efter byggandet. Åtgärder efter byggandet är inget annat än vissa åtgärder som utlöses när byggningen har utförts. Användaren utnyttjas för att utlösa mer än en åtgärd efter byggandet om han / hon önskar.
Som vi alla vet att statuser och rapporter för byggkörning är en av de viktigaste artefakterna eller utgångskriterierna för en programvaruutvecklings livscykel. Därför låter Hudson dig publicera byggkörningsrapporten, generera dokumentation, generera körbara filer / arkiv etc.
Testkörningsrapporter kan publiceras och skickas till intressenterna via e-post. Resultat av denna build kan utlösa körningen av en annan build.
Åtgärder efter byggandet är många, låt oss ta en stund att diskutera de mest grundläggande.
# 1. Aggregerade testresultat nedströms - Inställningen låter användaren sammanställa testkörningsresultaten för detta jobb och nedströmsjobb tillsammans för att producera mer effektfulla testresultat. Allt som användaren behöver göra är att ange namnet på det nedströms jobbet. Om användaren inte vill tillhandahålla något nedströms jobb men ändå vill utnyttja inställningen kan han leda Hudson till att hitta alla nedströmsprojekt.
# 2. Spela in fingeravtryck av filer för att spåra användningen - Inställningen kan användas av användaren för att spåra var en viss fil användes.
# 3. Publicera JUnit-testresultatrapport - Inställningen tillåter användaren att publicera JUnit-testrapporten genom att läsa och förstå den anpassade rapporten som genereras av JUnit. JUnit-testresultatrapporten ger användaren ett webbgränssnitt för att visa de skapade rapporterna. Dessa rapporter kan skickas via e-post till intressenterna. För att aktivera det här alternativet måste användaren tillhandahålla sökvägen till den anpassade rapporten som genereras av JUnit.
# 4. Arkiver artefakterna - Den här inställningen låter användaren skapa artefakter som kan distribueras för vidare användning. Artefakten kan produceras efter varje framgångsrik byggnad. Dessa artefakter kan direkt nås av användaren via webbgränssnittet. Artefakter kan vara släppkörbara filer i form av krigsfiler, jar-filer, zippade eller tjärmappar.
# 5. Publicera Javadoc - Med den här inställningen kan du publicera java-dokumentet till kunder och användare på Hudson-webbgränssnittet förutsatt att ditt projekt genererar java-dokumentet. För att aktivera detta alternativ måste en användare ange platsen för Java Doc mot Javadoc-katalogen.
Om användaren markerar alternativet ”Behåll Javadoc för varje framgångsrik byggnad” sparas den nyligen genererade Javadoc i den angivna mappen. Således skulle alla Javadocs som motsvarar den framgångsrika byggnaden bibehållas.
# 6. Bygg andra jobb - Inställningen låter användaren utlösa körningen av andra jobb när det här jobbet har utförts. Användaren kan utlösa körning av mer än ett jobb samtidigt. Inställningen kan vara till hjälp för att köra enhetstest- och integrationstestscenarier. Användaren kan även ställa in alternativet att bygga andra jobb även om det här jobbet misslyckas (instabil).
# 7. Publicera Coberturas täckningsrapport - Cobertura är ett java-baserat testverktyg som analyserar kodtäckningen för ditt projekt, dvs den bedömer procentandelen kod som täcks av testerna. Därför tillåter inställningen användaren att generera en rapport med kodtäckningsanalys. Inställningen kräver några parametrar innan du kan få en fullfjädrad testrapport om kodtäckning. Observera att den här inställningen inte kommer som standard, det vill säga det kräver att ett plugin installeras (vilket vi gjorde vid installationen eftersom det i allmänhet är en del av de föreslagna pluginsna).
(Klicka på bilden för att förstora)
# 8. E-postmeddelande - E-postavisering är en av de viktigaste åtgärderna efter byggandet. Alternativet låter användaren skicka e-postmeddelanden för build till intressenterna (utvecklare, testare, produktägare etc.) genom att konfigurera deras e-post-id. Hudson kan skicka e-postmeddelandet när byggnaden är instabil, lyckad, misslyckades etc. Användaren kan också ställa in utlösare för e-postmeddelanden. Meddelande-e-postmeddelandet kan skickas till mer än en mottagare samtidigt bara genom att ange ett vitt mellanrum mellan deras e-post-ID. Se skärmdumpen nedan för att kontrollera hur dessa inställningar kan tillhandahållas.
(Klicka på bilden för att förstora)
Anmärkningar:
- Användaren kan när som helst komma tillbaka till den här sidan och ändra inställningarna vid behov.
- Användaren kan visa informationen om varje alternativ i hjälpikonen som är kopplad till den.
- Användaren kan lägga till fler efterbyggda åtgärder med hjälp av plugins.
Slutsats
I denna handledning gjorde vi dig bekant med begreppet kontinuerlig integration. Vi betonade också dess betydelse under en livscykel för programvaruutveckling, särskilt i utvecklarens eller testarens liv.
Nästa handledning # 26 : Att gå vidare i serien skulle vi göra diskutera några avancerade Selen-koncept som direkt eller indirekt skulle hjälpa till att optimera ramverket för automatisering och ger användarna mer synlighet. Således, i nästa handledning, skulle vi diskutera loggningsfunktionen, dess potential, felsökningsfunktioner och mycket mer.
Notera: Denna handledning är en del av såväl Selen som DevOps handledningsserier. Klicka på länken nedan för tidigare och nästa handledning från DevOps-serien.
PREV-handledning | NÄSTA självstudie
Rekommenderad läsning
- Gurka Selen Tutorial: Gurka Java Selen WebDriver Integration
- Fördjupade förklaringar om förmörkelser för nybörjare
- Integration av selen med JMeter
- Automatiseringstestning med gurkaverktyg och selen - Selenhandledning # 30
- Spock för integration och funktionstestning med selen
- Användning av Maven Build Automation Tool och Maven Project Setup för Selen - Selen Tutorial # 24
- Integration av Jenkins med Selen WebDriver: Steg-för-steg-handledning
- Introduktion till Selen WebDriver - Selen Tutorial # 8