Referanse: hvordan Continuous Integration-prosessen fungerer

I dag skal vi se på historien til termen, diskutere utfordringene med å implementere CI, og presentere noen populære verktøy som kan hjelpe med det.

Referanse: hvordan Continuous Integration-prosessen fungerer
/ Flickr / Altug Karakoc / CC BY / Фото изменено

Termin

Continuous Integration (kontinuerlig integrasjon) er en tilnærming til programvareutvikling som innebærer hyppig bygging av prosjektet og testing av koden.

Målet er å gjøre integrasjonsprosessen forutsigbar og oppdage potensielle feil og feil i tidlig fase, slik at det er mer tid til å rette dem.

Begrepet Continuous Integration ble først introdusert i 1991. Det ble introdusert av skaperen av UML-språket, Grady Booch . Ingeniøren presenterte CI-konseptet som en del av sin egen utviklingspraksis— Booch-metoden. Den innebar inkrementell presisering av arkitektur under design av objektorienterte systemer. Grady beskrev ikke spesifikasjoner for kontinuerlig integrasjon, men senere i sin bok “Object-Oriented Analysis and Design with Applications“ sa han at metodens oppgave var å fremskynde utgivelsen av «interne versjoner».

Historie

I 1996 ble CI tatt opp av skaperne av metodologien ekstremprogrammering (XP)— Kent Beck og Ron Jeffries . Kontinuerlig integrasjon ble et av de tolv viktigste prinsippene i deres tilnærming. Grunnleggerne av XP presiserte kravene til CI-metodikken og understreket behovet for å bygge prosjektet flere ganger om dagen.

Tidlig på 2000-tallet begynte en av grunnleggerne av Agile Alliance, Martin Fowler , å fremme CI-metodikken. Hans eksperimenter med CI førte til utviklingen av det første programverktøyet på dette området—CruiseControl. Verktøyet ble laget av Martins kollega, Matthew Foemmel.

Byggesyklusen i verktøyet er implementert som en demon som periodisk sjekker versjonskontrollsystemet for endringer i kodebasen. Løsningen kan lastes ned fortsatt i dag—den distribueres er under BSD-lignende lisens.

Med fremveksten av programvare for CI begynte flere og flere selskaper å adoptere praksisen. Ifølge en Forrester [side 5 rapport] fra 2009 brukte 86% av de femti intervjuede teknologiselskapene CI-metoder eller var i ferd med å implementere dem.

I dag brukes Continuous Integration-praksis av organisasjoner i ulike bransjer. I 2018 gjennomførte en stor skytilbyder en undersøkelse blant IT-spesialister fra tjenestesektoren, utdanning og finans. Av de seks tusen respondentene svarte 58 % at de bruker CI-verktøy og -prinsipper i arbeidet sitt.

Hvordan det fungerer

Kjernen i kontinuerlig integrasjon består av to verktøy — versjonskontrollsystem og CI-server. Den siste kan være både en fysisk enhet eller en virtuell maskin i skyen. Utviklere laster opp ny kode én eller flere ganger om dagen. CI-serveren kopierer denne koden med alle avhengigheter og utfører byggingen. Deretter kjører den integrasjons- og enhetstester. Hvis testene er vellykkede, distribuerer CI-systemet koden.

Den generelle prosessen kan visualiseres som følger:

Referanse: hvordan Continuous Integration-prosessen fungerer

CI-metodologien stiller en rekke krav til utviklerne:

  • Umiddelbart rette opp problemer. Dette prinsippet kommer fra ekstrem programmering. Å fikse feil er utviklernes høyest prioriterte oppgave.
  • Automatisere prosesser. Utviklere og ledere må kontinuerlig lete etter 'flaskehalser' i integrasjonsprosessen og fjerne dem. For eksempel er 'flaskehalsen' i integrasjonen ofte testing. Bygge så ofte som mulig.
  • En gang om dagen for å synkronisere teamets arbeid. Utfordringer med implementering

