Migrálás a Gitbe a központi verziókövetésből

A csapat központi verziókövetésből a Gitbe való migrálása nem csupán új parancsok elsajátítását igényli. Az elosztott fejlesztés támogatásához a Git a központi verziókövetési rendszernél eltérő módon tárolja a fájlelőzményeket és az ágadatokat. A Gitbe történő sikeres migrálás központi verziókövetési rendszerből történő tervezéséhez és implementálásához ismerni kell ezeket az alapvető különbségeket.

A Microsoft számos belső csapatot és ügyfelet segített áttelepíteni a központi verziókövetési rendszerekből a Gitbe. Ez a tapasztalat a következő útmutatást hozta létre a következetesen sikeres gyakorlatok alapján.

A sikeres migrálás lépései

A sikeres migráláshoz a csapatoknak a következőnek kell lennie:

  • Értékelje ki az aktuális eszközöket és folyamatokat.
  • Válasszon ki egy Git-elágazási stratégiát.
  • Döntse el, hogy migrálja-e az előzményeket, és hogyan.
  • Az előző verziókövetési rendszer karbantartása.
  • Távolítsa el a bináris fájlokat, végrehajtható fájlokat és eszközöket a forrásvezérlőből.
  • Csoportok betanítása a Git alapelveibe és gyakorlataiba.
  • Tesztelje a Gitbe való migrálást.

Az aktuális eszközök és folyamatok kiértékelése

A verziókövetési rendszerek módosítása természetesen új eszközökkel és eljárásokkal megzavarja a fejlesztési munkafolyamatot. Ez a megszakítás lehetőséget jelenthet a DevOps-folyamat egyéb aspektusainak javítására.

A Teamsnek az új rendszerre való migrálás során érdemes megfontolnia a következő eljárások alkalmazását:

  • Folyamatos integráció (CI), ahol minden bejelentkezés létrehoz egy buildelési és tesztelési bérletet. A CI segít a hibák korai azonosításában, és erős biztonsági hálót biztosít a projektekhez.

  • A kód beadása előtt szükséges kódellenőrzések. A Git-elágaztatási modellben a lekéréses kérelmek kódjának áttekintése a fejlesztési folyamat része. A kódvizsgálatok kiegészítik a CI-munkafolyamatot.

  • Folyamatos teljesítés (CD) az üzembehelyezési folyamatok automatizálásához. A verziókövetési eszközök módosítása az üzembehelyezési folyamat módosításait igényli, ezért a migrálás jó alkalom egy modern kiadási folyamat bevezetésére.

Git-elágaztatási stratégia kiválasztása

A kód migrálása előtt a csapatnak ki kell választania egy elágaztatási stratégiát.

A Gitben a rövid élettartamú témakörágak lehetővé teszik a fejlesztők számára, hogy a fő ág közelében dolgozhassanak, és gyorsan integrálják őket, elkerülve az egyesítési problémákat. Két gyakori témakörág-stratégia a GitFlow és egy egyszerűbb változat, a GitHub Flow.

A Git elriasztja a hosszú élettartamú, izolált funkciók ágait, amelyek általában késleltetik az egyesítéseket, amíg az integráció nehézkessé nem válik. A modern CD-technikák, például a funkciójelzők használatával a csapatok gyorsan integrálhatják a kódot a főágba, de a folyamatban lévő funkciókat továbbra is elrejthetik a felhasználók elől, amíg el nem érik őket.

Azok a csapatok, amelyek jelenleg hosszú élettartamú szolgáltatáság-stratégiát használnak, a Gitbe való migrálás előtt funkciójelzőket alkalmazhatnak. A funkciójelölők használata leegyszerűsíti a migrálást a migrálandó ágak számának minimalizálásával. Függetlenül attól, hogy funkcióágakat vagy funkciójelzőket használnak, a csapatoknak dokumentálniuk kell az örökölt ágak és az új Git-ágak közötti leképezést, hogy mindenki megértse, hol véglegesítse az új munkáját.

Döntse el, hogy migrálja-e az előzményeket

Előfordulhat, hogy a Teams kísértést érez a meglévő forráskódelőzmények Gitbe való migrálására. Több eszköz azt állítja, hogy az összes ág teljes előzményeit migrálja egy központosított eszközből a Gitbe. Úgy tűnik, hogy egy Git-véglegesítés viszonylag jól megfelel az előző verziókövetési eszköz által használt módosítási vagy bejelentkezési modellnek.

Ez a leképezés azonban komoly korlátozásokkal rendelkezik.

  • A legtöbb központosított verziókövetési rendszerben az ágak mappákként léteznek az adattárban. A fő ág lehet például egy /trunk nevű mappa, más ágak pedig olyan mappák, mint az /branch/one és /branch/two. A Git-adattárakban az ágak tartalmazzák a teljes adattárat, így nehéz 1:1-re fordítást létrehozni.

  • Egyes verziókövetési rendszerekben a címkék vagy címkék olyan gyűjtemények, amelyek különböző fájlokat tartalmazhatnak a fában, még a különböző verziókban lévő fájlokat is. A Gitben a címke a teljes adattár pillanatképe egy adott időpontban. A címkék nem jelölhetik az adattár egy részhalmazát, és nem egyesíthetik a fájlokat különböző verziókban.

  • A verziókövetési rendszerek többsége a fájlok verziók közötti változásának részleteit tárolja, beleértve az olyan részletes módosítási típusokat is, mint az átnevezés, a visszavonás és a visszaállítás. A Git a teljes adattár pillanatképeként tárolja a verziókat, és a fájlok módosításának metaadatai nem érhetők el.

Ezek a különbségek azt jelentik, hogy a teljes előzmények migrációja a legjobb esetben veszteséges, és esetleg félrevezető lesz. Tekintettel a veszteségességre, az érintett erőfeszítésekre és a történelem használatának viszonylagos ritkaságára, a legtöbb csapatnak kerülnie kell az előzmények importálását. Ehelyett a csapatoknak tippmigrálást kell végeznie, és csak a legújabb ágverzió pillanatképét kell a Gitbe vinnie. A legtöbb csapat számára az időt érdemes a migrálás olyan területeire fordítani, amelyek nagyobb megtérüléssel rendelkeznek, például a folyamatok fejlesztésére.

A régi verziókövetési rendszer karbantartása

A migrálás során és után előfordulhat, hogy a fejlesztőknek továbbra is hozzá kell férnie az előző verziókövetési előzményekhez. Bár az előző verziókövetési előzmények idővel kevésbé lesznek relevánsak, mégis fontos, hogy hivatkozni lehessen rá. A szigorúan szabályozott környezetek konkrét jogi és naplózási követelményekkel rendelkezhetnek a verziókövetési előzményekhez.

Különösen az olyan csapatok esetében, amelyek csak tippmigrálást végeznek, erősen ajánlott az előző rendszer határozatlan ideig történő fenntartása. Migrálás után állítsa be a régi verziókövetési rendszert írásvédetté.

Nagy fejlesztői csapatok és szabályozott környezetek a Gitben is elhelyezhetnek nyomokat, amelyek a régi verziókövetési rendszerre mutatnak. Egy egyszerű példa egy szövegfájl, amely a Git-adattár gyökerénél első véglegesítésként van hozzáadva a tippmigrálás előtt, amely a régi verziókövetési kiszolgáló URL-címére mutat. Ha sok ág migrál, az egyes ágak szöveges fájljának meg kell magyaráznia, hogyan migráltak az ágak a régi rendszerből. A "breadcrumb" navigációs útmutató azoknak a fejlesztőknek is hasznos, akik a migráció után kezdenek el dolgozni egy projekten, és nem ismerik a régi verziókövető rendszert.

Bináris fájlok és eszközök eltávolítása

A Git tárolási modellje szövegfájlok és forráskódok verziószámozására van optimalizálva, amelyek kompaktak és nagy mértékben tömöríthetőek. A bináris fájlok általában nagyok, és miután hozzáadták őket egy adattárhoz, az adattár előzményeiben és minden későbbi klónban megmaradnak. Mivel a Git tárolja az előzményeket, a fejlesztőknek kerülnie kell bináris fájlok hozzáadását az adattárakhoz, különösen a nagyon nagy vagy gyakran változó bináris fájlokhoz. A Gitbe való migrálással eltávolíthatja ezeket a bináris fájlokat a kódbázisból.

Azt is javasoljuk, hogy könyvtárakat, eszközöket és a kimenetet zárja ki az adattárakból. Ehelyett használja a nuGet-hez hasonló csomagkezelő rendszereket a függőségek kezeléséhez.

Előfordulhat, hogy az olyan objektumoknak, mint az ikonok és az ábrák, igazodniuk kell a forráskód egy adott verziójához. A kis méretű, ritkán módosított objektumok, például az ikonok nem fogják felbomlani az előzményeket, és közvetlenül az adattárakba is belefoglalhatja őket. A nagyméretű vagy gyakran változó objektumok tárolásához használja a Git Large File Storage (LFS) bővítményt. A nagyméretű fájlok GitHubon való kezelésével kapcsolatos további információkért lásd: Nagyméretű fájlok kezelése. Az Azure Repos esetében lásd: Nagyméretű fájlok kezelése és tárolása a Gitben.

