Przenoszenie lub klonowanie z jednego sprzętu na inny Azure DevOps w środowisku lokalnym

Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 — TFS 2013

Uwaga

Azure DevOps Server wcześniej nosiła nazwę Visual Studio Team Foundation Server.

Możesz przenieść lub sklonować wdrożenie Azure DevOps Server oprogramowania. Przenosisz Azure DevOps Server z jednego komputera na inny, przywracając go do nowego sprzętu (nazywanego przeniesieniem opartym na przywracaniu). Na przykład możesz chcieć przenieść Azure DevOps Server na serwer o większej pojemności lub większej szybkości przetwarzania. Przejście na nowy serwer nie utraci żadnej historii projektu.

Aby sklonować Azure DevOps Server wdrożenia, wykonaj te same kroki co przeniesienie oraz kilka dodatkowych.

Przeniesienie jest konieczne, gdy planujesz zaprzestać korzystania z oryginalnego sprzętu i Azure DevOps Server wdrożenia. Klonowanie jest wykonuje się, gdy zamierzasz nadal używać oryginalnego Azure DevOps Server wystąpienia.

Ważne

W niektórych sytuacjach można zmienić domenę wdrożenia Azure DevOps Server, a także jego sprzęt. Zmiana domeny jest przeniesieniem opartym na środowisku i nigdy nie należy łączyć dwóch typów przenoszenia. Najpierw wykonaj przeniesienie sprzętu, a następnie zmień środowisko.

Sprawdzanie uprawnień

Aby pomyślnie przenieść Azure DevOps Server, musisz być administratorem w obu zestawach sprzętu (starym i nowym). Ponadto musisz być administratorem (lub mieć równoważne uprawnienia) dla usługi Azure DevOps Server i całego oprogramowania, od którego zależy twoje wdrożenie: SQL Server, raportowanie, produkty SharePoint (jeśli wdrożenie korzysta z raportowania lub SharePoint) oraz inne oprogramowanie, z którym współdziała wdrożenie, na przykład Project Server.

Upewnij się, że jesteś członkiem następujących grup:

  • Serwery: Administratorzy (lokalni administratorzy grupy lub równoważnej)

  • Azure DevOps Server: Administratorzy programu Team Foundation i użytkownicy konsoli administracyjnej

  • SQL Server: sysadmin

  • SharePoint Products: Administratorzy farmy (jeśli wdrożenie Azure DevOps Server integruje się z SharePoint Products)

Jeśli nie jesteś członkiem co najmniej jednej z tych grup, uzyskaj teraz uprawnienia.

Kopii zapasowej baz danych i klucza szyfrowania

  1. Otwórz konsolę administracyjną programu Azure DevOps Server a następnie na stronie Zaplanowane kopie zapasowe zrób pełną kopię zapasową. Kopia zapasowa będzie tworzyć kopię zapasową wszystkiego, co skonfigurowano dla kopii zapasowej w planie tworzenia kopii zapasowej, ale zrobi to natychmiast, nie zgodnie z czasem zaplanowanym w planie. Jeśli wdrożenie korzysta z raportowania, można utworzyć kopię zapasową klucza szyfrowania w ramach tego zestawu kopii zapasowych.

    Okno można zamknąć po zakończeniu zadania

    (Jeśli nie masz skonfigurowanych kopii zapasowych, przed utworzeniem pełnej kopii zapasowej musisz utworzyć plan).

  2. Po zakończeniu tworzenia kopii zapasowej sprawdź, czy kopia zapasowa jest dostępna na urządzeniu magazynu lub w udziałach sieciowych oraz czy można uzyskać dostęp do tej kopii zapasowej z nowego sprzętu.