Det første problemet er høye driftskostnader. Selv om selskapet bruker åpne CI-verktøy (som vi vil snakke om senere), må de fortsatt bruke penger på å opprettholde infrastrukturen. Skyteknologier kan imidlertid være løsningen.

De forenkler byggingen av ulike datakonfigurasjoner. I tillegg betaler selskapene

kun for ressursene de bruker, noe som hjelper dem å spare på infrastrukturen. betalt Ifølge undersøkelser [s. 14

], øker kontinuerlig integrasjon belastningen på selskapets ansatte (i det minste i begynnelsen). De må lære seg nye verktøy, og kolleger hjelper ikke alltid med opplæringen. Derfor må de håndtere nye rammeverk og tjenester 'underveis'. artikkel], kontinuerlig integrering øker belastningen på de ansatte i selskapet (i det minste i begynnelsen). De må lære seg nye verktøy, og kollegene hjelper ikke alltid med opplæringen. Derfor må de finne ut av nye rammeverk og tjenester "på farten".

Den tredje utfordringen er problemer med automatisering. Dette er en utfordring for organisasjoner med store mengder legacy-kode som ikke er dekket av automatiserte tester. Dette fører til at koden blir omskrevet før full implementering av CI.

Referanse: hvordan Continuous Integration-prosessen fungerer
/ Flickr / theilr / CC BY-SA

Hvem bruker

Blant de første som verdsatte fordelene med metoden var IT-giganter som Google. bruker Som implementerte kontinuerlig integrasjon fra midten av 2000-tallet. CI ble innført for å løse problemet med forsinkelser i søkemotorens drift. Kontinuerlig integrasjon har gjort det mulig å oppdage og fikse feil raskere. I dag bruker alle avdelinger hos IT-giganten CI.

Kontinuerlig integrasjon hjelper også små selskaper, og CI-verktøy brukes av finansielle og medisinske organisasjoner. For eksempel hjalp tjenester for kontinuerlig integrasjon hos Morningstar med å fikse sårbarheter 70% raskere. Den medisinske plattformen Philips Healthcare klarte å doble hastigheten på oppdateringstesting.

Tools

Her er noen populære CI-verktøy:

  • . Jeg vil svare slik. For de fleste oppgaver – en av de mest populære CI-systemene. Den støtter over tusen plugins for integrasjon med forskjellige VCS, skyplattformer og andre tjenester. Vi bruker også Jenkins i 1cloud: verktøyet er en del av vårt DevOps-system.. Det sjekker jevnlig Git-grenen som er ment for testing.
  • CruiseControl – et Python-rammeverk for å skrive egne prosesser for kontinuerlig integrasjon. Den første konfigurasjonen av verktøyet er ganske komplisert, men dette kompenseres av de omfattende tilpasningsmulighetene. Blant rammeverkets styrker fremhever brukerne dens lave ressursforbruk.
  • Concourse CI – en server fra Pivotal som bruker Docker-containere. Concourse CI integreres med alle verktøy og versjonskontrollsystemer. Utviklere bemerker at systemet passer for selskaper i alle størrelser.
  • Gitlab CI – et verktøy som er innebygd i versjonskontrollsystemet GitLab. Tjenesten fungerer i skyen og bruker YAML-filer til konfigurasjon. Som Concourse, gjør GitLab CI bruk av Docker-containere som hjelper med å isolere ulike prosesser fra hverandre.
  • Codeship – en skybasert CI-server som fungerer med GitHub, GitLab og BitBucket. Plattformen krever ikke lang innledende konfigurasjon – Codeship tilbyr standard forhåndsinstallerte CI-prosesser. For små prosjekter (opptil 100 bygg per måned) og open source-prosjekter er Codeship tilgjengelig gratis.

Materialer fra vår bedriftsblogg:

Kilde: habr.com

Kjøp pålitelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere 🔥 Kjøp pålitelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster