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

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

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.

Az adattár hatókörrel rendelkező Git-ágakkal ellentétben a TFVC-ágak elérési útja hatóköre nem olyan egyszerű. Állítsa be a sávot az ágak magas és csak ág létrehozására, ha kódra vagy kiadási elkülönítésre van szüksége.

Csak fő

A csak fő stratégia lehet mappaalapú, vagy a főmappaágrá alakítva, hogy további láthatósági funkciókat biztosíthasson. 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éket tartalmazó előzmény nem módosítható és nem módosítható.

Kezdje a fő elágaztatási stratégiával, bontsa ki stratégiailag, és fogadjon el 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 fordított integrálás (RI) a főre változik. Tartsa fenn ugyanazt a minőségi sávot az ágak között. Build-ellenőrzési teszteket (BVT-ket) készíthet és futtathat a deven ugyanúgy, mint a főként.

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óágelágaztatását a fő, az ábrán vagy a fejlesztői ágakból.

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

Megtarthatja a funkciómunkák élettartamát és a kapcsolódó funkcióág rövid élettartamú élettartamát. Az integrálási (FI) változások gyakran változnak a szülőágból. 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ási elkülönítés

A kiadási elkülönítés egy vagy több kiadási ágat vezet be a főverzióbó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 zárolásra, ideje létrehozni egy új á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 gyakori javítások visszafelé integrálhatók (RI) a fő ágba.

MEGJEGYZÉS: Az elágaztatási forgatókönyvek egyike sem módosítható, ezért észleli a kiadási ágakon végrehajtott vészhelyzeti gyorsjavításokat. 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 kiadás 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óla 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 érdemes az ágakat rövid élettartamúnak lenniük?

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

Miért csak elágazás, 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ók a kódbázisok 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-előléptetési 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őre egyesítését: a részletekért nem történt módosítás az egyesítéshez .

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

A TFVC szolgáltatáselkülönítési elágaztatási stratégiája 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ázata Önt terheli.

A jelen dokumentum egyetlen Microsoft-termékben foglalt szellemi termékkel kapcsolatban sem biztosít Önnek jogokat. A dokumentumot belső segédanyag céljára lemásolhatja és felhasználhatja.