hudson continuous integration tool tutorial selenium tutorial 25
I de to siste opplæringene i Selen-serien diskuterte vi de to viktigste byggeverktøyene - MAUR og Maven . Vi diskuterte deres betydning og praktiske betydning.
I vår forrige opplæring i DevOps-serien lærte vi om Integrering av Jenkins med Selen .
I den nåværende Selen online opplæringsveiledning , ville vi diskutere en kontinuerlig integrasjonsverktøy kjent som Hudson .
Les gjennom => Eksemplarisk guide på DevOps
Merk: Denne opplæringen er en del av Selen samt DevOps opplæringsserie. Klikk på de aktuelle koblingene for å navigere til den aktuelle serien.
Vi vil studere dens betydning og fordeler som vi får ut av ethvert kontinuerlig integrasjonsverktøy . Vi vil se på Hudson rett fra begynnelsen, fra installasjonen til de avanserte innstillingene.
Hva du vil lære:
- Kontinuerlig integrering
- Hudson - kontinuerlig integrasjonsverktøy
- Hudson Installasjon
- Hudson-konfigurasjon
- Konfigurerer e-postvarsling
- Opprette Hudson-prosjektet
- Konfigurerer Hudson Project
- Konfigurere kildekodebehandling
- Velge Build Triggers
- Påkalle byggetrinn
- Konfigurere handlinger etter bygging
- Konklusjon
- Anbefalt lesing
Kontinuerlig integrering
Mange ganger slutter vi med å jobbe med et prosjekt der en stor mengde utviklere og testere jobber sammen om forskjellige moduler. Utviklere og testere jobber med modulene sine og utvikler kjørbare filer. Disse arbeidsproduktene integreres deretter med jevne mellomrom. Derfor må den integreres, testes og bygges hver gang vi lager en utviklingskode for å sikre at den utviklede koden ikke går i stykker eller introduserer feil eller mangler.
Denne prosessen med å bygge og teste utviklingsarbeidet integrert med jevne mellomrom er kjent som Kontinuerlig integrasjon (CI) . Kontinuerlig integrasjon lar deg identifisere og adressere feilene eller feilene så snart som mulig i utviklingslivssyklusen, dvs. nærmere tiden de ble introdusert.
Kontinuerlig integrasjonssystem bygger og tester applikasjonen så snart den nye / endrede koden er forpliktet til Source Control Management-systemets akronym som SCM. Med sine store fordeler og innvirkning over bransjene, har det blitt en integrert del av programvareutviklingens livssyklus og praktiseres obligatorisk.
Hudson - kontinuerlig integrasjonsverktøy
Kontinuerlig integrering kan utføres automatisk. Hudson er et av de populære verktøyene for å utføre kontinuerlig integrasjon. Hudson er et Java-basert åpen kildekode kontinuerlig integrasjonsverktøy. Som alle andre kontinuerlige integrasjonsverktøy, gir Hudson teamene til å utløse builds og tester med endringer i Source Control Management System.
Hudson støtter et stort utvalg av verktøy og plugins.
Hudson:
- Støtter SCM-verktøy som CVS, Subversion (SVN), Git etc.
- Er i stand til å bygge ANT-baserte prosjekter, Maven-baserte prosjekter etc.
- Er i stand til å utføre skallskript og Windows-batchkommandoer
- Er i stand til å sende rapporter, varsler osv. Via e-post, SMS, Skype etc.
Hudson Installasjon
Forutsetninger
For å kunne bruke Hudson, trenger vi følgende ting for å være på plass før vi setter i gang:
- Source Code Repository (SVN / Git / CVS etc.)
- Bygg skript (Ant / Maven etc.)
Installasjon
Hudson kan enkelt installeres i en rekke miljøer. Hudson kan installeres på både Linux-maskinen og Windows-maskinen. Den distribueres også som en pakke spesifikk for OS-typen for forskjellige Linux-smaker, noe som gjør installasjonen til noen få oppgaver. Hudson kan kjøres som et frittstående program eller i Servlet Container. I denne opplæringen vil vi forklare Hudson-installasjonen på Windows-maskinen. Det er to forskjellige tilnærminger for å installere Hudson.
- Bruker WAR-fil
- Bruke Native Package
Innfødte pakker er tilgjengelige for Ubuntu / Debian, Oracle Linux, Redhat / Fedora / CentOS og openSUSE.
For denne opplæringen vil vi diskutere installasjon etter WAR-fil. La oss diskutere hele prosessen trinn for trinn.
Trinn 1 : Last ned Hudson WAR-filen fra Hudsons offisielle nettside - “ http://hudson-ci.org/ ”. Hold krigsfilen på ønsket sted i det lokale filsystemet. Denne WAR-filen kan startes direkte via ledeteksten eller kan brukes i Servlet Container. WAR er en kjørbar fil som har en Servlet Container innebygd i seg selv.
Steg 2 : Det neste trinnet er å initialisere Hudson nettbrukergrensesnitt. For dette må vi åpne en ledetekst og gå til mappen der Hudson-krigen holdes.
- Skriv java -jar hudson-3.0.1.war –httpPort = 8099
Ovennevnte kommando vil vise at det første oppsettet er påkrevd på Hudson Dashboard. Se skjermbildet nedenfor.
(Klikk for å forstørre bildet)
Merk: Det anbefales å starte Hudson som en tjeneste på Windows- eller Linux-maskin.
Trinn 3 : For å få tilgang til Hudson-vinduet, åpne nettleseren din og start Hudson.
- Skriv “http: // localhost: 8099 /” - Dette åpner Hudson-vinduet.
(Klikk for å forstørre bildet)
Trinn 4 : Velg de ønskede plugins og klikk på Finish-knappen. Vær tålmodig da det sannsynligvis vil ta noen minutter å installere alle pluginene.
Merk : Det er flere alternativer tilgjengelig for å gi støtte til SCM. Merk av for SCM-alternativet du vil bruke.
Når alle pluginene er installert, kan en bruker se Hudson Dashboard.
Hudson-konfigurasjon
Nå som Hudson Dashboard er klart, er neste trinn å konfigurere Hudson. La oss igjen diskutere hele prosessen i trinn:
Trinn 1 : For å konfigurere Hudson, klikk på lenken “Manage Hudson” som vises i menyen til venstre.
Steg 2 : Klikk på 'Konfigurer system' -linken i neste trinn. Se følgende skjermbilde.
Trinn 3 : Så snart du klikker på Konfigurer systemkoblingen, vil mange seksjoner for tilkoblingsparametere være. Legg til en oppføring i JDK som vist i følgende figur. Brukeren må oppgi navnet på JDK-installasjonen og stedet der java er installert. Mer enn én Java-forekomst kan legges til.
Brukeren kan også installere JDK automatisk ved å merke av for 'Installer automatisk'.
Trinn 4 : I neste trinn legger du til en oppføring i Ant som vist i følgende figur. Brukeren må oppgi navnet på Ant-installasjonen og stedet der Ant blir installert lokalt.
Som JDK og Ant kan en bruker konfigurere andre tilkoblingsparametere.
Merk : Husk alltid å fjerne merket for 'Installer automatisk'. Avkrysningsruten bør velges i tilfelle hvis du ønsker å laste ned gjenstanden fra internett.
Konfigurerer e-postvarsling
E-postvarslingsdelen vises på slutten av samme nettside. Brukeren må konfigurere følgende felt:
Klikk på en avansert knapp for å se alle alternativene knyttet til e-postvarsling.
- SMTP-server: SMTP Server lagrer informasjonen om SMTP Server, dvs. IP-nummeret eller det fullstendige navnet på serveren. For demonstrasjon, I denne veiledningen vil vi bruke Gmails SMTP-server.
- Standard bruker-e-post-suffiks : Det kan gis et e-post-suffiks i dette feltet, som kan være suffiks med brukernavnet og kan brukes til å sende e-postvarselet.
- Systemadministratorens e-postadresse : Admin-e-postadresse brukes som en avsender-e-post-ID der alle varslene vil bli sendt.
- Hudson URL : Hvis du sannsynligvis vil publisere rapporter eller bygge informasjon i e-postvarslingen, må Hudson URL oppgis. Hudson URL vil bli brukt til å få tilgang til rapportene. En gyldig URL må oppgis, men hvis alle mottakerne er koblet til intranettet, kan IP-adressen til maskinen som er vert for Hudson også oppgis.
- Bruk SMTP-godkjenning : Hvis du aktiverer dette alternativet, kan brukernavnet og passordfeltet vises for autentiseringsformål.
- Bruk SS L: Bruker kan aktivere SSL ved å velge dette alternativet for å koble til SMTP-serveren.
- SMTP-port: Brukeren må oppgi portnummeret i dette feltet som brukes til å kommunisere med e-postserveren. Hvis ingen portnumre er spesifisert, tildeles standardportnumrene.
- Charset : Dette feltet spesifiserer tegnsettet som brukes til å komponere e-post.
Som vi allerede har nevnt at vi bruker Gmail-postserveren til å sende e-postvarsler i denne opplæringen, kan du se følgende skjermbilder og gjøre de nødvendige endringene i delen E-postvarsling.
Klikk på Lagre-knappen for å lagre alle de nylig gjort endringene.
Opprette Hudson-prosjektet
Nå som vi har installert og konfigurert Hudson på maskinene våre, skal vi gå videre og lage Hudson-prosjekter. Som Hudson-konfigurasjon har vi flere konfigurasjonsalternativer for et Hudson-prosjekt. I denne veiledningen vil vi belyse de mest nyttige og mest brukte alternativene og utvidelsene.
For å opprette og konfigurere et nytt Hudson-prosjekt, følg trinnene fremover:
Klikk på alternativet 'Ny jobb' som vises i menyen til venstre. Den neste siden åpnes som viser alternativene knyttet til prosjektopprettelse og prosjektstiler.
Det er mange stiler der prosjektet / jobben kan opprettes. Legg merke til at prosjekt og jobb kan brukes om hverandre, ettersom de begge har en tendens til å bety det samme.
- Bygg en gratis stil programvare jo b: Dette er den mest brukte metoden for å lage en ny Hudson-jobb.
- Bygg jobb med flere konfigurasjoner : Denne stilen på prosjektet brukes til å utføre forskjellige jobber.
- Overvåk en ekstern jobb : Denne stilen på prosjektet overvåker en ekstern jobb.
- Kopier eksisterende jobb : Hvis vi har et prosjekt som ligner på et eksisterende prosjekt, kan denne stilen være nyttig. Alt du trenger å gjøre er å spesifisere navnet på den eksisterende jobben, og kopien til denne jobben vil bli opprettet.
Imidlertid, for denne opplæringen, ville vi lage et freestyle Hudson-prosjekt. Skriv inn navnet på jobben du vil opprette, og klikk på OK-knappen. Ved å klikke OK kommer du til Jobbs konfigurasjonsside som vist nedenfor:
Konfigurerer Hudson Project
Når vi har opprettet Hudson-jobben, er det på tide å konfigurere den. I likhet med Hudson-konfigurasjon har Hudson Job også fått forskjellige konfigurasjonsinnstillinger. La oss diskutere de viktige her.
For å være spesifikk, er det nemlig seks typer innstillinger for å konfigurere en jobb:
- Generelle jobbinnstillinger : Denne delen lar brukeren nevne grunnleggende informasjon om jobben. Brukeren kan sende inn jobbbeskrivelsen, deaktivere jobben, parametere jobben, kaste de eldre byggene og kan utføre mer enn en versjon for den samme jobben samtidig.
- Avanserte jobbalternativer : Denne delen lar brukeren konfigurere noen avanserte alternativer.
- Kildekodestyring : Denne delen lar deg angi innstillingene knyttet til kildekodestyringssystemet. Velg “Ingen” hvis ingen SCM brukes. Legg merke til at brukeren bare kunne se de SCM-alternativene hvis plugin ble installert på tidspunktet for Hudson-installasjonen. For å legge til mer SCM til Hudson, kan en bruker gå til Manage Plugins-siden og installere de nødvendige plugins.
- Bygg utløsere : Denne delen lar brukeren bestemme hvordan man skal starte utførelsen av byggingen.
- Bygge : Denne delen lar brukeren angi innstillinger for byggemekanismen.
- Handlinger etter bygging : Denne delen lar brukeren angi innstillinger for handlingene etter bygging som vil bli utført når byggekjøringen er fullført.
La oss ta et skritt foran og konfigurere jobben med de nødvendige innstillingene. Brukeren kan la alternativene under “Generelle jobbinnstillinger” og “Avanserte jobbalternativer” til standardstatus.
Konfigurere kildekodebehandling
Vi har snakket mye om etableringen av Hudson-prosjektet i avsnittene ovenfor i denne opplæringen. Hudson-prosjekt brukes vanligvis med et faktisk prosjekt (kildekode) som er koblet til et bestemt kildekodestyringssystem. Som nevnt i begynnelsen av denne opplæringen, har Hudson stor støtte til en rekke SCM-er. For å nevne noen støtter Hudson CVS, Git, SVN etc. I denne opplæringen vil vi konfigurere Subversion (SVN) som SCM.
Trinn 1 : Velg alternativet 'Subversion'. Så snart brukeren velger Subversion, vises følgende alternativer.
Steg 2: Neste trinn er å gi SVNs 'Repository URL'. Ettersom jeg har opprettet et lokalt depot, vil jeg oppgi en lokal repository URL. Et lokalt lager kan opprettes ved hjelp av Tortoise SVN.
beste gratis Windows 10 oppryddingsverktøyet
Hold alle de andre innstillingene i denne delen som standard.
Velge Build Triggers
Det neste trinnet er å konfigurere build-utløserne. Hudson lar deg sette utløsere for å starte byggekjøringsprosessen automatisk. Brukeren kan konfigurere jobben til å bygge automatisk hvis et annet prosjekt / jobb bygges. Alternativt kan brukeren også angi at build skal kjøres med jevne mellomrom, dvs. planlegge build-utførelse, eller bruker kan også planlegge en build for å se etter nye forpliktelser i SCM og utløse kjøring hvis noen av brukerne også kan angi å starte build-utførelsene når det er en oppdatering i maven-avhengighetene forutsatt at prosjektet ditt er et Maven-basert prosjekt.
For å angi disse alternativene, er alt du trenger å gjøre å velge ønsket utløser. Brukeren brukes også til å velge mer enn ett alternativ om gangen.
Mens du velger noen av de ovennevnte utløserne, kan det hende at brukeren må oppgi litt tilleggsinformasjon som er spesifikk for utløsertypen.
- Bygg etter at andre jobber er bygd: Navnet på jobbene som kan utløse utførelsen av denne jobben, bør nevnes.
- Bygg med jevne mellomrom: Tidsplanen bør nevnes. Det er en spesifikk protokoll som må følges for å nevne tidsplanen. Mer informasjon om Schedule er vist nedenfor:
- Avstemning SCM: Brukeren må spesifisere tidsplanen. Feltet fungerer på samme måte som 'Bygg periodisk'.
- Bygg når Maven-avhengigheter er oppdatert av Maven 3-integrering: Denne delen krever ingen innspill.
Mer informasjon kan du finne ved å utvide Hjelp-ikonene.
Hvis brukeren ikke ønsker å angi noen av disse byggutløserne, kan han / hun bestemme seg for å bygge jobben / prosjektet manuelt. Alt han / hun må gjøre er å klikke på 'Bygg nå' -linken som vises i menyen til venstre.
Påkalle byggetrinn
Nå som vi har sett alle de grunnleggende trinnene for å konfigurere et byggeprosjekt, la oss gå videre og legge til noen flere byggetrinn. Denne delen lar brukeren definere sin bygging med flere byggetrinn.
Hver av byggetrinnene har sin egen konvensjon å definere og påkalle.
Sjekk for eksempel ANT-anropet nedenfor:
Konfigurere handlinger etter bygging
Noen ganger blir det nødvendig og viktig å utføre visse handlinger etter byggingen. Handlinger etter bygging er ikke annet enn noen handlinger, de utløses når bygningen er utført. Brukeren er utnyttet for å utløse mer enn én handling etter byggingen hvis han / hun ønsker det.
Som vi alle vet, er status for utførelse av bygg og rapporter en av de viktigste artefakter eller utgangskriterier for en programvaresyklus. Derfor lar Hudson deg publisere byggekjøringsrapporten, generere dokumentasjon, generere kjørbare filer / arkiver etc.
Testutførelsesrapporter kan publiseres og sendes videre til interessentene via e-post. Resultatene av denne versjonen kan utløse kjøringen av en annen versjon.
Handlinger etter byggingen er mange, la oss ta et øyeblikk for å diskutere de mest grunnleggende.
#1. Samlede resultatene for nedstrøms test - Innstillingen lar brukeren samle testutførelsesresultatene for denne jobben og nedstrømsjobber sammen for å gi mer effektive testresultater. Alt brukeren trenger å gjøre er å oppgi navnet på nedstrømsjobben. I tilfelle hvis brukeren ikke ønsker å gi noen nedstrøms jobb, men likevel ønsker å utnytte innstillingen, kan han lede Hudson til å finne alle nedstrøms prosjekter.
# 2. Ta opp fingeravtrykk av filer for å spore bruk - Innstillingen kan brukes av brukeren til å spore hvor en bestemt fil ble brukt.
# 3. Publiser JUnit testresultatrapport - Innstillingen lar brukeren publisere JUnit-testrapporten ved å lese og forstå den tilpassede rapporten generert av JUnit. JUnit-testresultatrapporten gir brukeren et webgrensesnitt for å se de opprettet rapportene. Disse rapportene kan sendes via e-post til interessentene. For å aktivere dette alternativet, er alt brukeren er pålagt å oppgi stien til den tilpassede rapporten generert av JUnit.
# 4. Arkivere gjenstandene - Denne innstillingen lar brukeren lage gjenstander som kan distribueres for videre bruk. Artefakten kan produseres etter hver vellykket bygging. Disse gjenstandene kan brukeren få direkte tilgang til via nettgrensesnittet. Artefakter kan være utgivelige kjørbare filer i form av krigsfiler, jar-filer, zippede eller tjæremapper.
# 5. Publiser Javadoc - Denne innstillingen lar deg publisere Java-dokumentet til kunder og brukere på Hudson-nettgrensesnittet, forutsatt at prosjektet ditt genererer Java-dokumentet. For å aktivere dette alternativet, må en bruker oppgi plasseringen til Java Doc mot Javadoc-katalogen.
Hvis brukeren merker av for å merke alternativet “Behold Javadoc for hver vellykkede build”, vil den nylig genererte Javadoc bli lagret i den angitte mappen. Dermed vil alle Javadocs som tilsvarer den vellykkede bygningen opprettholdes.
# 6. Bygg andre jobber - Innstillingen lar brukeren utløse utførelsen av andre jobber når denne jobben er utført. Brukeren kan utløse kjøring av mer enn en jobb samtidig. Innstillingen kan være nyttig for å utføre testtest scenarier for enhetstest og integrering. Brukeren kan til og med angi muligheten til å bygge andre jobber selv om denne jobben mislykkes (ustabil).
# 7. Publiser Cobertura Coverage Report - Cobertura er et java-basert testverktøy som analyserer kodedekningen av prosjektet ditt, dvs. det vurderer prosentandelen av kode som testene dekker. Dermed tillater innstillingen brukeren å generere en rapport med kodedekningsanalyse. Innstillingen krever noen parametere før du kan få en fullverdig testrapport om kodedekning. Vær oppmerksom på at denne innstillingen ikke kommer som standard, det vil si at det kreves at et plugin installeres (som vi gjorde på installasjonstidspunktet, da det vanligvis er en del av de foreslåtte plugins).
(Klikk på bildet for å forstørre)
# 8. E-postvarsling - E-postvarsling er en av de viktigste handlingene etter byggingen. Alternativet lar brukeren sende e-postmeldingen om bygging til interessentene (utviklere, testere, produkteiere osv.) Ved å konfigurere e-post-ID-ene. Hudson kan sende e-posten når bygningen er ustabil, vellykket, mislyktes osv. Brukeren kan også angi utløsere for e-postvarsler. Varslings-e-posten kan sendes til mer enn én mottaker samtidig bare ved å gi et mellomrom mellom e-post-ID-ene. Se skjermbildet nedenfor for å sjekke hvordan disse innstillingene kan leveres.
(Klikk på bildet for å forstørre)
Merknader:
- Brukeren kan når som helst komme tilbake til denne siden og endre innstillingene om nødvendig.
- Brukeren kan se informasjonen om hvert alternativ i hjelpikonet som er tilknyttet det.
- Brukeren kan legge til flere handlinger etter byggingen ved hjelp av plugins.
Konklusjon
I denne veiledningen gjorde vi deg kjent med begrepet kontinuerlig integrasjon. Vi la også vekt på dens betydning under en livssyklus for programvareutvikling, spesielt i utviklerens eller testers liv.
Neste opplæring # 26 : Å gå videre i serien, ville vi diskutere noen avanserte Selen-konsepter som direkte eller indirekte kan bidra til å optimalisere Automation-rammeverket og gir mer synlighet for brukerne. Dermed vil vi i neste opplæring diskutere loggingsfunksjonen, dens potensial, feilsøkingsfunksjoner og mye mer.
Merk: Denne opplæringen er en del av Selen samt DevOps opplæringsserie. Klikk på lenken nedenfor for forrige og neste opplæring fra DevOps-serien.
PREV Opplæring | NESTE veiledning
Anbefalt lesing
- Agurk Selen Tutorial: Agurk Java Selen WebDriver Integration
- In-Depth Eclipse Tutorials For Beginners
- Integrering av selen med JMeter
- Automatiseringstesting ved hjelp av agurkverktøy og selen - Selenveiledning nr. 30
- Spock for integrering og funksjonstesting med selen
- Bruk av Maven Build Automation Tool og Maven Project Setup for Selenium - Selen Tutorial # 24
- Integrasjon av Jenkins med Selenium WebDriver: trinnvis veiledning
- Introduksjon til Selen WebDriver - Selenium Tutorial # 8