Procesy walidacji i importowania

  • Artykuł

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

W tym artykule przedstawiono przygotowanie wymagane do zaimportowania do usług Azure DevOps Services gotowych do uruchomienia. Jeśli podczas procesu wystąpią błędy, zobacz Rozwiązywanie problemów z błędami importowania i migracji.

Wymagania wstępne

  • Należy skonfigurować dzierżawę usługi Microsoft Entra zgodnie z opisem w temacie Microsoft Entra Połączenie Sync: wprowadź zmianę domyślnej konfiguracji. Narzędzie do migracji danych konfiguruje link do dzierżawy firmy Microsoft Entra po utworzeniu organizacji usługi Azure DevOps Services w ramach początku procesu importowania. Podczas synchronizowania lokalna usługa Active Directory z identyfikatorem Entra firmy Microsoft członkowie zespołu mogą używać tych samych poświadczeń do uwierzytelniania, a administratorzy usługi Azure DevOps Services mogą używać grup usługi Active Directory do ustawiania uprawnień w organizacji usług Azure DevOps Services. Aby skonfigurować synchronizację, użyj technologii Microsoft Entra Połączenie.
  • Przed rozpoczęciem zadań importowania sprawdź, czy korzystasz z obsługiwanej wersji serwera Azure DevOps Server.
  • Zalecamy użycie przewodnika migracji krok po kroku, aby przejść przez proces importowania. Przewodnik zawiera linki do dokumentacji technicznej, narzędzi i najlepszych rozwiązań.

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.

  1. Pobieranie narzędzia

  2. Kopiowanie pliku zip do jednej z warstw aplikacji usługi Azure DevOps Server

  3. 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.

  4. 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śmiń 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 /help

    b. Wyświetl tekst pomocy dla polecenia:

     Migrator validate /help

  5. Podczas pierwszego sprawdzania poprawności kolekcji zachowajmy prostotę. Polecenie powinno mieć następującą strukturę:

     Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}

    Gdzie {name} podaje nazwę dzierżawy firmy Microsoft Entra, na przykład do uruchamiania względem kolekcji DefaultCollection i dzierżawy fabrikam , polecenie będzie wyglądać następująco:

     Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}

  6. Aby uruchomić narzędzie z maszyny innej niż usługa Azure DevOps Server, potrzebny jest parametr /connectionString . Parametr parametry połączenia wskazuje bazę danych konfiguracji usługi Azure DevOps Server. Jeśli na przykład zweryfikowane polecenie jest uruchamiane przez firmę Fabrikam, polecenie 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.

  7. Po zakończeniu walidacji można wyświetlić pliki dziennika i wyniki.

    Zrzut ekranu przedstawiający wyniki weryfikacji i dzienniki w oknie wiersza polecenia.

    Podczas walidacji zostanie wyświetlone ostrzeżenie, jeśli niektóre potoki zawierają reguły przechowywania dla potoku. Usługa Azure DevOps Services używa modelu przechowywania opartego na projekcie i nie obsługuje zasad przechowywania potoku. 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 importowania. Jeśli narzędzie do migracji danych flaguje błędy, przed kontynuowaniem popraw je. Aby uzyskać wskazówki dotyczące poprawiania błędów walidacji, zobacz Rozwiązywanie problemów z błędami importowania i 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 zaimportować procesy 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.

Generowanie plików importu

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 importu. Po uruchomieniu prepare polecenia wygenerujesz dwa pliki importu:

  • IdentityMapLog.csv: przedstawia mapę tożsamości między usługą Active Directory i identyfikatorem Entra firmy Microsoft.
  • import.json: wymaga wypełnienia specyfikacji importu, której chcesz użyć do rozpoczęcia migracji.

Polecenie Prepare

