Przenoszenie lub klonowanie z jednego sprzętu do innego dla lokalnej usługi Azure DevOps

Artykuł
03/25/2024

Azure DevOps Server 2022 r. | Azure DevOps Server 2020 r. | Azure DevOps Server 2019 r.

Możesz przenieść lub sklonować wdrożenie oprogramowania Azure DevOps Server. Przenosisz Azure DevOps Server z jednej maszyny do innej, przywracając go do nowego sprzętu (nazywanego przenoszeniem opartym na przywracaniu). Na przykład możesz przenieść Azure DevOps Server na serwer z większą pojemnością lub większą szybkością przetwarzania. Po przejściu do nowego serwera nie utracisz żadnej historii projektu.

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

Przeniesienie jest wykonywane, gdy planujesz zaprzestać korzystania z oryginalnego sprzętu i Azure DevOps Server wdrożenia. Klon jest wykonywana, gdy zamierzasz kontynuować korzystanie z oryginalnego wystąpienia Azure DevOps Server.

Ważne

W niektórych sytuacjach warto 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 ukończ przenoszenie sprzętu, a następnie zmień środowisko.

Sprawdzanie uprawnień

Aby pomyślnie przenieść Azure DevOps Server, musisz być administratorem w obu zestawach sprzętu (stary i nowy). Ponadto musisz być administratorem (lub mieć równoważne uprawnienia) dla Azure DevOps Server i całego oprogramowania, na którym zależy wdrożenie: SQL Server, raportowanie i inne oprogramowanie, za pomocą którego międzyoperacyjnie oceniasz wdrożenie, takie jak Program Project Server.

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

Serwery: Administratorzy (lokalna grupa administratorów lub równoważne)
Azure DevOps Server: Administratorzy programu Team Foundation i użytkownicy konsoli Administracja
SQL Server: sysadmin

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

Tworzenie kopii zapasowych baz danych i klucza szyfrowania

Otwórz konsolę administracyjną Azure DevOps Server i na stronie Zaplanowane kopie zapasowe wykonaj pełną kopię zapasową. Kopia zapasowa utworzy kopię zapasową wszystkiego, co zostało skonfigurowane do tworzenia kopii zapasowej w planie kopii zapasowej, ale zrobi to natychmiast, a nie zgodnie z czasem zaplanowanym w planie. Jeśli wdrożenie korzysta z raportowania, możesz utworzyć kopię zapasową klucza szyfrowania w ramach tego zestawu kopii zapasowych.

(Jeśli nie masz skonfigurowanych kopii zapasowych, musisz utworzyć plan przed wykonaniem pełnej kopii zapasowej).
Po zakończeniu tworzenia kopii zapasowej sprawdź, czy kopia zapasowa jest dostępna na urządzeniu magazynu lub udziale sieciowym, i czy możesz uzyskać dostęp do tej kopii zapasowej z nowego sprzętu.

Instalowanie i konfigurowanie 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 uwzględnisz składniki usług raportowania i analizy. Musisz zainstalować tę samą wersję i wersję, która była wcześniej używana, w tym dodatek Service Pack i skumulowane poziomy aktualizacji.

Alternatywnie można utworzyć wystąpienie SQL Server na serwerze, na którym zainstalowano już zgodną wersję i przywrócić Azure DevOps Server bazy danych do tego wystąpienia, ale będzie to wymagało większej 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 SQL Server Management Studio i odłącz bazy danych ReportServer i ReportServerTempDB. W przeciwnym razie nie można przywrócić tych baz danych za pomocą kopii zapasowej utworzonej dla baz danych Azure DevOps Server.

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 obejmuje następujące składniki:

obsługiwany system operacyjny dla konfiguracji wdrożenia
Zainstaluj i skonfiguruj system Windows, usługi IIS (jeśli nie skonfigurowano domyślnie) i upewnij się, że serwer i jego oprogramowanie działają.

Aby uzyskać więcej informacji, zobacz wymagania systemowe dotyczące Azure DevOps Server.

Przywracanie baz danych Azure DevOps Server

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

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

Uruchom nośnik instalacyjny Azure DevOps Server. Na stronie Konfiguracja serwera Team Foundation Server wybierz pozycję Zainstaluj.
Po zakończeniu instalacji zostanie otwarte Centrum konfiguracji serwera Team Foundation Server . Zamknij go.

