Többlépcsős folyamatos egyesítés
A többlépcsős folyamatos egyesítés egy szoftverfejlesztői módszer, amelynek célja, hogy magas szinten integrált párhuzamos fejlesztést érjen el, és ez alatt csökkentse az egyesítésből származó problémák kiterjedését.[1]
Elmélet szerkesztés
A többlépcsős folyamatos egyesítés előnyt szerez a szoftverfejlesztés alapvető folyamatából: a szoftver több lépcsőfokon keresztül egy kezdetleges állapotból egy kész állapotba halad. Ennek segítségével a munkát szét lehet osztani logikai egységeire, amelyeken különálló csapatok dolgozhatnak egyszerre, és ezeket a egységeket időközönként egyesítik. Ami változik vállalatonként, az a lépcsőfokok száma, a csapatok mérete és száma és a csapatok kölcsönös függőségeinek felépítése.
Ajánlott gyakorlatok szerkesztés
A többlépcsős folyamatos egyesítés az a folyamatos integráció továbbfejlesztése, ezért az ott lévő általános gyakorlatok követése itt már feltételezve vannak.
Minél nagyobb és/vagy bonyolultabb a projekt, annál nagyobb az esélye, hogy a projekt instabil lesz. A figyelmeztetések és a nem működő lefordított programok száma növekszik, ahogy a projekt mérete növekszik. Lassulni fog a haladás, és a fő ág egyre instabilabb lesz. A fejlesztők és a fejlesztési helyszínek növekedésével a sikertelen fordítások száma exponenciálisan növekszik.[2]
Ajánlott gyakorlat #1 szerkesztés
Minden fejlesztő a saját feladatán dolgozik. Ahogy változások keletkeznek, folyamatos egyesítés történik a csapat ága alapján, ha az nem sikeres, akkor az a fejlesztő (akár a csapattársai segítségével) kijavítja az ágat. Amikor bármilyen probléma van, csak az a csapat érintett, és nem mindenki. Ez a modern gyártóüzemekhez hasonlít, ahol ha valaki megállítja egy gyártósor egy részét, akkor csak az a rész áll le, és nem az összes.
Megemlítésre méltó, hogy az elmúlt években a "téma" vagy "funkció" alapú ágmodellek népszerűséget szereztek a csapat alapúakhoz képest. Lásd például a Git-Flow ágazási modellt.[3]
Gyakran a csapat úgy dönt, hogy a második fázisba kezd: egyesítés a fő ággal. Ebben a fázisban a csapat ugyanazt csinálja, mint egy egyéni fejlesztő csinálna a fő ági fejlesztés során. A csapatnak mindenképpen össze kell fésülnie a fő ág változásait a saját águkkal, és a fordításnak és minden tesztnek sikeresnek kell lennie. A fő ággal való egyesítés könnyebb lesz, mint általában, mert a már sikeresen hozzáadott funkciók lesznek benne, nem a fejlesztés alatt állók. Azután a csapat változásai a fő ágba fésülődnek, ami elindít egy fordítási és tesztfolyamatot. Ha az sikeres, akkor a csapat visszaáll az első fázisra, ahol minden fejlesztő külön dolgozik a saját feladatán. Különben pedig a csapat addig dolgozik a fő ágon, amíg az ismét működőképes.
A változások olyan gyorsan történnek, amennyire csak lehetséges, csak akkor állnak meg, amikor probléma van. Ideális esetben a változások olyan gyakran jelennek meg a fő ágon, mintha azon történne a fejlesztés. A különbség az, hogy kevesebb hiba éri el magát a fő ágat fejlesztés alatt. Többlépcsős folyamatos egyesítés segítségével magas fokú integráció történhet párhuzamosan, és eközben az egyesítésből származó problémák kiterjedése lecsökken.[4]
Ajánlott gyakorlat #2 szerkesztés
A többlépcsős folyamatos egyesítés érdekében minden csapatnak saját ággal kell rendelkeznie, amibe a változások kerülnek.
Előnyök szerkesztés
A többlépcsős folyamatos egyesítésnek számos előnye van:
- Amikor egy egységteszt nem sikeres, vagy felfedezésre kerül egy bug, a fejlesztők visszaállíthatják a kódot egy bug mentes állapotra anélkül, hogy debuggolásra pazarolnák az időt.
- Egyesítési problémák azonnal felismerődnek és folyamatosan kijavítódnak.
- Korai figyelmeztetés a nem működő/nem kompatibilis kódról.
- Korai figyelmeztetés a nem kompatibilis változásokról.
- Azonnali egységtesztelés.
- Egy "frissen" fordított program mindig kéznél van tesztelésre, bemutatásra vagy kiadásra.
- Befejezetlen vagy nem működő kód hatása miatt a fejlesztők ösztönözve vannak arra, hogy fokozatosabban dolgozzanak rövidebb visszajelzési időközökkel.
Eszközök szerkesztés
Eszközök, amelyek segítik a többlépcsős folyamatos egyesítést:
- AccuRev[5] - Verzió kezelő és ALM eszköz
- Electric Cloud[5] — Fordító, tesztelő és telepítő keretrendszer
- AnthillPro - fordító, függőség- és kiadáskezelő eszköz
- Rational Team Concert[6] ALM-Platform
- Platform.sh[7] automatikusan létrehozza fejlesztői környezetet minden git ághoz, így minden ág egymástól függetlenül tesztelhető lesz
- Shippable[8] DevOps és folyamatos egyesítés automatizálás.
Kapcsolódó szócikkek szerkesztés
Források szerkesztés
- ↑ http://www.ddj.com/development-tools/212201506 Multi-Stage Continuous Integration accessdate 2009-02-25, Poole, Damon, 2008-12-02 Dr. Dobb's, Published by TechWeb
- ↑ http://damonpoole.blogspot.com/2008/01/advanced-multi-stage-continous.html Advanced Multi-Stage Integration, accessdate 2009-03-19, Poole, Damon, 2009-01-17 Agile Development Thoughts
- ↑ http://nvie.com/posts/a-successful-git-branching-model/
- ↑ http://www.cmcrossroads.com/content/view/12685/135/[halott link] Large Scale Continuous Integration, Poole, Damon, 2009-01-19 CMCrossroads Published by CMC Media
- ↑ a b http://www.accurev.com/press-releases/030408-accurev-electriccloud.html Archiválva 2008. július 20-i dátummal a Wayback Machine-ben. AccuRev and Electric Cloud Partner to Advance Multistage Continuous Integration and Scalable Agile Best Practices, accessdate 2009-03-19
- ↑ http://jazz.net/
- ↑ https://platform.sh/
- ↑ Chitnis, Ambarish. „Configuring Multi-Stage CI”. [2020. június 25-i dátummal az eredetiből archiválva] (Hozzáférés: 2020. június 22.) (amerikai angol nyelvű)
Fordítás szerkesztés
Ez a szócikk részben vagy egészben a Multi-stage 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.