Instalowanie i SQL Server na nowym serwerze warstwy danych

  • Zainstaluj SQL Server na nowym serwerze i upewnij się, że działa. Jeśli poprzednie wdrożenie używało raportowania, upewnij się, że dołączyć składniki usług raportowania i analizy. Należy zainstalować używaną wcześniej wersję i wydanie, w tym dodatek Service Pack i zbiorcze poziomy aktualizacji.

    Instalowanie SQL Server 2008 R2 — funkcje

    Alternatywnie można utworzyć wystąpienie usługi SQL Server na serwerze, który ma już zainstalowaną pasującą wersję, i przywrócić bazy danych programu Azure DevOps Server do tego wystąpienia, ale będzie to wymagało większej liczby konfiguracji po przywróceniu.

    Aby uzyskać więcej informacji na temat opcji instalowania i konfigurowania SQL Server, przejdź tutaj.

    Po zainstalowaniu SQL Server, jeśli wdrożenie obejmuje raportowanie, otwórz program SQL Server Management Studio i odłącz bazy danych ReportServer i ReportServerTempDB. W przeciwnym razie może nie być możliwe przywrócenie tych baz danych przy użyciu kopii zapasowej utworzonej dla Azure DevOps Server baz danych.

    Istniejące bazy danych należy odłączyć przed przywróceniem

Instalowanie i konfigurowanie oprogramowania na nowym serwerze warstwy aplikacji

Aby skonfigurować nowy serwer lub serwery dla Azure DevOps Server, należy najpierw zainstalować i skonfigurować oprogramowanie wymagane do jego obsługi. To oprogramowanie zawiera następujące składniki:

  • obsługiwany system operacyjny dla konfiguracji wdrożenia

  • obsługiwana wersja usługi SharePoint Products (jeśli wdrożenie jest zintegrowane z usługą SharePoint Products i chcesz przenieść je na ten sam serwer co Azure DevOps Server)

Uwaga

W przeciwieństwie do instalowania nowego wdrożenia usługi Azure DevOps Server nie będzie można instalować programu SharePoint Products w ramach opcji standardowa Single-Server lub zaawansowana podczas przechodzenia na nowy serwer. Należy ręcznie zainstalować tę samą wersję i wydanie produktów usługi SharePoint, które były używane w poprzednim wdrożeniu, lub postępować zgodnie ze wskazówkami dla używanej wersji i wydania produktów usługi SharePoint, aby oddzielnie przenieść wdrożenie na nowy sprzęt.

  • Zainstaluj i skonfiguruj Windows, usługi IIS (jeśli nie są skonfigurowane domyślnie) i SharePoint (jeśli używasz programu ) w nowym środowisku, i upewnij się, że serwer i jego oprogramowanie działa.

    Aby uzyskać więcej informacji, zobacz wymagania systemowe dla systemu Azure DevOps Server i Move SharePoint to new hardware (Przenoszenie SharePoint na nowy sprzęt).

Przywracanie baz Azure DevOps Server danych

Aby przywrócić bazy danych usługi Azure DevOps Server przy użyciu narzędzia przywracania, należy zainstalować program Azure DevOps Server na nowym serwerze warstwy danych, ale nie skonfigurować go, a następnie użyć funkcji przywracania w węźle Zaplanowane kopie zapasowe.

Jeśli chcesz przywrócić bazy Azure DevOps Server ręcznie przy użyciu SQL Server przywracania, możesz to zrobić, ale jest to trudniejsza procedura. Ponadto w nowym wdrożeniu trzeba będzie ręcznie usunąć z pamięci bazy danych. Kreator przywracania w Azure DevOps Server automatycznie robi to za Ciebie w ramach procesu przywracania, ale ta funkcja nie jest częścią narzędzi SQL Server przywracania.

Jeśli program SharePoint Foundation 2013 został zainstalowany przy użyciu procedury opisanej w części Przenoszenie programu SharePointdo nowego sprzętu i zamierzasz używać tego serwera jako serwera programu Azure DevOps Server, bity instalacji i konsola administracyjna będą już obecne na serwerze i możesz pominąć pierwsze dwa kroki w następnej procedurze.

  1. Uruchom nośnik Azure DevOps Server instalacji. Na stronie Team Foundation Server instalatora wybierz pozycję Zainstaluj.

  2. Po zakończeniu instalacji zostanie otwarta Team Foundation Server Configuration Center. Zamknij go.

    Konsola administracyjna zostanie automatycznie otwarta w stanie nieskonfigurowany. Jest to oczekiwane zachowanie.

  3. Aby uruchomić kreatora przywracania, otwórz konsolę administracyjną programu Azure DevOps Server i otwórz okno Zaplanowane kopie zapasowe.

    Uruchamianie kreatora przywracania

  4. Określ ścieżkę do zestawu kopii zapasowych i wybierz zestaw utworzony po zakończeniu przechowywania starego wdrożenia.

    Wybierz ścieżkę sieciową, a następnie zestaw przywracania

  5. Ukończ kreatora i przywróć bazy danych do nowego wystąpienia SQL Server.

    Bazy danych zostaną przywrócone na nowy serwer