Konsola administracyjna zostanie otwarta automatycznie w stanie nieskonfigurowanym. Jest to oczekiwane zachowanie.
Aby uruchomić kreatora przywracania, otwórz konsolę administracyjną dla Azure DevOps Server i otwórz zaplanowane kopie zapasowe.
Określ ścieżkę do zestawu kopii zapasowych i wybierz zestaw utworzony po przejściu w stan spoczynku starego wdrożenia.
Ukończ kreatora i przywróć bazy danych do nowego wystąpienia SQL Server.

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

Uwaga

Narzędzie PrepareClone było zalecane do użycia przed rozpoczęciem nowego wdrożenia Azure DevOps Server przy użyciu kopii zapasowej bazy danych już w środowisku produkcyjnym na innym serwerze. To polecenie nie jest już wymagane, ponieważ wprowadziliśmy jej funkcjonalność do scenariuszy przedprodukcyjnego uaktualniania i klonowania w kreatorze konfiguracji.

Wykonaj następny zestaw kroków na nowym serwerze warstwy aplikacji, jeśli zamierzasz kontynuować korzystanie z oryginalnego wystąpienia Azure DevOps Server. Te kroki są niezbędne, aby uniknąć ryzyka uszkodzenia jednego lub obu wdrożeń. Jeśli oba serwery są na żywo, może dojść do uszkodzenia, szczególnie jeśli wskazują na te same zasoby raportowania.

Otwórz okno wiersza polecenia jako administrator i zmień katalogi na Drive:%programfiles%\TFS 12.0\Tools. Otwórz okno wiersza polecenia i wprowadź:
Uruchom polecenie TFSConfig PrepareClone , aby usunąć informacje o zaplanowanych kopiach zapasowych i zasobach raportowania.
```
TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:DatabaseName /notificationURL: ApplicationTierURL
```
Uruchom polecenie TFSConfig ChangeServerID , aby zmienić identyfikatory GUID serwera skojarzone z bazami danych. Identyfikatory GUID muszą być unikatowe we wdrożeniu Azure DevOps Server.
```
TFSConfig ChangeServerID /SQLInstance:ServerName] /DatabaseName:ConfigurationDatabaseName [/ProjectCollectionsOnly] [/ConfigDBOnly] [/usesqlalwayson]
```

Uruchom polecenie TFSConfig RemapDBs, aby przekierować sklonowany 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

W konsoli administracyjnej programu Azure DevOps Server wybierz pozycję Konfiguruj zainstalowane funkcje, aby uruchomić centrum konfiguracji.
Uruchom kreatora tylko Application-Tier i w obszarze Bazy danych określ nowe wystąpienie SQL Server, w którym przywrócono bazy danych Azure DevOps Server. Wybierz bazę danych Tfs_Configuration z listy.
Przed zamknięciem ostatniej strony kreatora poszukaj symbolu "i". Oznacza to informacje, które mogą być potrzebne w przyszłości. Ostatnia strona zawiera również lokalizację dziennika konfiguracji.

Aktualizowanie adresów URL Azure DevOps Server

Przejdź do węzła warstwy aplikacji i przyjrzyj się powiadomieniom i adresom URL portalu internetowego. Należy pamiętać, że nadal wskazują lokalizację starego wdrożenia. Zaktualizuj je.
Po zaktualizowaniu adresów URL o nazwie nowego serwera przejrzyj informacje, aby upewnić się, że jest ona poprawna.

Aktualizowanie wszystkich kont usług

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

Otwórz okno wiersza polecenia jako administrator i zmień katalogi na Drive:\%programfiles%\TFS 12.0\Tools.
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 TFS_Configuration):

Konta TfsConfig /add /AccountType:ApplicationTier /account:AccountName/SQLInstance:ServerName/DatabaseName:DatabaseName:DatabaseName
W wierszu polecenia wpisz następujące polecenie, aby dodać konto źródeł danych:

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

Aby uzyskać więcej informacji, zobacz Accounts Command (Polecenia kont).

Aktualizowanie serwerów kompilacji

