Udostępnij przez


Wykonywanie zadań po migracji

Po zakończeniu migracji wiadomość e-mail zostanie wysłana do właściciela organizacji i w tym momencie każda osoba mająca dostęp może zalogować się do nowo zmigrowanej organizacji usług Azure DevOps Services. Jednak przed udostępnieniem organizacji wszystkim użytkownikom należy wykonać typowe zadania wymienione w tym artykule.

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

Weryfikowanie zmigrowanej zawartości

Natychmiast po udostępnieniu organizacji sprawdź zmigrowaną zawartość i konfigurację, aby upewnić się, że wszystkie krytyczne składniki zostały pomyślnie zmigrowane. Administratorzy kolekcji projektów powinni prowadzić ten proces i obejmować wszystkie główne obszary kolekcji. Zalecamy zweryfikowanie następujących elementów:

  • Kod źródłowy: upewnij się, że wszystkie repozytoria zostały prawidłowo zmigrowane i są dostępne.
  • Historia kompilacji: sprawdź, czy kompletna historia kompilacji jest nienaruszona i spełnia oczekiwania.
  • Ścieżki obszaru: Upewnij się, że wszystkie ścieżki obszaru są obecne i poprawnie ustrukturyzowane.
  • Elementy robocze: przejrzyj reprezentatywną próbkę elementów roboczych, aby potwierdzić integralność danych i relacje.
  • Uprawnienia i zabezpieczenia: sprawdź, czy uprawnienia użytkownika, grupy i mechanizmy kontroli dostępu są poprawnie skonfigurowane. W zależności od tego, jak użytkownicy są skonfigurowani w usłudze Azure DevOps Server, mogą nie pojawić się w sekcji Użytkownicy nowej organizacji, dopóki nie zalogują się po raz pierwszy. Jeśli brakuje jakiegokolwiek użytkownika po migracji, należy się zalogować, a następnie ponownie sprawdzić ich stan.
  • Połączenia usług i rury: sprawdź, czy połączenia usług i konfiguracje rur działają.
  • Pulpity nawigacyjne i widżety: upewnij się, że pulpity nawigacyjne są renderowane poprawnie, a widżety wyświetlają oczekiwane dane.

Ta walidacja pomaga zidentyfikować brakujące, niekompletne lub błędnie skonfigurowane dane przed otwarciem organizacji do szerszej bazy użytkowników, zapewniając bezproblemowe przejście i zminimalizowanie zakłóceń.

Ważne

Nie usuwaj ani nie niszczyj lokalnych danych ani likwiduj systemów, dopóki nie potwierdzisz, że wszystkie oczekiwane dane i funkcje istnieją w zmigrowanej organizacji.

Zmiana nazwy organizacji (opcjonalnie)

Jeśli utworzono organizację zastępczą o żądanej nazwie w fazie Rozpoczynanie pracy, możesz teraz zmienić nazwę zmigrowanej organizacji, aby ją zamienić. Ten krok jest niezbędny tylko wtedy, gdy jest to ostateczna migracja i chcesz użyć określonej nazwy organizacji. Aby uzyskać więcej informacji, zobacz Zmiana nazwy organizacji.

Konfigurowanie rozliczeń

Aby płacić za użytkowników lub usługi w usłudze Azure DevOps, takich jak hostowani agenci kompilacji i wdrażania, należy skonfigurować rozliczenia dla organizacji. Jeśli migrujesz więcej niż jedną kolekcję, upewnij się, że wszystkie organizacje są skonfigurowane do rozliczeń przy użyciu tej samej subskrypcji platformy Azure i że subskrypcja jest włączona dla rozliczeń w wielu organizacjach. Następnie, bez żadnych opłat, możesz przypisać dowolną liczbę podstawowych użytkowników w miesiącu kalendarzowym, w którym uruchamiana jest migracja.

Konfigurowanie agentów kompilacji

Jeśli w środowisku usługi Azure DevOps Server użyto zautomatyzowanych serwerów kompilacji lub wdrażania, możesz połączyć je z organizacją usługi Azure DevOps Services. W ramach migracji wszystkie definicje kompilacji zostały zmigrowane, ale należy ponownie skonfigurować agentów i pule dla nowej organizacji usług Azure DevOps Services.

Aby uzyskać więcej informacji, zobacz agentów usługi Azure Pipelines.

Jeśli planujesz używać istniejących lokalnych prywatnych agentów kompilacji, musisz wyczyścić ich pamięć podręczną, co gwarantuje, że nie napotkasz żadnych problemów z kompilacją związanych ze starszą kontrolą wersji programu Team Foundation (TFVC) ani wskaźnikami Git do kolekcji lokalnej. Aby uzyskać więcej informacji, zobacz odświeżanie pamięci podręcznych na komputerach klienckich.

Wskazówka

Jeśli używałeś usługi Release Management w Azure DevOps Server, to twoje potoki wydania i dane historyczne zostały zmigrowane. Ale, podobnie jak w przypadku kompilacji, trzeba ponownie skonfigurować agentów (przelinkować ponownie) i pule dla nowej organizacji.

Korzystanie z usługi Azure Artifacts

Usługa Azure Artifacts jest dołączona do usług Azure DevOps Services dla wszystkich użytkowników, którym udzielono licencji Podstawowa. Nie ma potrzeby instalowania rozszerzenia. Dane usługi Azure Artifacts powinny być dostępne po migracji. Aby uzyskać więcej informacji, zobacz Omówienie usługi Azure Artifacts.

Dostosowywanie usługi Azure Boards

Jeśli masz istniejące połączenie z serwerem GitHub Enterprise Server skojarzone z serwerem Azure DevOps Server, nie działa zgodnie z oczekiwaniami. Elementy robocze wymienione w usłudze GitHub mogą być opóźnione lub nigdy nie są wyświetlane w usługach Azure DevOps Services. Ten problem występuje, ponieważ adres URL wywołania zwrotnego skojarzony z usługą GitHub nie jest już prawidłowy.

Aby rozwiązać ten problem, rozważ następujące zadania:

  • Usuń i ponownie utwórz połączenie: Usuń i ponownie utwórz połączenie z repozytorium GitHub Enterprise Server. Postępuj zgodnie z sekwencją kroków podanych w dokumentacji Connect Azure Boards.
  • Napraw adres URL elementu webhook: przejdź do strony ustawień repozytorium usługi GitHub i zmodyfikuj adres URL elementu webhook, aby wskazać zmigrowany adres URL organizacji usługi Azure DevOps Services: https://dev.azure.com/{OrganizationName}/_apis/work/events?api-version=5.2-preview.

Aby uzyskać więcej informacji, zobacz Konfigurowanie i dostosowywanie usługi Azure Boards.

Przejrzyj uprawnienia

Twoja organizacja obejmuje pięciu darmowych użytkowników z podstawowym dostępem Basic. Aby uzyskać więcej informacji, zobacz Dodawanie użytkowników organizacji i zarządzanie dostępem.

Powiadamianie zespołów

Po uruchomieniu kompilacji i skonfigurowaniu subskrypcji licencji zalecamy otwarcie organizacji dla wszystkich użytkowników w celu weryfikacji. Następnie użytkownicy indywidualni mogą upewnić się, że cała zawartość jest na swoim miejscu, ma odpowiedni poziom dostępu i mogą pobierać kod.

Użytkownicy TFVC z lokalnymi obszarami roboczymi muszą ponownie mapować swoje obszary robocze na nową organizację, a użytkownicy Git muszą ponownie skonfigurować swoje zdalne repozytoria, aby pobrać kod.

Następny krok