Przekierowywanie SharePoint Products do nowej lokalizacji bazy danych zawartości

Jeśli wdrożenie korzysta z usługi SharePoint Products, masz już zainstalowaną tę samą wersję i edycję produktów usługi SharePoint, które były używane w poprzednim wdrożeniu, zgodnie z instrukcjami w tece Move SharePoint to new hardware(Przenoszenie programu SharePoint na nowy sprzęt), jak wspomniano powyżej. Teraz po przywróceniu starej bazy danych zawartości wdrożenia (WSS Content) na nowy serwer w ramach zestawu przywracania należy przekierować serwer z uruchomionym programem SharePoint Products do nowej lokalizacji tej bazy _ danych. Ta baza danych musi działać, zanim będzie można ponownie Azure DevOps Server z nowymi lokalizacjami jej baz danych.

  1. Otwórz wiersz polecenia jako administrator na nowym sprzęcie z systemem SharePoint Foundation.

  2. Zmień katalogi na Dysk: Program Files Common Files Microsoft Shared Web Server Extensions 15 bin i uruchom plik stsadm.exe z następującymi parametrami, gdzie SharePointFoundationServerName to nazwa serwera, na którym zainstalowano program \ SharePoint Foundation \ \ \ \ \ 2013, a SQLServerName to _ nazwa serwera, na którym przywrócono bazę danych zawartości WSS w ramach przywracania Azure DevOps Server baz danych:

    stsadm.exe –o addcontentdb –url http://SharePointFoundationServerName/sites -databasename WSS_Content -databaseserver SQLServerName
    
  3. Po pomyślnym ukończeniu tego polecenia wpisz następujące polecenie, gdzie Domain \ UserName jest kontem użytym do zainstalowania i skonfigurowania programu SharePoint Foundation 2013 do użycia z programem Azure DevOps Server:

    stsadm.exe -o addpermissionpolicy -url http://SharePointFoundationServerName -userlogin Domain\UserName -permissionlevel "full control"
    

(Opcja klonowania) Ponowne konfigurowanie identyfikatorów serwerów i ponowne mapowanie baz danych

Uwaga

Wcześniej zalecaliśmy używanie narzędzia PrepareClone przed wdrożeniem nowego Azure DevOps Server przy użyciu kopii zapasowej bazy danych, która jest już w środowisku produkcyjnym na innym serwerze. To polecenie nie jest już wymagane, ponieważ włączono jego funkcje do scenariuszy uaktualniania przedprodukcyjna i klonowania w kreatorze konfiguracji.

Wykonaj następny zestaw kroków na nowym serwerze warstwy aplikacji, jeśli zamierzasz nadal używać oryginalnego Azure DevOps Server aplikacji. Te kroki są niezbędne, aby uniknąć ryzyka uszkodzenia jednego lub obu wdrożeń. Jeśli oba serwery są na żywo, może to być uszkodzenie, szczególnie jeśli wskazują one na te same SharePoint lub raportowania zasobów.

  1. Otwórz okno wiersza polecenia jako administrator i zmień katalogi na Dysk: % programfiles%\TFS 12.0\Tools. Otwórz okno wiersza polecenia i wprowadź:

  2. Uruchom polecenie TFSConfig PrepareClone, aby usunąć informacje o zaplanowanych kopiach zapasowych, SharePoint i zasobach raportowania.

    TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:DatabaseName /notificationURL: ApplicationTierURL
    
  3. Uruchom polecenie ChangeServerID polecenia TFSConfig, aby zmienić identyfikatory GUID serwera skojarzone z bazami danych. Identyfikatory GUID muszą być unikatowe Azure DevOps Server wdrożenia.

    TFSConfig ChangeServerID /SQLInstance:ServerName] /DatabaseName:ConfigurationDatabaseName [/ProjectCollectionsOnly] [/ConfigDBOnly] [/usesqlalwayson]
    
  4. Uruchom polecenie TFSConfig RemapDBs, aby przekierować sklonowane Azure DevOps Server do jego baz danych.

    TFSConfig RemapDBs /DatabaseName:ServerName;DatabaseName /SQLInstances:ServerName1,erverName2 [/AnalysisInstance:ServerName] [/AnalysisDatabaseName:DatabaseName] [/review] [/continue] [/usesqlalwayson]
    

