Az ágalapú verzióhoz a következő ábráról kell beszélnünk, amely tökéletesen illusztrálja a konfigurációkezelési folyamat panorámáját. Először is, ez a diagram a Git modell alapján készült, de valójában a Git és a Subversion már kitalálta a verzióvezérlési menedzsment koncepcióját, ugyanakkor a Git minőségileg előrelép a Subversionhoz képest az ágazatkezelésben és az elosztott teljesítményben (de ez nem a cikk fő témája).
Mielőtt bemutatnánk ennek a grafikonnak az elvét, beszéljünk két különböző általános verziókezelési stratégiáról: az egyik a "pioneer gerince, stabil ág", a másik pedig "stabil gerinc, pioneer ág". Ahogy a neve is mutatja, ez a stabil verzió (gyártási verzió), amely a törzsön vagy az ágon található. A hagyományos VSS-t használó projektcsapatok esetében nehéz megmondani, melyik módhoz tartozik, főleg azért, mert a VSS-nek nincs fiókmenedzsment stratégiája, ezért sok projektcsapat két (vagy három) verziós könyvtárat hoz létre, amelyek megfelelnek a gyártási és fejlesztési környezetnek, természetesen ez egyfajta álcázott fiókmenedzsment. Ha viszont átváltasz a Subversion-ra vagy a Git-re verzióvezérlő eszközként, a legtöbb csapat a stabil trunk módot használja, vagyis a csomagtartó (teherautó vagy master) egy stabil gyártási környezethez kapcsolódik, és különböző kiadásokat jelöl meg, hogy jelezze a gyártási verziót. Személy szerint úgy gondolom, hogy a stabil gerincalapú kódmintának kellene lennie jelenleg a legabszolút mainstream kódverziókezelő megoldásnak. A fenti kép a szabványos "stabil gerinc" menedzsment modell.
mester: A megfelelő Subversion a truck。 A gyártási verzióhoz hasonlóan minden kiadásban egyszer megjelölik.
Release ág (más néven integrációs ág): Amíg a termelés frissül, először be kell olvasztani a release branch-be (integrációs ág). Ez valamennyire hasonlít ahhoz, amit a projektcsapat jelenleg a "előgyártás" és a "szimulált környezet" fogalmának nevez.
Develop Branch (dev branch vagy dev branch): A fejlesztési környezet által szembesülő környezet.
Feature ág (feature ág): Néhány független függvény külön fejlesztési ágból is elkülöníthető. Ez főként azért van, hogy kezeljék a bizonyos funkciók frissítése viszonylag sokáig, hogy ne húzzák le a megjelenést és az elkülönült ágak.
Hotfixes Branch (hibajavítás ág): A hiba itt főként gyártási hiba.
Miután bemutattam a törzset és az ágak, be kell mutatnom ezeknek az ágaknak a generálódásának és összeolvadásának irányát.
A master a gyártási verzió, és a trunk csak két ágat fogad el az összevonáshoz: az egyik a release ág (integrációs ág), a másik pedig a hotfixes ág. Egyetlen más ág sem lehet bevonni termelési ágba.
A kiadási ág kezdetben a gyártással egyidejűleg készül, ami pontosan ugyanaz, mint a gyártás. Csak a fejlesztői ágat fogadja el, hogy beolvadjon vele. Más szóval, nem fogadja el a közvetlenül a funkcióágból vagy a hibajavítások ágából való összeolvadást.
A fejlesztői ág, a fejlesztő ág, akárcsak az integrációs ág, ugyanaz, mint a termelési környezet egy adott időpontban. Azonban a fejlesztés előrehaladtával új funkciók is folyamatosan létrejönnek a fejlesztői ágon. A fejlesztőelmélet csak két ág összevonását fogadja el, az egyik hotfixek, a másik pedig a funkcióág.
Feature ág, egy adott ponttól (verziótól) kezdve a fejlesztő ággal, a feature ág végül egyesül a fejlesztő ággal.
Mutassuk be röviden a verziókezelési módszert egy forgatókönyv formájában
Tegyük fel, hogy egy gyártási verziót ábra osztanak (dev, hotfixes, release), és ekkor a dev összesen tíz funkciót fejleszt. Amikor a 10 funkcióból 8-at kifejlesztettek, a tesztcsapat beavatkozni kezdett a belső tesztelés érdekében, és a konfigurációs adminisztrátor telepítette a fejlesztői ágat a fejlesztői környezetbe tesztelésre folyamatos integrációs eszközökön keresztül (egy külön téma itt). Amikor a tesztellenőrzés megállapította, hogy két funkció teljesen elfogadhatatlan és újraelhelyezésre van szükség, például a egyszerű biztosítási biztosítás és a kártérítés, két funkcióágat választottak el a fejlesztőtől, amelyek az egyszerű biztosítási biztosításnak és a kártérítésnek felelnek meg, és a fejlesztő ágon a megfelelő kódot is vissza kellett fordítani (manuális kezelés itt). Amikor a tesztcsapat megállapítja, hogy nincs probléma a fejlesztői ági teszttel, az megfelel az UAT feltételeinek, ezért a konfigurációs adminisztrátor összeolvasza a fejlesztő ágat a release branch-szel, majd folyamatos integrációs eszközökkel publikálja ezt az ágot az előkészítő környezetbe, és átadja a felhasználónak tesztelésre. Amikor a felhasználói ellenőrzés problémát talál, a fejlesztő módosítja a fejlesztői ágat, majd beolvasztja a release ágba (itt, az eredeti képen közvetlenül a release ágban van módosítva, szerintem ez nem jó, azt javaslom, hogy a fejlesztő csak a fejlesztői ággal nézzen szembe), amikor a vering-kiadás ellenőrzési folyamat hirtelen rájön, hogy komoly hiba van a build környezetben, amit azonnal ki kell javítani, akkor sürgősen módosítják a hotfixes ágon, és sürgősen elindítják, miután ellenőrizték a helyességét. Ugyanakkor a hotfixes ág összeolvasztódik a dev-szel (itt főként manuális, mert ekkor a gyártási verzió már nagyon eltér a fejlesztő verziótól, és gyakran lehetetlen az automatikus összeolvást befejezni), majd a fejlesztő beolvasztva a kiadásba. Egy idő után a igényvisszaküldési funkció már nem lesz szükséges, és törölni kell, így a igényvisszaküldési funkció ága törlődik. Egy másik funkció könnyen biztosítható, és újra fejlesztették és összeolvasztották a fejlesztői ággal, hogy a következő online verzióval is elérhetővé váljon.
A fenti forgatókönyv lényegében magában foglalja a rutinszerű fejlesztést, kicsomagolást, vészhelyzeti frissítéseket és egyéb forgatókönyveket a napi fejlesztési folyamatban.
|
Közzétéve 2018. 04. 08. 10:25:39
|
|
|
|
