Omówienie migracji

2025-04-08

Przejście z usługi Azure DevOps Server do usługi Azure DevOps Services jest istotnym krokiem dla organizacji, które chcą korzystać z funkcji współpracy, skalowalności i ulepszonych funkcji opartych na chmurze. W tym omówieniu zapoznamy się z opcjami przenoszenia cennych danych z lokalnego serwera Azure DevOps Server do usług Azure DevOps Services opartych na chmurze.

Aby uzyskać informacje o głównych różnicach między lokalnym serwerem Azure DevOps Server i usługą Azure DevOps Services opartą na chmurze, zobacz Porównanie usług Azure DevOps Services z usługą Azure DevOps Server — Azure DevOps Server.

Niezależnie od wybranej opcji migracji zalecamy określenie najważniejszych zasobów, takich jak kod źródłowy i elementy robocze. Należy zastanowić się nad rozmiarem danych, złożonością organizacji i upewnić się, że masz wystarczająco dużo czasu na przebiegi testów przed rzeczywistą migracją w celu zapewnienia bezproblemowego i pomyślnego przejścia.

Podejścia do migracji

Ważne jest, aby ocenić zalety i wady każdego podejścia do migracji w oparciu o konkretne motywacje do wdrożenia usług Azure DevOps Services. Właściwa strategia zależy od unikatowego kontekstu i wymagań.

Opcje	Zalecane scenariusze	Ograniczenia
1. Migracja ręczna	Służy do mniejszych projektów lub określonych podzestawów danych.	Nie wszystkie dane można migrować z pełną wiernością i podlegają ograniczaniu przepustowości. Ta migracja nie obsługuje migrowania szablonów XML, dlatego należy ponownie utworzyć szablony procesów jako szablony dziedziczone.
2. Narzędzie do migracji danych usługi Azure DevOps	Zaleca się użycie do średnio- i wielkoskalowych migracji z różnorodnymi typami danych i złożonymi strukturami.	Możesz tylko przenieść jedną kolekcję z Azure DevOps Server do nowej organizacji Azure DevOps Services bez żadnych modyfikacji. Aby uzyskać więcej informacji, zobacz sekcję Ograniczenia.
3. Migracja oparta na interfejsie API	Oferuje elastyczność i dostosowywanie dla organizacji z unikatowymi wymaganiami migracji lub potrzebami automatyzacji.	Mogą wystąpić zmiany niskiej wierności, utrata danych i zmiany identyfikatorów. Aby uzyskać więcej informacji, zobacz sekcję Ograniczenia.

Opcja 1. Migracja ręczna

Na przykład, gdy zespół Azure DevOps w firmie Microsoft zdecydował się przejść z Azure DevOps Server na Azure DevOps Services, postanowiliśmy również przejść z Kontroli wersji Team Foundation (TFVC) na Git. Migracja wymagała dużej ilości planowania, ale podczas migracji utworzyliśmy nowe repozytorium Git przy użyciu "tip" wersji naszych źródeł TFVC i pozostawiliśmy naszą historię w usłudze Azure DevOps Server. Przenieśliśmy również nasze aktywne elementy robocze i pozostawiliśmy wszystkie stare usterki, ukończone scenariusze użytkownika, zadania itp.

Proces migracji ręcznej

Zidentyfikuj najważniejsze zasoby, które należy migrować — zazwyczaj kod źródłowy, elementy robocze lub oba te elementy. Inne zasoby w usłudze Azure DevOps Server — ciągi kompilacji, plany testów itd. — są trudniejsze do manualnej migracji.
Zidentyfikuj odpowiedni czas, aby przejść.
Przygotuj organizacje docelowe. Utwórz potrzebne organizacje i projekty zespołowe, aprowizuj użytkowników itd.
Migrowanie danych.
Rozważ wprowadzenie źródłowych implementacji usługi Azure DevOps Server tylko do odczytu. Można to zrobić w następujący sposób:
- Dostosuj uprawnienia na poziomie projektu: ustaw uprawnienia dla wszystkich użytkowników lub grup na tylko do odczytu na poziomie projektu, co można zrobić, modyfikując role zabezpieczeń w ustawieniach projektu.
- Modyfikowanie ustawień repozytorium: dla każdego repozytorium można zmienić ustawienia tak, aby były tylko do odczytu, co obejmuje dostosowanie uprawnień dla każdego użytkownika lub grupy, aby zezwalać tylko na akcje odczytu.
- Użyj wbudowanych grup zabezpieczeń: korzystaj z wbudowanych grup zabezpieczeń, aby wydajniej zarządzać uprawnieniami. Możesz przypisać użytkowników do grup, takich jak "Czytelnicy", aby zapewnić dostęp tylko do odczytu.
- Skriptowanie zmian uprawnień: jeśli masz wiele projektów lub repozytoriów, może być konieczne skryptowanie zmian. Możesz użyć rozszerzenia DevOps interfejsu wiersza polecenia platformy Azure, aby wyświetlić listę wszystkich uprawnień i zaktualizować je zgodnie z potrzebami.
- Wyłącz funkcję repozytorium: wyłącza dostęp do repozytorium, w tym kompilacji i żądań ściągnięcia, ale zachowuje możliwość odnajdywania repozytorium z ostrzeżeniem. Przejdź do Ustawienia projektu>Repozytoria> swojego repozytorium, a następnie obok opcji Wyłącz repozytorium przesuń przełącznik na Włączone.

Opcja 2. Narzędzie do migracji danych usługi Azure DevOps

Narzędzie do migracji danych usługi Azure DevOps to zestaw narzędzi udostępnianych przez firmę Microsoft w celu ułatwienia migracji danych z usługi Azure DevOps Server do usług Azure DevOps Services. Te narzędzia oferują usprawnione podejście do migrowania różnych artefaktów, w tym kodu źródłowego, elementów roboczych, przypadków testowych i innych danych związanych z projektem.

Przed zainicjowaniem procesu migracji narzędzia mogą przeprowadzić analizę przedmigracyjną w celu oceny gotowości środowiska źródłowego i identyfikowania potencjalnych problemów lub zależności, które mogą mieć wpływ na migrację. Oceń gotowość, aby móc wcześniej planować i ograniczać potencjalne wyzwania.

Ograniczenia narzędzia migracji

Narzędzie umożliwia "lift and shift" jedną kolekcję serwera Azure DevOps Server do jednej nowej organizacji usługi Azure DevOps Service bez modyfikacji z następujących powodów:

Integralność i spójność danych:
- Podczas migracji danych zachowanie integralności i spójności ma kluczowe znaczenie. Zezwolenie na modyfikacje podczas migracji może prowadzić do uszkodzenia lub niespójności danych.
- Narzędzie zapewnia, że dane pozostają nienaruszone podczas procesu transferu, minimalizując ryzyko wystąpienia błędów.
Zachowywanie danych źródłowych:
- Narzędzie do migracji ma na celu wiernie replikowanie danych źródłowych w środowisku docelowym.
- Modyfikacje mogą spowodować zmianę oryginalnych danych, co może spowodować rozbieżności między zmigrowanych danych a danymi źródłowymi.
Przewidywalne zachowanie:
- Ograniczając modyfikacje, narzędzie zapewnia przewidywalne zachowanie podczas migracji.
- Użytkownicy mogą polegać na spójnych wynikach bez nieoczekiwanych zmian.
Fokus migracji, a nie transformacja:
- Podstawowym celem narzędzia migracji jest przeniesienie danych z jednej lokalizacji do innej.
- Przekształcanie danych, takie jak modyfikowanie wartości, zwykle jest obsługiwane oddzielnie po migracji.
Obsługiwane scenariusze migracji:
- Przenoszenie projektów z jednej organizacji usługi Azure DevOps Services do innej organizacji usługi Azure DevOps Services nie jest obecnie obsługiwane.
- Migracja z jednego wystąpienia usługi Azure DevOps Server do innego nie jest obsługiwana.

Możesz przeczyścić dane, których nie potrzebujesz przed migracją lub po jej zakończeniu.

Proces narzędzia migracji

Spełnij wymagania wstępne, takie jak aktualizowanie serwera Azure DevOps Server do jednej z dwóch najnowszych wersji.
Zweryfikuj każdą kolekcję, którą chcesz przenieść do usługi Azure DevOps Services.
Generowanie plików migracji.
Przygotuj wszystko do wykonania migracji.
Wykonaj test próbny.
Przeprowadzanie migracji.
Upewnij się, że użytkownicy i dane zostały zmigrowane, a zbiór działa zgodnie z oczekiwaniami.

Opcja 3. Migracja oparta na interfejsie API

Jeśli nie możesz użyć narzędzia do migracji danych, ale nadal chcesz przeprowadzić migrację o wyższej wierności niż opcja 2, rozważ użycie różnych narzędzi, które wykorzystują publiczne interfejsy API do przenoszenia danych. Te narzędzia obejmują rozszerzenia dostępne w witrynie Visual Studio Marketplace.

