Wikipédia

Folyamatos integráció

Ez a közzétett változat, ellenőrizve: 2024. május 24.

A szoftverfejlesztés területén a folyamatos integráció (CI – continuous integration) az a fejlesztési folyamat, amikor a fejlesztők a munkájuk másolatát naponta akár többször is megosztják a verziókezelő rendszerben.[1] Grady Booch 1991-es módszerében javasolta először a CI kifejezést,[2] bár nem igazán támogatta a napi többszöri integrációt. Később az extrém programozás (XP) átvette a CI koncepcióját, és előnyben részesítette a napi egynél többszöri integráció folyamatát – még akár a napi tíz integrációt is.[3]

Indoklás

szerkesztés

Amikor a fejlesztő változtatni kezd a kódon, akkor másolja az aktuális forráskódot, amelyen dolgozik. Mivel a többi fejlesztő is megváltoztatott kódot küld a verziókezelő rendszerbe, ezért ez a példány fokozatosan eltűnik a verziókezelő rendszerből. Természetesen nem csak a meglévő forráskód változtatható meg, hanem új kód is hozzáadható, valamint új könyvtárak és egyéb erőforrások hozzáadása is lehetséges, amelyek viszont függőségeket és potenciális konfliktusokat hozhatnak létre.

Minél hosszabb ideig folytatjuk a fejlesztést egy ágazaton (Branch) belül anélkül, hogy egyesítenénk a fővonallal (master-branch), annál nagyobb a többszörös integrációs konfliktusok[4] és kudarcok kockázatának lehetősége, amikor a fejlesztett ágazatot végül egyesítjük a fővonalon. Amikor a fejlesztők kódot tesznek be a verziókezelőbe, először frissíteniük kell a kódot, hogy szemléltessék a másolat készítése óta bekövetkezett változásokat. Minél több változást tartalmaz a lerakat (repository), annál több munkát kell elvégezniük a fejlesztőknek, mielőtt benyújtanák a saját változásaikat.

Végül a lerakat annyira különbözhet a fejlesztők verzióitól, hogy beléphetnek az úgynevezett „integrációs pokolba”[5] ahol az integrációhoz szükséges idő meghaladhatja az eredeti módosítások elvégzéséhez szükséges időt.[6]

Munkafolyamatok

szerkesztés

Helyi tesztek futtatása

szerkesztés

A CI-t az automatizált egységteszttel kombinálva, a tesztvezérelt fejlesztés során kell felhasználni. Ezt úgy végezzük, hogy az összes egységtesztet futtatjuk és átadjuk a fejlesztőkörnyezetnek, mielőtt hozzáadnánk a fővonalhoz. Ez segít elkerülni, hogy az egyik fejlesztő befejezetlen munkáját megsemmisítse egy másik fejlesztő munkája. Szükség esetén a részben teljes funkciókat le lehet tiltani a végrehajtás előtt, például a funkcióváltások használatával.

Kód fordítása CI-ben

szerkesztés

A beépített fordítók rendszeresen vagy akár minden módosítás után összeállítják a kódot, és az eredményeket reprezentálják a fejlesztőknek. Az összeállító szerverek használatát már az XP-n (Extrém programozás) kívül vezették be, viszont a közösség és sok szervezet is elfogadta a CI-t anélkül, hogy az XP összes elvét elfogadták volna.

Tesztek futtatása CI-ben

szerkesztés

Az automatikus egységtesztek mellett a CI-t használó szervezetek általában építőkiszolgálót is használnak a folyamatos minőség-ellenőrzési folyamatok végrehajtása során – ez általában kis erőfeszítésekkel jár, viszont gyakran alkalmazva. Az egység és az integrációs tesztek futtatása mellett az ilyen folyamatok további statikus elemzéseket is futtatnak,és ezen kívül mérik és profilozzák a teljesítményt, kivonják és formázzák a forráskódot, valamint megkönnyítik a minőségbiztosítási folyamatokat. Például a nyílt forráskódú Travis CI szolgáltatáson a CI munkák csak 58,64% végez teszteket a folyamat során.[7]

A minőség-ellenőrzés folyamatos alkalmazásának a célja a szoftver minőségének javítása és a továbbításhoz szükséges idő lecsökkentése úgy, hogy a fejlesztés befejezése után a hagyományos ellenőrzési gyakorlatokat kiváltja. Ez nagyon hasonlít az eredeti elképzeléshez, amely szerint az integráció megkönnyítése érdekében a gyakoribb integrációt csak a minőségbiztosítási folyamatok során alkalmazzák.

Tárgy telepítése a CI-ből

