Hva er Jenkins?
Jenkins er en kontinuerlig integrasjonsserver med åpen kildekode som er i stand til å organisere en kjede av handlinger som hjelper til med å oppnå kontinuerlig integrasjonsprosess (og ikke bare) på en automatisk måte.
Jenkins er gratis og er helt skrevet på Java. Jenkins er et mye brukt program over hele verden som har rundt 300 000 installasjoner og vokser dag for dag.
Det er et serverbasert program og krever en webserver som Apache Tomcat. Årsaken til at Jenkins ble så populær er at den overvåker gjentatte oppgaver som oppstår under utviklingen av et prosjekt. For eksempel, hvis teamet ditt utvikler et prosjekt, vil Jenkins kontinuerlig teste prosjektbygningene dine og vise deg feilene i de tidlige stadiene av utviklingen din.
Ved å bruke Jenkins kan programvareselskaper akselerere programvareutviklingsprosessen, ettersom Jenkins kan automatisere bygging og test i rask hastighet. Jenkins støtter den komplette utviklingslivssyklusen til programvare fra å bygge, teste, dokumentere programvaren, distribuere og andre trinn i en livssyklus for programvareutvikling.
I denne veiledningen vil du lære
- Hva er Jenkins?
- Hva er kontinuerlig integrasjon?
- Jenkin Historie
- Hvorfor bruke kontinuerlig integrasjon med Jenkins?
- Virkelig casestudie av kontinuerlig integrasjon
- Fordeler med å bruke Jenkins
- Ulemper ved å bruke Jenkins
Hva er kontinuerlig integrasjon?
I kontinuerlig integrasjon etter at en kode er forpliktet, blir programvaren bygget og testet umiddelbart. I et stort prosjekt med mange utviklere blir forpliktelser gjort mange ganger i løpet av en dag. For hver kommitekode bygges og testes. Hvis testen er bestått, blir build testet for distribusjon. Hvis distribusjon er en suksess, skyves koden til produksjon. Denne forpliktelsen, bygge, teste og distribuere er en kontinuerlig prosess og derav navnet kontinuerlig integrering / distribusjon.
En kontinuerlig integrasjonsrørledning er et kraftig instrument som består av et sett med verktøy designet for å være vert , overvåke , kompilere og teste kode, eller kodeendringer, som:
- Kontinuerlig integrasjonsserver (Jenkins, Bamboo, CruiseControl, TeamCity og andre)
- Source Control Tool (f.eks. CVS, SVN, GIT, Mercurial, Perforce, ClearCase og andre)
- Bygg verktøy (Make, ANT, Maven, Ivy, Gradle og andre)
- Rammeverk for automatiseringstesting (Selen, Appium, TestComplete, UFT og andre)
Jenkin Historie
- Kohsuke Kawaguchi, en Java-utvikler, som jobbet i SUN Microsystems, var lei av å bygge koden og fikse feil gjentatte ganger. I 2004 opprettet en automatiseringsserver kalt Hudson som automatiserer bygge- og testoppgaver.
- I 2011 hadde Oracle som eide Sun Microsystems en tvist med Hudson open source-fellesskap, så de forkaster Hudson og omdøper det til Jenkins.
- Både Hudson og Jenkins fortsatte å operere uavhengig. Men på kort tid kjøpte Jenkins mange prosjekter og bidragsytere, mens Hudson forble med bare 32 prosjekter. Med tiden ble Jenkins mer populær, og Hudson vedlikeholdes ikke lenger.
Hvorfor bruke kontinuerlig integrasjon med Jenkins?
Noen tror kanskje at den gammeldagse måten å utvikle programvaren på er den bedre måten. La oss forstå fordelene med CI med Jenkins med følgende eksempel
La oss forestille oss at det er rundt 10 utviklere som jobber med et delt depot. Noen utviklere fullfører oppgaven på 25 dager, mens andre tar 30 dager å fullføre.
Før Jenkins | Etter Jenkins |
---|---|
Når alle utviklere hadde fullført sine tildelte kodingsoppgaver, pleide de å begå koden sin samtidig. Senere blir Build testet og distribuert. Code commit bygget, og testsyklusen var veldig sjelden, og en enkelt build ble gjort etter mange dager. | Koden bygges og testes så snart utvikler begår kode. Jenkin vil bygge og teste kode mange ganger i løpet av dagen. Hvis build er vellykket, vil Jenkins distribuere kilden til testserveren og varsle distribusjonsteamet. Hvis build mislykkes, vil Jenkins varsle feilene til utviklerteamet. |
Siden koden ble bygget på en gang, vil noen utviklere måtte vente til andre utviklere er ferdige med å kode for å sjekke deres bygg | Koden bygges umiddelbart etter at noen av utviklerne forplikter seg. |
Det er ikke en enkel oppgave å isolere, oppdage og fikse feil for flere forpliktelser. | Siden koden er bygd etter hver kommisjon fra en enkelt utvikler, er det lett å oppdage hvis kode forårsaket at bygningen mislyktes |
Kodebygging og testprosess er helt manuell, så det er mange sjanser for feil. | Automatisert bygging og test prosessbesparende timing og redusering av mangler. |
Koden distribueres når alle feilene er løst og testet. | Koden distribueres etter hver vellykket bygging og test. |
Utviklingssyklusen går sakte | Utviklingssyklusen er rask. Nye funksjoner er lettere tilgjengelig for brukere. Øker fortjenesten. |
Virkelig casestudie av kontinuerlig integrasjon
Jeg er sikker på at dere alle er klar over den gamle Nokia-telefonen. Nokia pleide å implementere en prosedyre som heter nightly build. Etter flere forpliktelser fra forskjellige utviklere i løpet av dagen, ble programvaren bygget hver natt. Siden programvaren ble bygget bare en gang om dagen, er det en stor smerte å isolere, identifisere og fikse feilene i en stor kodebase.
Senere vedtok de kontinuerlig integrasjonsmetode. Programvaren ble bygget og testet så snart en utvikler forpliktet seg til kode. Hvis det oppdages en feil, kan den respektive utvikleren raskt fikse feilen.
Jenkins Plugins
Som standard kommer Jenkins med et begrenset sett med funksjoner. Hvis du vil integrere Jenkins-installasjonen din med versjonskontrollverktøy som Git, må du installere plugins relatert til Git. Faktisk, for integrering med verktøy som Maven, Amazon EC2, må du installere respektive plugins i Jenkins.

