Hvad er JenkinsHvorfor bruge et værktøj til kontinuerlig integration (CI)?
Thomas Hamilton
⚡ Smart opsummering
Jenkins er den open source-automatiseringsserver, der bygger og tester kode, hver gang en udvikler foretager en commit, hvilket forvandler kontinuerlig integration fra en natlig pligt til en proces, der kører kontinuerligt hele arbejdsdagen.
Hvad er Jenkins?
Jenkins er en open source kontinuerlig integrationsserver skrevet i Java til at orkestrere en kæde af handlinger for at opnå den kontinuerlige integrationsproces på en automatiseret måde. Jenkins understøtter hele softwareudviklingslivscyklussen fra opbygning, testning, dokumentation af softwaren, implementering og andre faser af softwareudviklingslivscyklussen.
Jenkins er en udbredt applikation verden over med hundredtusindvis af installationer, og antallet vokser dag for dag. Ved at bruge Jenkins, softwarevirksomheder kan accelerere deres softwareudviklingsproces, da Jenkins kan automatisere bygge- og testprocesser i et hurtigt tempo.
Det er en serverbaseret applikation og kræver en webserver som Apache Tomcat. Årsagen Jenkins software blev så populær, er dens overvågning af gentagne opgaver, der opstår under udviklingen af et projekt. For eksempel, hvis dit team udviklerping et projekt, Jenkins vil løbende teste dine projektbuilds og vise dig fejlene i de tidlige stadier af din udvikling.
Bemærk: udplacering af WAR i Apache Tomcat fungerer stadig, men nuværende udgivelser leverer en indlejret servlet-container, så Jenkins kører normalt af sig selv. 2.555.x LTS-linjen kræver Java 21.
Hvad er kontinuerlig integration?
Kontinuerlig integration er en proces med at integrere kodeændringer fra flere udviklere i et enkelt projekt mange gange. Softwaren testes umiddelbart efter en kode-commit. Med hver kode-commit bliver kode bygget og testet. Hvis testen er bestået, testes bygningen til implementering. Hvis implementeringen lykkes, skubbes koden til produktion.
Denne forpligtelse, opbygning, test og implementering er en kontinuerlig proces og deraf navnet kontinuerlig integration/implementering.
Hvordan Jenkins arbejde?
Jenkins er en serverbaseret applikation og kræver en webserver som Apache Tomcat for at køre på forskellige platforme som f.eks. Windows, Linux, macOS, Unix osv. At bruge Jenkins, skal du oprette pipelines, som er en række trin, som en Jenkins serveren vil tage. Jenkins Continuous Integration Pipeline er et kraftfuldt instrument, der består af et sæt værktøjer designet til at hoste, overvåge, kompilere og teste kode eller kodeændringer, såsom:
- Kontinuerlig integrationsserver (Jenkins, Bamboo, CruiseControl, TeamCityog andre)
- Kildekontrolværktøj (f.eks. CVS, SVN, GIT, Mercurial, Perforce, ClearCase og andre)
- Byggeværktøj (Make, ANT, Maven, Ivy, Gradleog andre)
- Framework for automatiseringstest (Selenium, Appium, TestComplete, UFTog andre)
I nuværende versioner findes disse trin i en Jenkinsfilen committed ved siden af koden. Jenkins Controlleren læser filen og overleverer hvert trin til en agent, som er den maskine, der rent faktisk udfører arbejdet.
Jenkins Historie
- Kohsuke Kawaguchi, en Java udvikler, der arbejder hos SUN Microsystems, var træt af at bygge koden og rette fejl gentagne gange. I 2004 oprettede en automatiseringsserver kaldet Hudson, der automatiserer bygge- og testopgaver.
- I 2011, blev Oracle der ejede Sun Microsystems havde en tvist med Hudsons open source-fællesskab, så de delte Hudson op og omdøbte det til Jenkins.
- Både Hudson og Jenkins fortsatte med at operere uafhængigt. Men i løbet af kort tid, Jenkins erhvervede mange projekter og bidragydere, mens Hudson kun tilbageholdt 32 projekter. Med tiden, Jenkins blev 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 påping softwaren 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 repository. Nogle udviklere fuldfører deres opgave på 25 dage, mens andre bruger 30 dage på at færdiggøre den.
| Før Jenkins | Efter Jenkins |
|---|---|
|
Når alle udviklere havde fuldført deres tildelte kodningsopgaver, plejede de at begå deres kode på samme tid. Later, Build er testet og implementeret. Code commit blev bygget, og testcyklussen var meget sjælden, og en enkelt build blev færdiggjort efter mange dage. |
Koden bygges og testes, så snart udvikleren committer koden. Jenkins vil bygge og teste kode mange gange i løbet af dagen Hvis byggeriet lykkes, så Jenkins vil installere kildekoden på testserveren og underrette implementeringsteamet. Hvis konstruktionen mislykkes, så Jenkins vil underrette udviklerteamet om fejlene. |
| Da koden blev bygget på én gang, ville nogle udviklere skulle vente, indtil andre udviklere er færdige med at kode for at kontrollere deres build | Koden bygges umiddelbart efter, at nogen af udviklerne forpligter sig. |
| Det er ikke en let opgave at isolere, opdage og rette fejl for flere commits. | Da koden bygges efter hver commit fra en enkelt udvikler, er det nemt at finde ud af, hvis kode forårsagede, at buildet mislykkedes. |
| Code bygge og testproces er helt manuelle, så der er mange chancer for fejl. | Automatiseret bygge- og testproces sparer timing og reducerer defekter. |
| Koden implementeres, når alle fejlene er rettet og testet. | Koden implementeres efter hver succesfuld build og test. |
| Udviklingscyklussen er langsom | Udviklingscyklussen er hurtig. Nye funktioner er lettere tilgængelige for brugerne. Øger overskuddet. |
Real-world casestudie af kontinuerlig integration
Jeg er sikker på, at I alle kender til den gamle Nokia-telefon. Nokia plejede at implementere en procedure kaldet nightly build. Efter flere tilsagn fra forskellige udviklere i løbet af dagen, blev softwaren bygget hver nat. Da softwaren kun blev bygget én gang om dagen, er det en enorm smerte at isolere, identificere og rette fejlene i en stor kodebase.
Later, anvendte de en tilgang til kontinuerlig integration, som vist nedenfor. Softwaren blev bygget og testet, så snart en udvikler committede kode. Hvis der opdages en fejl, kan den respektive udvikler hurtigt rette fejlen.
Jenkins plugins
Som standard Jenkins leveres 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. Faktisk, for integration med værktøjer som Maven, Amazon EC2, skal du installere de respektive plugins i din Jenkins, som plugin-administratoren nedenfor viser.
Fordele ved at bruge Jenkins
- Jenkins administreres af lokalsamfundet, som er meget åbent. Hver måned afholder de offentlige møder og modtager input fra offentligheden til udviklingen af Jenkins projekt.
- Projektet holder en forudsigelig udgivelsesrytme: en ny baseline for langsigtet support vælges hver tolvte uge og modtager derefter planlagte patch-udgivelser.
- I takt med at teknologien vokser, gør det også JenkinsPlugin-databasen indeholder nu over to tusinde plugins. Med plugins, Jenkins bliver endnu mere kraftfuld og funktionsrig.
- Jenkins Værktøjet understøtter også cloudbaseret arkitektur, så du kan implementere Jenkins i cloudbaserede platforme.
- Grunden til Jenkins blev populært, er, at det blev skabt af en udvikler til udviklere.
Ulemper ved at bruge Jenkins
Selvom Jenkins er et meget kraftfuldt værktøj, det har sine mangler.
- Dens brugerflade er forældet og ikke brugervenlig sammenlignet med nuværende brugergrænsefladetrends, selvom nylige udgivelser har moderniseret meget af skærmdesignet.
- Selvom Jenkins er elsket af mange udviklere, er det ikke så nemt at vedligeholde det fordi Jenkins kører på en server og kræver visse færdigheder som serveradministrator for at overvåge dens aktivitet.
- En af grundene til, at mange mennesker ikke implementerer Jenkins skyldes dens vanskeligheder med installation og konfiguration Jenkins.
- Kontinuerlige integrationer går jævnligt i stykker på grund af nogle små indstillingsændringer. Kontinuerlig integration vil blive sat på pause og kræver derfor en vis opmærksomhed fra udvikleren.
- Plugin-afhængighedskonflikter opstår, når mange plugins opgraderes på forskellige tidspunkter, så plugin-opdateringer kræver deres eget vedligeholdelsesvindue.
Hvis disse afvejninger er vigtige for dit team, så sammenlign Bedre Jenkins Alternative værktøjer og den bredere liste over top kontinuerlige integrationsværktøjer før du forpligter dig til en selvhostet server.
