er absolutt ufullstendig uten Jenkins. Jenkins sammen med Git er en fantastisk kombinasjon. Så i denne artikkelen vil jeg snakke om Jenkins Git Integration og fordelene. Tips som vi skal dekke er som følger:
Så la oss begynne med vårt første tema.
Hva er Git - Hvorfor Git Kom til eksistens? 
Vi vet alle 'Nødvendighet er mor til alle oppfinnelser'. På samme måte dukket Git opp for å oppfylle visse nødvendigheter som utviklerne møtte før Git. Så la oss ta et skritt tilbake for å lære mer om Versjonskontrollsystemer (VCS) og hvordan Git ble til.
Versjonskontroll er håndtering av endringer i dokumenter, dataprogrammer, store nettsteder og annen informasjonssamling.
Det er to typer VCS:
Sentralisert versjonskontrollsystem (CVCS)
Distribuert versjonskontrollsystem (DVCS)
Sentralisert VCS
Et sentralisert versjonskontrollsystem (CVCS) bruker en sentral server for å lagre alle filer og muliggjør teamsamarbeid. Det fungerer på et enkelt arkiv som brukere kan få direkte tilgang til en sentral server.
Se diagrammet nedenfor for å få et bedre inntrykk av CVCS:
Datalageret i diagrammet ovenfor indikerer en sentral server som kan være lokal eller ekstern, som er direkte koblet til hver av programmørens arbeidsstasjoner.
finn største antall i java
Hver programmerer kan trekke ut eller Oppdater arbeidsstasjonene med dataene som finnes i depotet. De kan også gjøre endringer i dataene eller begå til depotet. Hver operasjon utføres direkte på depotet.
Selv om det virker ganske praktisk å opprettholde et enkelt lager, har det noen store ulemper. Noen av dem er:
Det er ikke lokalt tilgjengelig, noe som betyr at du alltid må være koblet til et nettverk for å utføre noen handlinger.
Siden alt er sentralisert, vil det uansett føre til at den sentrale serveren blir krasjet eller ødelagt, mister hele dataene i prosjektet.
Dette er hvor Distribuert VCS løser problemet.
Distribuert VCS
Disse systemene er ikke nødvendigvis avhengige av en sentral server for å lagre alle versjoner av en prosjektfil.I Distribuert VCS har hver bidragsyter en lokal kopi eller 'klone' av hovedregisteret. Her opprettholder alle et eget lokalt arkiv som inneholder alle filene og metadataene som er tilstede i hovedregisteret.
Du vil forstå det bedre ved å referere til diagrammet nedenfor:
Som du kan se i diagrammet ovenfor, vedlikeholder hver programmerer et lokalt depot alene, som faktisk er kopien eller klonen til det sentrale depotet på harddisken. De kan forplikte og oppdatere sitt lokale depot uten forstyrrelser.
De kan oppdatere sine lokale arkiver med nye data fra den sentrale serveren ved en operasjon kalt “ dra ”Og påvirker endringer i hovedregisteret ved en operasjon kalt“ trykk ”Fra deres lokale depot.
La oss nå prøve å vite om definisjonen av Git.
Git er et distribuert versjonskontrollverktøy som støtter distribuerte ikke-lineære arbeidsflyter ved å gi datasikkerhet for utvikling av kvalitetsprogramvare. Verktøy som Git muliggjør kommunikasjon mellom utviklingen og driftsteamet.
Normalt har du et stort antall samarbeidspartnere når du utvikler et stort prosjekt. Så det er veldig viktig å ha kommunikasjon mellom samarbeidspartnerne mens du gjør endringer i prosjektet.
Forpliktende meldinger i Git spiller en veldig viktig rolle i kommunikasjonen mellom teamet. Bortsett fra kommunikasjon, er den viktigste grunnen til å bruke Git at du alltid har en stabil versjon av koden med deg.
Derfor spiller Git en viktig rolle for å lykkes med DevOps.
Hva er Jenkins?
Jenkins er et open source-automatiseringsverktøy skrevet i Java med plugins bygget for kontinuerlig integrasjonsformål. Jenkins brukes til å bygge og teste programvareprosjektene dine kontinuerlig, noe som gjør det lettere for utviklere å integrere endringer i prosjektet, og gjør det lettere for brukere å få en ny versjon. Det lar deg også kontinuerlig levere programvaren din ved å integrere med et stort antall test- og distribusjonsteknologier.
Med Jenkins kan organisasjoner akselerere programvareutviklingsprosessen gjennom automatisering. Jenkins integrerer utviklingslivssyklusprosesser av alle slag, inkludert bygg, dokument, test, pakke, scene, distribusjon, statisk analyse og mye mer.
Jenkins oppnår kontinuerlig integrasjon ved hjelp av plugins. Plugins tillater integrering av ulike DevOps-stadier. Hvis du vil integrere et bestemt verktøy, må du installere programtilleggene for det verktøyet. For eksempel Git, Maven 2-prosjekt, Amazon EC2, HTML-utgiver, etc.
Fordelene med Jenkins inkluderer:
Det er et åpen kildekodeverktøy med god fellestøtte.
For enkelt å installere.
Den har 1000+ plugins for å lette arbeidet ditt. Hvis et plugin ikke eksisterer, kan du kode det og dele det med samfunnet.
Det er gratis.
Den er bygget med Java og er derfor bærbar til alle de viktigste plattformene.
Du vet nå hvordan Jenkins overvinner de tradisjonelle SDLC-manglene. Tabellen nedenfor viser sammenligningen mellom “Før og etter Jenkins”.
| Før Jenkins | Etter Jenkins |
|---|---|
| Hele kildekoden ble bygget og deretter testet. Å finne og fikse feil i tilfelle bygg- og testfeil var vanskelig og tidkrevende, noe som igjen bremser leveringsprosessen for programvaren. | Hver forpliktelse i kildekoden er bygget og testet. Så, i stedet for å sjekke hele kildekoden, trenger utviklere bare å fokusere på en bestemt forpliktelse. Dette fører til hyppige nye programvareutgivelser. |
| Utviklere må vente på testresultatene | Utviklere kjenner testresultatet av hver forpliktelse som er gjort i kildekoden på flukt. |
| Hele prosessen er manuell | Du trenger barebegå endringer i kildekoden, og Jenkins vil automatisere resten av prosessen for deg. |
Hvorfor brukes Jenkins og Git sammen?
Som diskutert tidligere, Gå er kildekontrollansvarlig. Det er der du beholder kildekoden for å spore alle kodeendringene som skjer over tid og for å basere versjonene når de er klare for utgivelse.
Jenkins derimot er en kontinuerlig integrasjonsløsning. Det er utviklet for å automatisere de fleste oppgavene som en utvikler må gjøre mens de utvikler en ny applikasjon (kodekvalitetskontroll, bygging, arkivering av byggeartefakter, integrasjonstesting, distribusjon til forskjellige miljøer osv.) Uten en CI-løsning, en utvikler må bruke mye tid på å gjøre disse repeterende ikke-produktive oppgavene.
Fordeler:
- Git og Jenkins er begge veldig mektige, men med stor kraft kommer stort ansvar. Det er ganske vanlig å rettferdiggjøre unødvendig mye komplikasjon i en rørledning rett og slett fordi du kan.
- Mens Jenkins har mange fine triks i ermet, er det enkelt å utnytte funksjonene til Git, da det gjør frigjøringsadministrasjon og feilsporing betydelig lettere over tid.
- Vi kan gjøre dette ved å være forsiktig med versjonene av koden vi bygger og merke dem på riktig måte. Dette holder utgivelsesrelatert informasjon nær koden , i motsetning til å stole på Jenkins-byggetall eller andre monikere.
- Beskytte Git-grener reduserer risikoen for menneskelige feil , og automatisering av så mange oppgaver som mulig reduserer hvor ofte vi må plage (eller vente på) disse menneskene.
Eksempel:
La oss ta eksemplet med en ny funksjon i en webapplikasjon. En utvikler vil bli identifisert og tilordnet oppgaven, han tar den eksisterende kodebasen fra kildekontrollen - si Git, gjør endringene sine, utfører enhetstesting, sørger for kodekvalitet manuelt og sjekker den nye koden tilbake til Git.
Deretter må han bygge koden, distribuere den i integrasjonsforekomst, kjøre integrasjonstesting og når endringen virker tilfredsstillende, ta opp en forespørsel om distribusjon av produksjon. Nå, hvis bare vi hadde en håndlangere for å ta oss av denne testingen, bygningen, kvalitetskontrollene og distribusjonsseksjonene, kunne den dårlige utvikleren ha fokusert bedre på de tingene han er veldig flink til - implementering og forbedring av funksjonens logikk.
Dette håndlangeren er Jenkins. Det fungerer som en orkestrator for å kjøre alle disse aktivitetene når endringen er sjekket inn i kildekontroll (Git), og gir dermed rask tilbakemelding til utvikleren om endringene han har gjort er gode nok for distribusjon av produksjonen eller ikke.Det er en ekstremt fleksibel, åpen kildekode og har massevis av plugins som kan gjøre nesten alt du vil at den skal gjøre.
Demo
Her vil vi se hvordan vi kan integrere Git med Jenkins. Det er fem trinn du må følge:
1. Opprett et prøveprogram:
Du kan lage et hvilket som helst eksempelprogram du vil ha, som Java eller Python eller et hvilket som helst annet program. Her vil vi skrive en enkel Python-program som skriver ut Hello, World!
2. Opprett en Jenkins-jobb:
Her må du først start Jenkins ved å bruke ledeteksten.
For det må du først navigere til Jenkins-stedet på systemet ditt og bruke kommandoen java -jar jenkins.war
Etter å ha kjørt denne kommandoen, åpner du nettleseren og går til Jenkins hjemmeside ved hjelp av lenken lokal vert: 8080 . Dette er standard portnummer.
hvordan du bruker delingsmetoden i java
Åpne Jenkins hjemmeside ved angi brukernavn og passord.
Klikk på for å lage et prosjekt Ny gjenstand og skriv inn prosjektnavn og velg Freestyle-prosjekt . Klikk på OK.
3. Legg til dette programmet i Github:
Åpne git bash på systemet ditt. Navigere til stedet for programmet ditt. Initialiser et tomt lager ved hjelp av kommandoen git init .
Bruk kommandoen git add. for å legge til filen i iscenesettingsområdet fra arbeidskatalogen.
Legg nå til filen i det lokale depotet ved hjelp av kommandoen git commit -m “demo.py-fil lagt til” .
Nå må du trykk denne filen til det eksterne depotet. For å gjøre det, gå til GitHub-kontoen din og opprett et nytt offentlig depot. Kopier nå plasseringen til dette depotet og gå til git bash terminal. Skriv inn kommandoen her git remote legg til opprinnelse . Siden nå har du koblet til det eksterne depotet, kan du nå skyve koden din der ved hjelp av kommandoen git push -u origin master. For å bekrefte dette, gå til GitHub-kontoen og oppdater siden. Du vil se filen lagt til der.
4. Legg til Git Plugin i Jenkins:
Gå til Jenkins hjemmeside Administrer Jenkins .
Neste klikk på Administrer programtillegg . Her sjekk fikk Git plugin i den installerte delen. Hvis den ikke er tilgjengelig her, kan du søke etter den i den tilgjengelige delen og laste den ned.
5. Konfigurer Jenkins-jobben for å utløse bygningen:
Gå til prosjektet i Jenkins som vi opprettet i trinn 2. Her i delen Source Code Management, velg git og skriv inn lenken til det offentlige depotet du opprettet i trinn 3. Neste i Bygg Triggers-delen , klikk på Poll SCM-alternativ . Her i Schedule-delen må du skrive inn fem stjerner atskilt med mellomrom. Dette er ingenting annet enn cronsyntaks for jobben din. Dette betyr at Jenkins vil se etter eventuelle endringer i kildekoden hvert minutt, og hvis det er noen endring, vil den utløse Jenkins-bygningen.
Klikk på Søke om og så videre Lagre . Klikk deretter på på startsiden for prosjektet Bygg nå . Dette vil kjøre prosjektet, og i konsollutgangen kan du se programutgangen din status for Jenkins-jobben. Hvis alt er i orden, vil det vises som Suksess .
Så dette blir Jenkins Git Integration gjort. Med dette har vi kommet til slutten av denne artikkelen om Jenkins Git Integration. Jeg håper du har hatt glede av denne artikkelen.
Nå som du har forstått hva Jenkins Git Integration er, sjekk ut dette av Edureka, et pålitelig online læringsfirma med et nettverk med mer enn 250 000 fornøyde elever spredt over hele verden. Edureka DevOps Certification Training-kurset hjelper elever til å forstå hva som er DevOps og få ekspertise i forskjellige DevOps-prosesser og verktøy som Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack og GIT for å automatisere flere trinn i SDLC.
Har du spørsmål til oss? Vennligst nevn det i kommentarfeltet, så kommer vi tilbake til deg