Ograniczenia migracji oparte na interfejsie API

W przypadku migracji opartej na interfejsie API występują następujące ograniczenia:

Migracja o niskiej wierności:
- Ograniczenie: narzędzia oparte na interfejsie API zapewniają większą wierność niż ręczne kopiowanie, ale nadal posiadają stosunkowo niską wierność.
- Implikacja: Chociaż te narzędzia oferują pewną wierność, nie zachowują wszystkich aspektów danych.
  - Przykład: Żadna z nich nie zachowuje oryginalnych dat zmian TFVC (Team Foundation Version Control).
  - Wiele z tych elementów nie zachowuje zmienionych dat poprawek elementów roboczych.
Utrata danych i zmiany identyfikatora
- Ograniczenie: Podczas migracji narzędzia odtwarzają zmiany elementów roboczych, zmiany zestawów kontrolnych TFVC, źródła pakietów i artefakty potoku.
- Implikacja: Ten proces może prowadzić do utraty danych, generowania nowych identyfikatorów i zmieniania dat tworzenia, modyfikowania i zamykania.
  - Przykład: kontekst historyczny powiązany z określonymi datami może zostać utracony, co wpływa na raportowanie i możliwość śledzenia.

Proces migracji opartej na interfejsie API

Ogólnie rzecz biorąc, zalecamy to podejście tylko wtedy, gdy dodatkowa wierność ponad ręczną kopię jest krytyczna. Jeśli zdecydujesz się na takie podejście, możesz rozważyć zatrudnienie konsultanta, który ma doświadczenie w pracy z co najmniej jednym narzędziem i przeprowadzić migrację testową przed ostateczną migracją.

Wiele organizacji potrzebuje migracji o bardzo wysokiej dokładności jedynie dla wybranej części swojej działalności. Nowa praca może zostać potencjalnie uruchomiona bezpośrednio w usłudze Azure DevOps Services. Inne prace, z mniej rygorystycznymi wymaganiami dotyczącymi wierności, można migrować przy użyciu jednego z innych podejść.

Obsługiwane modele procesów

Usługa Azure DevOps Services obsługuje następujące modele procesów:

Domyślnie hostowany kod XML jest wyłączony w usługach Azure DevOps Services. Podczas migracji włączamy model hostowanego procesu XML tylko wtedy, gdy projekt został dostosowany w usłudze Azure DevOps Server. Gdy Twój projekt znajduje się na Hosted XML, możesz uaktualnić go do odziedziczonego po migracji.

Najważniejsze zasady

Podczas migracji do usług Azure DevOps Services należy pamiętać o następujących kluczowych zasadach i ograniczeniach:

Usługa Azure DevOps Services jest tylko w języku angielskim: usługa Azure DevOps Server obsługuje wiele języków, jednak obecnie usługa Azure DevOps Services obsługuje tylko język angielski. Jeśli kolekcja używa języka innego niż angielski lub nieanglojęzycznego w przeszłości i przekonwertowała język na angielski podczas uaktualniania, nie możesz użyć narzędzia do migracji danych.
Dziedziczenie: projekt, który został utworzony na podstawie szablonu procesu Agile, Scrum lub CMMI i nigdy nie został dostosowany, jest w modelu procesu dziedziczenia po migracji.
Hostowany XML: Każdy projekt z dostosowaniami używa modelu procesu Hostowany XML.
Proces dla dostosowanego projektu: Chociaż usługa Azure DevOps Services umożliwia projektom współużytkowanie procesu, narzędzie do migracji danych tworzy proces XML typu Hosted dla każdego dostosowanego projektu zespołowego. Jeśli na przykład masz 30 dostosowanych projektów, masz 30 hostowanych procesów XML do zarządzania. Jeśli chcesz jeszcze bardziej dostosować hostowany proces XML dla wszystkich projektów, musisz oddzielnie zaktualizować każdy proces hostowanego kodu XML.
Walidacja procesu: walidacja procesu narzędzia do migracji danych wykrywa docelowy model procesu dla każdego projektu. Przed przeprowadzeniem migracji należy naprawić wszelkie błędy weryfikacji procesu dla hostowanych projektów XML. Warto rozważyć zaktualizowanie procesu projektów tak, aby był zgodny z jednym z naszych procesów (Agile, Scrum lub CMMI), aby skorzystać z modelu procesu dziedziczenia. Dowiedz się więcej na temat typów weryfikacji procesów w naszej dokumentacji.

Zasoby

Następne kroki

Rozpoczynanie pracy z narzędziem do migracji danych usługi Azure DevOps