Polecenie prepare pomaga wygenerować wymagane pliki importu. 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 Połączenie (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 importu, import.json, należy wypełnić przed importem.

validate W przeciwieństwie do polecenia wymaga połączenia internetowego, prepareponieważ musi nawiązać połączenie z identyfikatorem Entra firmy Microsoft, 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 intranetowym połączeniem z wystąpieniem usługi 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 Migrator polecenia z poziomu samego wystąpienia usługi Azure DevOps Server i maszyny zdalnej. Jeśli uruchamiasz polecenie z jednej z warstw aplikacji wystąpienia usługi Azure DevOps Server, polecenie powinno mieć następującą 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 bazy danych konfiguracji 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 importu.

Wkrótce po uruchomieniu polecenia zostanie wyświetlone okno logowania microsoft Entra. Zaloguj się przy użyciu tożsamości należącej do domeny dzierżawy określonej w poleceniu . Upewnij się, że określona dzierżawa firmy Microsoft Entra jest dzierżawą, z którą chcesz wspierać przyszłą organizację. 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 na potrzeby importu testowego i produkcyjnej dzierżawy firmy Microsoft Entra na potrzeby przebiegu produkcyjnego. Użycie testowej dzierżawy firmy Microsoft Entra może spowodować problemy z importowaniem tożsamości po rozpoczęciu pracy produkcyjnej z produkcyjną dzierżawą firmy Microsoft Entra w organizacji.

Po pomyślnym uruchomieniu polecenia w narzędziu prepare do migracji danych w oknie wyników zostanie wyświetlony zestaw dzienników i dwa pliki importu. W katalogu dziennika znajdź folder logs i dwa pliki:

  • import.json to plik specyfikacji importu. Zalecamy, aby pośminąć trochę czasu, aby go wypełnić.
  • IdentityMapLog.csv zawiera wygenerowane mapowanie usługi Active Directory na tożsamości firmy Microsoft Entra. Przejrzyj go pod kątem kompletności przed rozpoczęciem importowania.

Dwa pliki zostały szczegółowo opisane w następnych sekcjach.

Plik specyfikacji importu

Specyfikacja importu, import.json, jest plikiem JSON, który udostępnia ustawienia importu. Zawiera ona odpowiednią 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 zaimportowania.

Zrzut ekranu przedstawiający nowo wygenerowany plik specyfikacji importu.

Wyświetlane pola pliku import.json i wymagane akcje są 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 importowania. 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 importu. 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 importowania. 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 zaimportowania. 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 importowania. Podaj nazwę. Nazwę można szybko zmienić później po zakończeniu importowania.
UWAGA: nie twórz organizacji o tej nazwie przed uruchomieniem importu. Organizacja jest tworzona w ramach procesu importowania.
Typ importu Typ importu, który chcesz uruchomić. Nie musisz wykonywać żadnej akcji. W późniejszym kroku wybierz typ importu do uruchomienia.
Dane weryfikacji Informacje potrzebne do ułatwienia obsługi importu. Narzędzie do migracji danych generuje sekcję "ValidationData". Zawiera informacje ułatwiające obsługę importowania. Nie* edytuj wartości w tej sekcji lub importowanie może zakończyć się niepowodzeniem.

Po zakończeniu poprzedniego procesu powinien istnieć plik, który wygląda jak w poniższym przykładzie.

Zrzut ekranu przedstawiający częściowo ukończony plik specyfikacji importu.

Na poprzedniej ilustracji planista importu firmy Fabrikam dodał nazwę organizacji fabrikam-import i wybraną pozycję CUS (Central Stany Zjednoczone) jako lokalizację geograficzną do zaimportowania. Pozostały inne wartości, ponieważ mają zostać zmodyfikowane tuż przed przełączenie kolekcji do trybu offline przez planistę na potrzeby migracji.

Uwaga

Importy w trybie suchym mają automatycznie dołączany ciąg "-dryrun" na końcu nazwy organizacji, którą można zmienić po zaimportowaniu.

Obsługiwane lokalizacje geograficzne platformy Azure do importowania

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 do importowania. W poniższej tabeli wymieniono lokalizacje geograficzne platformy Azure, które można wybrać do zaimportowania. Uwzględniona jest również wartość, którą należy umieścić w pliku specyfikacji importu w celu określenia lokalizacji geograficznej na potrzeby importu.

Lokalizacja geograficzna Lokalizacja geograficzna platformy Azure Wartość specyfikacji importu
Stany Zjednoczone Środkowe Stany Zjednoczone CUS
Europa Europa Zachodnia UZE
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 równe znaczenie dla rzeczywistych danych migrowanych do usług Azure DevOps Services. Podczas przeglądania pliku ważne jest, aby zrozumieć, jak działa importowanie tożsamości i jakie mogą być potencjalne wyniki. Podczas importowania tożsamości może ona 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

Aktywne tożsamości odnoszą się do tożsamości użytkowników w usłudze Azure DevOps Services po zaimportowaniu. W usłudze Azure DevOps Services te tożsamości 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 Oczekiwany stan importu w pliku dziennika mapy tożsamości. Tożsamości bez wpisu wiersza w pliku również stają się historyczne. Przykładem tożsamości bez wpisu wiersza 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 wyświetlaj się jako użytkownicy w organizacji. Wszystko, co się utrzymuje, to pojęcie nazwy tej tożsamości w organizacji, dzięki czemu jej historia może być przeszukiwana 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:

Zrzut ekranu przedstawiający plik dziennika mapy tożsamości generowany przez narzędzie do migracji danych.

Kolumny w pliku dziennika mapy tożsamości zostały opisane w poniższej tabeli:

Ty i Twój administrator firmy Microsoft Entra muszą zbadać użytkowników oznaczonych jako Nie znaleziono dopasowania (sprawdź microsoft Entra ID Sync), aby zrozumieć, dlaczego nie są one częścią usługi Microsoft Entra Połączenie 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 tożsamości lokalna usługa Active Directory 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 dopasowanego wkrótce do aktywnego użytkownika lub Nie znaleziono dopasowania (Sprawdź synchronizację identyfikatorów entra firmy Microsoft) wskazujący, że tożsamość nie została znaleziona podczas synchronizacji identyfikatorów entra firmy Microsoft i jest importowana jako historyczna.
Oczekiwany stan importu Oczekiwany stan importowania użytkownika: Aktywny, jeśli istnieje dopasowanie między usługą Active Directory i identyfikatorem Entra firmy Microsoft, lub wartość historyczna, 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. Aktywny wskazuje, że tożsamość w tym wierszu mapuje się poprawnie podczas importowania, staje się aktywna. Historyczne oznacza, że tożsamości stają się historyczne podczas importowania. Ważne jest, aby przejrzeć wygenerowany plik mapowania pod kątem kompletności i poprawności.

Ważne

Importowanie nie powiedzie się, jeśli wystąpią poważne zmiany w usłudze Microsoft Entra Połączenie synchronizacji identyfikatora zabezpieczeń między próbami importu. Możesz dodać nowych użytkowników między przebiegami suchymi i wprowadzić poprawki, aby upewnić się, że wcześniej zaimportowane tożsamości historyczne stają się aktywne. Jednak zmiana istniejącego użytkownika, który został wcześniej zaimportowany jako aktywny, nie jest obecnie obsługiwana. W ten sposób importowanie zakończy się niepowodzeniem. Przykładem zmiany może być ukończenie importowania w trybie suchym, usunięcie tożsamości z identyfikatora Entra firmy Microsoft zaimportowanego aktywnie, ponowne utworzenie nowego użytkownika w identyfikatorze Entra firmy Microsoft dla tej samej tożsamości, a następnie próba zaimportowania innego. W takim przypadku aktywna tożsamość próbuje zaimportować między usługą Active Directory i nowo utworzoną tożsamością firmy Microsoft Entra, ale powoduje niepowodzenie importowania.

  1. Przejrzyj prawidłowo dopasowane tożsamości. Czy są obecne wszystkie oczekiwane tożsamości? Czy użytkownicy są mapowane na poprawną tożsamość firmy Microsoft Entra?

    Jeśli należy zmienić jakiekolwiek wartości, skontaktuj się z administratorem firmy Microsoft Entra, aby sprawdzić, czy tożsamość lokalna usługa Active Directory jest częścią synchronizacji z identyfikatorem Entra firmy Microsoft i została prawidłowo skonfigurowana. Aby uzyskać więcej informacji, zobacz Integrowanie tożsamości lokalnych z identyfikatorem Entra firmy Microsoft.

  2. 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 lokalna usługa Active Directory i identyfikatorem Entra firmy Microsoft.
    • Tożsamość nie jest jeszcze wypełniana w identyfikatorze Entra firmy Microsoft (na przykład jest to nowy pracownik).
    • Tożsamość nie istnieje w wystąpieniu firmy 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ść lokalna usługa Active Directory do synchronizacji z identyfikatorem Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz Integrowanie tożsamości lokalnych z identyfikatorem Entra firmy Microsoft. Musisz skonfigurować i uruchomić Połączenie firmy Microsoft, 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

Strategia importowania tożsamości proponowana w tej sekcji powinna być uwzględniana tylko przez małe zespoły.

Jeśli Połączenie microsoft Entra nie jest skonfigurowana, wszyscy użytkownicy w pliku dziennika mapy tożsamości są oznaczani jako historyczne. Uruchomienie importu w ten sposób powoduje zaimportowanie wszystkich użytkowników jako historycznych. Zdecydowanie zalecamy skonfigurowanie Połączenie firmy Microsoft w celu zapewnienia, że użytkownicy są zaimportowani jako aktywni.

Uruchomienie importu 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 usługi Microsoft Entra Połączenie jest zbyt wysoki.

Aby zaimportować wszystkie tożsamości jako historyczne, wykonaj kroki opisane w kolejnych sekcjach. Podczas kolejki importowania tożsamość używana do kolejki importu jest uruchamiana w organizacji jako właściciel organizacji. Wszyscy inni użytkownicy są importowane jako historyczne. 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 są właścicielami żadnej z ich historii i nie ma możliwości ponownego ponownego użycia tej historii w tożsamości Firmy Microsoft Entra. Jednak użytkownicy nadal mogą wyszukiwać historię preimportu, wyszukując nazwę <użytkownika> usługi Active Directory domeny><.

Narzędzie do migracji danych wyświetla ostrzeżenie, jeśli wykryje kompletny scenariusz tożsamości historycznych. Jeśli zdecydujesz się przejść w dół tej ścieżki migracji, musisz wyrazić zgodę w narzędziu 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 zaimportowaniu. 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 zaimportowaniu. Nigdy nie są naliczane opłaty za licencje przypisane podczas importowania, więc możesz bezpiecznie obsługiwać subskrypcje później.

Nie musisz powtarzać importowania próbnego, jeśli subskrypcje programu Visual Studio użytkowników nie są automatycznie uaktualniane w usługach Azure DevOps Services. Łączenie subskrypcji programu Visual Studio odbywa się poza zakresem importowania. Jeśli konto służbowe jest poprawnie połączone przed lub po zaimportowaniu, licencje użytkowników zostaną automatycznie uaktualnione podczas następnego logowania. Po pomyślnym uaktualnieniu licencji przy następnym uruchomieniu importu użytkownicy zostaną automatycznie uaktualnieni podczas pierwszego logowania do organizacji.

Przygotowywanie do importowania

Teraz wszystko jest gotowe do wykonania podczas importowania. Zaplanuj przestój z zespołem, aby przejąć kolekcję w tryb offline na potrzeby migracji. Po zaakceptowaniu czasu uruchomienia importu przekaż wygenerowane wymagane zasoby i kopię bazy danych na platformę Azure. Przygotowanie do importowania składa się z następujących pięciu kroków.

Krok 1. Przełącz kolekcję w tryb offline i odłącz ją.

Limit rozmiaru kolekcji dla metody DACPAC wynosi 150 GB. Jeśli narzędzie do migracji danych wyświetli ostrzeżenie, że nie można użyć metody DACPAC, musisz wykonać importowanie przy użyciu metody Usługi SQL Azure maszyny wirtualnej. Pomiń kroki od 2 do 5 w tym przypadku i postępuj zgodnie z instrukcjami podanymi w sekcji Importowanie dużych kolekcji , a następnie kontynuuj określanie typu importu.

Krok 2. Generowanie pliku DACPAC z kolekcji, którą zamierzasz zaimportować.
Krok 3. Przekaż plik DACPAC i zaimportuj pliki do konta usługi Azure Storage.
Krok 4. Generowanie tokenu SAS w celu uzyskania dostępu do konta magazynu.
Krok 5. Ukończenie specyfikacji importu.

Uwaga

Przed przeprowadzeniem importu produkcyjnego zdecydowanie zalecamy ukończenie importowania próbnego. Po uruchomieniu suchym można sprawdzić, czy proces importowania działa dla kolekcji i czy nie ma żadnych unikatowych kształtów danych, które mogą spowodować niepowodzenie importu produkcyjnego.

Krok 1. Odłączanie kolekcji

Odłączanie kolekcji jest kluczowym krokiem w procesie importowania. Dane tożsamości dla kolekcji znajdują się w bazie danych konfiguracji wystąpienia usługi Azure DevOps Server, gdy kolekcja jest dołączona i w trybie 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 można wykonać części tożsamości importu. Zalecamy, aby kolekcja była odłączona do momentu zakończenia importowania, ponieważ nie ma możliwości importowania zmian, które wystąpiły podczas importowania.

W przypadku importowania próbnego (testowego) zalecamy ponowne dołączenia kolekcji po utworzeniu kopii zapasowej w celu zaimportowania, więc nie martwisz się o posiadanie najnowszych danych dla tego typu importu. Aby całkowicie uniknąć czasu offline, możesz również użyć odłączenia w trybie offline na potrzeby przebiegów suchych.

Ważne jest, aby rozważyć koszt wyboru, aby spowodować zerowy przestój w przypadku suchego przebiegu. 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 udowodnić, że wykonanie bezpośrednio odłączonej kopii zapasowej zajmuje zaledwie kilka godzin.

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 rozmiar bazy danych kolekcji korzyści wynikające 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 wykonać importowanie przy użyciu metody Usługi SQL Azure maszyny wirtualnej podanej w temacie Importowanie dużych kolekcji.

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 .zip (Windows .NET 6) wersji SqlPackage.exe, ponieważ te wersje mogą generować DACPACs niezgodne z usługą Azure DevOps Services.
  • 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=True do parametry 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 pojedynczo jedną tabelę. 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 lokalizacji zapisywania 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 symbolu zastępczego 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: wystąpienie programu SQL Server, które 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 importowania

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 zaimportowania 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 [Foo] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Uwaga

Pamiętaj, aby włączyć tryb uwierzytelniania programu SQL Server i systemu Windows w programie SQL Server Management Studio na maszynie wirtualnej. Jeśli nie włączysz trybu uwierzytelniania, importowanie zakończy się niepowodzeniem.

Konfigurowanie pliku specyfikacji importu w celu kierowania maszyny wirtualnej

Zaktualizuj plik specyfikacji importu, aby uwzględnić informacje o sposobie nawiązywania połączenia z wystąpieniem programu SQL Server. Otwórz plik specyfikacji importu i wprowadź następujące aktualizacje.

  1. Usuń parametr DACPAC z obiektu plików źródłowych.

    Specyfikacja importu przed zmianą jest wyświetlana w poniższym kodzie.

    Zrzut ekranu przedstawiający specyfikację importu przed zmianą.

    Specyfikacja importu po zmianie jest wyświetlana w poniższym kodzie.

    Zrzut ekranu przedstawiający specyfikację importu po zmianie.

  2. 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 importu wygląda jak w poniższym przykładzie.

Zrzut ekranu przedstawiający specyfikację importu odwołującą się do maszyny wirtualnej Usługi SQL Azure.

Specyfikacja importu jest teraz skonfigurowana do używania maszyny wirtualnej Usługi SQL Azure do importowania. Wykonaj pozostałe kroki przygotowywania, aby zaimportować je do usług Azure DevOps Services. Po zakończeniu importowania pamiętaj, aby usunąć logowanie SQL lub obrócić hasło. Firma Microsoft nie zachowuje informacji logowania po zakończeniu importowania.

Krok 3. Przekazywanie pliku DACPAC

Uwaga

Jeśli używasz metody maszyny wirtualnej Usługi SQL Azure, musisz podać tylko parametry 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 w celu upewnienia się, że importowanie 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ć importu. W poniższej tabeli wymieniono dopuszczalne lokalizacje geograficzne służące do tworzenia konta magazynu i przekazywania danych.

Żądana lokalizacja geograficzna importu 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. Obecnie nie można zaimportować danych do innych lokalizacji platformy Azure w Stanach Zjednoczonych.

Kontener obiektów blob można utworzyć w witrynie Azure Portal. Po utworzeniu kontenera przekaż plik DACPAC kolekcji.

Po zakończeniu importowania usuń kontener obiektów blob i towarzyszące mu konto magazynu przy użyciu narzędzi, takich jak Narzędzie 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. Narzędzie AzCopy ma obsługę przekazywania wielowątkowego w celu szybszego przekazywania.

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 wykonania importu.

Tokeny SAS można wygenerować przy użyciu witryny Azure Portal. Z punktu widzenia zabezpieczeń zalecamy:

  1. Wybierz pozycję Tylko odczyt i lista jako uprawnienia dla tokenu SAS. Żadne inne uprawnienia nie są wymagane.
  2. Ustaw czas wygaśnięcia nie dalej niż siedem dni w przyszłości.
  3. Ogranicz dostęp tylko do adresów IP usług Azure DevOps Services.
  4. Umieść token SAS w bezpiecznej lokalizacji.

Krok 5. Ukończenie specyfikacji importu

Wcześniej w procesie wypełniono częściowo plik specyfikacji importu, znany jako import.json. W tym momencie masz wystarczającą ilość informacji, aby ukończyć wszystkie pozostałe pola z wyjątkiem typu importu. Typ importu zostanie omówiony później w sekcji importowania.

W pliku specyfikacji import.json w obszarze Źródło wypełnij następujące pola.

  • Lokalizacja: wklej klucz SYGNATURy dostępu współdzielonego wygenerowany na podstawie skryptu, a następnie skopiowany w poprzednim kroku.
  • Dacpac: upewnij się, że plik, w tym rozszerzenie pliku dacpac , ma taką samą nazwę jak plik DACPAC przekazany do konta magazynu.

Ostateczny plik specyfikacji importu powinien wyglądać podobnie do poniższego przykładu.

Zrzut ekranu przedstawiający ukończony plik specyfikacji importu.

Ograniczanie dostępu tylko do adresów IP usługi Azure DevOps Services

Aby uzyskać więcej informacji, zobacz Ograniczanie dostępu tylko do adresów IP usług Azure DevOps Services.

Opcja 1. Używanie tagów usługi

Możesz łatwo zezwolić na połączenia ze wszystkich lokalizacji geograficznych usługi Azure DevOps Services, dodając azuredevopstag usługi do sieciowych grup zabezpieczeń lub zapór za pośrednictwem portalu lub programowo.

Opcja 2. Korzystanie z listy IpList

IpList Użyj polecenia , aby uzyskać listę adresów IP, którym należy udzielić dostępu, aby zezwolić na połączenia z określonej lokalizacji geograficznej usługi Azure DevOps Services.

W dokumentacji pomocy znajdują się instrukcje i przykłady uruchamiania narzędzia Migrator z samego wystąpienia usługi Azure DevOps Server i maszyny zdalnej. Jeśli uruchamiasz polecenie z jednej z warstw aplikacji wystąpienia usługi Azure DevOps Server, polecenie powinno mieć następującą strukturę:

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

Listę adresów IP można dodać do sieciowych grup zabezpieczeń lub zapór za pośrednictwem portalu lub programowo.

Określanie typu importu

Importy można kolejkować jako przebieg suchy lub uruchomienie produkcyjne. Parametr ImportType określa typ importu:

  • DryRun: użyj suchego przebiegu do celów testowych. System usuwa suche przebiegi po 21 dniach.
  • ProductionRun: użyj przebiegu produkcyjnego, jeśli chcesz zachować wynikowy import i używać organizacji w pełnym wymiarze godzin w usługach Azure DevOps Services po zakończeniu importowania.

Napiwek

Zawsze zalecamy najpierw ukończenie importowania w trybie suchym.

Ukończono plik specyfikacji importu z typem importu

Organizacje działające w trybie suchym

Importowanie w trybie suchym pomaga zespołom testować migrację swoich kolekcji. Oczekuje się, że organizacje nie pozostaną na zawsze, ale będą istnieć przez krótki czas. W rzeczywistości przed rozpoczęciem migracji produkcyjnej należy usunąć wszystkie ukończone organizacje działające w trybie suchym. Wszystkie organizacje działające w trybie suchym 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óra powinna zostać odebrana po zakończeniu importowania. Pamiętaj, aby zanotować tę datę i odpowiednio zaplanować.

Większość suchych organizacji ma 15 dni przed usunięciem. Organizacje działające w trybie suchym mogą również mieć 21-dniowe wygaśnięcie, jeśli więcej niż 100 użytkowników ma podstawową lub większą licencję w czasie importowania. Po upływie określonego czasu organizacja suchego uruchomienia zostanie usunięta. Przed rozpoczęciem migracji produkcyjnej można powtarzać importowanie w trybie suchym tyle razy, ile potrzebujesz. Przed podjęciem próby wykonania nowej próby należy usunąć wszystkie poprzednie przebiegi suche. Gdy zespół jest gotowy do przeprowadzenia migracji produkcyjnej, należy ręcznie usunąć organizację z systemem suchym.

Aby uzyskać więcej informacji na temat działań po zaimportowaniu, zobacz artykuł po zaimportowaniu.

Jeśli wystąpią problemy z importowaniem, zobacz Rozwiązywanie problemów z importowaniem i migracją.

Uruchamianie importu

Twój zespół jest teraz gotowy do rozpoczęcia procesu uruchamiania importu. Zalecamy rozpoczęcie od pomyślnego importu w trybie suchym przed podjęciem próby zaimportowania do środowiska produkcyjnego. Podczas importowania próbnego można zobaczyć z wyprzedzeniem, jak wygląda importowanie, identyfikowanie potencjalnych problemów i uzyskiwanie doświadczenia przed rozpoczęciem pracy produkcyjnej.

Uwaga

  • Jeśli musisz powtórzyć ukończony import w środowisku produkcyjnym dla kolekcji, tak jak w przypadku wycofania, skontaktuj się z pomocą techniczną usługi Azure DevOps Services przed utworzeniem kolejnej kolejki importu.
  • 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, importowanie nie powiedzie się. 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 pośrednictwem zasad dzierżawy firmy Microsoft Entra.
  • Usługi Azure DevOps Services nie obsługują zasad przechowywania potoku i nie są przenoszone do hostowanej wersji.

Zagadnienia dotyczące planów wycofywania

Typowym problemem dla zespołów wykonujących końcowy przebieg produkcji jest ich plan wycofywania, jeśli coś pójdzie nie tak z importem. Zdecydowanie zalecamy przeprowadzenie suchego przebiegu, aby upewnić się, że możesz przetestować ustawienia importu podane w narzędziu do migracji danych dla usługi Azure DevOps.

Wycofanie końcowego przebiegu produkcyjnego jest dość proste. Przed kolejką importu należy odłączyć 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ć przebieg produkcyjny i przywrócić serwer lokalny do trybu online 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.

Kolejka importu

Ważne

Przed kontynuowaniem upewnij się, że kolekcja została odłączona przed wygenerowaniem pliku DACPAC lub przekazaniem bazy danych kolekcji do maszyny wirtualnej Usługi SQL Azure. Jeśli ten krok nie zostanie ukończony, importowanie zakończy się niepowodzeniem. W przypadku niepowodzenia importowania zobacz Rozwiązywanie problemów z błędami importowania i migracji.

Rozpocznij importowanie przy użyciu polecenia importowania narzędzia do migracji danych. Polecenie importu przyjmuje plik specyfikacji importu jako dane wejściowe. Analizuje plik, aby upewnić się, że podane wartości są prawidłowe i, jeśli się powiedzie, kolejkuje import do usług Azure DevOps Services. Polecenie importu wymaga połączenia internetowego, ale nie* wymaga połączenia z wystąpieniem 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 importu ma następującą strukturę:

Migrator import /importFile:{location of import specification file}

W poniższym przykładzie pokazano ukończone polecenie importu:

Migrator import /importFile:C:\DataMigrationToolFiles\import.json

Po zakończeniu walidacji zostanie wyświetlony monit o zalogowanie się do identyfikatora Entra firmy Microsoft. Ważne jest, aby zalogować się przy użyciu tożsamości, która jest członkiem tej samej dzierżawy firmy Microsoft Entra, co plik dziennika mapy tożsamości został skompilowany. Zalogowany użytkownik jest właścicielem zaimportowanej organizacji.

Uwaga

Każda dzierżawa firmy Microsoft Entra jest ograniczona do pięciu importów na okres 24-godzinny. Tylko importy, które są liczone w kolejce względem tego limitu.

Gdy twój zespół inicjuje importowanie, do użytkownika, który kolejkował import, zostanie wysłane powiadomienie e-mail. Około 5 do 10 minut po zakończeniu kolejki importu zespół może przejść do organizacji, aby sprawdzić stan. Po zakończeniu importowania zespół jest kierowany do logowania, a powiadomienie e-mail jest wysyłane do właściciela organizacji.