Konfigurowanie serwera warstwy aplikacji

  1. W konsoli administracyjnej programu Azure DevOps Server skonfiguruj zainstalowane funkcje, aby uruchomić centrum konfiguracji.

  2. Uruchom kreatora Application-Tier tylko bazy danych, a następnie w SQL Server bazy danych określ nowe SQL Server, w którym przywrócono Azure DevOps Server bazy danych. Wybierz z listy bazę danych _ konfiguracji tfs.

    Wybieranie zestawu kopii zapasowych SQL Server bazy danych

  3. Przed zamknięciem ostatniej strony kreatora poszukaj symbolu "i". Oznacza ona informacje, które mogą być w przyszłości konieczne. Ostatnia strona zawiera również lokalizację dziennika konfiguracji.

    Zanotuj wszelkie problemy i lokalizację pliku dziennika

Aktualizowanie Azure DevOps Server URL

  1. Przejdź do węzła warstwy aplikacji i przyjrzyj się powiadomieniom oraz adresom URL portalu internetowego. Należy pamiętać, że nadal wskazują lokalizację starego wdrożenia. Zaktualizuj je.

    Powiadomienia i internetowe adresy URL są aktualne

  2. Po zaktualizowaniu adresów URL przy użyciu nazwy nowego serwera przejrzyj informacje, aby upewnić się, że są poprawne.

    Adres URL serwera nadal używa hosta lokalnego

Aktualizowanie wszystkich kont usług

Należy zaktualizować konto usługi dla Azure DevOps Server (TFSService) i konta źródeł danych (TFSReports). Nawet jeśli te konta nie uległy zmianie, należy zaktualizować informacje, aby zapewnić, że tożsamość i format kont są odpowiednie dla nowego serwera.

  1. Otwórz okno wiersza polecenia jako administrator i zmień katalogi na Dysk: \ %programfiles% \ narzędzi TFS 12.0. \

  2. W wierszu polecenia wpisz następujące polecenie, aby dodać konto usługi dla usługi Azure DevOps, gdzie DatabaseName jest nazwą bazy danych konfiguracji (domyślnie konfiguracja serwera _ TFS):

    TfsConfig Accounts /add /AccountType:ApplicationTier /account: AccountName /SQLInstance: ServerName /DatabaseName: DatabaseName

  3. W wierszu polecenia wpisz następujące polecenie, aby dodać konto źródeł danych:

    TfsConfig Accounts /add /AccountType:ReportingDataSource /account: AccountName /SQLInstance:ServerName /DatabaseName:DatabaseName

    Aby uzyskać więcej informacji, zobacz Accounts Command.

Aktualizowanie serwerów kompilacji

Teraz musisz przekierować serwery kompilacji, aby wskazać przeniesione Azure DevOps Server wdrożenia.

  1. Na każdym serwerze kompilacji otwórz konsolę administracyjną i zatrzymaj usługę kompilacji.

  2. We właściwościach usługi kompilacji zaktualizuj właściwości komunikacji.

    Zatrzymaj usługę, a następnie dokonaj zmian

Konfigurowanie SharePoint internetowych

Jeśli wdrożenie korzysta z usługi SharePoint Products i przeniesiono program SharePoint Foundation 2013 w ramach przenoszenia programu Azure DevOps Server, może być konieczne przekierowanie aplikacji Azure DevOps Server do nowej aplikacji internetowej. Nawet jeśli tego nie zimkniesz, nadal należy naprawić połączenie, aby zapewnić odpowiednią wydajność.