szerkesztés

A CI gyakran összefonódik a folyamatos szállítással vagy a folyamatos telepítéssel az úgynevezett CI / CD csővezetékben. A CI gondoskodik arról, hogy a fővonalon bejelentkezett szoftver mindig olyan állapotban legyen, amely a felhasználók számára telepíthető, amit viszont a CD telepítési folyamat teljesen automatizál.

Történet

szerkesztés

A folyamatos integrációval kapcsolatos legkorábbi ismert munka az Infuse környezet volt, amelyet Kaiser G. E., Perry D. és Schell W. M. fejlesztett ki.[8]

Grady Booch 1994-ben a folyamatos integráció kifejezést használta az Objektumorientált elemzés és alkalmazás tervezésében (2. kiadás)[9] amelyben elmagyarázza, hogy hogyan fejlesztenek amikor mikrofolyamatokat végeznek „a belső kibocsátások a rendszer egyfajta folyamatos integrációját jelentik".

1997-ben Kent Beck és Ron Jeffries feltalálta az Extrém Programozási (XP) módszert, miközben a Chrysler átfogó kompenzációs rendszer projektjén alkalmazta a folyamatos integrációt.[1] Beck 1998-ban publikálta a folyamatos integrációt, amelyben hangsúlyozza a személyes kommunikáció fontosságát a technológiai támogatás mellett.[10] 1999-ben Beck bővebben foglalkozott az Extrém programozásról szóló könyvével.[11] A CruiseControl, volt az első nyílt forráskódú CI-eszközök egyike,[12] ami 2001-ben jelent meg.

Általános gyakorlatok

szerkesztés

Ez a szakasz felsorolja a különböző szerzők által javasolt bevált gyakorlatokat a folyamatos integráció eléréséhez és ezen gyakorlatok automatizálására. A legjobb gyakorlat az Automatikus összeépítés (Build automation).[13][14]

A folyamatos integrációnak – az új vagy megváltoztatott kódoknak a kódtárba történő integrálásának elég gyakorinak kell lennie, hogy ne fordulhasson elő hiba a beiktatás és az összeállítás között, valamint nem szabad hibáknak sem felmerülniük oly módon ,hogy a fejlesztők ne vegyék észre ezen hibákat, ugyanis ekkor nem tudnák azonnal kijavítani őket.[1] Normál gyakorlat az, hogy ezeket az összeépítéseket minden változtatás után végrehajtja, nem pedig egy időszakosan ütemezett összeállítást hajt végre. A gyors elkötelezettségek több fejlesztői környezetében történő elvégzésének gyakorlati lehetősége az ha minden egyes elkötelezettség után rövid időre elindul, és elkezdi összeépítést, amikor az időzítő lejár, vagy amikor az utolsó összeállítás óta hosszabb idő telik el. Érdemes figyelembe venni, hogy mivel minden új változtatás visszaállítja a használt időzítőt, ezért ez ugyanaz a technika, mintha egy gombokat lenyomó algoritmust használnánk.[15] Ilyen módon az elkövetési eseményeket „lebontják”, hogy elkerüljék a szükségtelen összegyűjtéseket a gyors változtatások sorozatai között. Számos automata eszköz automatikusan kínálja ezt az ütemezési lehetőséget.

Egy másik fontos tényező az atomi feladatokat támogató verziószabályozó rendszer megléte, ami a fejlesztő összes változását egyetlen átadási műveletnek tekinti. Ezért nincs értelme a megváltoztatott fájloknak csak a felét felépíteni.

Ezen célok elérésének érdekében a folyamatos integráció a következő elveken alapszik.

Kódtároló fenntartása

szerkesztés

Ez a gyakorlat a projekt forráskódjának felülvizsgálatát végző rendszer használatát támogatja. A projekt felépítéséhez szükséges összes tárgyat a lerakatba(repository) kell helyezni.Ebben a gyakorlatban és a revízió-ellenőrző közösségekben az a konvenció, hogy a rendszernek egy úgynevezett pénztárból kell felépülnie, ezáltal nem igényel további függőségeket.Az Extrém Programozás támogatója, Martin Fowler azt is megemlíti, hogy ha az elágazásokat eszközök támogatják, akkor annak a minimalizálását kell megkönnyíteni.[16] Ehelyett inkább érdemes a változtatások integrálását előtérbe helyezni, mint a szoftver többi verziójának egyszerre történő karbantartását.A fővonalnak viszont tartalmaznia kell a szoftver működő verzióját.

Automatikus összeállítás

szerkesztés

Egyetlen parancsnak képesnek kell lennie a rendszer felépítésére. Számos összeállító eszköz (Build tools), mint például a gyártó, évek óta létezik. Újabb eszközöket gyakran használnak a folyamatos integrációs környezetekben. Az automatikus összeállításnak magában kell foglalnia az integráció automatizálását, amely gyakran magában foglalja a telepítést egy termelés jellegű környezetbe. Sok esetben az összeállító szkript nem csak bináris fájlokat állít össze, hanem dokumentációkat, weboldalakat, statisztikákat és terjesztési eszközöket is (például Debian DEB, Red Hat RPM vagy Windows MSI fájlokat) generál.

Összeállító önteszt végrehajtása

szerkesztés

A kód elkészítése után az összes tesztet futtatni kell annak érdekében, hogy úgy viselkedjenek, ahogy a fejlesztők azt elvárják.[17]

Mindennap, mindenki hozzáadja a munkáját a fővonalhoz

szerkesztés

Rendszeres hozzáadással (comit) minden elkövető csökkentheti az ütköző változások számát. Egy hetes munka ellenőrzése azzal a kockázattal járhat, hogy az elkészült kód ellentétes lehet más funkciókkal szemben, és ezt a hibát nagyon nehéz lehet megoldani. Viszont a korai, kis konfliktusok a rendszerben arra késztetik a csapattagokat, hogy kommunikáljanak az általuk végrehajtott változásokról.[18] A folyamatos integráció definíciójának részét képezi az összes változás napi legalább egyszeri hozzáadása a verziókezelőhöz (egyszeri beépített szolgáltatásonként). Ezen felül általában ajánlott egy éjszakai összeállítás végrehajtása is. Viszont ezek alsó határok; a tipikus gyakoriság várhatóan sokkal több.

Minden hozzáadást a fővonalhoz kell igazítani

szerkesztés

Először is a rendszernek el kell készítenie a jelenlegi működő verziót, hogy ellenőrizze, hogy megfelelően integrálódnak-e. Általános gyakorlat az automatizált folyamatos integráció használata is, bár ezt manuálisan is meg lehet oldani. Az automatizált folyamatos integráció egy folyamatos integrációs szervert vagy démont(Számítógépes szoftver) alkalmaz, hogy figyelemmel tudja kísérni a revízió-vezérlő rendszert a változások szempontjából, majd automatikusan futtatja az összeállítási folyamatokat.

Minden hibajavításnak kísérleti esetet kell használnia

szerkesztés

A hiba kijavításához jó gyakorlat lehet egy olyan próbapéldány elküldése, amely a hibát reprodukálja. Ez elkerüli a javítás visszaállítását és a hiba megjelenését, amelyet regressziónak hívnak. A kutatók javaslatot tettek ennek a feladatnak az automatizálására: ha egy hibajavító feladat nem tartalmaz teszt esetet, akkor a már létező tesztekből is tudunk generálni.[19]

Gyors összeállítás megtartása

szerkesztés

Az összeállításnak gyorsan be kell fejeződnie, ezért ha probléma merül fel az integrációval, akkor az gyorsan azonosítható lesz.

Klón tesztelése a fejlesztő környezetben

szerkesztés

A tesztkörnyezet könnyen meghibásodáshoz vezethet a tesztelt rendszerekben, amikor telepítik őket a fejlesztői környezetbe, hiszen a fejlesztői környezet jelentősen eltérhet a tesztkörnyezettől.A fejlesztői környezet másolatának elkészítése azonban költséges. Ezért a tesztkörnyezetet vagy egy külön gyártás előtti környezetet ("átmeneti") kell összeállítani úgy, hogy a fejlesztői környezet verziója méretezhető legyen a költségek csökkentése érdekében, miközben megőrzi a technológiai verem (Stack) összetételeit és árnyalatait. Ezekben a tesztkörnyezetekben a szolgáltatás-virtualizációt általában arra használják, hogy igény szerint hozzáférést kapjanak azokhoz a függőségekhez (pl. API-k, harmadik féltől származó alkalmazások, szolgáltatások, mainframek stb.), amelyek még a csapat ellenőrzése alatt állnak, vagy még mindig fejlődnek vagy túl összetettek a konfiguráláshoz egy virtuális tesztlaborban.

Legfrissebb eredmények beszerzésének megkönnyítése

szerkesztés

A forráskód elérhetővé tétele az érdekelt felek és a tesztelők számára csökkentheti a szükséges újrafeldolgozások mennyiségét egy olyan szolgáltatás újjáépítésekor, amely nem felel meg a követelményeknek. Ezenkívül a korai tesztelés csökkenti a hibák fennmaradásának esélyét a telepítésig bezárólag. Ha a hibákat korábban megtaláljuk, csökkenthetjük a hibák elhárításához szükséges munkát.

