Verwysing: hoe die Deurlopende Integrasie-proses werk

Vandag sal ons na die geskiedenis van die term kyk, die probleme van die implementering van CI bespreek en verskeie gewilde hulpmiddels verskaf wat jou sal help om daarmee te werk.

Verwysing: hoe die Deurlopende Integrasie-proses werk
/flickr/ Altug Karakoc / CC BY / Foto gewysig

Termyn

Deurlopende integrasie is 'n benadering tot toepassingsontwikkeling wat gereelde projekbou en kodetoetsing behels.

Die doel is om die integrasieproses voorspelbaar te maak en potensiële foute en foute op 'n vroeë stadium op te spoor, sodat daar meer tyd is om dit reg te stel.

Die term Deurlopende integrasie het die eerste keer in 1991 verskyn. Dit is bekendgestel deur die skepper van die UML-taal Grady Butch (Grady Booch). Die ingenieur het die konsep van CI bekendgestel as deel van sy eie ontwikkelingspraktyk - Booch metode. Dit het inkrementele verfyning van die argitektuur geïmpliseer wanneer objekgeoriënteerde stelsels ontwerp word. Gradi het geen vereistes vir deurlopende integrasie beskryf nie. Maar later in sy boek “Objekgeoriënteerde analise en ontwerp met toepassings"Hy het gesê dat die doel van die metodologie is om die vrystelling van "interne vrystellings" te bespoedig.

Story

In 1996 is CI deur die skeppers van die metodologie aangeneem ekstreme programmering (XP) - Kent Beck (Kent Beck) en Ron Jeffries (Ron Jeffries). Deurlopende integrasie het een van die twaalf sleutelbeginsels van hul benadering geword. Die stigters van XP het die vereistes vir die CI-metodologie uitgeklaar en kennis geneem van die behoefte om die projek verskeie kere per dag te bou.

In die vroeë 2000's het een van die stigters van die Agile Alliance begin om die deurlopende integrasiemetodologie te bevorder Martin Fowler (Martin Fowler). Sy eksperimente met CI het gelei tot die eerste sagteware-instrument op hierdie gebied - CruiseControl. Die hulpprogram is geskep deur Martin se kollega, Matthew Foemmel.

Die bousiklus in die instrument word geïmplementeer as 'n daemon wat die weergawebeheerstelsel periodiek nagaan vir veranderinge in die kodebasis. Die oplossing kan vandag afgelaai word - dit versprei deur onder 'n BSD-agtige lisensie.

Met die koms van sagteware vir CI het meer en meer maatskappye die praktyk begin aanneem. Volgens Forrester-navorsing [bladsy 5 rapporteer], in 2009 het 86% van die vyftig tegnologiemaatskappye wat ondervra is, GI-metodes gebruik of geïmplementeer.

Vandag word die praktyk van Deurlopende Integrasie deur organisasies van 'n wye verskeidenheid industrieë gebruik. In 2018 het 'n groot wolkverskaffer 'n opname onder IT-spesialiste van maatskappye in die dienste-, onderwys- en finansiesektore gedoen. Van die sesduisend respondente het 58% gesê dat hulle GI-instrumente en -beginsels in hul werk gebruik.

Hoe werk dit

Deurlopende integrasie is gebaseer op twee instrumente: 'n weergawebeheerstelsel en 'n CI-bediener. Laasgenoemde kan óf 'n fisiese toestel óf 'n virtuele masjien in 'n wolkomgewing wees. Ontwikkelaars laai nuwe kode een of meer keer per dag op. Die CI-bediener kopieer dit outomaties met al die afhanklikhede en bou dit. Daarna voer dit integrasie- en eenheidstoetse uit. As die toetse suksesvol slaag, ontplooi die CI-stelsel die kode.

Die algemene prosesdiagram kan soos volg voorgestel word:

Verwysing: hoe die Deurlopende Integrasie-proses werk