Teraz należy przekierować serwery kompilacji, aby wskazywały przeniesione wdrożenie Azure DevOps Server.

Na każdym serwerze kompilacji otwórz konsolę administracyjną i zatrzymaj usługę kompilacji.
We właściwościach usługi kompilacji zaktualizuj właściwości komunikacji.

Konfigurowanie usług Reporting and 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 usług Analysis Services. Jeśli nie używasz raportowania, pomiń tę procedurę.

Przejdź do węzła Raportowanie. Wymienione wartości serwera raportów są stare, a nie nowe, więc je edytować.
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.
Wybierz pozycję Uruchom zadania , aby ponownie uruchomić raportowanie.
Wybierz pozycję Rozpocznij ponowne kompilowanie , aby ponownie skompilować magazyn.

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

Po przejściu do nowego sprzętu upewnij się, że wszyscy użytkownicy, grupy i konta usług dla wdrożenia są skonfigurowane z uprawnieniami, które wymagają poprawnego działania na każdym serwerze. Niektórych uprawnień, takich jak dodatkowe uprawnienia w SQL Server lub na komputerze lokalnym, nie można przeprowadzić automatycznej migracji. Na przykład administratorzy usługi Azure DevOps muszą należeć do lokalnej grupy Administratorzy na serwerze warstwy aplikacji, aby otworzyć konsolę administracyjną, dlatego 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 operacji. Ręcznie sprawdź członkostwo w grupach projektów i zespołach oraz sprawdź, czy te grupy i zespoły mają oczekiwane 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 uzyskiwać 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 masz pewności, 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 Azure DevOps Server oraz kont usług i zależności w 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 aktualizowanie pamięci podręcznej na potrzeby śledzenia elementów roboczych i kontroli wersji usługi Azure DevOps.
```
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 logowaniu, użyj polecenia witadmin rebuildcache .

Uwaga

W przypadku przywrócenia baz danych do innego punktu w czasie należy również odświeżyć pamięć podręczną kontroli wersji zgodnie z dokumentacją w temacie Odświeżanie pamięci podręcznych danych na komputerach klienckich.

Powiadomienie użytkowników

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

Nazwa nowego serwera i adres URL portalu internetowego, dzięki czemu mogą ponownie łączyć się ze swoimi projektami
Nowe nazwy baz danych do raportowania, jeśli raportowanie jest częścią wdrożenia
Jeśli są członkami projektu korzystającego z usługi Git, instrukcje dotyczące aktualizowania każdego klonu, które mają lokalnie dla każdego repozytorium dla tego projektu. W szczególności będą musieli uruchomić następujące polecenie dla każdego klonu:
```
git remote set-url <remote name> <new URL>
```
Użytkownicy mogą zobaczyć, jaki adres URL jest przeznaczony dla każdego klonu, przeglądając projekt na karcie Eksplorator.

Konfigurowanie kopii zapasowych

Mimo że utworzono kopie zapasowe zaplanowane dla starego wdrożenia, zaplanowane kopie zapasowe nie zostały zmienione w celu utworzenia kopii zapasowej przeniesionego wdrożenia. Należy je skonfigurować.

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

Pytania i odpowiedzi

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

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

Pyt.: Właśnie zdałem sobie sprawę, że chcę nadal korzystać ze starego Azure DevOps Server po przejściu do nowego sprzętu. Czy mogę to zrobić?

A: Tak, ale bardzo ważne jest, aby od razu wykonać dodatkowe kroki. W idealnym przypadku należy wykonać te kroki w ramach przenoszenia lub kroków klonowania. Jest to najlepszy sposób, aby uniknąć ryzyka uszkodzenia jednego lub obu wdrożeń. Jeśli oba serwery są na żywo, może dojść do uszkodzenia, szczególnie jeśli wskazują na te same zasoby raportowania.

Aby rozwiązać ten problem:

Uruchom polecenie TFSConfig PrepareClone na nowym serwerze
Uruchom polecenie TFSConfig ChangeServerID na nowym serwerze
Uruchom polecenie TFSConfig RemapDBs na nowym serwerze

Pyt.: Mam wdrożenie zintegrowane z programem Project Server. Czy muszę wykonać dodatkowe kroki, aby można było pracować z przeniesionymi Azure DevOps Server?

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