I dag vil vi se på udtrykkets historie, diskutere vanskelighederne ved at implementere CI og give flere populære værktøjer, der vil hjælpe dig med at arbejde med det.
/flickr/ / / Foto ændret
sigt
Kontinuerlig integration er en tilgang til applikationsudvikling, der involverer hyppige projektopbygninger og kodetest.
Målet er at gøre integrationsprocessen forudsigelig og opdage potentielle fejl og fejl på et tidligt tidspunkt, så der er mere tid til at rette dem.
Udtrykket Kontinuerlig Integration dukkede første gang op i 1991. Det blev introduceret af skaberen af UML-sproget (Grady Booch). Ingeniøren introducerede konceptet CI som en del af sin egen udviklingspraksis - . Det indebar en trinvis forfining af arkitekturen ved design af objektorienterede systemer. Gradi beskrev ingen krav til kontinuerlig integration. Men senere i sin bog ""Han sagde, at målet med metoden er at fremskynde udgivelsen af "interne udgivelser."
Story
I 1996 blev CI vedtaget af skaberne af metoden (XP) - (Kent Beck) og (Ron Jeffries). Kontinuerlig integration blev et af de tolv nøgleprincipper i deres tilgang. Grundlæggerne af XP præciserede kravene til CI-metoden og bemærkede behovet for at bygge projektet flere gange om dagen.
I begyndelsen af 2000'erne begyndte en af grundlæggerne af Agile Alliance at fremme den kontinuerlige integrationsmetodologi (Martin Fowler). Hans eksperimenter med CI førte til det første softwareværktøj på dette område - CruiseControl. Værktøjet blev skabt af Martins kollega, Matthew Foemmel.
Byggecyklussen i værktøjet er implementeret som en dæmon, der periodisk tjekker versionskontrolsystemet for ændringer i kodebasen. Løsningen kan downloades i dag - den under en BSD-lignende licens.
Med fremkomsten af software til CI begyndte flere og flere virksomheder at tage denne praksis i brug. Ifølge forskning fra Forrester [side 5 ], i 2009 brugte eller implementerede 86 % af de halvtreds undersøgte teknologivirksomheder CI-metoder.
I dag bliver praksis med kontinuerlig integration brugt af organisationer fra en lang række forskellige brancher. I 2018 gennemførte en stor cloud-udbyder en undersøgelse blandt it-specialister fra virksomheder inden for service-, uddannelses- og finanssektoren. Af de seks tusinde adspurgte sagde 58 %, at de bruger CI-værktøjer og -principper i deres arbejde.
Hvordan fungerer denne her
Kontinuerlig integration er baseret på to værktøjer: et versionskontrolsystem og en CI-server. Sidstnævnte kan enten være en fysisk enhed eller en virtuel maskine i et cloudmiljø. Udviklere uploader ny kode en eller flere gange om dagen. CI-serveren kopierer den automatisk med alle afhængigheder og bygger den. Bagefter kører den integration og enhedstest. Hvis testene lykkes, implementerer CI-systemet koden.
Det generelle procesdiagram kan repræsenteres som følger:
CI-metoden stiller en række krav til udviklere:
- Ret problemer med det samme. Dette princip kom til CI fra ekstrem programmering. At rette fejl er udviklernes højeste prioritet.
- Automatiser processer. Udviklere og ledere skal hele tiden lede efter flaskehalse i integrationsprocessen og fjerne dem. For eksempel er der ofte en flaskehals i integrationen afprøvning.
- Gennemfør samlinger så ofte som muligt. En gang om dagen for at synkronisere teamets arbejde.
Implementeringsvanskeligheder
Det første problem er høje driftsomkostninger. Selvom en virksomhed bruger åbne CI-værktøjer (som vi vil tale om senere), vil den stadig skulle bruge penge på infrastrukturunderstøttelse. Cloud-teknologier kan dog være løsningen.
De forenkler samlingen af computerkonfigurationer i forskellige skalaer. Plus af virksomheden kun for de anvendte ressourcer, hvilket hjælper med at spare på infrastrukturen.
Ifølge undersøgelser [side 14 ], kontinuerlig integration øger belastningen på virksomhedens ansatte (i hvert fald i første omgang). De skal lære nye værktøjer, og kollegerne hjælper ikke altid med træning. Derfor er du nødt til at håndtere nye rammer og tjenester på farten.
Den tredje vanskelighed er problemer med automatisering. Organisationer med en stor mængde ældre kode, der ikke er dækket af automatiserede tests, står over for dette problem. Dette fører til, at koden simpelthen omskrives før den fulde implementering af CI.
/flickr/ /
Hvem bruger
IT-giganter var blandt de første til at værdsætte fordelene ved metoden. Google kontinuerlig integration siden midten af 2000'erne. CI blev implementeret for at løse problemet med forsinkelser i søgemaskinen. Kontinuerlig integration hjalp til hurtigt at opdage og løse problemer. Nu bruges CI af alle afdelinger i IT-giganten.
Kontinuerlig integration hjælper også små virksomheder, og CI-værktøjer bruges også af finans- og sundhedsorganisationer. For eksempel, hos Morningstar hjalp kontinuerlig integrationstjenester med at rette sårbarheder 70 % hurtigere. Og Philips Healthcares medicinske platform var i stand til at fordoble hastigheden af testopdateringer.
Værktøj
Her er nogle populære værktøjer til CI:
- er et af de mest populære CI-systemer. Det understøtter mere end tusind plugins til integration med forskellige VCS, cloud-platforme og andre tjenester. Vi bruger også Jenkins på 1cloud: tool . Han tjekker jævnligt Git-grenen, der er beregnet til test.
- — en pythonramme til at skrive dine egne kontinuerlige integrationsprocesser. Den indledende opsætning af værktøjet er ret kompliceret, men dette kompenseres af de brede tilpasningsmuligheder. Blandt fordelene ved rammen fremhæver brugerne dens lave ressourceintensitet.
- er en server fra Pivotal, der bruger Docker-containere. Concourse CI integreres med alle værktøjer og versionskontrolsystemer. Udviklerne bemærker, at systemet er velegnet til arbejde i virksomheder af enhver størrelse.
- er et værktøj indbygget i GitLab versionskontrolsystemet. Tjenesten kører i skyen og bruger YAML-filer til konfiguration. Ligesom Concourse, Gitlab CI Docker-containere, der hjælper med at isolere forskellige processer fra hinanden.
- er en cloud CI-server, der fungerer med GitHub, GitLab og BitBucket. Platformen kræver ikke lang indledende opsætning - standard forudinstallerede CI-processer er tilgængelige i Codeship. For små (op til 100 builds pr. måned) og open source-projekter er Codeship tilgængelig gratis.
Materialer fra vores virksomhedsblog:
Kilde: www.habr.com