Share via

Omówienie migracji

  • Artykuł

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 Służy do migracji na dużą skalę o różnych typach danych i złożonych strukturach. Możesz tylko "lift and shift" jedną kolekcję usługi Azure DevOps Server do jednej nowej organizacji usługi 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 o niskiej wierności, utracie danych i identyfikatorach. Aby uzyskać więcej informacji, zobacz sekcję Ograniczenia.

Opcja 1. Migracja ręczna

Na przykład gdy zespół usługi Azure DevOps w firmie Microsoft zdecydował się przejść z usługi Azure DevOps Server do usługi Azure DevOps Services, postanowiliśmy również przejść z Kontrola wersji serwera Team Foundation (TFVC) do usługi 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ż aktywne elementy robocze i pozostawiliśmy wszystkie nasze stare usterki, ukończono scenariusze użytkownika i zadania itd.

Proces migracji ręcznej

  1. 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 — potoki kompilacji, plany testów itd. — są trudniejsze do ręcznej migracji.
  2. Zidentyfikuj odpowiedni czas, aby przejść.
  3. Przygotuj organizacje docelowe. Utwórz potrzebne organizacje i projekty zespołowe, aprowizuj użytkowników itd.
  4. Migrowanie danych.
  5. Rozważ wprowadzenie źródłowych wdrożeń 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.
    • Zmiany uprawnień skryptów: jeśli masz wiele projektów lub repozytoriów, może być konieczne ich tworzenie skryptów. 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 obszaru Repozytoria> ustawień>projektu repozytorium, a następnie obok pozycji Wyłącz repozytorium przenieś przełącznik do pozycji Włączone.

Opcja 2. Narzędzie do migracji 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ą przeprowadzać analizę premiacji 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 (na przykład modyfikowanie wartości) jest zwykle obsługiwane oddzielnie po migracji.

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

Proces narzędzia migracji

  1. Spełnij wymagania wstępne, takie jak aktualizowanie serwera Azure DevOps Server do jednej z dwóch najnowszych wersji.
  2. Zweryfikuj każdą kolekcję, którą chcesz przenieść do usługi Azure DevOps Services.
  3. Generowanie plików migracji.
  4. Przygotuj wszystko do wykonania migracji.
  5. Wykonaj przebieg testu.
  6. Przeprowadzanie migracji.
  7. Upewnij się, że użytkownicy i dane są migrowane, a kolekcja działa zgodnie z oczekiwaniami.

Opcja 3. Migracja oparta na interfejsie API

Jeśli z jakiegoś powodu nie możesz użyć narzędzia do migracji danych, ale nadal chcesz przeprowadzić migrację o wyższej wierności niż opcja 2, możesz wybrać spośród różnych narzędzi, które używają publicznych interfejsów API do przenoszenia danych.

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 są stosunkowo niskie wierność.
    • Implikacja: Chociaż te narzędzia oferują pewną wierność, nie zachowują wszystkich aspektów danych.
      • Przykład: Żadna z nich nie zachowuje oryginalnych dat zestawów zmian kontroli wersji serwera Team Foundation (Kontrola wersji serwera Team Foundation).
      • Wiele z tych elementów nie zachowuje zmienionych dat poprawek elementów roboczych.
  • Zmiany utraty i identyfikatora danych:
    • Ograniczenie: Podczas migracji narzędzia odtwarzają zmiany elementów roboczych, zestawy zmian kontroli wersji serwera Team Foundation, kanały informacyjne 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ść wykracza poza 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 bardzo wysokiej wierności migracji tylko dla podzbioru swojej pracy. 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. Po przejściu projektu na hostowany kod XML można uaktualnić go do dziedziczonej 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 kod XML: dowolny projekt z dostosowaniami używa modelu procesów Hostowany XML.
  • Przetwarzanie dla dostosowanego projektu: mimo że usługa Azure DevOps Services umożliwia projektom współużytkowanie procesu, narzędzie do migracji danych tworzy hostowany proces XML 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 usługi Azure DevOps