Jeśli nie używasz usługi SharePoint Products w ramach wdrożenia lub jeśli wdrożenie będzie nadal używać starego serwera SharePoint, możesz pominąć tę procedurę.

  • Otwórz konsolę administracyjną programu i przejdź do SharePoint Web Applications. Jeśli aplikacja internetowa nadal odwołuje się do starej witryny lub jeśli nowe wdrożenie korzysta z innej aplikacji internetowej niż wymieniona, wybierz pozycję Zmień i zaktualizuj ustawienia.

    Azure DevOps Server nadal przekierowuje do starej aplikacji

    Jeśli informacje są poprawne lub po ich poprawieniu wybierz pozycję Napraw połączenie. Dzięki temu można mieć pewność, że wszystko działa prawidłowo.

Konfigurowanie raportowania i Analysis Services

Jeśli wdrożenie korzysta z serwera raportów, należy przekierować Azure DevOps Server do jego lokalizacji, ponownie uruchomić magazyn i ręcznie ponownie skompilować bazę danych dla Analysis Services. Jeśli nie używasz raportowania, pomiń tę procedurę.

  1. Przejdź do węzła Raportowanie. Wymienione wartości serwera raportów to stare, a nie nowe, więc edytuj je.

    Raporty nadal wskazują stary serwer

  2. Zmień wartości na wszystkich trzech kartach, aby wskazać nowy serwer. Upewnij się, że w nowym wdrożeniu są podane poprawne informacje dotyczące konta źródeł danych.

    Upewnij się, że informacje na wszystkich 3 kartach są poprawne

  3. Wybierz pozycję Uruchom zadania, aby ponownie uruchomić raportowanie.

  4. Wybierz pozycję Rozpocznij ponowne kompilowanie, aby ponownie skompilować magazyn.

Weryfikowanie uprawnień dla użytkowników, grup i kont usług

Po zakończeniu przechodzenia na nowy sprzęt upewnij się, że wszyscy użytkownicy, grupy i konta usług dla wdrożenia są skonfigurowane z uprawnieniami wymaganymi do poprawnego działania na każdym serwerze. Niektórych uprawnień, takich jak dodatkowe uprawnienia w SQL Server lub na komputerze lokalnym, nie można automatycznie migrować. Na przykład Azure DevOps muszą być członkami lokalnej grupy Administratorzy na serwerze warstwy aplikacji, aby otworzyć konsolę administracyjną, więc należy dodać je ręcznie do tej grupy.

  • Zaloguj się na serwerze i upewnij się, że użytkownicy, grupy i konta usług są skonfigurowane z uprawnieniami wymaganymi do działania. Ręcznie sprawdź członkostwo w grupach projektów i zespołach i sprawdź, czy te grupy i zespoły mają wymagane uprawnienia.

  • Przejdź do kolekcji projektów i upewnij się, że wszystkie projekty w tej kolekcji są wyświetlane zgodnie z oczekiwaniami, a użytkownicy w tych projektach mogą odpowiednio uzyskać dostęp do swoich elementów roboczych.

  • Otwórz portal internetowy i sprawdź, czy witryny zespołu i zespoły są wyświetlane zgodnie z oczekiwaniami.

Nie wiesz, jakich grup i uprawnień można oczekiwać? Aby uzyskać więcej informacji, zobacz Dodawanie użytkowników do projektów,Ustawianie uprawnień administratora dla kolekcji projektów,Ustawianie uprawnień administratora dla programu Azure DevOps Serveroraz Konta usług i zależności w programie Azure DevOps Server.

Odświeżanie pamięci podręcznej danych na komputerach klienckich

  • Zaloguj się na serwerze i użyj usługi sieci Web ClientService, aby wymusić na klientach aktualizację pamięci podręcznej na potrzeby śledzenia elementów roboczych i Azure DevOps kontroli wersji.

    http://ServerName:8080/tfs/WorkItemTracking/v3.0/ClientService.asmx
    

    Aby uzyskać więcej informacji, zobacz Odświeżanie pamięci podręcznych danych na komputerach klienckich.

    Jeśli chcesz odświeżyć całą pamięć podręczną dla wszystkich użytkowników przy następnym logować się, użyj witadmin rebuildcache polecenia.

    Uwaga

    Jeśli bazy danych zostaną przywrócone do innego punktu w czasie, należy również odświeżyć pamięć podręczną kontroli wersji zgodnie z dokumentacją z tematu Odświeżanie pamięci podręcznych danych na komputerach klienckich.

