🥇Referencer: hvordan Continuous Integration-processen fungerer

I dag vil vi se på historien bag termen, diskutere udfordringerne ved implementering af CI og give nogle populære værktøjer, der kan hjælpe med det.

/ Flickr / Altug Karakoc / CC BY / Фото изменено

Term

Continuous Integration (kontinuerlig integration) er en tilgang til applikationsudvikling, der indebærer hyppige bygninger af projektet og testning af koden.

Målet er at gøre integrationsprocessen forudsigelig og opdage potentielle fejl og mangler på et tidligt stadium for at få mere tid til at rette dem.

Begrebet Continuous Integration dukkede første gang op i 1991. Det blev introduceret af skaberen af UML-sproget Grady Booch . Ingeniøren præsenterede CI-konceptet som en del af sin egen udviklingspraksis — Booch-metoden. Han mente, at det skulle involvere inkrementel forfinelse af arkitekturen under design af objektorienterede systemer. Grady beskrev ikke nogen specifikke krav til kontinuerlig integration. Men senere i sin bog "Object-Oriented Analysis and Design with Applications" sagde han, at metodens opgave var at fremskynde udgivelsen af "interne releases".

Historik

I 1996 blev CI adopteret af skaberne af metodologien ekstrem programmering (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-metodologien og påpegede nødvendigheden af at bygge projektet flere gange om dagen.

I begyndelsen af 2000'erne blev metodologien for kontinuerlig integration promoveret af en af grundlæggerne af Agile Alliance Martin Fowler . Hans eksperimenter med CI førte til udviklingen af det første softwareværktøj inden for dette område — CruiseControl. Værktøjet blev skabt af Martins kollega — Matthew Foemmel.

Byggeværkstedets cyklus er implementeret som en daemon, der periodisk tjekker versionsstyringssystemet for ændringer i kodebasen. Løsningen kan downloades den dag i dag — det er distribueres under en BSD-lignende licens.

Med fremkomsten af CI-software begyndte flere og flere virksomheder at adoptere praksisen. Ifølge en undersøgelse fra Forrester [s. 5 rapporten] brugte eller implementerede 86% af de femoghalvtreds adspurgte teknologivirksomheder CI-metoder i 2009.

I dag anvendes Continuous Integration-praksis af organisationer i forskellige brancher. I 2018 gennemførte en stor cloud-udbyder en undersøgelse blandt IT-specialister fra service-, uddannelses- og finanssektoren. Af de seks tusinde respondenter svarede 58%, at de anvender CI-værktøjer og -principper i deres arbejde.

Hvordan fungerer det

Grundlaget for kontinuerlig integration består af to værktøjer - versionskontrolsystemet og CI-serveren. Sidstnævnte kan være både en fysisk enhed eller en virtuel maskine i en cloud-miljø. Udviklere uploader ny kode en eller flere gange om dagen. CI-serveren kopierer automatisk koden med alle afhængigheder og bygger den. Derefter kører den integrations- og enhedstest. Hvis testsene lykkes, implementerer CI-systemet koden.

Den generelle skitse af processen kan repræsenteres som følger:

CI-metodologien stiller en række krav til udviklerne:

At rette problemer straks. Dette princip kom ind i CI fra ekstrem programmering. At rette fejl er den højeste prioritet for udviklerne.
At automatisere processer. Udviklere og ledere skal konstant søge efter 'flaskehalse' i integrationsprocessen og fjerne dem. For eksempel er det ofte 'flasken' for integrationen det er testning.
At udføre bygninger så ofte som muligt. En gang om dagen for at synkronisere teamets arbejde.

Udfordringer ved implementering

Det første problem er de høje driftsomkostninger. Selv hvis virksomheden bruger åbne CI-værktøjer (som vi vil tale om senere), skal den stadig bruge penge på at opretholde infrastrukturen. Men cloud-teknologi kan være løsningen.

De forenkler opbygningen af forskellige computerkonfigurationer. Plus er virksomhederne betaler kun for de ressourcer, de bruger, hvilket hjælper med at spare på infrastrukturen.

Ifølge undersøgelser [s.14 artikler], øger kontinuerlig integration arbejdsbyrden for virksomhedens medarbejdere (i det mindste i starten). De skal lære nye værktøjer, og kollegerne hjælper ikke altid med træningen. Derfor må de lære nye rammer og tjenester 'undervejs'.

Den tredje udfordring er problemer med automatisering. Dette støder organisationer med store mængder legacy-kode, som ikke er dækket af automatiserede tests. Det fører til, at koden blot omskrives, inden CI implementeres fuldt ud.

/ Flickr / theilr / CC BY-SA

Hvem bruger

IT-giganterne var blandt de første til at sætte pris på metodens fordele. Google bruger implementerede kontinuerlig integration midt i 2000'erne. CI blev indført for at løse problemet med forsinkelser i søgemaskinens drift. Kontinuerlig integration hjalp med hurtigt at opdage og rette fejl. I dag bruger alle IT-gigantens afdelinger CI.

Kontinuerlig integration hjælper også små virksomheder, og CI-værktøjer anvendes af finansielle og medicinske organisationer. For eksempel hjalp CI-tjenester hos Morningstar med at patche sårbarheder 70% hurtigere. Den medicinske platform Philips Healthcare formåede at fordoble hastigheden for test af opdateringer.

Værktøjer

Her er nogle populære værktøjer til CI:

Jenkins — et af de mest populære CI-systemer. Det understøtter over tusind plugins til integration med forskellige VCS, cloud-platforme og andre tjenester. Jenkins bruger vi også i 1cloud: værktøjet indgår i vores DevOps-system. Det kontrollerer regelmæssigt Git-grenen, der er beregnet til testning.
Buildbot — et python-rammeværk til at skrive egne processer for kontinuerlig integration. Den oprindelige opsætning af værktøjet er ret kompleks, men dette opvejes af de mange tilpasningsmuligheder. Blandt rammeværkets fordele fremhæver brugerne dens lave ressourceforbrug.
Concourse CI — en server fra Pivotal, der bruger Docker-containere. Concourse CI integreres med enhver værktøj og versionskontrolsystemer. Udviklerne bemærker, at systemet er velegnet til virksomheder af enhver størrelse.
Gitlab CI — et værktøj, der er integreret i GitLabs versionskontrolsystem. Tjenesten arbejder i skyen og bruger YAML-filer til konfiguration. Som Concourse anvender Gitlab CI bruger Docker-containere, der hjælper med at isolere forskellige processer fra hinanden.
Codeship — en cloud-baseret CI-server, der arbejder med GitHub, GitLab og BitBucket. Platformen kræver ikke en langvarig opsætning — der er standard CI-processer tilgængelige i Codeship. For små (op til 100 builds om måneden) og open source-projekter er Codeship gratis.