Przeprowadź próbne migracje
Twój zespół jest teraz gotowy do rozpoczęcia procesu rozpoczynania przebiegu testu migracji, a następnie pełnej migracji produkcyjnej. W tej fazie omówimy końcowe kroki kolejkowania migracji oprócz innych zadań, które zwykle pojawiają się na końcu projektu migracji.
Wymagania wstępne
Przed rozpoczęciem migracji przebiegu testu ukończ fazę Przygotowywanie przebiegu testu.
Ważne
Aby zapewnić bezproblemowy proces migracji, wykonaj jeden lub więcej testowych importów. Import testowy trwa 45 dni na potrzeby testowania i walidacji. Po 45 dniach wersja testowa wygaśnie i zostanie usunięta, co wymaga jej ponownego uruchomienia, jeśli to konieczne. Im więcej czasu upływa między przebiegiem testowym a produkcyjnym, tym bardziej usługa może się zmienić, co może spowodować wystąpienie błędów, które wychwyciłby świeży przebieg testowy. Możesz ponownie uruchomić importowanie przebiegu testu tyle razy, ile jest to konieczne. Każdy import rozpoczyna się od stanu początkowego zaimportowanej bazy danych, ponieważ nie jest możliwe, aby zmiany z jednego importu trwały do drugiego. Zwróć uwagę na następujące kwestie:
- Nie można przedłużyć przebiegu testu na czas nieokreślony
- Nie można zmienić testowej wersji na wersję produkcyjną
- Przebieg testu zostanie usunięty, jeśli wystąpi którykolwiek z następujących:
- Limit czasu uruchomienia testu
- Zostanie uruchomiony nowy przebieg testowy o tej samej nazwie
- Rozpoczyna się przebieg produkcyjny
- Organizacja jest usuwana ręcznie za pośrednictwem ustawień organizacji
Weryfikowanie kolekcji
Zweryfikuj każdą kolekcję, która ma zostać zmigrowana do usług Azure DevOps Services. Krok weryfikacji sprawdza różne aspekty kolekcji, w tym między innymi rozmiar, sortowanie, tożsamość i procesy.
Uruchom walidację przy użyciu narzędzia do migracji danych.
Pobierz narzędzie do migracji danych.
Skopiuj plik zip do jednej z warstw aplikacji usługi Azure DevOps Server.
Rozpakuj plik. Narzędzie można również uruchomić z innej maszyny bez zainstalowanego serwera Azure DevOps Server, o ile komputer może nawiązać połączenie z bazą danych konfiguracji wystąpienia usługi Azure DevOps Server.
Otwórz okno wiersza polecenia na serwerze i wprowadź polecenie cd, aby zmienić katalog, w którym jest przechowywane narzędzie do migracji danych. Poświęć chwilę, aby przejrzeć zawartość pomocy dla narzędzia.
a. Aby wyświetlić pomoc i wskazówki najwyższego poziomu, uruchom następujące polecenie.
Migrator /helpb. Wyświetl tekst pomocy dla polecenia .
Migrator validate /helpPodczas pierwszego sprawdzania poprawności kolekcji polecenie powinno mieć następującą prostą strukturę.
Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}Gdzie
{name}podaje nazwę dzierżawy Microsoft Entra, na przykład aby uruchomić dla DefaultCollection i dzierżawy fabrikam, polecenie będzie wyglądać podobnie do poniższego przykładu.Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}Aby uruchomić narzędzie z maszyny innej niż usługa Azure DevOps Server, potrzebny jest parametr /connectionString . Parametr ciągu połączenia wskazuje bazę danych konfiguracji Azure DevOps Server. Na przykład jeśli zweryfikowane polecenie jest uruchamiane przez firmę Fabrikam, polecenie będzie wyglądać następująco.
Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"Ważne
Narzędzie do migracji danych nie edytuje żadnych danych ani struktur w kolekcji. Odczytuje kolekcję tylko w celu zidentyfikowania problemów.
Po zakończeniu walidacji można wyświetlić pliki dziennika i wyniki.
Podczas walidacji zostanie wyświetlone ostrzeżenie, jeśli niektóre potoki zawierają reguły przechowywania dla poszczególnych potoków. Usługa Azure DevOps Services używa modelu przechowywania opartego na projekcie i nie obsługuje zasad przechowywania dla poszczególnych potoków. Jeśli przejdziesz do migracji, zasady nie są przenoszone do hostowanej wersji. Zamiast tego mają zastosowanie domyślne zasady przechowywania na poziomie projektu. Zachowaj ważne kompilacje, aby uniknąć ich utraty.
Po zakończeniu wszystkich weryfikacji można przejść do następnego kroku procesu migracji. Jeśli narzędzie do migracji danych flaguje błędy, popraw je przed kontynuowaniem. Aby uzyskać wskazówki dotyczące poprawiania błędów walidacji, zobacz Rozwiązywanie problemów z migracją i błędami migracji.
Importowanie plików dziennika
Po otwarciu katalogu dziennika może zostać wyświetlonych kilka plików rejestrowania.
Główny plik dziennika nosi nazwę DataMigrationTool.log. Zawiera szczegółowe informacje o wszystkim, co zostało uruchomione. Aby ułatwić skoncentrowanie się na określonych obszarach, dziennik jest generowany dla każdej głównej operacji weryfikacji.
Jeśli na przykład tfsMigrator zgłasza błąd w kroku "Weryfikowanie procesów projektu", możesz otworzyć plik ProjectProcessMap.log , aby wyświetlić wszystko, co zostało uruchomione dla tego kroku, zamiast przewijać cały dziennik.
Przejrzyj plik TryMatchOobProcesses.log tylko wtedy, gdy próbujesz przeprowadzić migrację procesów projektu w celu użycia odziedziczonego modelu. Jeśli nie chcesz używać dziedziczonego modelu, możesz zignorować te błędy, ponieważ nie uniemożliwiają importowania do usług Azure DevOps Services. Aby uzyskać więcej informacji, zobacz faza walidacji migracji.
Generowanie plików migracji
Narzędzie do migracji danych zweryfikowało kolekcję i zwraca wynik "Wszystkie weryfikacje kolekcji zostały pomyślnie przekazane". Przed przełączenie kolekcji do trybu offline w celu jej migracji wygeneruj pliki migracji. Po uruchomieniu prepare polecenia wygenerujesz dwa pliki migracji:
- IdentityMapLog.csv: przedstawia mapę tożsamości między usługą Active Directory i identyfikatorem Entra firmy Microsoft.
- migration.json: wymaga wypełnienia specyfikacji migracji, której chcesz użyć do rozpoczęcia migracji.
Polecenie Przygotuj
Polecenie prepare pomaga w generowaniu wymaganych plików migracji. Zasadniczo to polecenie skanuje kolekcję, aby znaleźć listę wszystkich użytkowników w celu wypełnienia dziennika mapy tożsamości, IdentityMapLog.csv, a następnie próbuje nawiązać połączenie z identyfikatorem Entra firmy Microsoft w celu znalezienia dopasowania każdej tożsamości. W tym celu firma musi użyć narzędzia Microsoft Entra Connect (wcześniej znanego jako narzędzie synchronizacji katalogów, narzędzie synchronizacji katalogów lub narzędzie DirSync.exe).
Jeśli synchronizacja katalogów jest skonfigurowana, narzędzie do migracji danych powinno znaleźć pasujące tożsamości i oznaczyć je jako Aktywne. Jeśli nie ma dopasowań, tożsamość jest oznaczona jako Historyczna w dzienniku mapy tożsamości, dlatego należy zbadać, dlaczego użytkownik nie jest uwzględniony w synchronizacji katalogu. Plik specyfikacji migracji, migration.json, należy wypełnić przed migracją.
W przeciwieństwie do polecenia validate, prepareto wymaga połączenia z internetem, ponieważ musi nawiązać połączenie z Microsoft Entra ID, aby wypełnić plik dziennika mapy tożsamości. Jeśli wystąpienie usługi Azure DevOps Server nie ma dostępu do Internetu, uruchom narzędzie z maszyny, która to robi. Jeśli możesz znaleźć maszynę z połączeniem intranetowym do instancji Azure DevOps Server i połączeniem internetowym, możesz uruchomić to polecenie. Aby uzyskać pomoc dotyczącą prepare polecenia, uruchom następujące polecenie:
Migrator prepare /help
W dokumentacji pomocy znajdują się instrukcje i przykłady uruchamiania polecenia Migrator bezpośrednio z instancji Azure DevOps Server oraz z maszyny zdalnej. Jeśli uruchamiasz polecenie z jednej z warstw aplikacji instancji Azure DevOps Server, polecenie powinno mieć taką strukturę.
Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region}
Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True"
Parametr connectionString jest wskaźnikiem do konfiguracyjnej bazy danych Twojego wystąpienia usługi Azure DevOps Server. Jeśli na przykład firma Fabrikam uruchamia prepare polecenie, polecenie wygląda jak w poniższym przykładzie:
Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"
Gdy narzędzie do migracji danych uruchamia prepare polecenie, uruchamia pełną walidację, aby upewnić się, że nic się nie zmieniło w kolekcji od czasu ostatniej pełnej weryfikacji. W przypadku wykrycia nowych problemów nie są generowane żadne pliki migracji.
Wkrótce po uruchomieniu polecenia zostanie wyświetlone okno logowania microsoft Entra. Zaloguj się, używając tożsamości z domeny dzierżawy wskazanej w poleceniu. Upewnij się, że określona dzierżawa Microsoft Entra jest tą, na której ma opierać się twoja przyszła organizacja. W naszym przykładzie firmy Fabrikam użytkownik wprowadza poświadczenia podobne do poniższego przykładowego zrzutu ekranu.
Ważne
Nie używaj testowej dzierżawy Microsoft Entra do migracji testowej ani produkcyjnej dzierżawy do produkcyjnego wdrożenia. Użycie testowej dzierżawy Microsoft Entra może spowodować problemy z migracją tożsamości, gdy zaczynasz uruchomienie środowiska produkcyjnego z produkcyjną dzierżawą Microsoft Entra w organizacji.
Po pomyślnym uruchomieniu prepare polecenia w narzędziu do migracji danych w oknie wyników zostanie wyświetlony zestaw dzienników i dwa pliki migracji. W katalogu dziennika znajdź folder logs i dwa pliki:
- migration.json to plik specyfikacji migracji. Zalecamy, aby poświęcić trochę czasu na jego wypełnienie.
- IdentityMapLog.csv zawiera wygenerowane mapowanie Active Directory na tożsamości Microsoft Entra. Przed rozpoczęciem migracji przejrzyj ją pod kątem kompletności.
Dwa pliki zostały szczegółowo opisane w następnych sekcjach.
Plik specyfikacji migracji
Specyfikacja migracji, migration.json, jest plikiem JSON, który zapewnia ustawienia migracji. Zawiera pożądaną nazwę organizacji, informacje o koncie magazynu i inne informacje. Większość pól jest wypełniana automatycznie, a niektóre pola wymagają danych wejściowych przed podjęciem próby migracji.
Wyświetlane pola i wymagane akcje pliku migration.json zostały opisane w poniższej tabeli:
| Pole | opis | Wymagana akcja |
|---|---|---|
| Źródło | Informacje o lokalizacji i nazwach plików danych źródłowych używanych do migracji. | Nie musisz wykonywać żadnej akcji. Przejrzyj informacje dotyczące akcji podrzędnych, które należy wykonać. |
| Lokalizacja | Klucz sygnatury dostępu współdzielonego do konta usługi Azure Storage hostujący pakiet aplikacji warstwy danych (DACPAC). | Nie musisz wykonywać żadnej akcji. To pole zostało omówione w późniejszym kroku. |
| Pliki | Nazwy plików zawierających dane migracji. | Nie musisz wykonywać żadnej akcji. Przejrzyj informacje dotyczące akcji podrzędnych, które należy wykonać. |
| Pakiet DACPAC | Plik DACPAC, który pakuje bazę danych kolekcji do użycia w celu wprowadzenia danych podczas migracji. | Nie musisz wykonywać żadnej akcji. W późniejszym kroku utworzysz ten plik przy użyciu kolekcji, a następnie przekażesz go do konta usługi Azure Storage. Zaktualizuj plik na podstawie nazwy używanej podczas generowania go w dalszej części tego procesu. |
| Obiekt docelowy | Właściwości nowej organizacji, do której ma nastąpić migracja. | Nie musisz wykonywać żadnej akcji. Przejrzyj informacje dotyczące akcji podrzędnych, które należy wykonać. |
| Nazwisko | Nazwa organizacji, która ma zostać utworzona podczas migracji. | Podaj nazwę. Nazwę można szybko zmienić później po zakończeniu migracji. UWAGA: nie twórz organizacji o tej nazwie przed uruchomieniem migracji. Organizacja jest tworzona w ramach procesu migracji. |
| Typ importu | Typ migracji, którą chcesz uruchomić. | Nie musisz wykonywać żadnej akcji. W późniejszym kroku wybierz typ migracji do uruchomienia. |
| Dane weryfikacji | Informacje potrzebne do ułatwienia obsługi migracji. | Narzędzie do migracji danych generuje sekcję "ValidationData". Zawiera informacje pomagające ulepszyć doświadczenie migracji. Nie* zmieniaj wartości w tej sekcji, bo migracja może się nie rozpocząć. |
Po zakończeniu poprzedniego procesu powinien istnieć plik, który wygląda jak w poniższym przykładzie.
Na poprzedniej ilustracji planista migracji firmy Fabrikam dodał nazwę organizacji fabrikam-import i wybrał CUS (Centralne Stany Zjednoczone) jako centralną lokalizację geograficzną migracji. Pozostałe wartości zostały zachowane bez zmian, aby mogły zostać zmodyfikowane tuż przed przełączeniem kolekcji do trybu offline przez planistę na potrzeby migracji.
Uwaga
Importy testowe mają automatycznie dołączany ciąg "-dryrun" na końcu nazwy organizacji, który można zmienić po migracji.
Obsługiwane regiony platformy Azure na potrzeby migracji
Usługa Azure DevOps Services jest dostępna w kilku lokalizacjach geograficznych platformy Azure. Jednak nie wszystkie lokalizacje, w których usługa Azure DevOps Services jest dostępna, są obsługiwane na potrzeby migracji. W poniższej tabeli wymieniono lokalizacje geograficzne platformy Azure, które można wybrać do migracji. Uwzględniona jest również wartość, którą należy umieścić w pliku specyfikacji migracji w celu określenia lokalizacji geograficznej migracji.
| Lokalizacja geograficzna | Lokalizacja geograficzna platformy Azure | Wartość specyfikacji importu |
|---|---|---|
| Stany Zjednoczone | Środkowe Stany Zjednoczone | CUS |
| Europa | Europa Zachodnia | ZUE |
| Zjednoczone Królestwo | Zjednoczone Królestwo, część południowa | UKS |
| Australia | Australia Wschodnia | EAU |
| SAmeryka Południowa | Brazylia Południowa | SBR |
| Azja i Pacyfik | Indie Południowe | MA |
| Azja i Pacyfik | Azja Południowo-wschodnia (Singapur) | SEA |
| Kanada | Kanada Środkowa | Napisy |
Dziennik mapy tożsamości
Dziennik mapy tożsamości ma takie samo znaczenie jak rzeczywiste dane, które migrujesz do usług Azure DevOps Services. Podczas przeglądania pliku ważne jest, aby zrozumieć, jak działa migracja tożsamości i jakie mogą być potencjalne wyniki. Migracja tożsamości może stać się aktywna lub historyczna. Aktywne tożsamości mogą logować się do usług Azure DevOps Services, ale tożsamości historyczne nie mogą.
Aktywne tożsamości
Tożsamości aktywne odnoszą się do tożsamości użytkowników w usłudze Azure DevOps Services po zakończeniu migracji. W usłudze Azure DevOps Services te identyfikatory są licencjonowane i wyświetlane jako użytkownicy w organizacji. Tożsamości są oznaczone jako aktywne w kolumnie "Oczekiwany stan importu" w pliku dziennika mapy tożsamości.
Tożsamości historyczne
Tożsamości historyczne są mapowane jako takie w kolumnie oczekiwanego stanu importu w pliku dziennika mapy tożsamości. Tożsamości bez wpisu do pliku również stają się historyczne. Przykładem tożsamości bez wpisu w systemie może być pracownik, który nie pracuje już w firmie.
W przeciwieństwie do aktywnych tożsamości, tożsamości historyczne:
- Nie masz dostępu do organizacji po migracji.
- Nie masz licencji.
- Nie pojawiaj się jako użytkownik w organizacji. Zachowana jest jedynie nazwa tej tożsamości w organizacji, aby można było przeszukiwać jej historię później. Zalecamy używanie tożsamości historycznych dla użytkowników, którzy nie pracują już w firmie lub którzy nie potrzebują dalszego dostępu do organizacji.
Uwaga
Po zaimportowaniu tożsamości jako historycznej nie można jej uaktywnić.
Omówienie pliku dziennika mapy tożsamości
Plik dziennika mapy tożsamości jest podobny do przedstawionego tutaj przykładu:
Kolumny w pliku dziennika mapy tożsamości zostały opisane w poniższej tabeli:
Ty i Twój administrator usługi Microsoft Entra musicie badać użytkowników oznaczonych jako Nie znaleziono dopasowań (Sprawdź Microsoft Entra ID Sync), aby zrozumieć, dlaczego nie są częścią usługi Microsoft Entra Connect Sync.
| Kolumna | opis |
|---|---|
| Active Directory: użytkownik (Azure DevOps Server) | Przyjazna nazwa wyświetlana używana przez tożsamość w usłudze Azure DevOps Server. Ta nazwa ułatwia zidentyfikowanie użytkownika, do którego wiersza na mapie odwołuje się. |
| Active Directory: identyfikator zabezpieczeń | Unikatowy identyfikator dla tożsamości Active Directory hostowanej lokalnie w usłudze Azure DevOps Server. Ta kolumna służy do identyfikowania użytkowników w kolekcji. |
| Microsoft Entra ID: Oczekiwany użytkownik importu (Azure DevOps Services) | Oczekiwany adres logowania użytkownika, który wkrótce stanie się aktywny lub Nie znaleziono dopasowania (Sprawdź synchronizację Entra ID firmy Microsoft), co wskazuje, że tożsamość została utracona podczas synchronizacji Entra ID firmy Microsoft i jest importowana jako historyczna. |
| Oczekiwany stan importu | Oczekiwany stan migracji użytkownika: Aktywny, jeśli jest dopasowanie między usługą Active Directory a Microsoft Entra ID, lub Historyczny, jeśli nie ma dopasowania. |
| Data weryfikacji | Ostatni raz dziennik mapy tożsamości został zweryfikowany. |
Podczas odczytywania pliku zwróć uwagę, czy wartość w kolumnie Oczekiwany stan importu jest aktywna , czy historyczna. Aktywne wskazuje, że tożsamość w tym wierszu zostaje poprawnie zmapowana podczas migracji i staje się aktywna. Historyczne oznacza, że tożsamości stają się historyczne w przypadku migracji. Ważne jest, aby przejrzeć wygenerowany plik mapowania pod kątem kompletności i poprawności.
Ważne
Migracja nie powiedzie się, jeśli wystąpią poważne zmiany w synchronizacji identyfikatora zabezpieczeń programu Microsoft Entra Connect między próbami migracji. Możesz dodać nowych użytkowników między przebiegami testów i wprowadzić poprawki, aby upewnić się, że wcześniej zaimportowane tożsamości historyczne staną się aktywne. Nie można jednak zmienić istniejącego użytkownika, który został wcześniej zaimportowany jako aktywny. Spowoduje to niepowodzenie migracji. Przykładem zmiany może być ukończenie migracji testowej, usunięcie tożsamości z Microsoft Entra ID, która została aktywnie zaimportowana, ponowne utworzenie użytkownika w Microsoft Entra ID dla tej samej tożsamości, a następnie próba kolejnej migracji. W takim przypadku aktywna migracja tożsamości jest podejmowana między usługą Active Directory a nowo utworzoną tożsamością firmy Microsoft Entra, ale powoduje niepowodzenie migracji.
Przejrzyj prawidłowo dopasowane tożsamości. Czy są obecne wszystkie oczekiwane tożsamości? Czy użytkownicy są mapowani na poprawną tożsamość Microsoft Entra?
Jeśli należy zmienić jakiekolwiek wartości, skontaktuj się z administratorem Microsoft Entra, aby sprawdzić, czy lokalna tożsamość usługi Active Directory jest częścią synchronizacji z Microsoft Entra ID i jest prawidłowo skonfigurowana. Aby uzyskać więcej informacji, zobacz Integrowanie tożsamości lokalnych z Microsoft Entra ID.
Następnie przejrzyj tożsamości, które są oznaczone jako historyczne. To etykietowanie oznacza, że nie można odnaleźć zgodnej tożsamości firmy Microsoft Entra z dowolnego z następujących powodów:
- Tożsamość nie jest skonfigurowana do synchronizacji między lokalną usługą Active Directory a Identyfikatorem Microsoft Entra.
- Tożsamość użytkownika nie została jeszcze zaktualizowana w Microsoft Entra ID (na przykład, jeśli jest to nowy pracownik).
- Tożsamość nie istnieje w Twoim wystąpieniu Microsoft Entra.
- Użytkownik, który jest właścicielem tej tożsamości, nie pracuje już w firmie.
Aby rozwiązać pierwsze trzy powody, skonfiguruj docelową tożsamość lokalną Active Directory do synchronizacji z Microsoft Entra ID. Aby uzyskać więcej informacji, zobacz Integracja tożsamości lokalnych z Microsoft Entra ID. Musisz skonfigurować i uruchomić program Microsoft Entra Connect, aby tożsamości zostały zaimportowane jako aktywne w usłudze Azure DevOps Services.
Czwarty powód można zignorować, ponieważ pracownicy, którzy nie znajdują się już w firmie, powinni zostać zaimportowani jako historyczni.
Tożsamości historyczne (małe zespoły)
Uwaga
Tylko małe zespoły powinny rozważyć strategię migracji tożsamości zaproponowaną w tej sekcji.
Jeśli Microsoft Entra Connect nie jest skonfigurowany, wszyscy użytkownicy w pliku dziennika mapy tożsamości są oznaczani jako historyczni. Uruchomienie migracji w ten sposób powoduje zaimportowanie wszystkich użytkowników jako historycznych. Zdecydowanie zalecamy skonfigurowanie programu Microsoft Entra Connect , aby upewnić się, że użytkownicy są zaimportowani jako aktywni.
Uruchomienie migracji ze wszystkimi tożsamościami historycznymi ma konsekwencje, które należy dokładnie rozważyć. Należy wziąć pod uwagę tylko zespoły z kilkoma użytkownikami, dla których koszt konfigurowania programu Microsoft Entra Connect jest zbyt wysoki.
Aby przeprowadzić migrację wszystkich tożsamości do stanu historycznego, wykonaj kroki opisane w kolejnych sekcjach. Kiedy dodajesz migrację do kolejki, tożsamość używana do tego celu jest włączana do organizacji jako właściciel organizacji. Wszyscy inni użytkownicy są importowani jako historyczni. Właściciele organizacji mogą następnie dodawać użytkowników z powrotem przy użyciu tożsamości firmy Microsoft Entra. Dodani użytkownicy są traktowani jako nowi użytkownicy. Nie posiadają żadnej części swojej historii i nie ma możliwości przypisania tej historii do tożsamości Microsoft Entra. Jednak użytkownicy nadal mogą przeglądać swoją historię sprzed migracji, wyszukując swoje \<domain>\<Active Directory username>.
Narzędzie do migracji danych wyświetla ostrzeżenie, jeśli wykryje kompletny scenariusz tożsamości historycznych. Jeśli zdecydujesz się wybrać tę ścieżkę migracji, musisz w narzędziu wyrazić zgodę na ograniczenia.
Subskrypcje programu Visual Studio
Narzędzie do migracji danych nie może wykryć subskrypcji programu Visual Studio (wcześniej znanych jako korzyści MSDN) podczas generowania pliku dziennika mapy tożsamości. Zamiast tego zalecamy zastosowanie funkcji automatycznego uaktualniania licencji po migracji. Jeśli konta służbowe użytkowników są poprawnie połączone , usługi Azure DevOps Services automatycznie stosują swoje korzyści z subskrypcji programu Visual Studio podczas pierwszego logowania po migracji. Nigdy nie są naliczane opłaty za licencje przypisane podczas migracji, dzięki czemu możesz bezpiecznie obsługiwać subskrypcje później.
Nie musisz powtarzać próby migracji, jeśli subskrypcje programu Visual Studio użytkowników nie są automatycznie zaktualizowane w Azure DevOps Services. Łączenie subskrypcji programu Visual Studio odbywa się poza zakresem migracji. Jeśli konto służbowe jest poprawnie połączone przed migracją lub po migracji, licencje użytkowników zostaną automatycznie uaktualnione podczas następnego logowania. Po pomyślnym uaktualnieniu licencji przy następnym uruchomieniu migracji użytkownicy zostaną automatycznie uaktualnieni podczas pierwszego logowania do organizacji.
Przygotowanie do migracji
Teraz masz wszystko gotowe do przeprowadzenia próbnej migracji. Zaplanuj przestój z zespołem, aby przejąć kolekcję w tryb offline na potrzeby migracji. Po zaakceptowaniu czasu uruchomienia migracji przekaż wygenerowane wymagane zasoby i kopię bazy danych na platformę Azure. Przygotowanie do migracji składa się z następujących pięciu kroków.
Krok 1. Przełącz kolekcję w tryb offline i odłącz ją.
Krok 2. Generowanie pliku DACPAC z kolekcji, którą zamierzasz zmigrować.
Krok 3. Przekazywanie plików DACPAC i plików migracji do konta usługi Azure Storage.
Krok 4. Generowanie tokenu SAS, aby uzyskać dostęp do magazynu konta.
Krok 5. Ukończenie specyfikacji migracji.
Uwaga
Przed przeprowadzeniem migracji produkcyjnej zdecydowanie zalecamy przeprowadzenie migracji testowej. Po uruchomieniu testu można sprawdzić, czy proces migracji działa dla kolekcji i czy nie ma żadnych unikatowych kształtów danych, które mogą spowodować niepowodzenie migracji produkcyjnej.
Krok 1. Odłączanie kolekcji
Odłączanie kolekcji jest kluczowym krokiem w procesie migracji. Dane tożsamości dla kolekcji znajdują się w bazie danych konfiguracji wystąpienia Azure DevOps Server, gdy kolekcja jest podłączona i dostępna online. Gdy kolekcja jest odłączona od wystąpienia usługi Azure DevOps Server, pobiera kopię tych danych tożsamości i pakuje ją z kolekcją na potrzeby transportu. Bez tych danych nie da się wykonać elementu tożsamości migracji.
Napiwek
Zalecamy, aby kolekcja była odłączona do momentu zakończenia migracji, ponieważ nie ma możliwości migracji zmian, które wystąpiły podczas migracji. Ponownie dołącz kolekcję po utworzeniu jej kopii zapasowej na potrzeby migracji, więc nie masz obaw o posiadanie najnowszych danych dla tego typu migracji. Aby całkowicie uniknąć czasu offline, możesz również zastosować odłączenie offline do przeprowadzania testów.
Ważne jest, aby rozważyć koszt wyboru osiągnięcia zerowego przestoju dla testowego uruchomienia. Wymaga to utworzenia kopii zapasowych kolekcji i bazy danych konfiguracji, przywrócenia ich w wystąpieniu SQL, a następnie utworzenia odłączonej kopii zapasowej. Analiza kosztów może wykazać, że zdecydowanie się na zaledwie kilka godzin przestoju w celu wykonania bezpośredniej kopii zapasowej odłączonego systemu jest na dłuższą metę bardziej korzystne.
Krok 2. Generowanie pliku DACPAC
DACPACs oferują szybką i stosunkowo łatwą metodę przenoszenia kolekcji do usług Azure DevOps Services. Jednak po przekroczeniu określonego progu rozmiaru bazy danych kolekcji, korzyści z używania pakietu DACPAC zaczynają się zmniejszać.
Uwaga
Jeśli narzędzie do migracji danych wyświetli ostrzeżenie, że nie można użyć metody DACPAC, musisz przeprowadzić migrację, korzystając z metody maszyny wirtualnej SQL Azure. Pomiń kroki od 2 do 5 w tym przypadku i postępuj zgodnie z instrukcjami w sekcji Przygotowywanie przebiegu testu, Migrowanie dużych kolekcji, a następnie kontynuuj określanie typu migracji. Jeśli narzędzie do migracji danych nie wyświetli ostrzeżenia, użyj metody DACPAC opisanej w tym kroku.
Pakiet DACPAC to funkcja programu SQL Server, która umożliwia pakowanie baz danych w jednym pliku i wdrażanie ich w innych wystąpieniach programu SQL Server. Plik DACPAC można również przywrócić bezpośrednio do usług Azure DevOps Services, dzięki czemu można go użyć jako metody pakowania do pobierania danych kolekcji w chmurze.
Ważne
- W przypadku korzystania z SqlPackage.exe należy użyć wersji programu .NET Framework SqlPackage.exe, aby przygotować pakiet DACPAC. Instalator MSI musi służyć do instalowania wersji programu .NET Framework SqlPackage.exe. Nie używaj interfejsu wiersza polecenia dotnet ani wersji .zip (Windows .NET 6) SqlPackage.exe, ponieważ te wersje mogą generować pliki DACPAC, które są niezgodne z usługami Azure DevOps.
- Wersja 161 pakietu SqlPackage domyślnie szyfruje połączenia bazy danych i może nie łączyć się. Jeśli wystąpi błąd procesu logowania, dodaj
;Encrypt=False;TrustServerCertificate=Truedo parametrów połączenia instrukcji SqlPackage.
Pobierz i zainstaluj SqlPackage.exe przy użyciu najnowszego instalatora MSI z informacji o wersji pakietu SqlPackage.
Po użyciu Instalatora MSI SqlPackage.exe instaluje się w ścieżce podobnej do %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\.
Podczas generowania pakietu DACPAC należy pamiętać o dwóch kwestiach: dysku, na którym jest zapisywany pakiet DACPAC, oraz miejsce na dysku na maszynie generującej pakiet DACPAC. Chcesz mieć pewność, że masz wystarczającą ilość miejsca na dysku, aby ukończyć operację.
Podczas tworzenia pakietu SqlPackage.exe tymczasowo przechowuje dane z kolekcji w katalogu tymczasowym na dysku C maszyny, z której inicjujesz żądanie pakowania.
Może się okazać, że dysk C jest zbyt mały, aby obsługiwać tworzenie pakietu DACPAC. Ilość potrzebnego miejsca można oszacować, wyszukując największą tabelę w bazie danych kolekcji. DACPACs są tworzone po jednej tabeli na raz. Maksymalna wymagana ilość miejsca do uruchomienia generacji jest w przybliżeniu równoważna rozmiarowi największej tabeli w bazie danych kolekcji. Jeśli zapiszesz wygenerowany pakiet DACPAC na dysku C, rozważ rozmiar bazy danych kolekcji zgodnie z raportem w pliku DataMigrationTool.log z przebiegu weryfikacji.
Plik DataMigrationTool.log zawiera listę największych tabel w kolekcji przy każdym uruchomieniu polecenia. Aby zapoznać się z przykładem rozmiarów tabel dla kolekcji, zobacz następujące dane wyjściowe. Porównaj rozmiar największej tabeli z wolnym miejscem na dysku, który hostuje katalog tymczasowy.
Ważne
Przed kontynuowaniem generowania pliku DACPAC upewnij się, że kolekcja jest odłączona.
[Info @08:23:59.539] Table name Size in MB
[Info @08:23:59.539] dbo.tbl_Content 38984
[Info @08:23:59.539] dbo.tbl_LocalVersion 1935
[Info @08:23:59.539] dbo.tbl_Version 238
[Info @08:23:59.539] dbo.tbl_FileReference 85
[Info @08:23:59.539] dbo.Rules 68
[Info @08:23:59.539] dbo.tbl_FileMetadata 61
Upewnij się, że dysk hostujący katalog tymczasowy ma co najmniej tyle wolnego miejsca. Jeśli tak nie jest, musisz przekierować katalog tymczasowy, ustawiając zmienną środowiskową.
SET TEMP={location on disk}
Innym zagadnieniem jest miejsce zapisania danych DACPAC. Wskazywanie zapisanej lokalizacji na odległym dysku zdalnym może spowodować wydłużenie czasu generowania. Jeśli dysk szybki, taki jak dysk półprzewodnikowy (SSD) jest dostępny lokalnie, zalecamy, aby dysk docelowy był lokalizacją zapisywania DACPAC. W przeciwnym razie zawsze szybsze jest użycie dysku znajdującego się na maszynie, na której znajduje się baza danych kolekcji, a nie dysk zdalny.
Po zidentyfikowaniu lokalizacji docelowej pakietu DACPAC i upewnieniu się, że masz wystarczającą ilość miejsca, nadszedł czas na wygenerowanie pliku DACPAC.
Otwórz okno wiersza polecenia i przejdź do lokalizacji SqlPackage.exe. Aby wygenerować pakiet DACPAC, zastąp wartości zastępcze wymaganymi wartościami, a następnie uruchom następujące polecenie:
SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory
- Źródło danych: instancja SQL Server, która hostuje bazę danych kolekcji usługi Azure DevOps Server.
- Katalog początkowy: nazwa bazy danych kolekcji.
- targetFile: lokalizacja na dysku i nazwa pliku DACPAC.
W poniższym przykładzie pokazano polecenie generacji DACPAC uruchomione w samej warstwie danych usługi Azure DevOps Server:
SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True" /targetFile:C:\DACPAC\Foo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory
Dane wyjściowe polecenia to plik DACPAC wygenerowany z bazy danych kolekcji Foo o nazwie Foo.dacpac.
Konfigurowanie kolekcji na potrzeby migracji
Po przywróceniu bazy danych kolekcji na maszynie wirtualnej platformy Azure skonfiguruj logowanie SQL, aby umożliwić usłudze Azure DevOps Services łączenie się z bazą danych w celu migracji danych. To logowanie umożliwia dostęp tylko do odczytu do pojedynczej bazy danych.
Aby rozpocząć, otwórz program SQL Server Management Studio na maszynie wirtualnej, a następnie otwórz nowe okno zapytania względem bazy danych do zaimportowania.
Ustaw odzyskiwanie bazy danych na proste:
ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;
Utwórz logowanie SQL dla bazy danych i przypisz to logowanie "TFSEXECROLE":
USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'
Zgodnie z naszym przykładem Fabrikam dwa polecenia SQL wyglądają jak w poniższym przykładzie:
ALTER DATABASE [Fabrikam] SET RECOVERY SIMPLE;
USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'
Uwaga
Włącz tryb uwierzytelniania programu SQL Server i systemu Windows w programie SQL Server Management Studio na maszynie wirtualnej. Jeśli nie włączysz trybu uwierzytelniania, migracja zakończy się niepowodzeniem.
Konfiguracja pliku specyfikacji migracji w celu ukierunkowania na maszynę wirtualną
Zaktualizuj plik specyfikacji migracji, aby uwzględnić informacje o sposobie nawiązywania połączenia z wystąpieniem programu SQL Server. Otwórz plik specyfikacji migracji i wprowadź następujące aktualizacje.
Usuń parametr DACPAC z obiektu plików źródłowych.
Specyfikacja migracji przed zmianą jest wyświetlana w poniższym kodzie.
Specyfikacja migracji po zmianie jest wyświetlana w poniższym kodzie.
Wypełnij wymagane parametry i dodaj następujący obiekt właściwości w obiekcie źródłowym w pliku specyfikacji.
"Properties": { "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" }
Po zastosowaniu zmian specyfikacja migracji wygląda jak w poniższym przykładzie.
Specyfikacja migracji jest teraz skonfigurowana do używania maszyny wirtualnej SQL Azure podczas migracji. Wykonaj pozostałe kroki przygotowania do migracji do usług Azure DevOps Services. Po zakończeniu migracji pamiętaj, aby usunąć logowanie SQL lub obrócić hasło. Firma Microsoft nie zachowuje informacji logowania po zakończeniu migracji.
Krok 3. Przekazywanie pliku DACPAC
Uwaga
Jeśli używasz SQL Azure VM, musisz podać tylko ciąg połączenia. Nie musisz przekazywać żadnych plików i możesz pominąć ten krok.
Pakiet DACPAC musi zostać umieszczony w kontenerze usługi Azure Storage, który może być istniejącym kontenerem lub utworzonym specjalnie na potrzeby migracji. Ważne jest, aby upewnić się, że kontener jest tworzony w odpowiednich lokalizacjach geograficznych.
Usługi Azure DevOps Services są dostępne w wielu lokalizacjach geograficznych. Podczas importowania do tych lokalizacji ważne jest prawidłowe umieszczenie danych, aby upewnić się, że migracja może rozpocząć się pomyślnie. Dane muszą być umieszczane w tej samej lokalizacji geograficznej, do której importujesz. Umieszczenie danych w dowolnym innym miejscu powoduje, że nie można uruchomić migracji. Poniższa tabela przedstawia dopuszczalne lokalizacje geograficzne dla tworzenia konta magazynowego i przesyłania danych.
| Żądana lokalizacja geograficzna migracji | Lokalizacja geograficzna konta magazynu |
|---|---|
| Środkowe Stany Zjednoczone | Środkowe Stany Zjednoczone |
| Europa Zachodnia | Europa Zachodnia |
| Zjednoczone Królestwo | Zjednoczone Królestwo, część południowa |
| Australia Wschodnia | Australia Wschodnia |
| Brazylia Południowa | Brazylia Południowa |
| Indie południowe | Indie południowe |
| Kanada Środkowa | Kanada Środkowa |
| Azja i Pacyfik (Singapur) | Azja i Pacyfik (Singapur) |
Mimo że usługi Azure DevOps Services są dostępne w wielu lokalizacjach geograficznych w Stanach Zjednoczonych, tylko lokalizacja Central Stany Zjednoczone akceptuje nowe usługi Azure DevOps Services. W tej chwili nie można migrować danych do innych lokalizacji platformy Azure w Stanach Zjednoczonych.
Utwórz kontener obiektów blob w portalu Azure. Po utworzeniu kontenera, przekaż plik kolekcji DACPAC.
Po zakończeniu migracji usuń kontener obiektów blob i towarzyszące mu konto magazynu przy użyciu narzędzi takich jak AzCopy lub inne narzędzie Eksploratora usługi Azure Storage, takie jak Eksplorator usługi Azure Storage.
Uwaga
Jeśli plik DACPAC jest większy niż 10 GB, zalecamy użycie narzędzia AzCopy, ponieważ obsługuje wielowątkowe przesyłanie w celu szybszego transferu.
Krok 4. Generowanie tokenu SAS
Token sygnatury dostępu współdzielonego (SAS) zapewnia delegowany dostęp do zasobów na koncie magazynu. Token umożliwia firmie Microsoft uzyskanie najniższego poziomu uprawnień wymaganych do uzyskania dostępu do danych w celu przeprowadzenia migracji.
Tokeny SAS można wygenerować przy użyciu witryny Azure Portal. Z punktu widzenia zabezpieczeń zalecamy wykonanie następujących zadań:
- Wybierz Odczyt i Listę jako uprawnienia dla tokenu SAS. Żadne inne uprawnienia nie są wymagane.
- Ustaw czas wygaśnięcia nie później niż siedem dni w przyszłości.
- Ogranicz dostęp tylko do adresów IP usług Azure DevOps Services.
- Traktuj klucz SAS jako tajemnicę. Nie pozostawiaj klucza w niezabezpieczonej lokalizacji, ponieważ przyznaje dostęp do odczytu i przeglądania danych przechowywanych w kontenerze.
Krok 5. Ukończenie specyfikacji migracji
Wcześniej w procesie wypełniono częściowo plik specyfikacji migracji, znany jako migration.json. W tym momencie masz wystarczającą ilość informacji, aby ukończyć wszystkie pozostałe pola z wyjątkiem typu migracji. Typ migracji zostanie omówiony w dalszej części sekcji migracji.
W pliku specyfikacji migration.json w obszarze Źródło wypełnij następujące pola.
- Lokalizacja: Wklej klucz SAS, który wygenerowałeś za pomocą skryptu, a następnie skopiowałeś w poprzednim kroku.
- Dacpac: Upewnij się, że plik, w tym rozszerzenie pliku .dacpac, ma taką samą nazwę jak plik DACPAC przekazany do konta pamięci masowej.
Ostateczny plik specyfikacji migracji powinien wyglądać podobnie do poniższego przykładu.
Określanie typu migracji
Importy mogą być kolejkowane jako przebieg testowy (DryRun) lub przebieg produkcyjny (ProductionRun). Parametr ImportType określa typ migracji:
- Przebieg suchy: nazywany również testowym. Służy do celów testowych i weryfikacji. System usuwa przebieg testu po upływie 45 dni.
- ProductionRun: użyj przebiegu produkcyjnego, jeśli chcesz zachować wynikową migrację i korzystać z organizacji w pełnym wymiarze czasu pracy w usługach Azure DevOps Services po zakończeniu migracji.
Napiwek
Zawsze zalecamy najpierw przeprowadzenie testowej migracji.
Organizacje do przeprowadzania testów
Organizacje przeprowadzające testy pomagają zespołom testować migrację swoich kolekcji. Przed uruchomieniem migracji produkcyjnej należy usunąć organizacje z ukończonymi przebiegami testowymi. Wszystkie organizacje uruchamiane testowo mają ograniczone istnienie i są automatycznie usuwane po upływie określonego czasu. Informacje o tym, kiedy organizacja zostanie usunięta, zostaną uwzględnione w wiadomości e-mail z informacją o powodzeniu, którą należy otrzymać po zakończeniu migracji. Pamiętaj, aby zanotować tę datę i odpowiednio zaplanować.
Organizacje testowe mają 45 dni przed ich usunięciem. Po upływie określonego czasu organizacja przebiegu testowego zostanie usunięta. Przed rozpoczęciem migracji produkcyjnej można powtarzać importowanie przebiegów testowych tyle razy, ile potrzebujesz.
Usuń przebiegi testów
Usuń wszystkie poprzednie przebiegi testu przed podjęciem próby utworzenia nowego. Gdy zespół jest gotowy do przeprowadzenia migracji produkcyjnej, należy ręcznie usunąć organizację uruchamiania testowego. Zanim będzie można uruchomić drugą migrację przebiegu testu lub ostateczną migrację produkcyjną, upewnij się, że usunięto wszystkie poprzednie organizacje usługi Azure DevOps Services utworzone w poprzednim przebiegu testowym. Aby uzyskać więcej informacji, zobacz Usuwanie organizacji.
Napiwek
pl-PL: Opcjonalne informacje mające na celu pomóc użytkownikowi osiągnąć większy sukces. Każda migracja przebiegów testowych następująca po pierwszej powinna zająć więcej czasu ze względu na dodatkowy czas potrzebny na oczyszczenie zasobów z poprzednich przebiegów testowych.
Udostępnienie nazwy organizacji po usunięciu lub zmianie nazwy organizacji może potrwać do jednej godziny. Aby uzyskać więcej informacji, zobacz artykuł Zadania po migracji .
Jeśli wystąpią problemy z migracją, zobacz Rozwiązywanie problemów z migracją i błędami migracji.
Uruchamianie migracji
Twój zespół jest teraz gotowy do rozpoczęcia procesu uruchamiania migracji. Zalecamy rozpoczęcie od pomyślnego wykonania testowej migracji przed podjęciem próby migracji produkcyjnej. W przypadku importowania przebiegów testowych możesz zobaczyć z wyprzedzeniem, jak wygląda migracja, zidentyfikować potencjalne problemy i uzyskać doświadczenie przed rozpoczęciem pracy produkcyjnej.
Uwaga
- Administratorzy platformy Azure mogą uniemożliwić użytkownikom tworzenie nowych organizacji usługi Azure DevOps. Jeśli zasady dzierżawy firmy Microsoft Entra są włączone, migracja nie zostanie ukończona. Przed rozpoczęciem sprawdź, czy zasady nie są ustawione lub czy występuje wyjątek dla użytkownika wykonującego migrację. Aby uzyskać więcej informacji, zobacz Ograniczanie tworzenia organizacji za pomocą polityki dzierżawy Microsoft Entra.
- Usługi Azure DevOps Services nie obsługują zasad przechowywania dla poszczególnych potoków i nie są one przenoszone do wersji hostowanej.
Zagadnienia dotyczące planów wycofywania
Częstym zmartwieniem dla zespołów wykonujących ostateczne wdrożenie produkcyjne jest ich plan cofnięcia zmian, jeśli coś pójdzie nie tak z migracją. Zdecydowanie zalecamy przeprowadzenie testu, aby upewnić się, że możesz przetestować ustawienia migracji podane w narzędziu do migracji danych dla usługi Azure DevOps.
Wycofanie końcowej serii produkcyjnej jest dość proste. Przed kolejką migracji odłącz kolekcję projektów zespołowych od usługi Azure DevOps Server, co sprawia, że jest niedostępna dla członków zespołu. Jeśli z jakiegokolwiek powodu musisz wycofać proces produkcyjny i ponownie uruchomić serwer lokalny dla członków zespołu, możesz to zrobić. Dołącz ponownie kolekcję projektów zespołowych lokalnie i poinformuj zespół, że nadal działają normalnie, podczas gdy zespół przegrupuje się, aby zrozumieć potencjalne błędy.
Następnie możesz skontaktować się z pomocą techniczną usługi Azure DevOps Services, aby uzyskać pomoc w zrozumieniu przyczyny błędu, jeśli nie możesz określić przyczyny. Aby uzyskać więcej informacji, zobacz artykuł Rozwiązywanie problemów. Zgłoszenia pomocy technicznej można otworzyć na poniższej stronie https://aka.ms/AzureDevOpsImportSupport. Jeśli problem wymaga zaangażowania inżynierów grupy produktów, te przypadki są obsługiwane w regularnych godzinach pracy.
Odłącz kolekcję projektów zespołowych od usługi Azure DevOps Server, aby przygotować ją do migracji.
Przed wygenerowaniem kopii zapasowej bazy danych SQL należy całkowicie odłączyć kolekcję od serwera Azure DevOps (a nie SQL) przy użyciu Narzędzia do Migracji Danych. Proces odłączania w usłudze Azure DevOps Server przenosi informacje o tożsamości użytkownika, które są przechowywane poza bazą danych kolekcji, co umożliwia ich przeniesienie na nowy serwer lub, w tym przypadku, do Azure DevOps Services.
Odłączanie kolekcji można łatwo wykonać z poziomu konsoli administracyjnej serwera Usługi Azure DevOps w wystąpieniu serwera Usługi Azure DevOps. Aby uzyskać więcej informacji, zobacz Przenoszenie kolekcji projektów, Odłącz kolekcję.
Kolejkowanie migracji
Ważne
Przed kontynuowaniem upewnij się, że kolekcja została odłączona przed wygenerowaniem pliku DACPAC lub przekazaniem bazy danych kolekcji do maszyny wirtualnej SQL Azure. Jeśli ten krok nie zostanie ukończony, migracja zakończy się niepowodzeniem. Jeśli migracja nie powiedzie się, zobacz Rozwiązywanie błędów migracji.
Rozpocznij migrację przy użyciu polecenia import narzędzia do migracji danych. Polecenie importu przyjmuje plik specyfikacji migracji jako dane wejściowe. Analizuje on plik, aby upewnić się, że podane wartości są prawidłowe i, jeśli się powiedzie, kolejkuje migrację do usług Azure DevOps Services. Polecenie importu wymaga połączenia z internetem, ale nie wymaga połączenia z instancją usługi Azure DevOps Server.
Aby rozpocząć, otwórz okno wiersza polecenia i zmień katalogi na ścieżkę do narzędzia do migracji danych. Zalecamy przejrzenie tekstu pomocy dostarczonego z narzędziem. Uruchom następujące polecenie, aby wyświetlić wskazówki i pomoc dotyczącą polecenia importowania:
Migrator import /help
Polecenie kolejkowania migracji ma następującą strukturę:
Migrator import /importFile:{location of migration specification file}
W poniższym przykładzie pokazano ukończone polecenie importu:
Migrator import /importFile:C:\DataMigrationToolFiles\migration.json
Po pomyślnym zakończeniu walidacji, zaloguj się do Microsoft Entra ID używając tożsamości, która jest członkiem tej samej dzierżawy Microsoft Entra, względem której został utworzony plik dziennika mapy tożsamości. Zalogowany użytkownik jest właścicielem zaimportowanej organizacji.
Uwaga
Każda dzierżawa Microsoft Entra jest ograniczona do pięciu importów w ciągu 24 godzin. Tylko importy, które są w kolejce, wliczają się do tego limitu.
Gdy twój zespół inicjuje migrację, do użytkownika, który w kolejce migracji, zostanie wysłane powiadomienie e-mail. Około 5 do 10 minut po dodaniu migracji do kolejki, zespół może udać się do siedziby organizacji, aby sprawdzić status. Po zakończeniu migracji twój zespół jest kierowany do logowania, a powiadomienie e-mail jest wysyłane do właściciela organizacji.
Narzędzie do migracji danych flaguje błędy, które należy poprawić przed migracją. W tym artykule opisano najbardziej typowe ostrzeżenia i błędy, które mogą wystąpić podczas przygotowywania do migracji. Po skorygowaniu każdego błędu ponownie uruchom polecenie migrator validate, aby sprawdzić rozwiązanie.