Minden programozónak a projekt frissítésével kell kezdenie a napot. Ezáltal mind naprakészek lesznek.

Mindenki láthatja a fejlesztés legújabb eredményeit

szerkesztés

Ez szükséges annak a kiderítésében, hogy az összeépítés megszakadt-e, és ha igen, ki hajtotta végre a vonatkozó változtatást, és mi volt ez a változás.

Telepítés automatizálása

szerkesztés

A legtöbb CI-rendszer lehetővé teszi szkriptek futtatását a fejlesztés befejezése után. A legtöbb esetben viszont lehetséges egy olyan szkript írása is, amely az alkalmazást egy élő tesztkiszolgálóra telepíti, amelyet mindenki megnézhet. Ezen gondolkodásmód további előrelépése a folyamatos üzembe helyezés, amely a szoftvernak közvetlenül a gyártásba történő bevezetését követeli meg, gyakran egy kiegészítő automatizálással, a hibák vagy visszamenőleges értékek megelőzése végett.[20] [21]

Költségek és előnyök

szerkesztés

A folyamatos integráció célja, hogy olyan előnyöket biztosítson, mint például:

  • Az integrációs hibák a korai észlelések miatt, és a kis változtatások miatt könnyen megtalálhatók. Ez időt és pénzt takarít meg egy projekt élettartama alatt.
  • Elkerülhető az utolsó pillanatban kialakuló káosz a kiadás időpontjában,ha mindenki megpróbálja ellenőrizni kissé összeegyeztethetetlen verzióit.
  • Ha az egységteszt sikertelen vagy netán hiba jelentkezik, vagy ha a fejlesztőknek hibajavítás nélkül vissza kell állítaniuk a kódbázist hibamentes állapotba, akkor csak kevés módosítás veszik el (mivel az integráció gyakran fordul elő).
  • A „jelenlegi” verzió állandó rendelkezésre állása tesztelési, bemutató vagy kiadási célokra.
  • A gyakori kódbevitel arra készteti a fejlesztőket, hogy moduláris, kevésbé összetett kódot hozzanak létre.

A folyamatos automatizált tesztelés előnyei a következők:

  • Befolyásolja a gyakori automatizált tesztelést.
  • Azonnali visszajelzés a helyi változások rendszerszintű hatásairól.
  • Az automatikus tesztelésből és a CI-ből generált szoftvermérők (mint például a kód lefedettségének, a kód komplexitásának és a szolgáltatás teljességének) automatikus ellenőrzése miatt a fejlesztők inkább a funkcionális és minőségi kód fejlesztésére összpontosítanak, és elősegítik a csapat lendületének fejlesztését is.

A folyamatos integráció néhány hátránya:

  • Az automatizált tesztkészlet felépítése jelentős munkát igényel, ideértve az új funkciók lefedésére és a szándékos kódmódosításokra irányuló folyamatos erőfeszítéseket is.
    • A tesztelést a szoftverfejlesztés legjobb gyakorlatának is tekintik, függetlenül attól, hogy folyamatos integrációt alkalmaz-e, és az automatizálás a projekt módszertanának szerves része, mint például a tesztvezérelt fejlesztés.
    • A folyamatos integráció bármilyen tesztkészlet nélkül elvégezhető, de a kiadható termék előállításához a minőségbiztosítás költségei elég magasak lehetnek, ha manuálisan és gyakran kell elvégezni a teszteket.
  • Van némi munka az összeállító rendszer felállításával kapcsolatban, amely összetetté válhat, ezzel megnehezítve a rugalmas módosításokat.[22]
    • Számos folyamatos integrációs szoftverprojekt létezik, mind saját, mind nyílt forráskódú szoftverekkel, amelyek szabadon felhasználhatók.
  • A folyamatos integráció nem feltétlenül értékes, ha a projekt hatóköre kicsi vagy nem tesztelhető örökölt kódot is tartalmaz.
  • A hozzáadott értékek függnek a tesztek minőségétől és attól, hogy a kód valóban tesztelhető-e.[23]
  • A nagyobb csoportok azt jelentik, hogy az új kódot folyamatosan bővítik az integrációs sorba, így a módosítások követése (a minőség megőrzése mellett) nehéz lesz és a sorok felépítése mindenkit lelassíthat.
  • Napi többszöri módosítás és integráció esetén a szolgáltatás részleges kódját könnyen el lehet nyomni, és ezért az integrációs tesztek a szolgáltatás befejezéséig sikertelenek lesznek.
  • A biztonság és a küldetés szempontjából kritikus fejlesztésbiztosítás (például DO-178C, ISO 26262) szigorú dokumentációt és folyamatbeli felülvizsgálatot igényel, amelyet a folyamatos integrációval nehéz elérni.Az ilyen típusú életciklus gyakran további lépéseket tesz szükségessé a termék kiadása előtt, amikor már a termék hatósági jóváhagyása is szükséges.

