Hivatkozás: hogyan működik a folyamatos integrációs folyamat

Ma áttekintjük a kifejezés történetét, megvitatjuk a CI bevezetésének nehézségeit, és számos népszerű eszközt kínálunk, amelyek segítenek a vele való munkavégzésben.

Hivatkozás: hogyan működik a folyamatos integrációs folyamat
/flickr/ Altug Karakoc / CC BY / Fotó módosítva

kifejezés

A folyamatos integráció az alkalmazásfejlesztés olyan megközelítése, amely gyakori projektfelépítést és kódtesztelést foglal magában.

A cél az integrációs folyamat kiszámíthatóvá tétele, a lehetséges hibák és hibák korai szakaszban történő észlelése, hogy több idő maradjon azok kijavítására.

A Continuous Integration kifejezés először 1991-ben jelent meg. Az UML nyelv megalkotója vezette be Grady Butch (Grady Booch). A mérnök saját fejlesztési gyakorlata részeként vezette be a CI fogalmát - Booch módszer. Az objektumorientált rendszerek tervezése során az architektúra fokozatos finomítását jelentette. Gradi nem írt le semmilyen követelményt a folyamatos integrációhoz. De később a könyvében „Objektum-orientált elemzés és tervezés alkalmazásokkal„Azt mondta, hogy a módszertan célja a „belső kiadások” megjelenésének felgyorsítása.

Történet

1996-ban a CI-t átvették a módszertan megalkotói extrém programozás (XP) - Kent Beck (Kent Beck) és Ron Jeffries (Ron Jeffries). A folyamatos integráció megközelítésük tizenkét alapelvének egyike lett. Az XP alapítói tisztázták a CI módszertan követelményeit, és megjegyezték, hogy a projektet naponta többször kell megépíteni.

A 2000-es évek elején az Agilis Szövetség egyik alapítója elkezdte népszerűsíteni a folyamatos integráció módszertanát. Martin Fowler (Martin Fowler). A CI-vel végzett kísérletei az első szoftvereszközhöz vezettek ezen a területen - a CruiseControl-hoz. A segédprogramot Martin kollégája, Matthew Foemmel készítette.

Az eszköz összeállítási ciklusa démonként van megvalósítva, amely időszakonként ellenőrzi a verzióvezérlő rendszert a kódbázis változásaiért. A megoldás ma letölthető – ez forgalmazza BSD-szerű licenc alatt.

A CI szoftverek megjelenésével egyre több vállalat kezdte átvenni ezt a gyakorlatot. A Forrester kutatása szerint [5 jelentés], 2009-ben a megkérdezett ötven technológiai vállalat 86%-a használt vagy alkalmazott CI-módszert.

Napjainkban a folyamatos integráció gyakorlatát a legkülönfélébb iparágak szervezetei alkalmazzák. 2018-ban egy nagy felhőszolgáltató felmérést végzett a szolgáltatási, oktatási és pénzügyi szektor vállalatainak informatikusai körében. A hatezer válaszadó 58%-a nyilatkozott úgy, hogy a CI eszközöket és elveket használja munkája során.

Ez hogy működik

A folyamatos integráció két eszközön alapul: egy verziókezelő rendszeren és egy CI szerveren. Ez utóbbi lehet fizikai eszköz vagy virtuális gép felhőkörnyezetben. A fejlesztők naponta egyszer vagy többször töltenek fel új kódot. A CI-szerver automatikusan lemásolja az összes függőséggel együtt, és összeállítja. Ezt követően integrációs és egységteszteket futtat. Ha a tesztek sikeresek, a CI-rendszer telepíti a kódot.

Az általános folyamatábra a következőképpen ábrázolható:

Hivatkozás: hogyan működik a folyamatos integrációs folyamat

A CI módszertana számos követelményt támaszt a fejlesztőkkel szemben:

  • A problémákat azonnal javítsa ki. Ez az elv az extrém programozásból jött a CI-be. A hibák kijavítása a fejlesztők legfontosabb feladata.
  • Automatizálja a folyamatokat. A fejlesztőknek és menedzsereknek folyamatosan keresniük kell az integrációs folyamat szűk keresztmetszeteit, és azokat fel kell küszöbölniük. Például gyakran van szűk keresztmetszet az integrációban kiderül tesztelés.
  • A lehető leggyakrabban hajtsa végre az összeszerelést. Naponta egyszer, hogy szinkronizálja a csapat munkáját.

Megvalósítási nehézségek

Az első probléma a magas üzemeltetési költségek. Még ha egy vállalat nyílt CI-eszközöket használ is (erről később lesz szó), akkor is költenie kell az infrastruktúra támogatására. A felhőtechnológiák azonban megoldást jelenthetnek.

Leegyszerűsítik a különböző méretű számítógép-konfigurációk összeállítását. Plusz a cég fizetve vannak csak a felhasznált erőforrásokra, ami segít megtakarítani az infrastruktúrát.

Felmérések szerint [14. oldal Cikk], a folyamatos integráció növeli a vállalati alkalmazottak terhelését (legalábbis eleinte). Új eszközöket kell megtanulniuk, és a kollégák sem mindig segítenek a képzésben. Ezért útközben új keretrendszerekkel és szolgáltatásokkal kell megküzdenie.

A harmadik nehézség az automatizálással kapcsolatos problémák. Azon szervezetek szembesülnek ezzel a problémával, amelyek nagy mennyiségű örökölt kóddal rendelkeznek, amelyet nem fednek le az automatizált tesztek. Ez ahhoz a tényhez vezet, hogy a kódot egyszerűen átírják a CI teljes megvalósítása előtt.

Hivatkozás: hogyan működik a folyamatos integrációs folyamat
/flickr/ theilr / CC BY-SA

Ki használja

Az IT-óriások az elsők között értékelték a módszertan előnyeit. Google felhasznál folyamatos integráció a 2000-es évek közepe óta. A CI-t azért vezették be, hogy megoldja a keresőmotor késései problémáját. A folyamatos integráció segített a problémák gyors felismerésében és megoldásában. A CI-t jelenleg az IT-óriás összes részlege használja.

A folyamatos integráció a kisvállalkozásokat is segíti, a CI eszközöket a pénzügyi és egészségügyi szervezetek is használják. Például a Morningstarnál a folyamatos integrációs szolgáltatások 70%-kal gyorsabban javították a sebezhetőségeket. A Philips Healthcare orvosi platform pedig megduplázta a frissítések tesztelésének sebességét.

Tools

Íme néhány népszerű eszköz a CI-hez:

  • Jenkins az egyik legnépszerűbb CI rendszer. Több mint ezer beépülő modult támogat a különféle VCS-ekkel, felhőplatformokkal és egyéb szolgáltatásokkal való integrációhoz. Jenkinst is használunk az 1cloud: eszköznél szerepel a DevOps rendszerünkben. Rendszeresen ellenőrzi a tesztelésre szánt Git ágat.
  • Buildbot — python keretrendszer saját folyamatos integrációs folyamatainak megírásához. Az eszköz kezdeti beállítása meglehetősen bonyolult, de ezt kompenzálja a széles testreszabási lehetőségek. A keretrendszer előnyei közül a felhasználók kiemelik az alacsony erőforrás-intenzitást.
  • Konferencia CI a Pivotal szervere, amely Docker-tárolókat használ. A Concourse CI minden eszközzel és verziókezelő rendszerrel integrálható. A fejlesztők megjegyzik, hogy a rendszer bármilyen méretű cégnél alkalmazható.
  • Gitlab CI a GitLab verziókezelő rendszerébe beépített eszköz. A szolgáltatás a felhőben fut, és YAML fájlokat használ a konfigurációhoz. Mint a Concourse, a Gitlab CI vonatkozik Docker konténerek, amelyek segítenek elkülöníteni a különböző folyamatokat egymástól.
  • Kódolás egy felhőalapú CI-szerver, amely a GitHub, a GitLab és a BitBucket szolgáltatásokkal működik. A platform nem igényel hosszú kezdeti beállítást – szabványos előre telepített CI-folyamatok állnak rendelkezésre a Codeshipben. Kisebb (havi 100 buildig) és nyílt forráskódú projektekhez a Codeship ingyenesen elérhető.

Vállalati blogunk anyagai:

Forrás: will.com

Hozzászólás