Powiadomienie użytkowników

Teraz, po Azure DevOps Server wdrożenia, musisz poinformować użytkowników, jak nawiązać połączenie z przeniesionym wdrożeniem. W szczególności należy podać im następujące informacje:

  • Nazwa nowego serwera i adres URL portalu internetowego, aby można było ponownie połączyć się ze swoimi projektami

  • Nazwy nowych baz danych do raportowania, jeśli raportowanie jest częścią wdrożenia

  • Nowy adres URL SharePoint, jeśli SharePoint jest częścią wdrożenia

  • Jeśli są członkami projektu, który korzysta z usługi Git, instrukcje dotyczące aktualizowania każdego klonu, który ma lokalnie dla każdego repozytorium dla tego projektu. W szczególności będzie musiał uruchomić następujące polecenie dla każdego klonu:

    git remote set-url <remote name> <new URL>
    

    Użytkownicy mogą zobaczyć adres URL każdego klonu, przeglądając projekt na karcie Eksplorator.

    Kopiowanie adresu URL w celu ręcznego klonowania repozytorium w programie

Konfigurowanie kopii zapasowych

Mimo że zaplanowano tworzenie kopii zapasowych dla starego wdrożenia, te zaplanowane kopie zapasowe nie zostały zmienione w celu tworzenia kopii zapasowej przeniesionego wdrożenia. Należy je skonfigurować.

  • W konsoli administracyjnej przejdź do węzła Zaplanowane kopie zapasowe i ponownie skonfiguruj zaplanowane kopie zapasowe w celu tworzenia kopii zapasowych Azure DevOps Server baz danych na nowym serwerze. Aby uzyskać więcej informacji, zobacz Tworzenie harmonogramu i planu tworzenia kopii zapasowych.

Pytania i odpowiedzi

Pytanie: Chcę zmienić domeny, a nie serwery fizyczne. Czy mogę to zrobić?

Odpowiedź: tak. Jest to nazywane przeniesieniem opartym na środowisku, a kroki można znaleźć tutaj. Nie należy próbować łączyć przenoszenia opartego na środowisku z przenoszeniem opartym na sprzęcie. Najpierw wykonaj przeniesienie sprzętu, a następnie zmień środowisko.

Pytanie: Właśnie zdawałem sobie sprawę, że chcę nadal korzystać ze Azure DevOps Server po przeniesieniu na nowy sprzęt. Czy mogę to zrobić?

A: Tak, ale bardzo ważne jest, aby wykonać dodatkowe kroki od razu. Najlepiej wykonać te kroki w ramach kroków przenoszenia lub klonowania. Jest to najlepszy sposób uniknięcia ryzyka uszkodzenia jednego lub obu wdrożeń. Jeśli oba serwery są na żywo, może to być uszkodzenie, szczególnie jeśli wskazują one na te same SharePoint zasobów raportowania.

Aby rozwiązać ten problem:

  1. Uruchom polecenie TFSConfig PrepareClone na nowym serwerze

  2. Uruchom polecenie ChangeServerID tfsconfig na nowym serwerze

  3. Uruchom polecenie TFSConfig RemapDBs na nowym serwerze

Pytanie: Mam wdrożenie zintegrowane z programem Project Server. Czy muszę wykonać jakieś dodatkowe kroki, aby pracować z przeniesionym Azure DevOps Server?

A: Tak, po zakończeniu przenoszenia sprzętu musisz użyć polecenia TFSAdmin ProjectServer /RegisterPWA z opcjami /tfs, /force i /pwa, aby ponownie zarejestrować Azure DevOps Server u Project Server. Więcej informacji na temat integracji Azure DevOps Server z programem Project Server można znaleźć tutaj.