Fordeler med å bruke Jenkins
- Jenkins administreres av samfunnet som er veldig åpent. Hver måned holder de offentlige møter og tar innspill fra publikum for utviklingen av Jenkins-prosjektet.
- Så langt er rundt 280 billetter stengt, og prosjektet publiserer stabil utgivelse hver tredje måned.
- Etter hvert som teknologien vokser, gjør Jenkins det også. Så langt har Jenkins rundt 320 plugins publisert i sin plugins-database. Med plugins blir Jenkins enda kraftigere og funksjonsrik.
- Jenkins støtter også skybasert arkitektur slik at du kan distribuere Jenkins i skybaserte plattformer.
- Årsaken til at Jenkins ble populær er at den ble opprettet av en utvikler for utviklere.
Ulemper ved å bruke Jenkins
Selv om Jenkins er et veldig kraftig verktøy, har det sine mangler.
- Grensesnittet er utdatert og ikke brukervennlig sammenlignet med dagens UI-trender.
- Selv om Jenkins er elsket av mange utviklere, er det ikke så lett å vedlikeholde det fordi Jenkins kjører på en server og krever noen ferdigheter som serveradministrator for å overvåke aktiviteten.
- En av grunnene til at mange ikke implementerer Jenkins, er på grunn av vanskeligheter med å installere og konfigurere Jenkins.
- Kontinuerlige integrasjoner brytes regelmessig på grunn av noen små innstillingsendringer. Kontinuerlig integrering blir satt på pause og krever derfor noe utvikler oppmerksomhet.
Konklusjon:
- I kontinuerlig integrasjon, etter at en kode er blitt begått, blir programvaren bygget og testet umiddelbart
- Jenkins er en åpen kildekode kontinuerlig integrasjonsserver som er i stand til å organisere en kjede av handlinger
- Før Jenkins, da alle utviklere hadde fullført sine tildelte kodingsoppgaver, pleide de å begå koden sin samtidig. Senere blir Build testet og distribuert.
- Etter Jenkins blir koden bygget og test så snart utvikler begår kode. Jenkin vil bygge og teste kode mange ganger i løpet av dagen
- Som standard kommer Jenkins med et begrenset sett med funksjoner. Hvis du vil integrere Jenkins-installasjonen din med versjonskontrollverktøy som Git, må du installere plugins relatert til Git
- De største fordelene med Jenkins er at den styres av samfunnet som holder offentlige møter og tar innspill fra publikum for utvikling av Jenkins-prosjekter.
- Den største ulempen med Jenkin er at grensesnittet er utdatert og ikke brukervennlig sammenlignet med dagens UI-trender.