Hatékony elágaztatási stratégia kiválasztása

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

A kockázat elkülönítéséhez hasznos, ha ágakat hoz létre a Team Foundation Version Control (TFVC) adattáraihoz. Fontolja meg, hogy a csapattagok általában milyen kihívásokkal szembesülnek, ha egy olyan szoftverprojekten dolgoznak, amelyet több mint öt vagy tíz személy alkalmaz:

• A csoport néhány (vagy talán több) különböző funkciócsoportot tartalmaz, amelyek mindegyike ésszerűen különálló funkciókon dolgozik. Az egyes csapatok azonban a más csapatok által létrehozott funkcióktól is függnek. El kell különítenie az egyes csapatokban végzett munka által bevezetett változások kockázatát, és végül minden erőfeszítést egyetlen termékbe kell egyesítenie.

• A tesztcsapatnak a kód stabil verziójára van szüksége a teszteléshez, és ugyanakkor a fejlesztőknek tovább kell haladnia az új funkciókkal, amelyek időnként destabilizálják a terméket.

• A szoftver két korábbi verzióval és egy aktuális verzióval rendelkezik. Annak ellenére, hogy a legtöbb fejlesztési erőfeszítést az aktuális verzióba fektetik, az előző verziókat továbbra is támogatni kell a szervizcsomagok, a kritikus javítások és a biztonsági javítások, valamint egyéb módosítások időnkénti kiadásával.

Ez a cikk néhány gyakori elágaztatási stratégiát mutat be, amelyek segítenek a helyes döntés meghozatalában.

A git ágak adattár szintű hatókörével ellentétben a TFVC ágak elérési útspecifikusak és nem olyan könnyűek. Állítson magas mércét az ágak létrehozására, és csak akkor hozzon létre ágat, ha kód vagy kiadás elkülönítésére van szükség.

Csak fő

A Kizárólag Fő stratégia lehet mappaalapú, vagy a fő mappa elágazássá átalakítva, hogy további láthatósági funkciókat tegyen lehetővé. Véglegesíti a módosításokat a főágban, és opcionálisan címkékkel jelzi a fejlesztési és kiadási mérföldköveket.

KOCKÁZAT: A TFVC-címkék változtathatósága és a történelem hiánya növelheti a változáskezelés kockázatát.

Kezdje a fő elágazó stratégiával, ágazzon stratégiailag, és alkalmazzon más stratégiákat, hogy szükség szerint összetettebb stratégiákká fejlődjenek.

Fejlesztés elkülönítése

Ha stabil főágat kell fenntartania és védenie, elágaztathat egy vagy több fejlesztői ágat a főágból. Lehetővé teszi az elkülönítést és az egyidejű fejlesztést. A munka elkülöníthető a fejlesztési ágakban funkció, szervezet vagy ideiglenes együttműködés alapján.

Lehetséges, hogy a főágban változások történtek. Mindig továbbítsa a fő integrálást (FI) a fejlesztői ágra, és oldja fel az egyesítési ütközéseket. Ezután a változtatásokat fordított integrálással (RI) juttassa vissza a main-be. Tartsa fenn ugyanazt a minőségi sávot az ágak között. Build-ellenőrzési teszteket (BVT-ket) futtathat a dev ágon ugyanúgy, mint a main ágon.

MEGJEGYZÉS: Ezzel a stratégiával a csapatok valószínűleg örökre megőrzik a fejlesztői ágat, ami nagy egyesítési jegyelőzményeket hozhat létre.

Funkcióelkülönítés

A funkcióelkülönítés a fejlesztési elkülönítés speciális származtatása, amely lehetővé teszi egy vagy több funkcióág elágaztatását a fő vagy a fejlesztő ágakból.

Ha egy adott szolgáltatáson kell dolgoznia, érdemes lehet létrehozni egy szolgáltatáságat.

Tartsa röviden a funkciómunkák és a kapcsolódó funkcióág élettartamát. Gyakran integrálja a szülőág változásait előrefelé (FI). A fordított integrálás (RI) csak akkor kerül vissza a szülőhöz, ha teljesül néhány elfogadott csapatfeltétel, például a kész definíciója. A fő funkciók visszaállítása költséges lehet, és alaphelyzetbe állíthatja a tesztelést.

Kiadás elkülönítése

A kiadási izoláció egy vagy több kiadási ágat vezet be a mainből. A stratégia lehetővé teszi az egyidejű kiadáskezelést, a több és párhuzamos kiadásokat, valamint a kódbázis pillanatképeit a kiadás időpontjában.

Ha a kiadás készen áll a véglegesítésre, ideje létrehozni egy új fejlesztési ágat a kiadáshoz.

Soha ne továbbítsa az integrálást (FI) a főről. A kiadási ágak zárolása hozzáférési engedélyekkel a kiadás nem szándékos módosításának megakadályozása érdekében. A kiadási ágon elvégzett javítások és gyorsjavítások visszaintegrálhatók (RI) a fő ágba.

