Hvad er Jenkins?
Jenkins er en open source kontinuerlig integrationsserver, der er i stand til at organisere en kæde af handlinger, der hjælper med at opnå den kontinuerlige integrationsproces (og ikke kun) på en automatisk måde.
Jenkins er gratis og er udelukkende skrevet på Java. Jenkins er en meget anvendt applikation over hele verden, der har omkring 300.000 installationer og vokser dag for dag.
Det er en serverbaseret applikation og kræver en webserver som Apache Tomcat. Årsagen til, at Jenkins blev så populær, er, at den overvåger gentagne opgaver, der opstår under udviklingen af et projekt. For eksempel, hvis dit team udvikler et projekt, vil Jenkins løbende teste dine projektbygninger og vise dig fejlene i de tidlige stadier af din udvikling.
Ved at bruge Jenkins kan softwarevirksomheder fremskynde deres softwareudviklingsproces, da Jenkins kan automatisere opbygning og test i hurtig tempo. Jenkins understøtter den komplette udviklingslivscyklus af software fra opbygning, test, dokumentation af softwaren, implementering og andre faser af en softwareudviklings livscyklus.
I denne vejledning lærer du
- Hvad er Jenkins?
- Hvad er kontinuerlig integration?
- Jenkin Historie
- Hvorfor bruge kontinuerlig integration med Jenkins?
- Virkelig casestudie af kontinuerlig integration
- Fordele ved at bruge Jenkins
- Ulemper ved at bruge Jenkins
Hvad er kontinuerlig integration?
I kontinuerlig integration efter en kodeforpligtelse bygges og testes softwaren med det samme. I et stort projekt med mange udviklere foretages forpligtelser mange gange i løbet af en dag. Med hver commit-kode bygges og testes. Hvis testen er bestået, testes build til implementering. Hvis implementering er en succes, skubbes koden til produktion. Denne forpligtelse, opbygning, test og implementering er en kontinuerlig proces og dermed navnet kontinuerlig integration / implementering.
En kontinuerlig integrationsrørledning er et kraftfuldt instrument, der består af et sæt værktøjer designet til at være vært , overvåge , kompilere og teste kode eller kodeændringer som:
- Kontinuerlig integrationsserver (Jenkins, Bamboo, CruiseControl, TeamCity og andre)
- Source Control Tool (f.eks. CVS, SVN, GIT, Mercurial, Perforce, ClearCase og andre)
- Byg værktøj (Make, ANT, Maven, Ivy, Gradle og andre)
- Framework til automatiseringstest (Selen, Appium, TestComplete, UFT og andre)
Jenkin Historie
- Kohsuke Kawaguchi, en Java-udvikler, der arbejder hos SUN Microsystems, var træt af at opbygge koden og rette gentagne gange fejl. I 2004 oprettede en automatiseringsserver kaldet Hudson, der automatiserer bygge- og testopgaver.
- I 2011 havde Oracle, der ejede Sun Microsystems, en tvist med Hudson open source-samfund, så de forkælede Hudson og omdøbte det til Jenkins.
- Både Hudson og Jenkins fortsatte med at operere uafhængigt. Men på kort tid erhvervede Jenkins mange projekter og bidragsydere, mens Hudson forblev med kun 32 projekter. Med tiden blev Jenkins mere populær, og Hudson vedligeholdes ikke længere.
Hvorfor bruge kontinuerlig integration med Jenkins?
Nogle mennesker tror måske, at den gammeldags måde at udvikle softwaren på er den bedre måde. Lad os forstå fordelene ved CI med Jenkins med følgende eksempel
Lad os forestille os, at der er omkring 10 udviklere, der arbejder på et delt lager. Nogle udviklere fuldfører deres opgave på 25 dage, mens andre tager 30 dage at gennemføre.
| Før Jenkins | Efter Jenkins |
|---|---|
| Når alle udviklere havde gennemført deres tildelte kodningsopgaver, plejede de at begå deres kode på samme tid. Senere testes og implementeres Build. Kodeforpligtelse bygget, og testcyklus var meget sjælden, og en enkelt opbygning blev udført efter mange dage. | Koden bygges og testes, så snart udvikler begår kode. Jenkin vil bygge og teste kode mange gange i løbet af dagen. Hvis build er vellykket, vil Jenkins distribuere kilden i testserveren og underrette implementeringsteamet. Hvis build mislykkes, underretter Jenkins fejlene til udviklerholdet. |
| Da koden blev bygget på én gang, skal nogle udviklere vente, indtil andre udviklere er færdige med at kode for at kontrollere deres build | Koden bygges straks efter at nogen af udviklerne forpligter sig. |
| Det er ikke en let opgave at isolere, opdage og rette fejl til flere forpligtelser. | Da koden er bygget efter hver forpligtelse fra en enkelt udvikler, er det let at opdage, hvis kode fik bygningen til at mislykkes |
| Kodebyggelse og testproces er helt manuel, så der er mange chancer for fiasko. | Automatiseret bygning og test procesbesparende timing og reducering af mangler. |
| Koden implementeres, når alle fejlene er rettet og testet. | Koden implementeres efter hver vellykket build og test. |
| Udviklingscyklus er langsom | Udviklingscyklussen er hurtig. Nye funktioner er lettere tilgængelige for brugerne. Øger overskuddet. |
Virkelig casestudie af kontinuerlig integration
Jeg er sikker på, at I alle er opmærksomme på den gamle telefon Nokia. Nokia plejede at implementere en procedure kaldet nightly build. Efter flere forpligtelser fra forskellige udviklere i løbet af dagen, bygges softwaren hver aften. Da softwaren kun blev bygget en gang om dagen, er det en enorm smerte at isolere, identificere og rette fejlene i en stor kodebase.
Senere vedtog de en kontinuerlig integrationsmetode. Softwaren blev bygget og testet, så snart en udvikler begik kode. Hvis der opdages en fejl, kan den respektive udvikler hurtigt rette fejlen.
Jenkins-plugins
Som standard leveres Jenkins med et begrænset sæt funktioner. Hvis du vil integrere din Jenkins-installation med versionskontrolværktøjer som Git, skal du installere plugins relateret til Git. For integration til værktøjer som Maven, Amazon EC2 skal du faktisk installere respektive plugins i dine Jenkins.
Fordele ved at bruge Jenkins
- Jenkins ledes af samfundet, der er meget åbent. Hver måned afholder de offentlige møder og tager input fra offentligheden til udviklingen af Jenkins-projektet.
- Indtil videre er omkring 280 billetter lukket, og projektet offentliggør stabil frigivelse hver tredje måned.
- Efterhånden som teknologien vokser, vokser Jenkins også. Indtil videre har Jenkins omkring 320 plugins offentliggjort i sin plugins-database. Med plugins bliver Jenkins endnu mere kraftfuld og funktionsrig.
- Jenkins understøtter også skybaseret arkitektur, så du kan implementere Jenkins i skybaserede platforme.
- Årsagen til, at Jenkins blev populær, er at den blev oprettet af en udvikler til udviklere.
Ulemper ved at bruge Jenkins
Selvom Jenkins er et meget kraftfuldt værktøj, har det sine mangler.
- Dens grænseflade er forældet og ikke brugervenlig sammenlignet med nuværende UI-tendenser.
- Selvom Jenkins er elsket af mange udviklere, er det ikke så let at vedligeholde det, fordi Jenkins kører på en server og kræver nogle færdigheder som serveradministrator for at overvåge dets aktivitet.
- En af grundene til, at mange mennesker ikke implementerer Jenkins, skyldes dets vanskeligheder med at installere og konfigurere Jenkins.
- Kontinuerlige integrationer bryder regelmæssigt på grund af nogle små indstillingsændringer. Kontinuerlig integration bliver sat på pause og kræver derfor noget udvikleres opmærksomhed.
Konklusion:
- I kontinuerlig integration, efter en kodeforpligtelse, bygges og testes softwaren med det samme
- Jenkins er en open source kontinuerlig integrationsserver, der er i stand til at organisere en kæde af handlinger
- Før Jenkins, da alle udviklere havde gennemført deres tildelte kodningsopgaver, plejede de at begå deres kode på samme tid. Senere testes og implementeres Build.
- Efter Jenkins er koden bygget og test, så snart udvikler begår kode. Jenkin vil opbygge og teste kode mange gange i løbet af dagen
- Som standard leveres Jenkins med et begrænset sæt funktioner. Hvis du vil integrere din Jenkins-installation med versionskontrolværktøjer som Git, skal du installere plugins relateret til Git
- De største fordele ved Jenkins er, at det styres af samfundet, der holder offentlige møder og tager input fra offentligheden til udvikling af Jenkins-projekter
- Den største ulempe ved Jenkin er, at dens grænseflade er forældet og ikke brugervenlig sammenlignet med nuværende UI-tendenser.