Az áttelepítés áttekintése
Az Azure DevOps Serverről az Azure DevOps Servicesre való áttérés alapvető lépés azon szervezetek számára, amelyek szeretnék kihasználni a felhőalapú együttműködés, a méretezhetőség és a továbbfejlesztett funkciók előnyeit. Ebben az áttekintésben áttekintjük az értékes adatok helyszíni Azure DevOps Serverről a felhőalapú Azure DevOps Servicesbe való átvitelének lehetőségeit.
A helyszíni Azure DevOps Server és a felhőalapú Azure DevOps Services közötti fő különbségekről az Azure DevOps Services és az Azure DevOps Server összehasonlítása című témakörben olvashat.
A kiválasztott áttelepítési lehetőségtől függetlenül javasoljuk, hogy határozza meg a legfontosabb objektumokat, például a forráskódot és a munkaelemeket. Gondoljon az adatok méretére, a szervezet összetettségére, és győződjön meg arról, hogy a tényleges migrálás előtt elegendő ideje van a tesztelési futtatásokra a zökkenőmentes és sikeres átállás érdekében.
A migrálás megközelítései
Az Azure DevOps Services bevezetésének konkrét motivációi alapján elengedhetetlen, hogy felmérje a migrálás egyes megközelítéseinek előnyeit és hátrányait. A megfelelő stratégia az egyedi környezettől és követelményektől függ.
| Beállítások | Ajánlott forgatókönyvek | Korlátozások |
|---|---|---|
| 1: Manuális migrálás | Kisebb projektekhez vagy adott adathalmazokhoz használható. | Nem minden adat migrálható teljes hűséggel, és szabályozásra van szükség. Ez az áttelepítés nem támogatja az XML-sablonok migrálását, ezért a folyamatsablonokat örökölt sablonként kell újra létrehoznia. |
| 2: Az Azure DevOps adatmigrálási eszköze | Közepes és nagy léptékű migrálásokhoz használható változatos adattípusokkal és összetett struktúrákkal. | Csak egy Azure DevOps Server-gyűjteményt "emelhet át" egy új Azure DevOps Services-szervezetbe módosítás nélkül. További információkért lásd a Korlátozások szakaszt. |
| 3: API-alapú migrálás | Rugalmasságot és testreszabást biztosít az egyedi migrálási követelményekkel vagy automatizálási igényekkel rendelkező szervezetek számára. | Alacsony megbízhatósági, adatvesztési és azonosítóváltozások fordulhatnak elő. További információkért lásd a Korlátozások szakaszt. |
1. lehetőség: Manuális migrálás
Amikor például a Microsoft Azure DevOps csapata úgy döntött, hogy az Azure DevOps Serverről az Azure DevOps Servicesre vált, úgy döntöttünk, hogy a Team Foundation verziókövetésről (TFVC) a Gitre váltunk. A migrálás sok tervezést igényelt, de migráláskor létrehoztunk egy új Git-adattárat a TFVC-forrásaink "tipp" verziójával, és hátrahagytuk az előzményeket az Azure DevOps Serverben. Az aktív munkaelemeket is áthelyeztük, és hátrahagytuk az összes régi hibát, befejezett felhasználói történeteket és feladatokat stb.
Manuális migrálási folyamat
- Azonosítsa a migráláshoz szükséges legfontosabb eszközöket – általában a forráskódot, a munkaelemeket vagy mindkettőt. Az Azure DevOps Server egyéb eszközeit – a folyamatokat, a tesztelési terveket és így tovább – nehezebb manuálisan migrálni.
- Azonosítsa az áttűnés megfelelő időpontját.
- A célszervezetek előkészítése. Hozza létre a szükséges szervezeteket és csapatprojekteket, hozzon létre felhasználókat stb.
- Az adatok migrálása.
- Fontolja meg a forrás Azure DevOps Server üzembe helyezésének írásvédettvé tételét. Ezt a következő módokon teheti meg:
- Projektszintű engedélyek módosítása: Állítsa be az összes felhasználó vagy csoport engedélyeit írásvédettre a projekt szintjén, amelyet a Projekt beállításaiban lévő biztonsági szerepkörök módosításával tehet meg.
- Az adattár beállításainak módosítása: Az egyes adattárakban módosíthatja a beállításokat, hogy írásvédetté tegyék őket, ami magában foglalja az egyes felhasználók vagy csoportok engedélyeinek módosítását, hogy csak olvasási műveleteket engedélyezzenek.
- Beépített biztonsági csoportok használata: A beépített biztonsági csoportok használatával hatékonyabban kezelheti az engedélyeket. A felhasználókat olyan csoportokhoz rendelheti, mint az "Olvasók", hogy csak olvasási hozzáférést biztosítsanak.
- Szkriptelési engedélymódosítások: Ha sok projekttel vagy adattárral rendelkezik, előfordulhat, hogy szkripttel kell rendelkeznie. Az Azure CLI DevOps-bővítményével listázhatja az összes engedélyt, és szükség szerint frissítheti őket.
- Az adattár letiltása funkció: Letiltja az adattárhoz való hozzáférést, beleértve a buildeket és a lekéréses kérelmeket, de figyelmeztetéssel tartja felderíthetőnek az adattárat. Nyissa meg az adattárat a Project-beállítások>tárházai> között, és a Tárház letiltása mellett váltson be állásba.
2. lehetőség: Azure DevOps Migration Tool
Az Azure DevOps Adatmigrálási eszköz a Microsoft által biztosított segédprogramok készlete, amelyek megkönnyítik az adatok Azure DevOps Serverről Az Azure DevOps Services szolgáltatásba való migrálását. Ezek az eszközök leegyszerűsített megközelítést kínálnak a különböző összetevők, például a forráskód, a munkaelemek, a tesztelési esetek és más projekthez kapcsolódó adatok migrálásához.
A migrálási folyamat megkezdése előtt az eszközök elvégezhetnek egy premigrációs elemzést a forráskörnyezet felkészültségének felméréséhez, és azonosíthatják a migrálást esetlegesen érintő problémákat vagy függőségeket. Mérje fel a felkészültséget, hogy előre megtervezhesse és elháríthassa a lehetséges kihívásokat.
A migrálási eszköz korlátozásai
Az eszköz lehetővé teszi, hogy egy Azure DevOps Server-gyűjteményt egy új Azure DevOps Service-szervezetbe "emeljen fel és váltson át" az alábbi okok miatt:
- Adatintegritás és konzisztencia:
- Az adatok migrálása során elengedhetetlen az integritás és a konzisztencia fenntartása. A migrálás során végzett módosítások engedélyezése adatsérüléshez vagy következetlenséghez vezethet.
- Az eszköz biztosítja, hogy az adatok érintetlenek maradnak az átviteli folyamat során, minimalizálva a hibák kockázatát.
- Forrásadatok megőrzése:
- A migrálási eszköz célja a forrásadatok hű replikálása a célkörnyezetben.
- A módosítások megváltoztathatják az eredeti adatokat, ami eltéréseket okozhat a migrált adatok és a forrásadatok között.
- Kiszámítható viselkedés:
- A módosítások korlátozásával az eszköz kiszámítható viselkedést biztosít a migrálás során.
- A felhasználók konzisztens eredményekre támaszkodhatnak váratlan módosítások nélkül.
- Migrálási fókusz, nem átalakítás:
- Az áttelepítési eszköz elsődleges célja az adatok áthelyezése egyik helyről a másikra.
- Az adatátalakítást (például az értékek módosítását) általában a migrálás után külön kezelik.
Törölheti azokat az adatokat, amelyekre nincs szüksége az áttelepítés előtt vagy után.
Migrálási eszköz folyamata
- Az előfeltételek teljesítése, például az Azure DevOps Server frissítése a két legújabb kiadás egyikére.
- Ellenőrizze az Azure DevOps Servicesbe áthelyezni kívánt gyűjteményeket.
- Migrálási fájlok létrehozása.
- Készítsen elő mindent a migrálás végrehajtásához.
- Végezzen tesztfuttatást.
- Migrálás végrehajtása.
- Győződjön meg arról, hogy a felhasználók és az adatok át lettek migrálva, és a gyűjtemény a várt módon működik.
3. lehetőség: API-alapú migrálás
Ha valamilyen oknál fogva nem tudja használni az adatmigrálási eszközt, de a 2. lehetőségnél magasabb megbízhatósági migrálást szeretne, akkor számos olyan eszköz közül választhat, amelyek nyilvános API-kat használnak az adatok áthelyezéséhez.
API-alapú migrálási korlátozások
Az API-alapú migrálás során a következő korlátozások lépnek fel:
- Alacsony hűségű migrálás:
- Korlátozás: Az API-alapú eszközök nagyobb hűséget biztosítanak, mint a manuális másolás, de még mindig viszonylag alacsony a hűség.
- Következmények: Bár ezek az eszközök némi hűséget biztosítanak, nem őrzik meg az adatok minden aspektusát.
- Példa: Egyik sem őrzi meg a TFVC-módosítások eredeti dátumát (Team Foundation verziókövetés).
- Sokan nem őrzik meg a munkaelem-változatok módosított dátumait sem.
- Adatvesztés és azonosítóváltozások:
- Korlátozás: A migrálás során az eszközök újra lejátszják a munkaelemek módosításait, a TFVC-változáskészleteket, a csomagcsatornákat és a folyamatösszetevőket.
- Következmények: Ez a folyamat adatvesztéshez, új azonosítók létrehozásához, valamint létrehozási, módosítási és lezárási dátumok módosításához vezethet.
- Példa: Az adott dátumokhoz kapcsolódó előzménykörnyezet elveszhet, ami hatással van a jelentéskészítésre és a nyomon követhetőségre.
API-alapú migrálási folyamat
Általában csak akkor javasoljuk ezt a megközelítést, ha a manuális másolaton túli további hűség kritikus fontosságú. Ha úgy dönt, hogy ezt a megközelítést választja, érdemes lehet felvennie egy tanácsadót, aki rendelkezik tapasztalattal egy vagy több eszközzel, és a végleges migrálás előtt elvégez egy tesztelési migrálást.
Sok szervezetnek nagyon nagy hűségű migrálásra van szüksége a munkájuknak csak egy részhalmazához. Az új munka akár közvetlenül az Azure DevOps Servicesben is elkezdődhet. Más, kevésbé szigorú megbízhatósági követelményekkel rendelkező munkát a többi módszer egyikével migrálhat.
Támogatott folyamatmodellek
Az Azure DevOps Services a következő folyamatmodelleket támogatja:
Alapértelmezés szerint a üzemeltetett XML ki van kapcsolva az Azure DevOps Servicesben. A migrálás során csak akkor kapcsoljuk be az üzemeltetett XML-folyamatmodellt, ha testre szabott egy projektet az Azure DevOps Serverben. Ha a projekt az üzemeltetett XML-en van, frissítheti azt az áttelepítés utáni öröklöttre.
Alapelvek
Az Azure DevOps Servicesbe való migráláskor tartsa szem előtt az alábbi fő alapelveket és korlátozásokat:
- Az Azure DevOps Services csak angol nyelvű: Az Azure DevOps Server több nyelvet is támogat, de az Azure DevOps Services jelenleg csak az angol nyelvet támogatja. Ha a gyűjtemény nem angol nyelvet használ, vagy korábban nem angol nyelvet használt, és a verziófrissítés során a nyelvet angolra konvertálta, nem használhatja az adatmigrálási eszközt.
- Öröklés: Az Agile-, Scrum- vagy CMMI-folyamatsablonból létrehozott és soha nem testre szabott projekt a migrálás utáni öröklési folyamatmodellen található.
- Üzemeltetett XML: Minden testreszabással rendelkező projekt az üzemeltetett XML-folyamatmodellt használja.
- Folyamat testre szabott projektenként: Bár az Azure DevOps Services lehetővé teszi a projektek számára a folyamatok megosztását, az Adatmigrálási eszköz egy üzemeltetett XML-folyamatot hoz létre minden egyéni csapatprojekthez. Ha például 30 testreszabott projektje van, 30 üzemeltetett XML-folyamatot kell kezelnie. Ha az üzemeltetett XML-folyamatot az összes projekthez szeretné testre szabni, az egyes üzemeltetett XML-folyamatokat külön kell frissítenie.
- Folyamatérvényesítés: Az adatmigrálási eszköz folyamatérvényesítése észleli az egyes projektek célfolyamat-modelljét. A migrálás előtt ki kell javítania az üzemeltetett XML-projektek folyamatérvényesítési hibáit. Érdemes lehet úgy frissíteni a projektek folyamatát, hogy megfeleljen az egyik folyamatunknak (Agile, Scrum vagy CMMI), hogy kihasználhassa az öröklési folyamat modelljét. További információ a folyamatérvényesítési típusokról a dokumentációnkban.
Források
Következő lépések
Kapcsolódó cikkek
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: