Udostępnij za pośrednictwem

Weryfikowanie i przygotowywanie środowiska serwera do migracji

  • Artykuł

Walidacja obejmuje przygotowanie uaktualnionego środowiska usługi Azure DevOps Server do migracji. Ten artykuł ułatwia rozwiązywanie typowych problemów. Jeśli nie wystąpiły żadne błędy i wszystkie testy weryfikacyjne zostały pomyślnie pomyślnie przekazane, kolekcja projektów zespołowych jest gotowa i możesz przejść do następnej fazy. Przejrzyj pliki dziennika, aby znaleźć błędy, jeśli nie wszystkie testy zostały przekazane.

Diagram przedstawiający wyróżniony Etap weryfikacji siedmiu etapów migracji.

Wymagania wstępne

Pobierz najnowsze narzędzie do migracji danych.

Typy weryfikacji procesów platformy Learn

Podczas walidacji narzędzie do migracji danych określa docelowy model procesu dla każdego projektu. Automatycznie przypisuje jeden z następujących dwóch modeli procesów do każdego projektu w kolekcji:

  • Model procesów dziedziczonych: jeśli projekt został utworzony przy użyciu szablonu procesu Agile, Scrum lub Capability Maturity Model Integration (CMMI) i nigdy nie został dostosowany.
  • Hostowany model procesu XML: jeśli proces projektu wydaje się być dostosowany. Dostosowany proces zawiera pola niestandardowe, typy elementów roboczych lub inne typy dostosowań.

Gdy hostowany proces XML jest docelowym modelem procesów, narzędzie do migracji danych sprawdza, czy można migrować dostosowania. Narzędzie do migracji danych generuje dwa pliki podczas walidacji:

  • DataMigrationTool.log: zawiera zestaw błędów weryfikacji procesu znalezionych w kolekcji. Napraw wszystkie błędy procesu, które znaleziono, aby kontynuować migrację.
  • TryMatchOobProcesses.log: Wyświetla listę dla każdego projektu docelowy model procesu — dziedziczenie lub hostowany kod XML. W przypadku projektów ustawionych na docelowy model procesów Hostowany XML wyjaśniono, dlaczego są one uważane za dostosowane. Nie musisz usuwać tych błędów, ale zawierają wskazówki dotyczące tego, co należy zrobić w przypadku migracji do modelu procesu dziedziczenia. Po przeprowadzeniu migracji kolekcji można zmigrować projekt do modelu procesu Dziedziczenie.

Weryfikowanie kolekcji projektów zespołowych

Ponieważ każda kolekcja projektów zespołowych odpowiada własnej bazie danych SQL, proces weryfikacji sprawdza różne aspekty kolekcji, w tym:

  • Rozmiar bazy danych kolekcji
  • Sortowanie bazy danych SQL
  • Tożsamości użytkowników w kolekcji
  • Dostosowania szablonu (proces)

Aby rozpocząć walidację, użyj narzędzia migracji. Zalecamy uruchomienie narzędzia migracji z jednego z serwerów warstwy aplikacji (AT) w środowisku usługi Azure DevOps Server.

W przypadku określonych opcji wiersza polecenia zażądaj tekstu pomocy przy użyciu następującego polecenia:

	Migrator validate /help

Najczęstszym sposobem rozpoczęcia walidacji jest określenie adresu URL kolekcji projektów zespołowych z następującą strukturą:

	Migrator validate /collection:http://localhost:8080/tfs/DefaultCollection

Wyświetlanie ostrzeżeń i błędów walidacji

Po zakończeniu procesu migracji program generuje pliki dziennika i wyniki wyświetlane na ekranie wiersza polecenia. Jeśli nie wystąpią żadne błędy i wszystkie testy poprawności zostaną pomyślnie wykonane, kolekcja projektów zespołowych jest gotowa do następnej fazy. W przypadku niepowodzenia sprawdzania poprawności przejrzyj pliki dziennika, aby zidentyfikować błędy, a następnie je rozwiązać.

Skoncentruj Migrator.log się na pliku, który zawiera podstawowe informacje o sprawdzaniu poprawności i pomaga zachować dostosowywanie. Inne pliki odpowiadają określonym błędom walidacji na podstawie ich nazw. Wyszukaj ciąg "Validation — Starting validation of project 1" (Walidacja — rozpoczynanie walidacji projektu 1). Każdy projekt jest weryfikowany. Przeskanuj wszystkie projekty i wyszukaj wszystkie wiersze zawierające prefiks [Error...

TryMatchOobProcesses.log Ponadto lista błędów związanych z projektami korzystającymi z procesów OOB (Out-of-Box) (takich jak Agile, Scrum lub CMMI). Jeśli projekt używa procesu OOB bez dostosowań, projekt zostanie uwzględniony w modelu dziedziczonego. Co ważne, błędy w tym pliku nie utrudniają procesu migracji.

Zrzut ekranu przedstawiający plik DataMigrationTool.log wygenerowany przez narzędzie do migracji danych.

Aby uzyskać listę błędów walidacji, zobacz Rozwiązywanie problemów z błędami walidacji. Dla każdego błędu weryfikacji podano numer błędu, opis i metodę do rozwiązania. W dziennikach sprawdzania poprawności mogą pojawić się różne typy błędów. Poszukaj pomocy od wytrenowanego partnera DevOps, usług konsultingowych firmy Microsoft lub pomocy technicznej Premier firmy Microsoft, aby rozwiązać napotkane błędy.

Usuwanie błędów szablonu procesu

Podstawowe błędy, które znajdziemy, to problemy z szablonem procesu. Te problemy wynikają z nieaktualnych projektów zespołowych, które nie obejmują najnowszych funkcji usługi Azure DevOps Server lub nieobsługiwanych dostosowań przez usługę Azure DevOps Services. Jednak usługa Azure DevOps Services obsługuje szereg dostosowań, a walidacja flaguje tylko te, które wymagają premigracji rozpoznawania. Narzędzie do migracji danych przeprowadza kompleksową kontrolę zgodności szablonów usług Azure DevOps Services, ale niektóre modyfikacje mogą być konieczne.

  • Dostosowane szablony procesów lub nieaktualne szablony mogą powodować błędy weryfikacji procesu podczas migracji.
  • Jeśli używasz procesu OOB Agile, Scrum lub CMMI, sprawdź, czy TryMatchOobProcesses.log występują błędy. Projekty bez błędów są mapowe na procesy OOB.
  • Niektóre dostosowania nie działają w usługach Azure DevOps Services. Przejrzyj listę obsługiwanych dostosowań.
  • W przypadku projektów korzystających ze starszych szablonów uruchom Kreatora konfigurowania funkcji, aby zaktualizować szablony z najnowszymi funkcjami i zmniejszyć liczbę błędów.
  • Upewnij się, że witadmin jest dostępna na maszynie, na której naprawiasz błędy procesu. Istotne jest wprowadzenie zmian w szablonach procesów.

Rozważ następujące narzędzia do rozwiązywania błędów procesu:

  • Skorzystaj z narzędzia wiersza polecenia witadmin.exe dołączonego do instalacji programu Visual Studio. Szczegółowa dokumentacja techniczna dotycząca rozwiązywania tych błędów jest dostępna pod tym linkiem.
  • Automatyzowanie eksportowania szablonów procesów dla każdego projektu zespołowego przy użyciu nieudokumentowanego narzędzia do migracji: Migracja weryfikuje /collection:http://localhost:8080/tfs/DefaultCollection /SaveProcesses.
  • Zapoznaj się z programem TFS Team Project Manager w witrynie GitHub (link). Umożliwia ona porównywanie projektów zespołowych ze znanymi szablonami procesów, w tym gotowe szablony.

Aby naprawić błędy, zmień składnię XML i zastosuj zmiany z powrotem do projektu.

Napiwek

Zalecamy ręczne modyfikowanie kodu XML zamiast używania narzędzi TFS Power Tools.

Aby pobrać szablon procesu z projektu, dodaj /SaveProcesses parametr podczas uruchamiania narzędzia do migracji danych.

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

To polecenie wyodrębnia kod XML z projektu i umieszcza go w tym samym folderze co dzienniki. Wyodrębnij pliki zip na komputer lokalny, aby można było edytować pliki.

Teraz napraw kod XML. Użyj dzienników z pliku DataMigrationTool.log, aby określić błędy dla każdego projektu.

Zrzut ekranu przedstawiający plik rejestrowania procesów wygenerowany przez narzędzie do migracji danych.

Niektóre błędy wymagają użycia witadmin changefield polecenia . Zmiana nazwy pola jest najbardziej typowym przykładem. Aby zaoszczędzić trochę czasu, zalecamy uruchomienie polecenia witadmin changefield , a następnie ponowne uruchomienie narzędzia do migracji danych. W ten sposób ponownie eksportuje kod XML z poprawionymi nazwami. W przeciwnym razie ręcznie napraw pola w składni XML.

Po wprowadzeniu poprawki zastosuj zmiany z powrotem do usługi Azure DevOps Server. W zależności od wprowadzonych zmian należy uruchomić co najmniej jedno polecenie witadmin. Utworzyliśmy skrypt programu PowerShell, aby zautomatyzować ten proces. Skrypt zawiera wszystkie polecenia witadmin potrzebne do potwierdzenia całego procesu.

Skrypty można uzyskać w sekcji Process Customization Scripts (Skrypty dostosowywania procesu). Użyj skryptu import/ConformProject.ps1.

.\conformproject.ps1 "<collection url>" "<project name>" "<process template folder>"

Po zakończeniu działania skryptu uruchom ponownie narzędzie do migracji danych, aby zweryfikować kolekcję. Wykonaj kroki od 1 do 3, dopóki narzędzie do migracji danych nie generuje więcej błędów walidacji.

Zrzut ekranu przedstawiający zgodny proces projektu w programie PowerShell.

Napiwek

Jeśli dopiero zaczynasz korzystać z kodu XML i witadmin, zalecamy wprowadzenie jednej poprawki naraz, a następnie zgodność. Kontynuuj tę pętlę do momentu usunięcia wszystkich błędów.

Aktualizowanie procesu systemowego

Jeśli rozpoczęto korzystanie ze starszej wersji usługi Azure DevOps Server, twoje projekty prawdopodobnie używają starszego szablonu procesu. Jeśli te projekty nie zostały zaktualizowane przy użyciu Kreatora konfigurowania funkcji, narzędzie do migracji danych wykrywa błędy procesu. W rzadkich przypadkach nawet kreator może nie rozwiązać starych problemów związanych z procesem.

Mogą pojawić się niektóre z następujących przykładowych komunikatów o błędach:

Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element PortfolioBacklog is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element BugWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackRequestWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackResponseWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Team.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField RemainingWork.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Order.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Effort.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Activity.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationStartInformation.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationLaunchInstructions.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationType.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF400572: The Project Process Settings must be configured for this feature to be used.

Jeśli projekt nie został dostosowany (na przykład dodane pola, typy elementów roboczych itd.), naprawienie tych błędów jest proste. Jednak jeśli proces został dostosowany, takie podejście nie wystarczy. Należy ręcznie dostosować szablony procesów, aby zachować dostosowania przed zastąpieniem.

Wykonaj następujące kroki dla każdego projektu, aby dopasować proces:

  1. Zidentyfikuj początkowy proces rozpoczęcia projektu (Scrum, Agile lub CMMI).
  2. Odwiedź witrynę Process Customization Scripts (Skrypty dostosowywania procesu) w witrynie GitHub i pobierz repozytorium.
  3. Skoncentruj się na zawartości w folderze Migracja.
  4. Użyj poniższego ConformProject.ps1 skryptu, aby dopasować wybrany projekt do procesu systemu Agile. Ta akcja aktualizuje cały projekt jako Agile.
.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"

Typowe błędy walidacji

VS402841: Pole X w typie elementu roboczego Usterka ma wartość syncnamechanges=false, ale ma reguły, które sprawiają, że jest to pole tożsamości. Pola tożsamości muszą mieć wartość syncnamechanges=true. Zaktualizuj szablon procesu, aby uwzględnić tę zmianę.

W usługach Azure DevOps Services dodaliśmy regułę, aby każde pole tożsamości miało syncnamechanges=true atrybut . W usłudze Azure DevOps Server ta reguła nie ma zastosowania. W związku z tym narzędzie do migracji danych identyfikuje to jako problem. Wprowadzenie tej zmiany w środowisku lokalnym usługi Azure DevOps Server nie powoduje żadnych szkód.

Uruchom polecenie witadmin changefield . Składnia polecenia wygląda podobnie do poniższego przykładu.

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /syncnamechanges:true

Aby uzyskać więcej informacji na temat polecenia witadmin changefield , zobacz Zarządzanie polami elementów roboczych.

TF402556: aby pole System.IterationId było dobrze zdefiniowane, należy nazwać identyfikator iteracji i ustawić jego typ na Liczbę całkowitą.

Ten błąd jest często skojarzony z nieaktualnymi szablonami procesów. Aby rozwiązać ten problem, można uruchomić Kreatora konfigurowania funkcji dla każdego projektu. Alternatywnie możesz wykonać następujące polecenie, aby zautomatyzować proces.

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /name:newname

TF402571: brak wymaganego elementu BugWorkItems w konfiguracji procesu.

Ten błąd jest często spotykany, gdy proces nie został zaktualizowany przez jakiś czas. Aby rozwiązać ten problem, uruchom Kreatora konfigurowania funkcji dla każdego projektu.

TF402564: Zdefiniowano XX listy globalne. Dozwolone są tylko 64

Usługa Azure DevOps Services natywnie obsługuje 64 listy globalne. Ten błąd zwykle pojawia się, gdy istnieje duża liczba potoków kompilacji, ponieważ każdy nowy potok tworzy listę globalną o nazwie Builds - TeamProjectName. Aby rozwiązać ten błąd, usuń wszystkie nieaktualne listy globalne.

Powtarzanie sprawdzania poprawności

W każdej iteracji rozwiąż błędy i przeprowadź sprawdzanie poprawności, aby je rozwiązać, zgodnie z plikami dziennika weryfikacji. Utrwalić ten cykl, dopóki wszystkie błędy nie zostaną naprawione i otrzymasz potwierdzenie pomyślnego sprawdzenia poprawności kolekcji.

Następne kroki

Przygotowanie do uruchomienia testowego