Hva er JenkinsHvorfor bruke et verktøy for kontinuerlig integrasjon (CI)?
⚡ Smart oppsummering
Jenkins er en åpen kildekode-automatiseringsserver som bygger og tester kode hver gang en utvikler commiterer, og dermed gjør kontinuerlig integrasjon fra et nattlig ork til en prosess som kjører kontinuerlig gjennom hele arbeidsdagen.
Hva er Jenkins?
Jenkins er en åpen kildekode Continuous Integration-server skrevet inn Java for å orkestrere en kjede av handlinger for å oppnå den kontinuerlige integrasjonsprosessen på en automatisert måte. Jenkins støtter hele programvarens utviklingssyklus fra bygging, testing, dokumentasjon av programvaren, distribusjon og andre stadier av programvareutviklingssyklusen.
Jenkins er et mye brukt program over hele verden, med hundretusenvis av installasjoner og en økning dag for dag. Ved å bruke Jenkins, programvareselskaper kan akselerere programvareutviklingsprosessen sin, ettersom Jenkins kan automatisere bygging og testing i et raskt tempo.
Det er en serverbasert applikasjon og krever en webserver som Apache Tomcat. Årsaken Jenkins programvaren ble så populær, er overvåkingen av gjentatte oppgaver som oppstår under utviklingen av et prosjekt. Hvis for eksempel teamet ditt utviklerping et prosjekt, Jenkins vil kontinuerlig teste prosjektbyggene dine og vise deg feilene i tidlige stadier av utviklingen.
OBS: utplassering av WAR i Apache Tomcat fungerer fortsatt, men nåværende utgivelser leverer en innebygd servlet-container, så Jenkins kjører vanligvis på egenhånd. 2.555.x LTS-linjen krever Java 21.
Hva er kontinuerlig integrasjon?
Kontinuerlig integrasjon er en prosess med å integrere kodeendringer fra flere utviklere i et enkelt prosjekt mange ganger. Programvaren testes umiddelbart etter en kodebekreftelse. Med hver kodebekreftelse bygges og testes koden. Hvis testen er bestått, testes bygningen for distribusjon. Hvis distribusjonen er vellykket, blir koden sendt til produksjon.
Denne forpliktelsen, byggingen, testen og distribusjonen er en kontinuerlig prosess og derav navnet kontinuerlig integrasjon/distribusjon.
Hvordan gjør Jenkins arbeide?
Jenkins er en serverbasert applikasjon og krever en webserver som Apache Tomcat for å kjøre på forskjellige plattformer som Windows, Linux, macOS, Unix, osv. For å bruke Jenkins, må du lage rørledninger som er en serie trinn som en Jenkins serveren vil ta. Jenkins Continuous Integration Pipeline er et kraftig instrument som består av et sett med verktøy designet for å være vert for, overvåke, kompilere og teste kode, eller kodeendringer, som:
- Kontinuerlig integrasjonsserver (Jenkins, Bamboo, CruiseControl, TeamCity, og andre)
- Kildekontrollverktøy (f.eks. CVS, SVN, GIT, Mercurial, Perforce, ClearCase og andre)
- Byggeverktøy (Make, ANT, Maven, Ivy, Gradle, og andre)
- Rammeverk for automatiseringstesting (Selenium, Appium, TestComplete, UFT, og andre)
I nåværende versjoner ligger disse trinnene i en Jenkinsfilen som ble lagt ved siden av koden. Jenkins Kontrolleren leser filen og overfører hvert trinn til en agent, som er maskinen som faktisk kjører arbeidet.
Jenkins Historie
- Kohsuke Kawaguchi, en Java utvikler, som jobbet hos 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, Oracle som eide Sun Microsystems hadde en tvist med Hudsons åpen kildekode-fellesskap, så de delte Hudson og ga det nytt navn til Jenkins.
- Både Hudson og Jenkins fortsatte å operere uavhengig. Men i løpet av kort tid, Jenkins fikk mange prosjekter og bidragsytere, mens Hudson bare hadde 32 prosjekter igjen. Med tiden, Jenkins ble mer populær, og Hudson vedlikeholdes ikke lenger.
Hvorfor bruke kontinuerlig integrasjon med Jenkins?
Noen tror kanskje at den gammeldagse måten å utvikle påping programvaren 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 arkiv. Noen utviklere fullfører oppgaven sin på 25 dager, mens andre bruker 30 dager på å fullføre.
| Før Jenkins | Etter Jenkins |
|---|---|
|
Når alle utviklere hadde fullført de tildelte kodeoppgavene, pleide de å forplikte koden sin samtidig. Later, Bygg er testet og distribuert. Code commit bygget, og testsyklusen var svært sjelden, og en enkelt bygging ble ferdig etter mange dager. |
Koden bygges og testes så snart utvikleren har lagt inn koden. Jenkins vil bygge og teste kode mange ganger i løpet av dagen Hvis byggingen er vellykket, da Jenkins vil distribuere kildekoden til testserveren og varsle distribusjonsteamet. Hvis byggingen mislykkes, da Jenkins vil varsle utviklerteamet om feilene. |
| Siden koden ble bygget på en gang, ville noen utviklere måtte vente til andre utviklere er ferdige med kodingen for å sjekke bygget | Koden bygges umiddelbart etter at en av utviklerne forplikter seg. |
| Det er ikke en lett oppgave å isolere, oppdage og fikse feil for flere forpliktelser. | Siden koden bygges etter hver commit fra én utvikler, er det enkelt å oppdage hvilken kode som forårsaket at byggingen mislyktes. |
| Code bygge og testprosess er helt manuelle, så det er mange sjanser for feil. | Automatisert bygge- og testprosess sparer timing og reduserer defekter. |
| Koden distribueres når alle feilene er fikset og testet. | Koden distribueres etter hver vellykket bygg og test. |
| Utviklingssyklusen er treg | Utviklingssyklusen er rask. Nye funksjoner er lettere tilgjengelig for brukere. Øker fortjenesten. |
Real-world case-studie av kontinuerlig integrasjon
Jeg er sikker på at alle dere er klar over den gamle Nokia-telefonen. Nokia pleide å implementere en prosedyre kalt nattlig bygg. Etter flere forpliktelser fra forskjellige utviklere i løpet av dagen, ble programvaren bygget hver natt. Siden programvaren ble bygget bare én gang om dagen, er det en stor smerte å isolere, identifisere og fikse feilene i en stor kodebase.
Later, tok de i bruk en tilnærming til kontinuerlig integrasjon, vist nedenfor. Programvaren ble bygget og testet så snart en utvikler implementerte kode. Hvis det oppdages en feil, kan den respektive utvikleren raskt fikse feilen.
Jenkins plugins
Som standard Jenkins kommer med et begrenset sett med funksjoner. Hvis du vil integrere din Jenkins installasjon med versjonskontrollverktøy som Git, må du installere plugins relatert til Git. Faktisk, for integrasjon med verktøy som Maven, Amazon EC2, må du installere respektive plugins i din Jenkins, som plugin-behandleren nedenfor viser.
Fordeler med å bruke Jenkins
- Jenkins administreres av lokalsamfunnet, som er veldig åpent. Hver måned holder de offentlige møter og tar imot innspill fra publikum for utviklingen av Jenkins prosjekt.
- Prosjektet holder en forutsigbar utgivelsesrytme: en ny langsiktig støttebaselinje velges hver tolvte uke, og deretter mottar den planlagte oppdateringsutgivelser.
- Etter hvert som teknologien vokser, gjør også JenkinsPlugin-databasen inneholder nå over to tusen pluginer. Med pluginer, Jenkins blir enda kraftigere og funksjonsrik.
- Jenkins Verktøyet støtter også skybasert arkitektur slik at du kan distribuere Jenkins i skybaserte plattformer.
- Grunnen til Jenkins ble populært er at det ble laget av en utvikler for utviklere.
Ulemper ved bruk Jenkins
Selv Jenkins er et veldig kraftig verktøy, det har sine svakheter.
- Grensesnittet er utdatert og ikke brukervennlig sammenlignet med dagens UI-trender, selv om nylige utgivelser har modernisert mye av skjermdesignet.
- Selv 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 skyldes vanskeligheten med installasjon og konfigurering Jenkins.
- Kontinuerlige integrasjoner bryter regelmessig på grunn av noen små innstillingsendringer. Kontinuerlig integrasjon vil bli satt på pause og krever derfor en viss oppmerksomhet fra utviklere.
- Konflikter mellom plugin-avhengigheter oppstår når mange pluginer oppgraderes til forskjellige tider, så plugin-oppdateringer trenger sitt eget vedlikeholdsvindu.
Hvis disse avveiningene er viktige for teamet ditt, sammenlign Beste Jenkins Alternative verktøy og den bredere listen over topp kontinuerlige integrasjonsverktøy før du forplikter deg til en selvhostet server.