Képzés biztosítása

A Gitbe való migrálás egyik legnagyobb kihívása, hogy segít a fejlesztőknek megérteni, hogyan tárolja a Git a változásokat, és hogyan alakítják a commitok a fejlesztési előzményeiket. Nem elég egy olyan csalási lap előkészítése, amely a régi parancsokat Git-parancsokba rendeli. A fejlesztőknek nem kell a verziókövetési előzményekre gondolniuk egy központosított, lineáris modell tekintetében, és ismerniük kell a Git előzménymodelljét és a véglegesítési gráfot.

Az emberek különböző módokon tanulnak, ezért többféle képzési anyagot kell megadnia. Az élő, laboralapú képzés egy szakértő oktatóval jól működik néhány ember számára. A Pro Git könyv kiváló kiindulópont, amely ingyenesen elérhető online.

A rendelkezésre álló ingyenes gyakorlati képzések a következők:

A szervezeteknek azon kell dolgozniuk, hogy azonosítsák a Git-szakértőket a csapatokban, segítsék őket másokon, és arra ösztönözzék a többi csapattagot, hogy tegyenek fel kérdéseket.

A migrálás tesztelése

Miután a csapatok frissítették a folyamataikat, elemezték a kódjukat, és betanították a tagjaikat, ideje migrálni a forráskódot. Akár tippmigrálást végez, akár előzményeket migrál, fontos, hogy egy vagy több tesztelési migrálást hajt végre egy tesztadattárban. A végleges migrálás előtt győződjön meg arról, hogy:

  • Az összes kódfájl áttelepítése.
  • Minden ág elérhető.
  • Az adattárban nincsenek kóbor bináris fájlok.
  • A felhasználók rendelkeznek a beolvasáshoz és leküldéshez szükséges engedélyekkel.
  • A buildek sikeresek, és minden teszt sikeres.

A kód migrálása

Végezze el a végső migrálást munkaszüneti órákban, ideális esetben a mérföldkövek között, amikor természetes állásidő van. A futam végén végzett migrálás problémákat okozhat, miközben a fejlesztők megpróbálják befejezni a munkát. Próbáljon meg áttelepülni egy hétvégére, amikor senkinek sem kell bejelentkeznie.

Tervezze meg, hogy a régi verziókövetési rendszertől a Gitig szilárd átállást tervez. Ha több rendszert próbál párhuzamosan üzemeltetni, előfordulhat, hogy a fejlesztők nem tudják, hol vagy hogyan kell bejelentkezni. A félreértések elkerülése érdekében állítsa a régi verziókövetési rendszert csak olvashatóvá. E védelem nélkül szükség lehet egy második migrálásra, amely köztes módosításokat is tartalmaz.

A tényleges migrálási folyamat attól függően változik, hogy melyik rendszerből migrál. A Team Foundation verziókövetéséből való migrálásról további információt a Migrálás TFVC-ről Gitre című témakörben talál.

Migrálási ellenőrzőlista

Csapat munkafolyamatai:

  • Határozza meg, hogyan fognak futni a buildek.
  • Döntse el, hogy mikor futnak a tesztek.
  • Kiadáskezelési folyamat fejlesztése.
  • Áthelyezze a kódértékeléseket a pull request-ekhez.

Elágaztatási stratégia:

  • Válassza ki a Git elágaztatási stratégiáját.
  • Dokumentálja az elágaztatási stratégiát, a kiválasztás okát és az örökölt ágak leképezését.

History:

  • Döntse el, hogy mennyi ideig futtassa az örökölt verziókövetést.
  • Azonosíthatja a migrálni kívánt ágakat.
  • Szükség esetén hozzon létre egy útmutatót, amely segít a mérnököknek visszatérni az örökölt rendszerhez.

Bináris fájlok és eszközök:

  • Azonosítsa az adattárból eltávolítandó bináris és nem nyilvános fájlokat.
  • Döntsön a nagy méretű fájlok, például a Git-LFS megközelítéséről.
  • Eszközök és könyvtárak, például a NuGet szállításának megközelítése meghatározása.

Képzés:

  • Tananyagok azonosítása.
  • Képzési események, írott anyagok és videók tervezése.
  • Azonosítsa a csapat azon tagjait, amelyek helyi Git-szakértőkként szolgálnak.

Kódmigrálás:

  • A migrálás zökkenőmentességének biztosítása érdekében több tesztfuttatást is elvégezhet.
  • Azonosítsa és közölje az átállási időt.
  • Hozza létre az új Git-adattárat.
  • Állítsa be a régi rendszert írásvédettre.
  • Először migrálja a fő ágat, majd a többi szükséges ágat.

Következő lépések

  • Last updated on