MEGJEGYZÉS: Az elágaztatási forgatókönyvek egyike sem változtathatatlan, ezért tapasztalja, hogy vészhelyzeti gyorsjavításokat hajtanak végre a kiadási ágakon. Alakítsa ki az egyes stratégiákat a követelményeknek megfelelően anélkül, hogy szem elől tévesztené az összetettséget és a kapcsolódó költségeket.

Karbantartás és verzió elkülönítése

A karbantartási és kiadási elkülönítési stratégia karbantartási ágakat vezet be. Ez a stratégia lehetővé teszi a szervizcsomagok és a kódbázis pillanatképeinek egyidejű kezelését a kiadás időpontjában.

Ezt a stratégiát akkor használja, ha karbantartási modellre van szüksége az ügyfeleknek a következő fő kiadásra való frissítéshez, és kiadásonként további szervizcsomagokra.

A kiadási elkülönítéshez hasonlóan a karbantartási elkülönítés és a kiadási ágak akkor jönnek létre, amikor a kiadás készen áll a zárolásra. Soha ne továbbítsa az integrációt a főről a karbantartásra vagy a karbantartásról a kiadásra. A módosítások elkerülése érdekében zárolja a kiadási ágat. A jövőbeni karbantartási módosítások a karbantartási ágon is elvégezhetők .

Hozzon létre új karbantartási és kiadási ágakat a későbbi kiadásokhoz, ha ezt az elkülönítési szintet igényli.

Karbantartás, gyorsjavítás, kiadási elkülönítés

Bár nem ajánlott, továbbra is fejlesztheti a stratégiákat további gyorsjavítási ágak és a kapcsolódó kiadási forgatókönyvek bevezetésével.

Ezen a ponton sikeresen megvizsgált néhány gyakori TFVC-elágazási forgatókönyvet. Fejlesztheti őket, vagy megvizsgálhat más stratégiákat, például a funkciók összesítését, a funkciók be- és kikapcsolását annak megállapításához, hogy egy szolgáltatás futásidőben elérhető-e.

Q&A

Miért legyenek rövid életűek az ágak?

Az ágak rövid élettartamú megtartásával az egyesítési ütközések a lehető legkevesebbre kerülnek.

Miért csak akkor ágazni el, ha szükséges?

A DevOps használatához a build, a tesztelés és az üzembe helyezés automatizálására kell támaszkodnia. A változás folyamatos, gyakori és egyesítési műveletek esetén nagyobb kihívást jelent, mivel az egyesítési ütközések gyakran manuális beavatkozást igényelnek. Ezért javasoljuk, hogy kerülje az elágazást, és támaszkodjon más stratégiákra, például a funkciók összevonására.

Miért érdemes eltávolítani az ágakat?

A hosszú távú egyesítési következmények csökkentése érdekében a cél az, hogy a módosítások a lehető leghamarabb vissza legyenek helyezve a főbe . Az ideiglenes, nem használt és bőséges ágak zavart és többletterhelést okoznak a csapat számára.

Elágaztatható egy kódbázis a projektek között?

Igen. Ez nem ajánlott, kivéve, ha a csapatoknak meg kell osztaniuk a forrást, és nem oszthatnak meg közös folyamatot.

Mi a helyzet a kód promóciós stratégiával?

A Code Promotion stratégia a vízesés fejlesztési korszakának ereklyéinek tűnik. Általában hosszú tesztelési ciklusokkal, valamint külön fejlesztői és tesztelési csapatokkal. A stratégia már nem ajánlott. A stratégiával kapcsolatos további információkért tekintse meg az elágaztatási útmutatót.

A dev és a fő ág egyesítésekor miért nem észlelhető változás?

Valószínűleg figyelmen kívül hagyta a korábbi egyesítések módosításait, például az keep source ütközésfeloldási beállítás használatával. Tekintse meg a fejlesztési ág fő ágba való egyesítése részleteit: nem történtek módosítások az egyesítés során.

Vannak hasonlóságok a TFVC és a Git ágstratégiák között?

A TFVC elágaztatási stratégiája, amely a szolgáltatáselkülönítést célozza, hasonló a Git-témakörágakhoz.

Szerzők: Jesse Houwing, Marcus Fernandez, Mike Fourie, és Willy Schaub az ALM | DevOps Rangers. Itt felveheti velük a kapcsolatot.

(c) 2015 Microsoft Corporation. Minden jog fenntartva. Ezt a dokumentumot a rendszer az "is"-ként adja meg. A dokumentumban kifejezett információk és nézetek, beleértve az URL-címet és más internetes webhelyhivatkozásokat, értesítés nélkül változhatnak. A használat kockázatát Ön viseli.

Ez a dokumentum nem biztosít önnek semmilyen jogi jogot semmilyen Microsoft-termékben lévő szellemi tulajdonhoz. Ezt a dokumentumot saját belső, referencia céljaira másolhatja és használhatja.