Die CI-metodologie stel 'n aantal vereistes vir ontwikkelaars:

  • Maak probleme dadelik reg. Hierdie beginsel het na CI gekom van uiterste programmering. Die regmaak van foute is die ontwikkelaars se hoogste prioriteit.
  • Outomatiseer prosesse. Ontwikkelaars en bestuurders moet voortdurend na knelpunte in die integrasieproses soek en dit uitskakel. Daar is byvoorbeeld dikwels 'n bottelnek in integrasie dit blyk toets.
  • Voer vergaderings so gereeld as moontlik. Een keer per dag om die span se werk te sinchroniseer.

Implementeringsprobleme

Die eerste probleem is hoë bedryfskoste. Selfs al gebruik 'n maatskappy oop CI-gereedskap (waaroor ons later sal praat), sal dit steeds geld aan infrastruktuurondersteuning moet spandeer. Wolktegnologieë kan egter die oplossing wees.

Hulle vereenvoudig die samestelling van rekenaarkonfigurasies op verskillende skaal. Plus van die maatskappy betaal slegs vir die hulpbronne wat gebruik word, wat help om op infrastruktuur te bespaar.

Volgens opnames [bladsy 14 Artikel], deurlopende integrasie verhoog die las op maatskappywerknemers (ten minste aanvanklik). Hulle moet nuwe gereedskap aanleer, en kollegas help nie altyd met opleiding nie. Daarom moet u nuwe raamwerke en dienste onderweg hanteer.

Die derde probleem is probleme met outomatisering. Organisasies met 'n groot hoeveelheid verouderde kode wat nie deur outomatiese toetse gedek word nie, ondervind hierdie probleem. Dit lei daartoe dat die kode eenvoudig herskryf word voor die volle implementering van CI.

Verwysing: hoe die Deurlopende Integrasie-proses werk
/flickr/ hulle / CC BY-SA

Wie gebruik

IT-reuse was van die eerstes wat die voordele van die metodologie waardeer het. Google gebruike deurlopende integrasie sedert die middel van die 2000's. CI is geïmplementeer om die probleem van vertragings in die soekenjin op te los. Deurlopende integrasie het gehelp om probleme vinnig op te spoor en op te los. Nou word CI deur alle departemente van die IT-reus gebruik.

Deurlopende integrasie help ook klein ondernemings, en CI-instrumente word ook deur finansiële en gesondheidsorgorganisasies gebruik. Byvoorbeeld, by Morningstar het deurlopende integrasiedienste gehelp om kwesbaarhede 70% vinniger te herstel. En die Philips Healthcare mediese platform kon die spoed van toetsopdaterings verdubbel.

Tools

Hier is 'n paar gewilde gereedskap vir CI:

  • Jenkins is een van die gewildste CI-stelsels. Dit ondersteun meer as duisend plugins vir integrasie met verskeie VCS, wolkplatforms en ander dienste. Ons gebruik ook Jenkins by 1cloud: tool ingesluit in ons DevOps-stelsel. Hy kyk gereeld na die Git-tak wat bedoel is om te toets.
  • boubot — 'n luislangraamwerk vir die skryf van jou eie deurlopende integrasieprosesse. Die aanvanklike opstelling van die instrument is redelik ingewikkeld, maar dit word vergoed deur die wye aanpassingsopsies. Onder die voordele van die raamwerk beklemtoon gebruikers die lae hulpbronintensiteit daarvan.
  • Hal CI is 'n bediener van Pivotal wat Docker-houers gebruik. Concourse CI integreer met enige gereedskap en weergawebeheerstelsels. Die ontwikkelaars let daarop dat die stelsel geskik is vir werk in maatskappye van enige grootte.
  • Gitlab CI is 'n instrument wat in die GitLab-weergawebeheerstelsel ingebou is. Die diens loop in die wolk en gebruik YAML-lêers vir konfigurasie. Soos Concourse, Gitlab CI van toepassing is Docker-houers wat help om verskillende prosesse van mekaar te isoleer.
  • Kodskap is 'n wolk CI-bediener wat met GitHub, GitLab en BitBucket werk. Die platform vereis nie lang aanvanklike opstelling nie - standaard vooraf geïnstalleerde CI-prosesse is beskikbaar in Codeship. Vir klein (tot 100 geboue per maand) en oopbronprojekte is Codeship gratis beskikbaar.

Materiaal van ons korporatiewe blog:

Bron: will.com

Voeg 'n opmerking