Vad är JenkinsVarför använda ett verktyg för kontinuerlig integration (CI)?
Thomas Hamilton
⚡ Smart sammanfattning
Jenkins är den automatiseringsserver med öppen källkod som bygger och testar kod varje gång en utvecklare gör en commit, vilket förvandlar kontinuerlig integration från en nattlig syssla till en process som körs kontinuerligt under hela arbetsdagen.
Vad är Jenkins?
Jenkins är en öppen källkodsserver för kontinuerlig integration inskriven Java för att orkestrera en kedja av åtgärder för att uppnå den kontinuerliga integrationsprocessen på ett automatiserat sätt. Jenkins stöder hela programvarans utvecklingslivscykel, från byggande, testning, dokumentation av programvaran, driftsättning och andra steg i programvaruutvecklingens livscykel.
Jenkins är en flitigt använd applikation runt om i världen, med hundratusentals installationer och antalet växer dag för dag. Genom att använda Jenkins, mjukvaruföretag kan påskynda sin mjukvaruutvecklingsprocess, eftersom Jenkins kan automatisera byggande och testning i snabb takt.
Det är en serverbaserad applikation och kräver en webbserver som Apache Tomcat. Anledningen Jenkins Det som blev så populärt med programvara är dess övervakning av upprepade uppgifter som uppstår under utvecklingen av ett projekt. Om ditt team till exempel utvecklarping ett projekt, Jenkins kommer kontinuerligt att testa dina projektbyggen och visa dig felen i tidiga skeden av din utveckling.
Obs: utplacera WAR i Apache Tomcat fungerar fortfarande, men nuvarande versioner levererar en inbäddad servlet-container, så Jenkins körs normalt av sig självt. 2.555.x LTS-linjen kräver Java 21.
Vad är kontinuerlig integration?
Kontinuerlig integration är en process för att integrera kodändringar från flera utvecklare i ett enda projekt många gånger. Programvaran testas omedelbart efter en kodkommit. Med varje kodbekräftelse byggs och testas kod. Om testet är godkänt testas byggnaden för distribution. Om distributionen lyckas skickas koden till produktion.
Denna commit, bygg, test och distribution är en kontinuerlig process och därav namnet kontinuerlig integration/distribution.
Hur fungerar Jenkins arbete?
Jenkins är en serverbaserad applikation och kräver en webbserver som Apache Tomcat för att köras på olika plattformar som Windows, Linux, macOS, Unix, etc. Att använda Jenkins, måste du skapa pipelines som är en serie steg som en Jenkins servern kommer att ta. Jenkins Continuous Integration Pipeline är ett kraftfullt instrument som består av en uppsättning verktyg utformade för att vara värd för, övervaka, kompilera och testa kod, eller kodändringar, som:
- Kontinuerlig integrationsserver (Jenkins, Bamboo, CruiseControl, TeamCity, och andra)
- Källkontrollverktyg (t.ex. CVS, SVN, GIT, Mercurial, Perforce, ClearCase med flera)
- Byggverktyg (Make, ANT, Maven, Ivy, Gradle, och andra)
- Ramverk för automatiseringstestning (Selenium, Appium, TestComplete, UFT, och andra)
I nuvarande versioner finns dessa steg i en Jenkinsfilen som lagts in bredvid koden. Den Jenkins Kontrollenheten läser filen och överlämnar varje steg till en agent, vilket är den maskin som faktiskt kör arbetet.
Jenkins Historik
- Kohsuke Kawaguchi, a Java utvecklaren, som arbetar på SUN Microsystems, var trött på att bygga koden och repetera fel upprepade gånger. År 2004 skapade en automatiseringsserver som heter Hudson som automatiserar bygg- och testuppgifter.
- 2011, Oracle som ägde Sun Microsystems hade en tvist med Hudsons öppen källkodsgemenskap, så de delade upp Hudson och döpte om det till Jenkins.
- Både Hudson och Jenkins fortsatte att verka självständigt. Men på kort tid, Jenkins förvärvade många projekt och bidragsgivare medan Hudson bara hade 32 projekt kvar. Med tiden, Jenkins blev mer populär, och Hudson underhålls inte längre.
Varför använda kontinuerlig integration med Jenkins?
Vissa människor kanske tror att det gammaldags sättet att utvecklaping programvaran är det bättre sättet. Låt oss förstå fördelarna med CI med Jenkins med följande exempel
Låt oss föreställa oss att det finns ungefär 10 utvecklare som arbetar på ett delat arkiv. Vissa utvecklare slutför sin uppgift på 25 dagar medan andra tar 30 dagar att slutföra.
| Innan Jenkins | Efter Jenkins |
|---|---|
|
När alla utvecklare hade slutfört sina tilldelade kodningsuppgifter brukade de begå sin kod samtidigt. Later, Build testas och distribueras. Code commit byggdes, och testcykeln var mycket oregelbunden, och en enskild version gjordes efter många dagar. |
Koden byggs och testas så snart utvecklaren har skrivit koden. Jenkins kommer att bygga och testa kod många gånger under dagen Om bygget lyckas, då Jenkins kommer att distribuera källkoden till testservern och meddelar distributionsteamet. Om bygget misslyckas, då Jenkins kommer att meddela utvecklarteamet om felen. |
| Eftersom koden byggdes på en gång, skulle vissa utvecklare behöva vänta tills andra utvecklare är klara med kodningen för att kontrollera sin konstruktion | Koden byggs omedelbart efter att någon av utvecklarna åtar sig. |
| Det är inte en lätt uppgift att isolera, upptäcka och åtgärda fel för flera commits. | Eftersom koden byggs efter varje commit av en enskild utvecklare är det enkelt att upptäcka vems kod som orsakade att bygget misslyckades. |
| Code bygga och testprocess är helt manuella, så det finns många chanser att misslyckas. | Automatiserad bygg- och testprocess som sparar tid och minskar defekter. |
| Koden distribueras när alla fel är åtgärdade och testade. | Koden distribueras efter varje framgångsrik konstruktion och test. |
| Utvecklingscykeln är långsam | Utvecklingscykeln är snabb. Nya funktioner är mer lättillgängliga för användare. Ökar vinsten. |
Verklig fallstudie av kontinuerlig integration
Jag är säker på att ni alla känner till den gamla Nokia-telefonen. Nokia brukade implementera en procedur som kallas nattlig konstruktion. Efter flera åtaganden från olika utvecklare under dagen byggdes programvaran varje natt. Eftersom programvaran bara byggdes en gång om dagen, är det en enorm smärta att isolera, identifiera och åtgärda felen i en stor kodbas.
Later, de använde sig av en metod för kontinuerlig integration, som visas nedan. Programvaran byggdes och testades så snart en utvecklare implementerade kod. Om något fel upptäcks kan respektive utvecklare snabbt åtgärda felet.
Jenkins Insticksprogram
Som standard Jenkins levereras med en begränsad uppsättning funktioner. Om du vill integrera din Jenkins installation med versionshanteringsverktyg som Git, då behöver du installera plugins relaterade till Git. För integration med verktyg som Maven, Amazon EC2, du måste installera respektive plugin i din Jenkins, som plugin-hanteraren nedan visar.
Fördelar med att använda Jenkins
- Jenkins förvaltas av ett samhälle som är mycket öppet. Varje månad håller de offentliga möten och tar emot synpunkter från allmänheten för utvecklingen av Jenkins projektet.
- Projektet håller en förutsägbar releaserytm: en ny baslinje för långsiktigt stöd väljs var tolfte vecka och får sedan schemalagda patch-releaser.
- I takt med att tekniken växer, gör även JenkinsPlugin-databasen innehåller nu över två tusen plugins. Med plugins, Jenkins blir ännu kraftfullare och funktionsrikare.
- Jenkins verktyget stöder även molnbaserad arkitektur så att du kan driftsätta Jenkins i molnbaserade plattformar.
- Anledningen till Jenkins blev populärt är att det skapades av en utvecklare för utvecklare.
Nackdelar med att använda Jenkins
Även Jenkins är ett mycket kraftfullt verktyg, det har sina brister.
- Dess gränssnitt är föråldrat och inte användarvänligt jämfört med nuvarande UI-trender, även om nya utgåvor har moderniserat mycket av skärmdesignen.
- Även Jenkins är älskad av många utvecklare, är det inte så lätt att underhålla det eftersom Jenkins körs på en server och kräver vissa färdigheter som serveradministratör för att övervaka dess aktivitet.
- En av anledningarna till att många inte implementerar Jenkins beror på dess svårighet att installera och konfigurera Jenkins.
- Kontinuerliga integrationer bryter regelbundet på grund av några små inställningsändringar. Kontinuerlig integration kommer att pausas och kräver därför viss uppmärksamhet från utvecklare.
- Konflikter mellan plugin-program och beroenden uppstår när många plugin-program uppgraderas vid olika tidpunkter, så plugin-uppdateringar behöver ett eget underhållsfönster.
Om dessa avvägningar är viktiga för ditt team, jämför Bäst Jenkins Alternativa verktyg och den bredare listan över toppverktyg för kontinuerlig integration innan man bestämmer sig för en egenhostad server.
