Git-elágaztatási stratégia bevezetése

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

A Githez hasonló elosztott verziókövetési rendszerek rugalmasságot biztosítanak a kódmegosztáshoz és -kezeléshez használt verziókövetésben. A csapatnak egyensúlyt kell találnia a rugalmasság és az együttműködés és a kód egységes megosztása között.

A csapattagok a másokkal megosztott Git-ágakon keresztül teszik közzé, osztják meg, tekintik át és iterálják a kódmódosításokat. Elágaztatási stratégia bevezetése a csapat számára. Jobban együttműködhet, és kevesebb időt tölthet a verziókövetés kezelésével és a kód fejlesztésével.

Az alábbi elágaztatási stratégiák a Git microsoftos használatának módján alapulnak. További információ: Hogyan használjuk a Gitet a Microsoftnál.

Az ágstratégia egyszerű megőrzése

Az ágstratégiának egyszerűnek kell maradnia. A stratégiát az alábbi három fogalom alapján hozhatja létre:

• Használjon szolgáltatáságakat az összes új funkcióhoz és hibajavításhoz.
• A szolgáltatáságak egyesítése a fő ágba lekéréses kérelmek használatával.
• Kiváló minőségű, naprakész főág megtartása.

Egy olyan stratégia, amely kiterjeszti ezeket a fogalmakat, és elkerüli az ellentmondásokat, egy olyan verziókövetési munkafolyamatot eredményez a csapat számára, amely egységes és könnyen követhető.

Funkcióágak használata a munkájához

A főág alapján fejlesztheti a funkciókat, és kijavíthatja a funkcióágak hibáit. Ezeket az ágakat témakörágaknak is nevezik. A funkcióágak elkülönítik a folyamatban lévő munkát a főág befejezett munkáitól. A Git-ágak létrehozása és karbantartása olcsó. Még a kisebb javításoknak és módosításoknak is rendelkezniük kell saját funkcióágukkal.

A funkcióágak létrehozása az összes módosításhoz egyszerűvé teszi az előzmények áttekintését. Tekintse meg az ágban végrehajtott véglegesítéseket, és tekintse meg a lekéréses kérelmet, amely egyesítette az ágat.

Szolgáltatáságak elnevezése konvenció szerint

A szolgáltatáságak egységes elnevezési konvencióval azonosíthatják az ágon végzett munkát. Az ág nevében egyéb információkat is megadhat, például azt, hogy ki hozta létre az ágat.

Néhány javaslat a funkcióágak elnevezésére:

• felhasználók/felhasználónév/leírás
• users/username/workitem
• hibajavítás/leírás
• feature/feature-name
• feature/feature-area/feature-name
• gyorsjavítás/leírás

Feljegyzés

Az ágelnevezési stratégia kikényszerítésére szolgáló házirendek beállításával kapcsolatos információkért lásd: Ágmappák megkövetelése.

Funkciójelzők használata a hosszú ideig futó ágak kezeléséhez

További információ a funkciójelzők kódban való használatáról.

Kód áttekintése és egyesítése lekéréses kérelmekkel

A lekéréses kérelmekben végzett felülvizsgálat kritikus fontosságú a kódminőség javítása szempontjából. Csak a felülvizsgálati folyamatot átadó lekéréses kérelmekkel egyesítse az ágakat. Ne egyesítsen ágakat a fő ághoz lekéréses kérelem nélkül.

A lekéréses kérelmek áttekintése több időt vesz igénybe. A csapatnak meg kell egyeznie a lekéréses kérelmek létrehozóitól és véleményezőitől elvárt elvárásokról. A véleményezők feladatainak elosztása az ötletek csapaton belüli megosztásához és a kódbázis ismeretének terjesztéséhez.

Néhány javaslat a sikeres lekéréses kérelmekre:

• Két véleményező optimális szám a kutatás alapján.
• Ha a csapat már rendelkezik kód-felülvizsgálati folyamattal, kérje le a lekéréses kérelmeket a már végzett művelethez.
• Ügyeljen arra, hogy ugyanazokat a véleményezőket nagy számú lekéréses kérelemhez rendelje. A lekéréses kérelmek akkor működnek jobban, ha a véleményezői feladatok meg vannak osztva a csapatban.
• Adjon meg elég részletet a leírásban, hogy gyorsan feljavasíthassa a véleményezőket a módosítások gyors elvégzéséhez.
• A lekéréses kérelemhez mellékelje a módosítások egy szakaszos környezetben futó build- vagy csatolt verzióját. Mások egyszerűen tesztelhetik a módosításokat.

Kiváló minőségű, naprakész főág megtartása

A főágban lévő kódnak teszteket kell átadnia, tisztán kell felépítenie, és mindig naprakésznek kell lennie. A főágnak szüksége van ezekre a tulajdonságokra, hogy a csapat által létrehozott szolgáltatáságak a kód ismert, jó verziójából indulnak ki.

Állítson be egy olyan ágházirendet a főághoz, amely:

• A kód egyesítéséhez lekéréses kérelem szükséges. Ez a megközelítés megakadályozza a fő ágba történő közvetlen leküldéseket, és biztosítja a javasolt módosítások megvitatását.
• A lekéréses kérelem létrehozásakor automatikusan hozzáadja a véleményezőket. A hozzáadott csapattagok áttekintik a kódot, és megjegyzést fűznek a lekéréses kérelem változásaihoz.
• A lekéréses kérelem végrehajtásához sikeres build szükséges. A főágba egyesített kódnak tisztán kell épülnie.

Tipp.

A lekéréses kérelmek buildelési folyamatának gyorsnak kell lennie, hogy ne zavarja a felülvizsgálati folyamatot.

Kiadások kezelése

A kiadási ágak használatával koordinálhatja és stabilizálhatja a kód kiadásának változásait. Ez az ág hosszú élettartamú, és a szolgáltatáságakkal ellentétben nem egyesül vissza a fő ágba egy lekéréses kérelemben. Hozzon létre annyi kiadási ágat, amennyit csak szeretne. Ne feledje, hogy minden aktív kiadási ág a támogatni kívánt kód egy másik verzióját jelöli. Zárolja a kiadási ágakat, ha készen áll egy adott kiadás támogatásának leállítására.

Kiadási ágak használata

Hozzon létre egy kiadási ágat a főágból, amikor közel kerül a kiadáshoz vagy más mérföldkőhöz, például egy futam végéhez. Adjon egyértelmű nevet ennek az ágnak, amely társítja azt a kiadással, például release/20.

Hozzon létre ágakat a kiadási ág hibáinak kijavításához, és egyesítse őket vissza a kiadási ágba egy lekéréses kérelemben.

Portváltozások vissza a főágra

Győződjön meg arról, hogy a kiadási ágban és a fő ágban is kijavítja a földet. Az egyik módszer, hogy javításokat hajt végre a kiadási ágban, majd módosításokat hajt végre a fő ágban a kód regressziójának megakadályozása érdekében. Egy másik megközelítés (és az Azure DevOps csapata által alkalmazott módszer) az, hogy mindig módosításokat hajt végre a fővonalon, majd azokat a kiadási ágba portozza. A kiadási folyamat stratégiájáról bővebben is olvashat.

Ebben a témakörben a kiadási ág módosításait és a fővonalba való átvitelüket fogjuk tárgyalni. Egyesítés helyett használjon cseresznyeszedést, hogy pontosan szabályozhassa, hogy a véglegesítések mely véglegesítéseket legyenek visszahordva a fő ágba. A kiadási ág fő ágba való egyesítése olyan kiadásspecifikus módosításokat hozhat, amelyeket nem szeretne a főágban.

Frissítse a fő ágat a kiadási ágban végrehajtott módosítással az alábbi lépésekkel:

1. Hozzon létre egy új szolgáltatáságat a főágon kívül a módosítások portjának létrehozásához.
2. Válassza ki a kiadási ág módosításait az új funkcióágra.
3. A funkcióágat egy második lekéréses kérelemben egyesítse vissza a fő ágba.

Ez a kiadási ág munkafolyamata érintetlenül tartja az alapszintű munkafolyamat alappilléreit: a funkcióágakat, a lekéréses kérelmeket és egy erős fő ágat, amely mindig a kód legújabb verzióját tartalmazza.

Miért nem használ címkéket a kiadásokhoz?

Más elágaztatási munkafolyamatok Git-címkék használatával jelölnek meg egy adott véglegesítést kiadásként. A címkék hasznosak az előzményekben szereplő pontok fontosként való megjelöléséhez. A címkék további lépéseket vezetnek be a munkafolyamatban, amelyek nem szükségesek, ha ágakat használ a kiadásokhoz.

A címkéket a rendszer a véglegesítésektől elkülönítve tartja karban és küldi el. A csapattagok egyszerűen kihagyhatják a véglegesítés címkézését, majd később vissza kell menniük az előzményekbe a címke javításához. A címke leküldésének további lépését is elfelejtheti, így a következő fejlesztő a kód egy régebbi verziójából dolgozik a kiadás támogatásakor.

A kiadási ág stratégiája kiterjeszti az alapszintű szolgáltatáság-munkafolyamatot a kiadások kezelésére. A csapatnak nem kell új verziókövetési folyamatot alkalmaznia, kivéve a cseresznyés-pick portmódosításokat.

Üzemelő példányok kezelése

A kód több központi telepítését ugyanúgy kezelheti, mint a több kiadást. Hozzon létre egy egyértelmű elnevezési konvenciót, például üzembe helyezési/teljesítménytesztelést, és kezelje a környezeti ágakat kiadási ágakként. A csapatnak meg kell egyeznie egy olyan folyamattal, amellyel frissítheti az üzembe helyezési ágakat a főág kódjával. A cherry-pick hibajavítások az üzembe helyezési ágban vissza a fő ágba. Használja ugyanazokat a lépéseket, mint a kiadási ág módosításainak portolása.

Ez alól a javaslat alól kivételt képez, ha folyamatos üzembe helyezési formát használ. A folyamatos üzembe helyezés során az Azure Pipelines használatával előléptetheti a buildeket a főágból az üzembehelyezési célokba.