Irodalom

szerkesztés
  1. ↑ a b c Fowler: Continuous Integration, 2006. május 1. (Hozzáférés: 2014. január 9.)
  2. ↑ Booch, Grady. Object Oriented Design: With Applications. Benjamin Cummings, 209. o. (1991). ISBN 9780805300918. Hozzáférés ideje: 2014. augusztus 18. 
  3. ↑ Beck (1999. november 4.). „Embracing change with extreme programming”. Computer 32 (10), 70–77. o. DOI:10.1109/2.796139. ISSN 0018-9162. 
  4. ↑ Duvall, Paul M.. Continuous Integration. Improving Software Quality and Reducing Risk. Addison-Wesley (2007). ISBN 978-0-321-33638-5 
  5. ↑ Cunningham: Integration Hell. WikiWikiWeb, 2009. augusztus 5. (Hozzáférés: 2009. szeptember 19.)
  6. ↑ What is Continuous Integration?. Amazon Web Services
  7. ↑ Durieux (2019. november 4.). „An Analysis of 35+ Million Jobs of Travis CI”. 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME), 291–295. o, Kiadó: IEEE. DOI:10.1109/ICSME.2019.00044. 
  8. ↑ Kaiser, G. E. (1989). „Infuse: fusing integration test management with change management”. Proceedings of the Thirteenth Annual International Computer Software & Applications Conference: 552–558. doi:10.1109/CMPSAC.1989.65147. 
  9. ↑ Booch, Grady. Object-Oriented Analysis and Design with applications [archivált változat], 2nd (1998. december 1.). Hozzáférés ideje: 2014. december 2. [archiválás ideje: 2019. augusztus 19.] 
  10. ↑ Beck, Kent. Extreme Programming Explained. Addison-Wesley Professional, 97. o. (1999). ISBN 978-0-201-61641-5 
  11. ↑ „A Brief History of DevOps, Part III: Automated Testing and Continuous Integration”, CircleCI, 2018. február 1. (Hozzáférés: 2018. május 19.) 
  12. ↑ „A Brief History of DevOps, Part III: Automated Testing and Continuous Integration”, CircleCI, 2018. február 1. (Hozzáférés: 2018. május 19.) 
  13. ↑ Brauneis, David (1 January 2010), "[OSLC Possible new Working Group – Automation"], open-services.net Community mailing list
  14. ↑ Taylor, Bradley: Rails Deployment and Automation with ShadowPuppet and Capistrano. Rails machine . [2012. december 2-i dátummal az eredetiből archiválva]. (Hozzáférés: 2010. február 16.)
  15. ↑ See for example Debounce. Arduino, 2015. július 29.
  16. ↑ Fowler: Practices. Continuous Integration. (Hozzáférés: 2015. november 29.)
  17. ↑ Radigan: Continuous integration. Atlassian Agile Coach
  18. ↑ Continuous Integration. Thoughtworks
  19. ↑ Danglot (2020. március 5.). „An approach and benchmark to detect behavioral changes of commits in continuous integration” (angol nyelven). Empirical Software Engineering. DOI:10.1007/s10664-019-09794-7. ISSN 1382-3256. 
  20. ↑ Ries: Continuous deployment in 5 easy steps. Radar. O’Reilly, 2009. március 30. (Hozzáférés: 2013. január 10.)
  21. ↑ Fitz: Continuous Deployment at IMVU: Doing the impossible fifty times a day. Wordpress, 2009. február 10. (Hozzáférés: 2013. január 10.)
  22. ↑ Laukkanen (2016). „Problems, causes and solutions when adopting continuous delivery—A systematic literature review”. Information and Software Technology 82, 55–79. o. DOI:10.1016/j.infsof.2016.10.001. 
  23. ↑ Debbiche: Assessing challenges of continuous integration in the context of software requirements breakdown: a case study

Fordítás

szerkesztés

Ez a szócikk részben vagy egészben a Continuous integration című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

Kapcsolódó szócikk

szerkesztés

További információk

szerkesztés
A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Folyamatos_integráció&oldid=27155794”