Zarządzanie lokalną usługą Azure DevOps przy użyciu narzędzia TFSConfig
Azure DevOps Server 2022 r. | Azure DevOps Server 2020 r. | Azure DevOps Server 2019 r.
Możesz użyć narzędzia wiersza polecenia TFSConfig , aby wykonać różne akcje administracyjne dla lokalnego wdrożenia usługi Azure DevOps.
Program TFSConfig można uruchomić z dowolnej maszyny, na której zainstalowano Azure DevOps Server.
Lokalizacja narzędzia wiersza polecenia
Narzędzia wiersza polecenia usługi Azure DevOps są instalowane w katalogu /Tools serwera warstwy aplikacji usługi Azure DevOps.
- Azure DevOps Server 2020 r.:
%programfiles%\Azure DevOps Server 2020\Tools - Azure DevOps Server 2019 r.:
%programfiles%\Azure DevOps Server 2019\Tools - TFS 2018:
%programfiles%\Microsoft Team Foundation Server 2018\Tools - TFS 2017:
%programfiles%\Microsoft Team Foundation Server 15.0\Tools - TFS 2015:
%programfiles%\Microsoft Team Foundation Server 14.0\Tools - TFS 2013:
%programfiles%\Microsoft Team Foundation Server 12.0\Tools - TFS 2012:
%programfiles%\Microsoft Team Foundation Server 11.0\Tools - TFS 2010:
%programfiles%\Microsoft Team Foundation Server 2010\Tools
Wymagania wstępne
Aby wiele poleceń działało poprawnie, program TFSConfig będzie musiał mieć możliwość nawiązania połączenia z różnymi serwerami i usługami, które są częścią wdrożenia serwera TFS, a użytkownik z programem TFSConfig będzie musiał mieć uprawnienia administracyjne dla tych samych serwerów i usług. Wymagania dotyczące określonych poleceń zostaną nazwane poniżej.
Wiele poleceń TFSConfig musi być uruchamianych z wiersza polecenia z podwyższonym poziomem uprawnień, nawet jeśli uruchomiony użytkownik ma poświadczenia administracyjne. Aby otworzyć wiersz polecenia z podwyższonym poziomem uprawnień, kliknij przycisk Start, kliknij prawym przyciskiem myszy wiersz polecenia, a następnie kliknij polecenie Uruchom jako administrator. Aby uzyskać więcej informacji, zobacz: Kontrola konta użytkownika.
Możesz również interaktywnie wykonywać akcje administracyjne przy użyciu konsoli administracyjnej dla Azure DevOps Server. Zobacz Szybki przewodnik dotyczący zadań administracyjnych.
Wyświetlanie listy poleceń i uzyskiwanie pomocy
Aby wyświetlić pełną listę poleceń TFSConfig , użyj polecenia pomocy :
TFSConfig help
Aby uzyskać pomoc dotyczącą pojedynczego polecenia, użyj polecenia pomocy i określ nazwę polecenia, z którym chcesz uzyskać pomoc. Aby na przykład uzyskać pomoc dotyczącą polecenia konta :
TFSConfig help accounts
Konta
Użyj polecenia accounts, aby zarządzać tymi kontami usług Azure DevOps Server.
- konto usługi Azure DevOps Server
- konto źródeł danych dla SQL Server Reporting Services
- konto usługi Azure DevOps Proxy Server
Możesz również użyć tego polecenia, aby zmienić własność Azure DevOps Server baz danych.
TfsConfig accounts /change|add|set|delete|updatepassword|resetowner
[/accountType:<adminConsole|applicationTier|proxy|reportingDataSource>]
[/account:<accountName>] [/password:<password>]
[/sqlInstance:<serverName>] [/databaseName:<databaseName>] [/continue]
| Operacja | Opis |
|---|---|
| UpdatePassword | Zmienia hasło konta, które jest używane jako konto usługi. Zmienia istniejące konto i wszystkie typy kont, które są uruchamiane jako podane konto. |
| Zmiana | Zmienia konto używane jako konto usługi. Dodaje nowe konto do niezbędnych zasobów i grup, przyznaje wymagane uprawnienia, a następnie ustawia usługę do jej użycia. Nie powoduje to usunięcia starego konta z zasobów. Jeśli nie używasz opcji accountType , konto usługi dla warstwy aplikacji zostanie zmienione. |
| Dodaj | Dodaje tylko nowe konto do niezbędnych zasobów. Przydatne w scenariuszach równoważenia obciążenia sieciowego. Użyj flagi kontynuuj, jeśli niektóre kolekcje są niedostępne. Dodaj można ponownie uruchomić później, aby zaktualizować wszystkie pominięte kolekcje. Dodaje konto do grup wymaganych do korzystania z konta jako konta usługi. |
| Set | Ustawia tylko usługę, aby używać konta już dodanego do zasobów. Przydatne w scenariuszach równoważenia obciążenia sieciowego. |
| Usuń | Usuwa konto ze wszystkich zasobów. Środki ostrożności należy stosować podczas usuwania konta, ponieważ może to spowodować, że inne serwery nie będą mogły uzyskać usługi odmowy. |
| ResetOwner | Jeśli bazy danych zostaną przywrócone w ramach przenoszenia, klonowania lub odzyskiwania po awarii, właściciel bazy danych może przełączyć się na administratora przywracającego serwer. Ta opcja iteruje wszystkie bazy danych i ustawia identyfikator logowania dbo do bieżącego właściciela. |
| Accounttype | Opis |
|---|---|
| AdminConsole | Użytkownicy konsoli administracyjnej to użytkownicy, którzy otrzymali minimalne uprawnienia w różnych zasobach do korzystania z konsoli programu . |
| ApplicationTier | Zmienia konto usługi w puli aplikacji dla podstawowych usług internetowych. (TFSService) |
| Serwer proxy | Zmienia konto usługi w puli aplikacji dla usług internetowych serwera proxy. (TFSProxy) |
| ReportingDataSource | Zmienia konto używane przez raporty w celu uzyskania dostępu do danych raportowania. (TFSReports) |
Wartość domyślna to ApplicationTier.
Klasa sqlInstance i databaseName są odpowiednie tylko do użycia podczas dodawania konta do baz danych przed skonfigurowaniem warstwy aplikacji. Jest to przede wszystkim przydatne w scenariuszach odzyskiwania po awarii, w których wymagane jest inne konto przed uruchomieniem kreatora konfiguracji tylko usługi AT.
Opcja kontynuuj jest używana podczas dodawania lub zmieniania konta. W przypadku tych operacji konto jest zmieniane w każdej bazie danych kolekcji. Jeśli zostanie dostarczona kontynuacja, będzie kontynuowana, jeśli kolekcja jest niemożliwa do osiągnięcia. Można go uruchomić ponownie, gdy są dostępne.
Uwaga
Konta muszą mieć format domainName\userName. W przypadku kont systemowych należy używać cudzysłowów wokół pełnej nazwy konta (na przykład "NT Authority\Network Service"). Konta systemowe nie wymagają hasła.
| Parametr | Opis |
|---|---|
| Konto | Określa nazwę konta, które chcesz dodać, zmienić lub usunąć z przywoływałego typu konta, na przykład /AccountType:ApplicationTier. |
| Hasło | Określa hasło konta usługi. Ten parametr jest opcjonalny, jeśli używasz konta systemowego lub konta, które nie ma hasła, takiego jak usługa sieciowa. |
| sqlInstance | Używane tylko z /ResetOwner. Określa nazwę serwera z uruchomionym SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Należy określić nazwę i wystąpienie w następującym formacie: Servername\instancename. |
| databaseName | Używane tylko z /ResetOwner. Określa nazwę bazy danych, której własność ma zostać zmieniona. Za pomocą tego polecenia należy zresetować własność bazy danych określonej dla konta, na którym jest uruchamiane polecenie. |
| continue | Aktualizacje wszystkie grupy, które nie są dostępne podczas uruchamiania polecenia. Ta opcja jest zwykle używana w scenariuszach równoważenia obciążenia sieciowego. |
Wymagania wstępne
Aby użyć polecenia accounts , musisz być członkiem:
- grupa zabezpieczeń Administratorzy usługi Azure DevOps
- rola administratora systemu dla wszystkich wystąpień SQL Server używanych przez wystąpienie Azure DevOps Server.
Jeśli używasz opcji /proxy , musisz być administratorem na serwerze proxy.
Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.
Uwagi
Użyj polecenia accounts, aby zautomatyzować zmiany w kontach usług, bazach danych i grupach kont usług Azure DevOps Server. Możesz skonfigurować konta, które zostały już utworzone, ale nie można tworzyć kont.
Przed zmianą domeny lub grupy roboczej konta konto musi mieć poufne konto i nie można delegować uprawnień na serwerze warstwy aplikacji. Aby uzyskać więcej informacji, zobacz tę stronę w witrynie sieci Web firmy Microsoft: Włączanie uwierzytelniania delegowanego.
Polecenie accounts obsługuje wdrożenia lokalne Azure DevOps Server. Aby zmienić właściciela konta konta Azure DevOps Services, zobacz Zmienianie własności konta.
Przykłady
Zmień konto usługi źródeł danych dla usług Reporting Services na nowe konto w domenie Contoso i Contoso\NewAccounthasło na Password.
TfsConfig accounts /change /AccountType:ReportingDataSource /Account:Contoso\NewAccount /Password:Password
Dodaj konto systemowe usługi sieciowej do grup kont usług dla Azure DevOps Server (konta systemowe nie mają haseł).
TfsConfig accounts /add /AccountType:ApplicationTier /Account:"NT Authority\Network Service"
Zmień własność TFS_Warehouse bazy danych na ContosoMain SQL Server w TeamDatabases nazwanym wystąpieniu na konto użytkownika, w którym uruchamiasz polecenie.
Uwaga
Nie można określić, które konto ma zostać ustawione jako właściciel baz danych podczas korzystania z tego polecenia. Właściciel zostanie ustawiony na konto, w ramach którego uruchamiasz polecenie.
TfsConfig accounts /ResetOwner /SQLInstance:ContosoMain\TeamDatabases /DatabaseName:TFS_Warehouse
AddProjectReports
Uwaga
Polecenie addProjectReports jest dostępne w wersji TFS 2017.1 i nowszych.
Użyj polecenia addProjectReports , aby dodać lub zastąpić raporty dla istniejącego projektu zespołowego.
TfsConfig addProjectReports /collection:<teamProjectCollectionUrl> /teamProject:<projectName> /template:<templateName>
[/force]
| Opcja | Opis |
|---|---|
| — kolekcja | Wymagane. Adres URL kolekcji projektów zespołowych. |
| teamproject | Wymagane. Określa nazwę projektu zespołowego. |
| szablon | Wymagane. Określa nazwę szablonu procesu. Dostępne opcje to Agile, CMMI i Scrum. |
| Życie | Opcjonalny. Określa, że raporty powinny zostać zastąpione, jeśli już istnieją. |
Wymagania wstępne
Aby użyć polecenia addProjectReports , musisz mieć uprawnienia do uruchamiania programu TFSConfig i przekazywania raportów do usługi Reporting Service.
Uwagi
Użyj polecenia addProjectReports , gdy projekt nie ma raportów lub chcesz zaktualizować raporty zdefiniowane dla procesu.
Może być konieczne użycie tego polecenia, gdy:
- Projekt został utworzony w portalu usługi Azure DevOps, a nie w programie Visual Studio
- Projekt został utworzony na podstawie programu Visual Studio, jednak raportowanie nie zostało skonfigurowane w Azure DevOps Server.
Jeśli chcesz zastąpić raporty w projekcie domyślnymi raportami, ponieważ uaktualniono Azure DevOps Server i stare raporty w projekcie nie są już zgodne, użyj opcji /force. Jeśli raporty zostały dostosowane, przed wykonaniem tej czynności utwórz kopię zapasową.
Aby dowiedzieć się więcej na temat dodawania raportów do lokalnego Azure DevOps Server, zobacz Dodawanie raportów do projektu.
Przykład
W poniższym przykładzie pokazano, jak dodać raporty Agile do MyProject projektu w http://myTfsServer:8080/tfs/DefaultCollection kolekcji projektów.
TFSConfig addProjectReports /collection:http://myTfsServer:8080/tfs/DefaultCollection /teamproject:MyProject /template:Agile
Authentication
Polecenie Uwierzytelnianie zmienia protokół uwierzytelniania sieciowego używany przez Azure DevOps Server warstwę aplikacji lub witrynę internetową serwera proxy.
TFSConfig Authentication [/provider:NTLM|Negotiate] [/viewAll] [/siteType:ApplicationTier|Proxy]
Opcja
Opis
/viewAll
Wyświetla bieżące ustawienia uwierzytelniania dla Azure DevOps Server.
/provider: { NTLM | Negocjuj }
Określa dostawcę uwierzytelniania, który chcesz skonfigurować dla witryny sieci Web.
- NTLM: użyj protokołu uwierzytelniania NTML
- Negocjuj: korzystanie z protokołu uwierzytelniania negocjowania (Kerberos)
/siteType
Określa witrynę internetową (warstwę aplikacji lub serwer proxy), której protokół uwierzytelniania sieciowego chcesz zmienić. Warstwa aplikacji jest domyślna.
Wymagania wstępne
Aby użyć polecenia Uwierzytelnianie , musisz być członkiem grupy zabezpieczeń Administratorzy usługi Azure DevOps i administratorem lokalnym na serwerze warstwy aplikacji lub serwerze proxy, w zależności od wartości opcji siteType .
Uwagi
Polecenie Uwierzytelnianie jest używane przez administratora, który chce zmienić protokół uwierzytelniania sieciowego dla co najmniej jednej witryny internetowej, na której opiera się Azure DevOps Server. Administrator uruchamia to polecenie z warstwy aplikacji, aby zaktualizować te witryny internetowe, które wymagają zmiany w protokole uwierzytelniania sieciowego. Polecenie zmienia właściwość NTAuthenticationProviders w metabazie usług IIS.
Przed użyciem polecenia Authentication w celu zmiany protokołu uwierzytelniania można uruchomić polecenie z opcją /viewAll , aby zobaczyć, jakie są istniejące ustawienia.
Przykład
Poniższy przykład przedstawia bieżącą wartość przypisaną dla protokołu uwierzytelniania sieciowego.
TFSConfig Authentication /viewAll
Certyfikaty
Użyj polecenia certyfikatów, aby zmienić sposób konfigurowania certyfikatów na potrzeby uwierzytelniania klienta we wdrożeniu Azure DevOps Server korzystających z protokołu HTTPS, secure sockets layer (SSL) i certyfikatów.
TfsConfig certificates [/machine] [/disable] [/autoSelect] [/noprompt] [/thumbprints:thumbprint1[,thumbprint2,...]]
| Opcja | Opis |
|---|---|
| Maszyny | Określa, że lista certyfikatów będzie pochodzić z kontekstu komputera lokalnego zamiast bieżącego kontekstu użytkownika. |
| Wyłącz | Określa, że ustawienie certyfikatu uwierzytelniania klienta zostanie wyłączone. |
| autowybierz | Określa, że certyfikat zostanie automatycznie wybrany z listy certyfikatów. Okno Zarządzanie certyfikatami klienta nie zostanie otwarte. |
| noprompt | Określa, że okno Zarządzanie certyfikatami klienta nie zostanie otwarte po uruchomieniu polecenia Certyfikaty. |
| odciski palca | Określa, że zostanie użyty certyfikat zgodny z określonym odciskiem palca. Można określić więcej niż jeden certyfikat, oddzielając poszczególne odciski palca przecinkami. |
Wymagania wstępne
Aby użyć polecenia certyfikatów , musisz być członkiem grupy zabezpieczeń Administratorzy usługi Azure DevOps i lokalnej grupy Administratorzy na komputerze, z którego uruchamiasz polecenie. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.
Uwagi
Domyślnie polecenie certyfikatów automatycznie wybierze certyfikat klienta z listy certyfikatów dla bieżącego użytkownika. Można jednak użyć opcji polecenia, aby określić określony certyfikat lub certyfikaty z bieżącego kontekstu użytkownika lub z kontekstu komputera lokalnego.
Przed użyciem polecenia certyfikatów należy najpierw skonfigurować serwery we wdrożeniu Azure DevOps Server, aby korzystać z certyfikatów. Aby uzyskać więcej informacji, zobacz Konfigurowanie protokołu HTTPS z protokołem Secure Sockets Layer (SSL) dla Azure DevOps Server.
Użyj polecenia certyfikatów, aby skonfigurować certyfikaty klienta używane przez wdrożenie Azure DevOps Server, które zostały skonfigurowane do używania protokołu HTTPS/SSL i certyfikatów. Jeśli używasz polecenia Certyfikaty bez opcji, certyfikat klienta zostanie automatycznie wybrany z bieżącego kontekstu użytkownika, z którego uruchamiasz polecenie.
Przykłady
W poniższym przykładzie pokazano, jak określić certyfikat komputera lokalnego, który ma odcisk aa bb cc dd ee palca bez monitowania.
TfsConfig certificates /machine /thumbprint:aa bb cc dd ee /noprompt
W poniższym przykładzie pokazano, jak określić przy użyciu automatycznego wyboru certyfikatu klienta z bieżącego magazynu użytkowników.
TfsConfig certificates /autoselect
Changeserverid
Polecenie changeServerID zmienia identyfikatory GUID skojarzone z bazami danych dla Azure DevOps Server. Identyfikatory GUID muszą być unikatowe we wdrożeniu Azure DevOps Server. Jeśli więcej niż jedna baza danych ma ten sam identyfikator GUID, wdrożenie może stać się niestabilne lub bezużyteczne. Można zmienić identyfikator GUID bazy danych konfiguracji, identyfikatory GUID dla wszystkich baz danych kolekcji projektów we wdrożeniu lub oba te elementy.
Chociaż zwykle nie używa się tego polecenia w codziennych operacjach, można użyć tego polecenia w następujących okolicznościach:
Wdrożenie zostało przywrócone do nowego sprzętu, stare wdrożenie nadal działa i chcesz korzystać z obu wdrożeń. Ten scenariusz jest czasami określany jako klonowanie serwera.
Chcesz przetestować aktualizację oprogramowania lub konfigurację sprzętu na zduplikowane wdrożenie, aby nie ryzykować zakłócenia środowiska produkcyjnego.
Chcesz w pełni przetestować przywracanie baz danych do nowego sprzętu w laboratorium testowym lub oddzielnym środowisku, aby upewnić się, że wdrożenie można przywrócić.
Identyfikator GUID dla bazy danych kolekcji należy zresetować po przeniesieniu go do innego wdrożenia, dla którego ten identyfikator GUID jest już zarezerwowany.
Uwaga
Polecenie changeServerID nie jest odwracalne. Po zmianie identyfikatora GUID nie można cofnąć tej zmiany, z wyjątkiem przywracania poprzedniej wersji tej bazy danych.
TfsConfig changeServerID /sqlInstance:<serverName> /databaseName:<configurationDatabaseName>
[/projectCollectionsOnly] [/configDBOnly] [/collectionName]
| Opcja | Opis |
|---|---|
| sqlInstance | Wymagane. Określa nazwę serwera z uruchomioną SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName. |
| databaseName | Wymagane. Określa nazwę bazy danych konfiguracji dla Azure DevOps Server. Domyślnie nazwa tej bazy danych jest TFS_ConfigurationDB. |
| projectCollectionsOnly | Określa, że zostaną zmienione tylko identyfikatory GUID dla kolekcji. |
| configDBOnly | Określa, że zostanie zmieniony tylko identyfikator GUID bazy danych konfiguracji. |
| Collectionname | Określa, aby utworzyć nowy identyfikator wystąpienia dla określonej kolekcji, ale nie dla wystąpienia usługi Azure DevOps i innych kolekcji. |
Wymagania wstępne
Aby użyć polecenia changeServerID, musisz być członkiem grupy zabezpieczeń Administratorzy usługi Azure DevOps i członkiem roli zabezpieczeń administratora systemu dla wszystkich wystąpień SQL Server używanych przez Azure DevOps Server. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla usługi Azure DevOps.
Uwagi
Użyj polecenia changeServerID, aby utworzyć dyskretny duplikat wdrożenia Azure DevOps Server na potrzeby testowania lub klonowania. Po użyciu polecenia changeServerID należy skierować klientów, aby utworzyć połączenie ze zmienionym serwerem, zanim będzie można go użyć.
Przykład
W poniższym przykładzie pokazano, jak zmienić identyfikatory GUID wszystkich baz danych we wdrożeniu Azure DevOps Server firmy Contoso1, gdzie baza danych konfiguracji jest hostowana na serwerze o nazwie ContosoMain w nazwanym wystąpieniu TeamDatabases w SQL Server.
TfsConfig changeServerID /SQLInstance:ContosoMain\TeamDatabases /DatabaseName:TFS_ConfigurationDB
Indeks kodu
Użyj polecenia codeIndex, aby zarządzać indeksowaniem kodu w Azure DevOps Server. Na przykład możesz zresetować indeks, aby naprawić informacje o funkcji CodeLens, lub wyłączyć indeksowanie w celu zbadania problemów z wydajnością serwera.
TfsConfig codeIndex /indexingStatus | /setIndexing:[on|off|keepupOnly] |
/ignoreList:[ add | remove | removeAll | view ] <serverPath> |
/listLargeFiles [/fileCount:FileCount] [/minSize:MinSize] |
/reindexAll |
/destroyCodeIndex [/noPrompt] |
/temporaryDataSizeLimit:[ view | <SizeInGBs> | disable ] |
/indexHistoryPeriod:[ view | all | <NumberOfMonths> ] [/collectionName:<collectionName> | /collectionId:<collectionId>]
| Opcja | Opis |
|---|---|
| indexingStatus | Pokaż stan i konfigurację usługi indeksowania kodu. |
| setIndexing | on: Rozpocznij indeksowanie wszystkich zestawów zmian. wyłączone: zatrzymaj indeksowanie wszystkich zestawów zmian. keepupOnly: zatrzymaj indeksowanie wcześniej utworzonych zestawów zmian i zacznij indeksować tylko nowe zestawy zmian. |
| ignoreList | Określa listę plików kodu i ich ścieżki, których nie chcesz indeksować. add: Dodaj plik, który nie ma być indeksowany do listy ignorowanych plików. remove: usuń plik, który ma zostać zaindeksowany z listy ignorowanych plików. removeAll: wyczyść zignorowaną listę plików i rozpocznij indeksowanie wszystkich plików. view: Zobacz wszystkie pliki, które nie są indeksowane. ServerPath: określa ścieżkę do pliku kodu. Symbol wieloznaczny (*) można użyć na początku, na końcu lub na obu końcach ścieżki serwera. |
| listLargeFiles | Pokazuje określoną liczbę plików, które przekraczają określony rozmiar w KB. Następnie możesz użyć opcji /ignoreList , aby wykluczyć te pliki z indeksowania. W tym celu będziesz potrzebować serwera Team Foundation Server 2013 z aktualizacją Update 3. |
| reindexAll | Wyczyść wcześniej indeksowane dane i ponownie uruchom indeksowanie. |
| destroyCodeIndex | Usuń indeks kodu i usuń wszystkie indeksowane dane. Nie wymaga potwierdzenia, jeśli używasz /noPrompt opcji. |
| temporaryDataSizeLimit | Kontrolowanie ilości danych tymczasowych tworzonych przez funkcję CodeLens podczas przetwarzania zestawów zmian. Domyślny limit to 6 GB (2 GB w aktualizacji Update 5). view: Pokaż bieżący limit rozmiaru. SizeInGBs: zmień limit rozmiaru. wyłącz: usuń limit rozmiaru. Ten limit jest sprawdzany, zanim funkcja CodeLens przetworzy nowy zestaw zmian. Jeśli dane tymczasowe przekraczają ten limit, funkcja CodeLens wstrzyma przetwarzanie przeszłych zmian, a nie nowych. Funkcja CodeLens ponownie uruchomi przetwarzanie po wyczyszczeniu danych i spadnie poniżej tego limitu. Oczyszczanie jest uruchamiane automatycznie raz dziennie. Oznacza to, że dane tymczasowe mogą przekroczyć ten limit do momentu uruchomienia oczyszczania. W tym celu będziesz potrzebować serwera Team Foundation Server 2013 z aktualizacją Update 4. |
| indexHistoryPeriod | Określ, jak długo indeksować historię zmian. Ma to wpływ na to, ile historii pokazuje CodeLens. Domyślny limit to 12 miesięcy. Oznacza to, że funkcja CodeLens pokazuje historię zmian tylko z ostatnich 12 miesięcy. view: Pokaż bieżącą liczbę miesięcy. all: Indeksuj całą historię zmian. NumberOfMonths: zmień liczbę miesięcy używanych do indeksowania historii zmian. W tym celu będziesz potrzebować serwera Team Foundation Server 2013 z aktualizacją Update 4. |
| Collectionname | Określa nazwę kolekcji projektu, na której ma zostać uruchomione polecenie CodeIndex . Wymagane, jeśli nie używasz /CollectionId. |
| Collectionid | Określa numer identyfikacyjny kolekcji projektu, na której ma zostać uruchomione polecenie CodeIndex . Wymagane, jeśli nie używasz /CollectionName |
Wymagania wstępne
Aby użyć polecenia codeIndex , musisz być członkiem grupy zabezpieczeń Administratorzy usługi Azure DevOps. Zobacz Dokumentację uprawnień dla Azure DevOps Server.
Przykłady
Aby wyświetlić stan indeksowania kodu i konfigurację:
TfsConfig codeIndex /indexingStatus /collectionName:"Fabrikam Web Site"
Aby rozpocząć indeksowanie wszystkich zestawów zmian:
TfsConfig codeIndex /setIndexing:on /collectionName:"Fabrikam Web Site"
Aby zatrzymać indeksowanie wcześniej utworzonych zestawów zmian i zacząć indeksować tylko nowe zestawy zmian:
TfsConfig codeIndex /setIndexing:keepupOnly /collectionName:"Fabrikam Web Site"
Aby znaleźć maksymalnie 50 plików, które są większe niż 10 KB:
TfsConfig codeIndex /listLargeFiles /fileCount:50 /minSize:10 /collectionName:"Fabrikam Web Site"
Aby wykluczyć określony plik z indeksowania i dodać go do listy ignorowanych plików:
TfsConfig codeIndex /ignoreList:add "$/Fabrikam Web Site/Catalog.cs" /collectionName:"Fabrikam Web Site"
Aby wyświetlić wszystkie pliki, które nie są indeksowane:
TfsConfig codeIndex /ignoreList:view
Aby wyczyścić wcześniej indeksowane dane i ponownie uruchomić indeksowanie:
TfsConfig codeIndex /reindexAll /collectionName:"Fabrikam Web Site"
Aby zapisać całą historię zestawu zmian:
TfsConfig codeIndex /indexHistoryPeriod:all /collectionName:"Fabrikam Web Site"
Aby usunąć limit rozmiaru danych tymczasowych CodeLens i kontynuować indeksowanie niezależnie od tymczasowego rozmiaru danych:
TfsConfig codeIndex /temporaryDataSizeLimit:disable /collectionName:"Fabrikam Web Site"
Aby usunąć indeks kodu z potwierdzeniem:
TfsConfig codeIndex /destroyCodeIndex /collectionName:"Fabrikam Web Site"
Kolekcja
Możesz użyć polecenia kolekcji, aby dołączyć, odłączyć lub usunąć kolekcję projektu z wdrożenia Azure DevOps Server. Możesz również użyć polecenia kolekcji , aby zduplikować bazę danych istniejącej kolekcji, zmienić jej nazwę i dołączyć ją do wdrożenia. Ten proces jest czasami określany jako klonowanie kolekcji.
TfsConfig collection {/attach | /create | /detach | /delete} [/collectionName:<collectionName>]
[/description:<collectionDescription>]
[/collectionDB:<serverName>;<databaseName>]
[/processModel:Inheritance|Xml]
[/reportingFolder:<reportingFolderPath>]
[/clone] [/verify] [/continue]
| Opcja | Opis |
|---|---|
| dołączać | Wymagane, jeśli nie jest używany /detach ani /delete . Jeśli określisz tę opcję, musisz również użyć opcji /collectionDB . Jako opcję można również użyć /collectionName i /clone z tą opcją. Jeśli używasz opcji /attach, określona baza danych kolekcji zostanie dodana do wdrożenia Azure DevOps Server. |
| create | Tworzy kolekcję. |
| Odłączyć | Wymagane, jeśli nie jest używany /attach ani /delete . Jeśli określisz tę opcję, musisz również użyć opcji /collectionName . Jeśli używasz opcji /detach, baza danych dla określonej kolekcji zostanie zatrzymana, a kolekcja zostanie odłączona od wdrożenia Azure DevOps Server. |
| delete | Wymagane, jeśli nie jest używany /detach ani /attach . Jeśli określisz tę opcję, musisz również użyć opcji /collectionName . Jeśli używasz opcji /delete, baza danych dla określonej kolekcji zostanie zatrzymana, a kolekcja zostanie trwale odłączona od Azure DevOps Server. Nie będzie można ponownie dołączyć bazy danych kolekcji do tego lub innego wdrożenia. |
| CollectionName | Określa nazwę kolekcji projektów. Jeśli nazwa kolekcji zawiera spacje, należy ująć nazwę w cudzysłów (na przykład "Moja kolekcja"). Wymagane, jeśli jest używany /detach lub /delete . Jeśli używasz tej opcji z /detach lub /delete, określa kolekcję, która zostanie odłączona lub usunięta. Jeśli używasz tej opcji z /attach, określa nową nazwę kolekcji. Jeśli używasz tej opcji zarówno z /attach , jak i /clone, określa nazwę zduplikowanej kolekcji. |
| CollectionDB | Wymagane, jeśli / attach jest używany. Ta opcja określa nazwę serwera, na którym działa SQL Server, oraz nazwę bazy danych kolekcji hostowanej na tym serwerze. |
| ServerName | Określa nazwę serwera, który hostuje bazę danych konfiguracji dla Azure DevOps Server, oraz nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName. |
| DatabaseName | Określa nazwę bazy danych konfiguracji. Domyślnie nazwa tej bazy danych jest TFS_ConfigurationDB. |
| clone | Jeśli określisz tę opcję, oryginalna baza danych kolekcji zostanie dołączona jako klon w SQL Server, a ta baza danych zostanie dołączona do Azure DevOps Server. Ta opcja jest używana głównie w ramach dzielenia kolekcji projektów. |
Porada
Opcja /delete nie usunie bazy danych kolekcji z SQL Server. Po usunięciu bazy danych kolekcji z Azure DevOps Server można ręcznie usunąć bazę danych z SQL Server.
Wymagania wstępne
Aby użyć polecenia kolekcji , musisz być członkiem grupy zabezpieczeń Administratorzy team Foundation, a także lokalnej grupy Administratorzy na maszynie z uruchomioną programem TfsConfig. Musisz również być członkiem roli zabezpieczeń administratora systemu dla wszystkich wystąpień SQL Server używanych przez bazy danych Azure DevOps Server. Jeśli wdrożenie jest zintegrowane z programem SharePoint i używasz opcji /delete , musisz również być członkiem grupy Administratorzy farmy dla farmy, z której usuwasz zbiór witryn.
Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.
Uwagi
Aby zarządzać kolekcjami interaktywnie lub utworzyć kolekcję, możesz użyć węzła Kolekcje projektów w konsoli administracyjnej usługi Azure DevOps. Zobacz Zarządzanie kolekcjami projektów.
Przykłady
W poniższym przykładzie pokazano, jak trwale usunąć Contoso Summer Intern Projects kolekcję projektu z wdrożenia Azure DevOps Server.
TfsConfig collection /delete /CollectionName:"Contoso Summer Intern Projects"
TFSConfig - Team Foundation Server Configuration Tool
Copyright � Microsoft Corporation. All rights reserved.
Deleting a project collection is an irreversible operation. A deleted collection cannot be reattached to the same or another Team Foundation Server. Are you sure you want to delete 'Contoso Summer Intern Projects'? (Yes/No)
Yes
Found Collection 'Contoso Summer Intern Projects' Deleting...
The delete of collection 'Contoso Summer Intern Projects' succeeded.
W poniższym przykładzie pokazano, jak zduplikować Contoso Summer Interns Projects kolekcję projektu, nadać jej Contoso Winter Interns Projectsnazwę i dołączyć zduplikowaną kolekcję do wdrożenia Azure DevOps Server.
TfsConfig collection /attach /collectiondb:"ContosoMain;TFS_Contoso Summer Interns Projects"
/CollectionName:"Contoso Winter Intern Projects" /clone
ColumnStoreIndex
Uwaga
Dostępność poleceń: wymaga wersji TFS 2015.2 i nowszych.
Użyj polecenia columnStoreIndex, aby włączyć lub wyłączyć indeksy magazynu kolumn dla baz danych używanych przez wdrożenie Azure DevOps Server.
TfsConfig columnStoreIndex /enabled:<true|false>
/sqlInstance:<serverName>
/databaseName:<databaseName>
| Opcja | Opis |
|---|---|
| enabled | Określa, czy włączasz, czy wyłączasz indeks magazynu kolumn dla danego wystąpienia i bazy danych SQL. |
| sqlInstance | Określa nazwę serwera, który hostuje bazę danych, dla której indeks magazynu kolumn jest włączony lub wyłączony, oraz nazwę wystąpienia, jeśli jest używane wystąpienie inne niż domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName. |
| databaseName | Określa nazwę bazy danych, dla której indeks magazynu kolumn jest włączony lub wyłączony. |
Wymagania wstępne
Aby użyć polecenia columnStoreIndex, musisz być członkiem roli sysadmin dla określonego wystąpienia SQL Server.
Uwagi
Zazwyczaj należy użyć polecenia columnStoreIndex , jeśli przenosisz bazę danych z wystąpienia SQL, które obsługuje indeks magazynu kolumn do tego, który nie. W takim przypadku należy wyłączyć wszystkie indeksy magazynu kolumn, zanim będzie można pomyślnie przenieść bazy danych. Podobnie, jeśli przenosisz bazę danych z powrotem do wystąpienia SQL, które obsługuje indeks magazynu kolumn, możesz ponownie włączyć indeks magazynu kolumn, aby zaoszczędzić miejsce i uzyskać wydajność.
Przykład
W poniższym przykładzie pokazano, jak włączyć indeks magazynu kolumn dla bazy danych o nazwie TFS_DefaultCollection w wystąpieniu SQL uruchomionym na serwerze o nazwie ContosoMain w nazwanym wystąpieniu TeamDatabases.
TfsConfig columnStoreIndex /enabled:true /sqlInstance:ContosoMain\TeamDatabases /databaseName:TFS_DefaultCollection
Konfigurowanie poczty e-mail
Skonfiguruj serwer z systemem Azure DevOps Server, aby używać istniejącego serwera SMTP na potrzeby alertów poczty e-mail.
TfsConfig configureMail /Enabled:<true|false> /FromEmailAddress:<emailAddress> /SmtpHost:<SMTPHostName>
| Opcja | Opis |
|---|---|
| FromEmailAddress | Określa adres, z którego mają być wysyłane powiadomienia e-mail z Azure DevOps Server na potrzeby zaewidencjonowania, elementu roboczego przypisanego do Ciebie lub innych powiadomień. Ten adres jest również sprawdzany pod kątem ważności, a w zależności od konfiguracji serwera może być konieczne reprezentowanie prawidłowego konta e-mail na serwerze poczty. Jeśli adres nie istnieje lub jest nieprawidłowy, zostanie użyty domyślny adres e-mail. |
| SmtpHost | Określa nazwę serwera, który hostuje serwer poczty. |
Wymagania wstępne
Aby użyć polecenia configureMail , musisz być członkiem grupy zabezpieczeń Administratorzy team Foundation na serwerze warstwy aplikacji Azure DevOps. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server
Uwagi
Konsolę administracyjną można również skonfigurować Azure DevOps Server do korzystania z serwera SMTP.
Przykład
W poniższym przykładzie przedstawiono składnię używaną do konfigurowania adresu e-mail z adresu e-mail i TFS@contoso.com serwera poczty SMTP jako ContosoMailServer:
TfsConfig configureMail /FromEmailAddress:TFS@contoso.com /SmtpHost:ContosoMailServer
DbCompression
Użyj polecenia dbCompression, aby włączyć lub wyłączyć kompresję strony bazy danych dla baz danych używanych przez wdrożenie Azure DevOps Server.
TfsConfig dbCompression /pageCompression:[enable|disable]
/sqlInstance:<serverName>
/databaseName:<databaseName>
[/rebuildNow [/offline]]
| Opcja | Opis |
|---|---|
| pageCompression | Określa, czy włączasz lub wyłączasz kompresję strony dla danego wystąpienia i bazy danych SQL. |
| sqlInstance | Określa nazwę serwera, który hostuje bazę danych, dla której kompresja strony jest włączona lub wyłączona, oraz nazwę wystąpienia, jeśli jest używane wystąpienie inne niż domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName |
| databaseName | Określa nazwę bazy danych, dla której kompresja strony jest włączona lub wyłączona. |
| rebuildNow | Opcjonalny. Określa, czy indeksy baz danych powinny zostać od razu skompilowane (i skompresowane lub zdekompresowane). Jeśli nie jest używany, indeksy zostaną ponownie skompilowane przez zadanie w tle, które jest uruchamiane co tydzień. |
| tryb offline | Opcjonalny. Używane tylko w połączeniu z /rebuildNow. Jeśli /offline nie zostanie określony, indeksy zostaną ponownie skompilowane w trybie online. Jeśli określono /offline , indeksy zostaną ponownie skompilowane w trybie offline. Spowoduje to zablokowanie innych operacji, ale może być szybsze niż ponowne kompilowanie indeksu online. |
Wymagania wstępne
Aby użyć polecenia dbCompression, musisz być członkiem roli sysadmin dla określonego wystąpienia SQL Server.
Uwagi
Zwykle używa się polecenia dbCompression , jeśli przenosisz bazę danych z wystąpienia SQL, które obsługiwało kompresję do tej, która nie była obsługiwana. W takim przypadku należy wyłączyć kompresję i dekompresować wszystkie indeksy przed pomyślnym przeniesieniem baz danych. Podobnie, jeśli przenosisz bazę danych z powrotem do wystąpienia SQL, które obsługuje kompresję, możesz ponownie włączyć kompresję, aby zaoszczędzić miejsce.
To polecenie zmienia się tylko wtedy, czy Azure DevOps Server woli korzystać z kompresji strony bazy danych, czy nie — bazy danych muszą być nadal hostowane w wystąpieniu SQL, którego wersja obsługuje kompresję. Aby uzyskać więcej informacji, zobacz Funkcje obsługiwane przez wersje SQL Server.
Przykład
W poniższym przykładzie pokazano, jak natychmiast włączyć kompresję strony z indeksami ponownie skompilowanymi w trybie online dla bazy danych o nazwie TFS_DefaultCollection w wystąpieniu SQL działającym na serwerze o nazwie ContosoMainTeamDatabases.
TfsConfig dbCompression /pageCompression:enable /sqlInstance:ContosoMain\TeamDatabases /databaseName:TFS_DefaultCollection /rebuildNow
DeleteTestResults
Użyj polecenia deleteTestResults , aby usunąć stare przechowywane wyniki testu z magazynu kolekcji. Zazwyczaj odbywa się to w celu zmniejszenia rozmiaru magazynu lub skrócenia czasu wykonywania migracji wyników testu do nowego schematu.
TfsConfig deleteTestResults /ageInDays:<number> /sqlInstance:<serverName> /databaseName:<databaseName>
[/type:[automated|manual|all]]
[/preview]
| Opcja | Opis |
|---|---|
| ageInDays | Wyniki testów starsze niż określona liczba dni zostaną usunięte lub w wersji zapoznawczej. |
| sqlInstance | Nazwa serwera, który hostuje bazę danych, dla której wyniki testów są usuwane lub wyświetlane w wersji zapoznawczej, oraz nazwę wystąpienia, jeśli jest używane wystąpienie inne niż domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName. |
| databaseName | Nazwa bazy danych, dla której wyniki testów są usuwane lub wyświetlane w wersji zapoznawczej. |
| typ | Opcjonalny. Typ wyników testu do usunięcia. Prawidłowe wartości są zautomatyzowane, ręczne i wszystkie. |
| preview | Opcjonalny. Wyświetl liczbę wyników testu, które zostaną usunięte na podstawie wieku w dniach, ale nie usuwaj tych wyników. |
Wymagania wstępne
Aby użyć polecenia deleteTestResults, musisz być członkiem roli sysadmin dla określonego wystąpienia SQL Server.
Uwagi
Użyj /preview parametru, aby wyświetlić wyniki testu posortowane według nazwy projektu i roku bez usuwania tych wyników.
Przykład
W poniższym przykładzie pokazano, jak usunąć wyniki testów ręcznych starszych niż 60 dni dla bazy danych o nazwie TFS_DefaultCollection w wystąpieniu SQL uruchomionym na serwerze o nazwie ContosoMain w nazwanym wystąpieniu TeamDatabases.
TfsConfig deleteTestResults /ageInDays:60 /sqlInstance:ContosoMain\TeamDatabases /databaseName:TFS_DefaultCollection /type:manual
Pula wdrożenia
Polecenie deploymentPool zostało zaprojektowane pod kątem migrowania wszystkich grup wdrożeń z jednej puli wdrożenia do innej.
TfsConfig deploymentpool /migrateDeploymentGroups /fromPool:<source pool name> /toPool:<destination pool name>
| Opcja | Opis |
|---|---|
| fromPool | Nazwa puli źródłowej. |
| toPool | Nazwa puli docelowej. |
Tożsamości
Polecenia tożsamości wyświetla listę lub zmienia identyfikator zabezpieczeń (SID) użytkowników i grup we wdrożeniu Azure DevOps Server. Może być konieczne zmianę lub zaktualizowanie identyfikatora SID dla użytkowników i grup w jednym z następujących scenariuszy:
Zmienianie domeny wdrożenia
Zmiana z grupy roboczej na domenę lub z domeny na grupę roboczą
Migrowanie kont między domenami w usłudze Active Directory
Uwaga
Nie musisz uruchamiać tego polecenia, jeśli zmieniasz domeny w tym samym lesie usługi Active Directory. Azure DevOps Server automatycznie obsłuży zmiany identyfikatora SID dla ruchów w tym samym lesie.
TfsConfig identities [/change /fromdomain:<domainName1> /todomain:<domainName2>
[/account:<accountName> [/toaccount:<accountName>]] [/sqlInstance:<serverName> /databaseName:<databaseName>]
| Opcja | Opis |
|---|---|
| zmienianie | Określa, że chcesz zmienić tożsamości, a nie wyświetlać ich na liście. |
| fromdomain | Wymagane podczas korzystania z /change. Określa oryginalną domenę tożsamości, które chcesz zmienić. Jeśli zmieniasz się ze środowiska grupy roboczej, określa nazwę komputera. |
| todomain | Wymagane podczas korzystania z /change. Określa domenę, do której chcesz zmienić tożsamości. W przypadku zmiany w środowisku grupy roboczej określa nazwę komputera. |
| account | Określa nazwę konta, dla którego chcesz wyświetlić listę lub zmienić tożsamości. |
| toaccount | Określa nazwę konta, do którego chcesz zmienić tożsamości. |
| SQLInstance | Określa nazwę serwera z uruchomionym SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Jeśli określisz wystąpienie, musisz użyć następującego formatu: Servername\instancename |
| DatabaseName | Określa nazwę bazy danych konfiguracji dla Azure DevOps Server. |
Wymagania wstępne
Aby użyć polecenia tożsamości, musisz być członkiem grupy zabezpieczeń Team Foundation Administrators i członkiem roli administratora systemu dla wszystkich wystąpień SQL Server używanych przez serwer Team Foundation Server. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.
Uwagi
Opcjonalnie możesz określić bazę danych, aby zmienić tożsamości przed skonfigurowaniem serwera warstwy aplikacji na potrzeby wdrożenia. Na przykład można określić bazę danych, aby zmienić konto usługi podczas klonowania wdrożenia Azure DevOps Server.
Po zmianie tożsamości konto docelowe lub konta muszą już istnieć w systemie Windows.
Przed zaktualizowaniem właściwości kont, które zostaną zmienione za pomocą tego polecenia, należy poczekać na następną synchronizację tożsamości z systemem Windows. To wymaganie obejmuje zmiany z grupy na użytkownika, użytkownika do grupy i konta domeny na konto lokalne.
Przykłady
W poniższym przykładzie pokazano, jak wyświetlić listę nazw wszystkich użytkowników i grup systemu Windows przechowywanych w Azure DevOps Server oraz wyświetlać, czy identyfikator SID dla każdego użytkownika lub grupy jest zgodny z identyfikatorem SID w systemie Windows. Administratorzy domeny Contoso1 utworzyli grupy domen, takie jak Contoso1\\Developers i Contoso1\\Testers ułatwiające zarządzanie uprawnieniami między Azure DevOps Server, SQL Server Reporting Services i produktami programu SharePoint.
TfsConfig identities
TFSConfig - Team Foundation Server Configuration Tool
Copyright � Microsoft Corporation. All rights reserved.
Account Name Exists (see note 1) Matches (see note 2)
--------------------------------------------------------------------
CREATOR OWNER True True
Contoso1\hholt True True
BUILTIN\Administrators True True
Contoso1\Developers True True
Contoso1\Testers True True
Contoso1\PMs True True
Contoso1\jpeoples True True
Contoso1\Domain Admins True True
Contoso1\SVCACCT1 True True
9 security identifiers (SIDs) were found stored in Team Foundation Server. Of these, 9 were found in Windows. 0 had differing SIDs.
W poniższym przykładzie pokazano, jak zmienić identyfikatory SID dla wszystkich kont w Azure DevOps Server z domeny Contoso1 na identyfikatory SID dla kont, które mają zgodne nazwy w domenieContosoPrime. Tylko nazwy kont, które są zgodne, będą miały zaktualizowane identyfikatory SID. Jeśli na przykład hholt konto istnieje jako Contoso1\hholt i ContosoPrime\hholt, identyfikator SID konta zostanie zmieniony na identyfikator SID dla .ContosoPrime\hholt ContosoPrime\hholt Jeśli konto nie istnieje, identyfikator SID nie zostanie zaktualizowany dla elementu Contoso1\hholt.
TfsConfig identities /change /fromdomain:Contoso1 /todomain:ContosoPrime
W poniższym przykładzie pokazano, jak zmienić konto dla pojedynczego konta użytkownika na Contoso1\hholtkonto innego użytkownika, ContosoPrime\jpeoples.
TfsConfig identities /change /fromdomain:Contoso1 /todomain:ContosoPrime /account:hholt /toaccount:jpeoples
W poniższym przykładzie pokazano, jak zmienić identyfikator SID NT AUTHORITY\NETWORK SERVICE konta usługi używanego we wdrożeniu Azure DevOps Server podczas zmiany domeny wdrożenia z Contoso1 na ContosoPrime. Aby zmienić konto systemowe, takie jak usługa sieciowa, należy wykonać proces dwuetapowy. Najpierw należy zmienić konto usługi z NT AUTHORITY\NETWORK SERVICE na konto domeny w nowej domenie TempSVC, a następnie zmienić konto z powrotem na USŁUGĘ SIECIową na serwerze w nowej domenie. Baza danych konfiguracji jest hostowana na serwerze o nazwie ContosoMain w nazwanym wystąpieniu TeamDatabases w SQL Server.
TfsConfig identities /change /fromdomain:"NT AUTHORITY" /todomain:ContosoPrime /account:"NETWORK SERVICE"
/toaccount:TempSVC /SQLInstance:ContosoMain\TeamDatabases /DatabaseName:TFS_ConfigurationDB
TfsConfig identities /change /fromdomain:ContosoPrime /todomain:"NT AUTHORITY" /account:TempSVC
/toaccount:"NETWORK SERVICE"
Stanowiska
Za pomocą polecenia zadania można utworzyć plik dziennika zawierający szczegółowe informacje o ostatnim działaniu zadania dla określonej kolekcji projektów lub ponowić próbę wykonania zadania dla jednej lub wszystkich kolekcji projektów.
TfsConfig jobs /retry|dumplog [/CollectionName:<collectionName>] [/CollectionId:<id>]
| Opcja | Opis |
|---|---|
| retry | Wymagane, jeśli /dumplog nie jest używany. Określa, że najnowsze zadanie zostanie ponownie odcięte dla określonej kolekcji projektu. Jeśli używasz tej opcji, musisz również użyć /CollectionName lub /CollectionID opcji. |
| dumplog | Wymagane, jeśli /retry nie jest używany. Określa, że ostatnie działanie zadania dla kolekcji zostanie wysłane do pliku dziennika. Jeśli używasz tej opcji, musisz również użyć opcji /CollectionName lub /CollectionID . |
| CollectionName | Wymagane, jeśli /CollectionID nie jest używany. Określa nazwę kolekcji, dla której najnowsze zadanie zostanie ponowione (/ponowione) lub zarejestrowane (/dumplog). Jeśli chcesz określić wszystkie kolekcje, możesz użyć gwiazdki (*). |
| CollectionID | Wymagane, jeśli /CollectionName nie jest używany. Określa numer identyfikacyjny kolekcji, dla której najnowsze zadanie zostanie ponowione (/ponowione) lub zarejestrowane (/dumplog). |
Wymagania wstępne
Aby użyć polecenia zadania , musisz być członkiem grupy zabezpieczeń Administratorzy usługi Azure DevOps. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.
Uwagi
Aby wykonać zadanie interaktywnie, możesz otworzyć konsolę administracyjną usługi Azure DevOps, wybrać kartę Stan dla kolekcji, a następnie wybrać pozycję Ponów próbę zadania. Aby uzyskać więcej informacji, zobacz Otwieranie konsoli administracyjnej usługi Azure DevOps.
Przykład
W poniższym przykładzie pokazano, jak utworzyć plik dziennika, który zawiera listę najnowszych działań zadania dla Contoso Summer Intern Projects kolekcji projektów w Azure DevOps Server.
TfsConfig jobs /dumplog /CollectionName:"Contoso Summer Intern Projects"
Tryb offlineDetach
Polecenie offlineDetach służy do tworzenia bazy danych kolekcji w trybie offline w odłączonej bazie danych kolekcji offline.
TfsConfig offlineDetach /configurationDB:<databaseName>
/collectionDB:<databaseName>
| Opcja | Opis |
|---|---|
| configurationDB | Określa nazwę bazy danych konfiguracji do użycia. |
| collectionDB | Określa nazwę bazy danych kolekcji do odłączenia. |
Wymagania wstępne
Aby użyć polecenia offlineDetach, musisz być członkiem roli sysadmin dla określonego wystąpienia SQL Server.
Uwagi
To polecenie modyfikuje schemat określonej bazy danych kolekcji i nigdy nie powinno być uruchamiane względem baz danych, które są używane przez wdrożenie serwera Team Foundation Server. Jeśli bazy danych są używane przez wdrożenie serwera Team Foundation Server, użyj TfsConfig collection /detach zamiast tego.
To polecenie jest przydatne, gdy trzeba przywrócić pojedynczą bazę danych kolekcji z kopii zapasowej bez przywracania innych baz danych kolekcji, które są częścią tego samego wdrożenia Azure DevOps Server. Wcześniej wymagane było przywrócenie kompletnego i spójnego zestawu baz danych (konfiguracji i wszystkich kolekcji) do środowiska przejściowego, skonfigurowanie wdrożenia Azure DevOps Server przy użyciu tych baz danych i odłączenie jednej kolekcji zainteresowań.
Zamiast tego można teraz przywrócić spójne kopie bazy danych konfiguracji i bazy danych kolekcji zainteresowań i uruchomić polecenie offlineDetach . Odłączona baza danych kolekcji może być następnie dołączona do dowolnego wdrożenia Azure DevOps Server w odpowiedniej wersji.
Przykład
Poniższy przykład ilustruje odłączanie bazy danych kolekcji o nazwie , przy użyciu bazy danych konfiguracji o TFS_PrimaryCollectionnazwie TFS_Configuration, z obu w wystąpieniu SQL uruchomionym na serwerze o nazwie ContosoTemp w nazwanym wystąpieniu Backups.
TfsConfig offlineDetach /configurationDB:ContosoTemp\Backups;TFS_Configuration /collectionDB:ContosoTemp\Backups;TFS_PrimaryCollection
Serwer proxy
Za pomocą polecenia serwera proxy można zaktualizować lub zmienić ustawienia używane przez serwer proxy usługi Azure DevOps. Serwer proxy usługi Azure DevOps zapewnia obsługę rozproszonych zespołów w celu korzystania z kontroli wersji przez zarządzanie pamięcią podręczną pobranych plików kontroli wersji w lokalizacji rozproszonego zespołu. Konfigurując serwer proxy usługi Azure DevOps, można znacznie zmniejszyć przepustowość wymaganą w przypadku połączeń na całym obszarze. Ponadto nie trzeba zarządzać pobieraniem i buforowaniem plików wersji; zarządzanie plikami jest niewidoczne dla dewelopera, który korzysta z plików. W międzyczasie wszelkie wymiany metadanych i przekazywania plików nadal pojawiają się w Azure DevOps Server. Jeśli używasz Azure DevOps Services do hostowania projektu programistycznego w chmurze, możesz użyć polecenia proxy, aby nie tylko zarządzać pamięcią podręczną dla projektów w kolekcji hostowanej, ale także zarządzać niektórymi ustawieniami używanymi przez usługę.
Aby uzyskać więcej informacji na temat instalowania serwera proxy usługi Azure DevOps i początkowej konfiguracji serwera proxy,
Zobacz Instrukcje: instalowanie serwera proxy usługi Azure DevOps i konfigurowanie lokacji zdalnej. Aby uzyskać więcej informacji na temat konfigurowania serwera proxy na komputerach klienckich, zobacz Dokumentacja poleceń kontroli wersji usługi Azure DevOps.
TfsConfig proxy /add|delete|change [/Collection:<teamProjectCollectionURL> /account:<accountName>]
/Server:<TeamFoundationServerURL> [/inputs:Key1=Value1; Key2=Value2;...] [/continue]
| Opcja | Opis |
|---|---|
| add | Dodaje określony serwer lub kolekcję do listy serwerów proxy w pliku Proxy.config. Można uruchomić /dodać wiele razy, aby uwzględnić więcej kolekcji lub serwerów. W przypadku używania /add z kolekcją hostowaną na Azure DevOps Services zostanie wyświetlony monit o podanie poświadczeń w Azure DevOps Services. |
| zmienianie | Zmienia poświadczenia przechowywane jako konto usługi dla Azure DevOps Services. /change opcja jest używana tylko dla Azure DevOps Services; nie należy jej używać do lokalnych wdrożeń Azure DevOps Server. |
| delete | Usuwa określony serwer lub kolekcję z listy serwerów proxy w pliku Proxy.config. |
| account | Określa konto używane jako konto usługi dla serwera proxy w Azure DevOps Services. Ta opcja jest używana tylko dla Azure DevOps Services w połączeniu z /change opcji. Domyślne konto usługi używane na potrzeby Azure DevOps Services to "Usługa konta". |
| continue | Kontynuuje wykonywanie polecenia, nawet jeśli proces weryfikacji generuje ostrzeżenia. |
| Kolekcja | Określa adres URL kolekcji projektów hostowanej na Azure DevOps Services w AccountName.DomainName/CollectionName formacie . |
| account | Określa nazwę konta, które jest używane jako konto usługi dla Azure DevOps Services. Jeśli nazwa konta ma spacje, nazwa musi być ujęta w znaki cudzysłowu (""). Wszystkie znaki specjalne w nazwach kont muszą być określone zgodnie ze składnią wiersza polecenia. |
| account | Określa adres URL wdrożenia Azure DevOps Server w ServerURL:Port/tfs formacie. |
| PersonalAccessTokenFile | Opcjonalnie określa ścieżkę do pliku zawierającego osobisty token dostępu. Ten token będzie używany do uwierzytelniania w kolekcji lub na koncie podczas rejestrowania serwera proxy. (Dodano w programie TFS 2018 Update 1) |
| Wejścia | Opcjonalny. Określa dodatkowe ustawienia i wartości do użycia podczas konfigurowania serwera proxy.! Na przykład wartości i GvfsProjectNameGvfsRepositoryName mogą służyć do konfigurowania repozytorium Git do użycia z systemem plików Git Virtual File System (GVFS) (dodano w programie TFS 2018 Update 1) |
Wymagania wstępne
Aby użyć polecenia serwera proxy , musisz być członkiem grupy zabezpieczeń Administratorzy usługi Azure DevOps i administratorem na serwerze proxy. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.
Uwagi
Użyj polecenia serwera proxy, aby zaktualizować istniejącą konfigurację serwera proxy Azure DevOps Server. Nie można użyć polecenia serwera proxy do początkowej instalacji i konfiguracji serwera proxy.
Przykłady
W poniższym przykładzie pokazano, jak dodać wdrożenie Azure DevOps Server o nazwie FABRIKAM do listy serwerów proxy.
TfsConfig proxy /add /Server:http://www.fabrikam.com:8080/tfs
W poniższym przykładzie pokazano, jak dodać kolekcję projektów hostowaną na Azure DevOps Services do listy serwerów proxy przy użyciu osobistego tokenu dostępu do uwierzytelniania. Ten token będzie używany tylko do rejestrowania serwera proxy przy użyciu konta Azure DevOps Services — domyślne konto usługi będzie nadal używane do uruchamiania serwera proxy. Ten parametr został dodany w programie TFS 2018 Update 1 w celu obsługi rejestrowania serwera proxy z Azure DevOps Services bez konieczności monitu logowania.
TfsConfig proxy /add /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver
W poniższym przykładzie pokazano, jak dodać kolekcję projektów do listy serwerów proxy. W tym przykładzie użyto osobistego tokenu dostępu do uwierzytelniania w kolekcji określonej za pomocą parametru /Collection . Osobisty token dostępu do użycia jest zapisywany w pliku pod adresem c:\PersonalAccessToken.txt.
TfsConfig proxy /add /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver
/PersonalAccessTokenFile:c:\PersonalAccessToken.txt
W poniższym przykładzie pokazano, jak zmienić konto usługi używane przez serwer proxy dla kolekcji projektów hostowanej na Azure DevOps Services. Kolekcja ma nazwę PhoneSaver, nazwa konta używana dla Azure DevOps Services to HelenaPetersen.fabrikam.com, a konto usługi używane przez serwer proxy jest zmieniane na My Proxy Service Account. Ponieważ nazwa konta zawiera spacje, cudzysłowy są używane do uwzględnienia nazwy.
TfsConfig proxy /change /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver
/account:"My Proxy Service Account"
W poniższym przykładzie pokazano, jak dodać repozytorium Git do użycia z systemem GVFS.
TfsConfig proxy /add /Collection:https://HelenaPetersen.tfs.visualstudio.com/PhoneSaver /inputs:GvfsProjectName=PhoneSaver;GvfsRepositoryName=AnotherRepository
RebuildWarehouse
Za pomocą polecenia rebuildWarehouse można ponownie skompilować bazy danych SQL Server Reporting Services i SQL Server Analysis Services używane przez Azure DevOps Server.
TfsConfig rebuildWarehouse /analysisServices | /all [/ReportingDataSourcePassword:Password]
| Opcja | Opis |
|---|---|
| analysisServices | Wymagane, jeśli /all nie jest używany. Określa, że tylko baza danych dla usług Analysis Services zostanie ponownie skompilowana. Jeśli dla usług Analysis Services nie istnieje żadna baza danych, należy również użyć opcji /reportingDataSourcePassword . |
| all | Wymagane, jeśli /analysisServices nie jest używany. Określa, że wszystkie bazy danych raportowania i analizy używane przez Azure DevOps Server zostaną przebudowane. |
| reportingDataSourcePassword | Wymagane, jeśli baza danych TFS_Analysis nie istnieje. Określa hasło konta używanego jako konto źródeł danych dla SQL Server Reporting Services (TFSReports). Aby uzyskać więcej informacji, zobacz Konta usług i zależności w Azure DevOps Server. |
Wymagania wstępne
Aby użyć polecenia rebuildWarehouse , musisz być członkiem następujących grup:
Grupa zabezpieczeń Administratorzy usługi Azure DevOps i grupa zabezpieczeń Administratorzy na serwerze lub serwerach z uruchomioną konsolą administracyjną usługi Azure DevOps
Grupa sysadmin na serwerze lub serwerach z uruchomionym wystąpieniem SQL Server hostujących bazy danych dla Azure DevOps Server
Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.
Uwagi
To polecenie można użyć podczas przenoszenia lub dzielenia kolekcji projektu, przywracania danych lub zmiany konfiguracji wdrożenia.
Aby interaktywnie rozpocząć ponowne kompilowanie tych baz danych, możesz użyć węzła Raportowanie w konsoli administracyjnej usługi Azure DevOps. Aby uzyskać więcej informacji, zobacz Otwieranie konsoli administracyjnej usługi Azure DevOps.
Przykład
W poniższym przykładzie pokazano, jak ponownie skompilować bazę danych usług Analysis Services na potrzeby wdrożenia Azure DevOps Server.
TfsConfig rebuildWarehouse /analysisServices
TFSConfig - Team Foundation Server Configuration Tool
Copyright � Microsoft Corporation. All rights reserved.
The Analysis Services database was successfully rebuilt.
Rejestrowanie bazy danychDB
Użyj bazy danych registerDB, aby zaktualizować nazwę serwera, który hostuje bazę danych konfiguracji w Azure DevOps Server. To polecenie można użyć podczas przywracania bazy danych konfiguracji do nowego sprzętu lub zmiany domeny wdrożenia.
TfsConfig registerDB /sqlInstance:<serverName> /databaseName:<databaseName>
| Opcja | Opis |
|---|---|
| SQLInstance | Wymagane. Określa nazwę serwera z uruchomionym SQL Server i nazwę wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Jeśli określisz wystąpienie, musisz użyć formatu: ServerName\InstanceName. |
| databaseName | Wymagane. Określa nazwę bazy danych konfiguracji. Domyślnie jest to Tfs_Configuration. |
Wymagania wstępne
Aby użyć polecenia registerDB, musisz być członkiem grupy Administratorzy usługi Azure DevOps na serwerze warstwy aplikacji dla usługi Azure DevOps i członkiem grupy sysadmin w SQL Server na serwerze warstwy danych dla usługi Azure DevOps. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.
Uwagi
Przed użyciem tego polecenia należy utworzyć kopię zapasową baz danych dla Azure DevOps Server.
Aby polecenie registerDB powiodło się, należy uruchomić następujące pule aplikacji i programy:
- Azure DevOps Server pula aplikacji (pula aplikacji)
- ReportServer (pula aplikacji)
- SQL Server Reporting Services (program)
Aby to polecenie działało poprawnie, należy podać dokładną nazwę lub adres bazy danych konfiguracji. Jeśli musisz zmienić serwer, na którym jest przechowywana ta baza danych, należy upewnić się, że Azure DevOps Server wskazuje nową lokalizację.
Przykład
Poniższy przykład przekierowuje Azure DevOps Server do bazy danych konfiguracji znajdującej się na serwerze ContosoMain w wystąpieniu TeamDatabasesSQL Server .
TfsConfig registerDB /SQLInstance:ContosoMain\TeamDatabases /databaseName:Tfs_Configuration
Ponowne mapowanie baz danych
Polecenie remapDBs przekierowuje Azure DevOps Server do jego baz danych, gdy są one przechowywane na więcej niż jednym serwerze i przywracasz, przenosisz lub w inny sposób zmieniasz konfigurację wdrożenia. Na przykład należy przekierować Azure DevOps Server do dowolnych baz danych kolekcji projektów, jeśli są one hostowane na oddzielnym serwerze lub serwerach z bazy danych konfiguracji. Należy również przekierować Azure DevOps Server do serwera lub serwerów z systemem SQL Server Analysis Services lub SQL Server Reporting Services, jeśli te bazy danych są hostowane na oddzielnym serwerze lub wystąpieniu z bazy danych konfiguracji.
TfsConfig remapDBs /DatabaseName:ServerName;DatabaseName /SQLInstances:ServerName1,ServerName2
[/AnalysisInstance:<serverName>] [/AnalysisDatabaseName:<databaseName>]
[/preview] [/continue]
| Opcja | Opis |
|---|---|
| DatabaseName | Określa nazwę serwera, który hostuje bazę danych, którą chcesz mapować dla Azure DevOps Server, oprócz nazwy samej bazy danych. |
| SqlInstances | Określa nazwę serwera, na którym działa SQL Server, oprócz nazwy wystąpienia, jeśli chcesz użyć wystąpienia innego niż wystąpienie domyślne. Jeśli określasz więcej niż jeden serwer, musisz użyć przecinka, aby oddzielić wiele par nazw serwerów i wystąpień. |
| AnalysisInstance | Opcjonalny. Określa nazwę serwera i wystąpienia, które hostuje SQL Server Analysis Services. Użyj tej opcji, aby określić serwer i wystąpienie hostujące bazę danych usług Analysis Services. |
| AnalysisDatabaseName | Opcjonalny. Określa nazwę bazy danych usług Analysis Services, której chcesz użyć z Azure DevOps Server, jeśli masz więcej niż jedną taką bazę danych na serwerze określonym z opcją /AnalysisInstance. |
| preview | Opcjonalny. Wyświetla akcje, które należy wykonać, aby zaktualizować konfigurację. |
| continue | Opcjonalny. Określa, że polecenie RemapDB powinno kontynuować, nawet jeśli podczas próby zlokalizowania co najmniej jednej bazy danych wystąpi błąd. Jeśli używasz /continue opcji, wszystkie kolekcje, których bazy danych nie znajdują się na serwerze lub serwerach, które określisz, zostaną ponownie skonfigurowane do używania serwera i wystąpienia hostujące bazę danych konfiguracji. |
Wymagania wstępne
Aby użyć polecenia remapDBs, musisz być członkiem grupy zabezpieczeń Administratorzy usługi Azure DevOps i członkiem grupy zabezpieczeń sysadmin dla wszystkich baz danych SQL Server, które Azure DevOps Server używa. Aby uzyskać więcej informacji, zobacz Dokumentacja uprawnień dla Azure DevOps Server.
Uwagi
Użyj polecenia remapDBs, aby ponownie skonfigurować Azure DevOps Server do używania różnych serwerów i wystąpień SQL Server z serwerów i wystąpień w oryginalnej instalacji.
Przykład
W poniższym przykładzie pokazano, jak przekierować Azure DevOps Server do bazy danych TFS_Configurationkonfiguracji .
Ta baza danych jest hostowana w ContosoMain nazwanym wystąpieniu TeamDatabases.
Bazy danych kolekcji projektów są przechowywane zarówno ContosoMain\TeamDatabases w wystąpieniu domyślnym, jak i w systemie Contoso2.
TfsConfig remapDBs /DatabaseName:ContosoMain\TeamDatabases;TFS_Configuration
/SQLInstances:ContosoMain\TeamDatabases,Contoso2
RepairJobQueue
Polecenie repairJobQueue służy do naprawiania zaplanowanych zadań, które zostały zatrzymane dla hostów wdrożeń i kolekcji.
TfsConfig repairJobQueue
Wymagania wstępne
Aby użyć polecenia repairJobQueue , musisz być członkiem lokalnej grupy administratorów na maszynie z uruchomionym programem TfsConfig. Musisz również być członkiem roli zabezpieczeń administratora systemu dla wszystkich wystąpień SQL Server używanych przez wdrożenie Azure DevOps Server.
Uwagi
Zwykle należy użyć polecenia repairJobQueue , jeśli zauważysz, że zaplanowane zadania nie są uruchomione.
Polecenie nie bierze żadnych argumentów i wymaga skonfigurowania Azure DevOps Server wdrożenia.
Przykład
TfsConfig repairJobQueue
Ustawienia
Za pomocą polecenia settings można zautomatyzować zmiany w ujednoliconym lokalizatorze zasobów (URL), który jest używany przez interfejs powiadomień i adres serwera dla Azure DevOps Server. Domyślnie adres URL interfejsu powiadomień i adres URL serwera są zgodne w Azure DevOps Server, ale można skonfigurować oddzielne adresy URL. Na przykład możesz użyć innego adresu URL dla automatycznych wiadomości e-mail generowanych Azure DevOps Server. To narzędzie należy uruchomić z poziomu warstwy aplikacji, aby zaktualizować wszystkie serwery, aby korzystały z nowych adresów URL.
Aby zmienić te adresy URL interaktywnie lub po prostu wyświetlić bieżące ustawienia, możesz użyć konsoli administracyjnej usługi Azure DevOps. Zobacz Krótki przewodnik po zadaniach administracyjnych.
TfsConfig settings [/publicURL:URL]
| Opcja | Opis |
|---|---|
| publicUrl | Określa adres URL serwera warstwy aplikacji dla usługi Azure DevOps. Ta wartość jest przechowywana w bazie danych konfiguracji dla usługi Azure DevOps. |
Wymagania wstępne
Musisz być członkiem grupy zabezpieczeń Administratorzy usługi Azure DevOps i administratorzy na serwerze warstwy aplikacji. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.
Uwagi
Polecenie ustawień zmienia informacje o połączeniu dla komunikacji między serwerami we wdrożeniu Azure DevOps Server. Adres URL określony w /publicURL musi być dostępny dla wszystkich serwerów we wdrożeniu.
Przykład
Poniższy przykład zmienia wartość elementu NotificationURL na http://contoso.example.com/tfs i wartość ServerURL na http://contoso.example.com:8080/tfs.
TfsConfig settings /publicURL:http://contoso.example.com:8080/tfs
Konfigurowanie
Polecenie instalatora służy do odinstalowywania funkcji, które są obecnie skonfigurowane na maszynie, na której jest uruchamiane polecenie.
TfsConfig setup /uninstall:<feature[,feature,...]>
Opcja
Opis
/Odinstalować
Określa co najmniej jedną funkcję do odinstalowania z maszyny, na której uruchamiasz polecenie. Dostępne opcje to: All, ApplicationTier, Search i VersionControlProxy.
Wymagania wstępne
Aby użyć polecenia konfiguracji , musisz być członkiem grupy zabezpieczeń Administratorzy usługi Azure DevOps.
Przykłady
Poniższy przykład odinstalowuje wszystkie funkcje Azure DevOps Server z bieżącej maszyny.
TfsConfig setup /uninstall:All
Poniższy przykład odinstalowuje warstwę aplikacji i funkcje kompilacji z bieżącej maszyny.
TfsConfig setup /uninstall:ApplicationTier
TCM
Podczas uaktualniania do najnowszej wersji Azure DevOps Server system automatycznie próbuje uaktualnić składniki zarządzania testami, w tym plany testów i zestawy.
Jeśli migracja automatyczna nie powiedzie się, użyj polecenia TCM , aby uaktualnić plany testów i zestawy testów ręcznie do odpowiednich typów elementów roboczych (WIT).
TFSConfig TCM /upgradeTestPlans|upgradeStatus /CollectionName:CollectionName /TeamProject:TeamProjectName
Opcja
Opis
/upgradeTestPlans
Wymagane, chyba że / upgradeStatus jest używany.
Konwertuje istniejący plan testów i zestawy testów, aby wskazywały plany testów oparte na elementach roboczych i zestawy testów. Aktualizuje również istniejące dane zarządzania testami i linki między innymi istniejącymi artefaktami testowymi, takimi jak punkty testów, przebiegi testów i wyniki testów.
/upgradeStatus
Wymagane, chyba że / upgradeTestPlans jest używany.
Raportuje stan migracji danych testowych dla określonego projektu. Będzie również wskazywać, czy określony projekt ma jakiekolwiek plany testów.
/CollectionName:CollectionName
Wymagane. Określa kolekcję projektów zawierającą projekt, dla którego chcesz przeprowadzić migrację danych testowych lub sprawdź stan migracji.
Jeśli w nazwie kolekcji projektu znajdują się spacje, należy ująć nazwę w znaki cudzysłowu, na przykład "Fabrikam Fiber Collection".
/TeamProjectName:TeamProjectName
Wymagane. Określa projekt, dla którego chcesz przeprowadzić migrację danych testowych lub sprawdź stan migracji. Ten projekt musi być zdefiniowany w kolekcji określonej przy użyciu /collectionName parametru.
Jeśli w nazwie projektu znajdują się spacje, należy ująć nazwę w cudzysłów, na przykład "Mój projekt".
Wymagania wstępne
Musisz być członkiem grupy zabezpieczeń Administratorzy programu Team Foundation i administratorem na serwerze warstwy aplikacji.
Zobacz Ustawianie uprawnień administratora dla Azure DevOps Server.
Uwagi
Aby użyć tego polecenia, serwer warstwy aplikacji musi zostać uaktualniony do najnowszej wersji programu Azure DevOps Server 2019.
Przed użyciem polecenia TCM należy najpierw zaimportować definicję elementu roboczego planu testu i kategorię planu testów do projektu.
Aby dowiedzieć się więcej o migracji i korzystaniu z tego polecenia, zobacz Ręczne aktualizacje do obsługi zarządzania testami.
Polecenie TCM jest stosowane do poszczególnych projektów. Jeśli musisz uaktualnić plany testów w więcej niż jednym projekcie, musisz uruchomić go osobno dla każdego projektu.
Musisz uruchomić polecenie TCM z katalogu narzędzi dla Azure DevOps Server. Domyślnie ta lokalizacja to: drive:\%programfiles%\TFS 12.0\Tools.
Polecenie TCM jest używane tylko w przypadku niepowodzenia automatycznej migracji istniejących danych testowych.
Aby dowiedzieć się więcej o migracji i korzystaniu z tego polecenia, ręczne aktualizacje do obsługi zarządzania testami. Jeśli nie możesz uzyskać dostępu do planów testów lub zestawów testów zdefiniowanych przed uaktualnieniem serwera, uruchom polecenie TFSConfig TCM upgradeStatus , aby określić stan migracji.
Uruchamiasz polecenie TCM dla pojedynczego projektu. Jeśli musisz uaktualnić więcej niż jeden projekt, musisz uruchomić go na każdym projekcie z kolei.
Przykłady
W poniższym przykładzie pokazano, jak sprawdzić stan uaktualnienia planu testów w projekcie Fabrikam Fiber hostowanym w domyślnej kolekcji projektów (DefaultCollection):
tfsconfig tcm /upgradeStatus /CollectionName:DefaultCollection /TeamProject:"Fabrikam Fiber"
Instalacji nienadzorowanej
Dostępność poleceń: Azure DevOps Server 2019
Polecenie nienadzorowane jest przeznaczone dla użytkowników, którzy znają Azure DevOps Server i proces konfiguracji oraz którzy muszą zainstalować Azure DevOps Server na różnych maszynach.
Jeśli na przykład używasz usługi Azure DevOps Build, możesz użyć polecenia nienadzorowanego , aby zainstalować wiele serwerów kompilacji przy użyciu tego samego pliku konfiguracji.
Użyj opcji /create , aby utworzyć plik nienadzorowany. Ten plik definiuje wszystkie parametry konfiguracji instalacji Azure DevOps Server. Następnie użyj /configure opcji, aby rzeczywiście wykonać konfigurację.
Ten proces umożliwia skonfigurowanie Azure DevOps Server od początku do końca bez konieczności dostarczania danych wejściowych podczas procesu instalacji. W przypadku wielu instalacji pomaga to również zapewnić, że dokładnie te same parametry konfiguracji są używane na wielu serwerach.
TfsConfig unattend /create|configure /type:InstallType /unattendfile:ConfigurationFileName
[/inputs:Key1=Value1; Key2=Value2;...] [/verify] [/continue]
| Opcja | Opis |
|---|---|
| create | Tworzy plik nienadzorowany o określonej nazwie i parametrach. |
| konfigurowanie | Konfiguruje Azure DevOps Server przy użyciu określonego pliku i parametrów nienadzorowanych. Musisz użyć /type lub /unattendfile z tą opcją. |
| typ | Określa typ konfiguracji do użycia. Jeśli używasz /configure, /type lub /unattendfile są wymagane, ale nie można użyć obu. |
| plik nienadzorowany | Określa plik nienadzorowany do utworzenia lub użycia, w zależności od tego, czy początkowy parametr to /create, czy /configure. W przypadku używania /configure wymagany jest plik /unattendfile lub /type. |
| Wejścia | Opcjonalny. Jeśli używasz /create, określa ustawienia i wartości do użycia podczas tworzenia pliku nienadzorowanego. Jeśli używasz /configurespecifies dodatkowych ustawień i wartości do użycia w połączeniu z plikiem nienadzorowanym. Alternatywą dla używania /inputs jest ręczne edytowanie pliku nienadzorowanego w dowolnym edytorze zwykłego tekstu. Jest to konieczne w przypadku niektórych typów wejściowych, takich jak ServiceAccountPassword lub PersonalAccessToken, ponieważ nie można ustawić tych wartości wpisów tajnych przy użyciu /inputs parametru. |
| verify | Opcjonalny. Określa przebieg konfiguracji, który wykonuje tylko testy weryfikacyjne na podstawie pliku nienadzorowanego, danych wejściowych i typu konfiguracji. Jest to alternatywa dla wykonania pełnej konfiguracji. |
| continue | Opcjonalny. Określa, że /create lub /configure powinny być kontynuowane niezależnie od ostrzeżeń z kontroli weryfikacji. |
| InstallType | Opis |
|---|---|
| NewServerBasic | Konfiguruje podstawowe usługi programistyczne dla Azure DevOps Server. Obejmuje to kontrolę źródła, elementy robocze, kompilację i opcjonalnie Search. |
| NewServerAdvanced | Konfiguruje podstawowe usługi programistyczne i umożliwia opcjonalną konfigurację integracji z usługami Reporting Services. |
| Uaktualnienie | Uaktualnia Azure DevOps Server do bieżącej wersji z obsługiwanej poprzedniej wersji. |
| PreProductionUpgrade | Przetestuj uaktualnienie w istniejącym wdrożeniu Azure DevOps Server w środowisku przedprodukcyjnym. Zazwyczaj odbywa się to przy użyciu baz danych przywróconych z kopii zapasowych produkcyjnych. Ten scenariusz obejmuje dodatkowe kroki, aby upewnić się, że nowe wdrożenie nie będzie zakłócać wdrożenia produkcyjnego. |
| ApplicationTierOnlyBasic | Skonfiguruj nową warstwę aplikacji przy użyciu istniejących ustawień z dostarczonej bazy danych konfiguracji. Ta opcja umożliwia szybkie uruchamianie nowej warstwy aplikacji przy użyciu istniejących ustawień. Jeśli chcesz zmienić istniejące ustawienia, zamiast tego użyj typu Advanced ApplicationTierOnlyAdvanced. |
| ApplicationTierOnlyAdvanced | Skonfiguruj nową warstwę aplikacji z pełną kontrolą nad wszystkimi ustawieniami. Ustawienia będą domyślne dla istniejących wartości z podanej bazy danych konfiguracji. Jeśli chcesz zachować wszystkie istniejące ustawienia, zamiast tego użyj typu ApplicationTierOnlyBasic. |
| Clone | Skonfiguruj nowe wdrożenie Azure DevOps Server, które jest klonem istniejącego wdrożenia. Zazwyczaj odbywa się to przy użyciu baz danych przywróconych z kopii zapasowych produkcyjnych, aby utworzyć środowisko, w którym można przetestować zmiany konfiguracji, rozszerzenia i inne modyfikacje. Ten scenariusz obejmuje dodatkowe kroki, aby upewnić się, że nowe wdrożenie nie będzie zakłócać wdrożenia produkcyjnego. |
| Serwer proxy | Konfiguruje usługę serwera proxy kontroli wersji. |
Wymagania wstępne
Musisz być członkiem grupy Administratorzy na komputerze, na którym instalujesz oprogramowanie.
W zależności od typu instalacji może być również wymagane dodatkowe uprawnienia administratora.
Jeśli na przykład używasz polecenia nienadzorowanego do zainstalowania Azure DevOps Server, musisz być członkiem grupy sysadmin w wystąpieniu SQL Server, które będzie obsługiwać Azure DevOps Server. Aby uzyskać więcej informacji, zobacz sekcję Q & A w sekcji Dodawanie administratorów na poziomie serwera do Azure DevOps Server.
Uwagi
Aby można było skonfigurować Azure DevOps Server za pomocą polecenia nienadzorowanego, należy utworzyć konta usług, które będą używane w ramach wdrożenia. Należy również zainstalować dowolne wstępnie wymagane oprogramowanie dla wybranego typu instalacji. Obejmuje to Azure DevOps Server siebie. Musisz zainstalować Azure DevOps Server, ale nie musisz go konfigurować, ponieważ polecenie nienadzorowane wykona to za Ciebie.
Polecenie nienadzorowane konfiguruje składniki Azure DevOps Server. Nie wykonuje początkowej instalacji oprogramowania. Konfiguruje oprogramowanie zgodnie ze specyfikacjami po wystąpieniu bitów na komputerze.
Przykłady
W poniższym przykładzie pokazano, jak utworzyć plik nienadzorowany dla podstawowej instalacji Azure DevOps Server.
TfsConfig unattend /create /type:basic /unattendfile:configTFSBasic.ini
W tym przykładzie plik nienadzorowany jest tworzony w tym samym katalogu co polecenie . Plik dziennika jest tworzony w ramach polecenia, a lokalizacja pliku jest zwracana w poleceniu w ramach wykonywania polecenia.
W poniższym przykładzie pokazano, jak określić repozytorium Git do użycia z systemem GVFS podczas konfiguracji.
TfsConfig unattend /configure /type:proxy /inputs:ProjectCollectionUrl=http://FabrikamFiberTFS:8080/tfs/defaultcollection;GvfsProjectName=Fabrikam-Fiber-Git;GvfsRepositoryName=TestGit
W poniższym przykładzie pokazano, jak utworzyć plik nienadzorowany na potrzeby konfiguracji serwera proxy usługi Azure DevOps.
Ważne
W tym przykładzie, jeśli administratorzy chcą użyć osobistego tokenu dostępu do uwierzytelniania, będą musieli ręcznie edytować plik, aby określić wartość osobistego tokenu dostępu. Można to osiągnąć, dodając wiersz osobistego tokenu dostępu w utworzonym pliku nienadzorowanym, takim jak: PersonalAccessToken=PersonalAccessTokenValue.
TfsConfig unattend /create /type:proxy "/inputs:ProjectCollectionUrl=http://FabrikamFiberTFS:8080/tfs/defaultcollection" /unattendFile:c:\unattend.txt
W poniższym przykładzie pokazano, jak utworzyć plik nienadzorowany dla konfiguracji Azure DevOps Server Kompilacja na serwerze przy użyciu FabrikamFiber\BuildSVC konta usługi kompilacji, a następnie skonfigurować Azure DevOps Server Build przy użyciu tego pliku nienadzorowanego.
Ważne
W tym przykładzie po utworzeniu pliku nienadzorowanego administrator ręcznie edytuje plik, aby określić hasło dla konta usługi kompilacji. Dodanie hasła jako danych wejściowych przy użyciu ServiceAccountPassword=Password; nie powoduje dodania informacji o haśle do pliku.
TfsConfig unattend /create /type:build /unattendfile:configTFSBuild.ini
/inputs:IsServiceAccountBuiltIn=false;ServiceAccountName=FabrikamFiber\\BuildSVCTFSConfig
TfsConfig unattend /configure /unattendfile:configTFSBuild.ini
Pierwsze polecenie zwraca następujące polecenie:
Microsoft (R) TfsConfig - Team Foundation Server Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.
Command: unattend
Logging sent to file C:\ProgramData\Microsoft\Team Foundation\Server Configuration\Logs\TFS_Build Configuration_0512_203133.log
Drugie polecenie zwraca następujące informacje, w tym nazwę serwera, na którym skonfigurowano kompilację usługi Azure DevOps, oraz kolekcję projektów skojarzona FabrikamFiberTFS z kontrolerem DefaultCollection:
Microsoft (R) TfsConfig - Team Foundation Server Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.
Command: unattend
---------------------------------------------
Inputs:
---------------------------------------------
Feedback
Send Feedback: True
Build Resources
Configuration Type: create
Agent Count: 1
New Controller Name: FabrikamFiberTFS - Controller
Clean Up Resources: False
Project Collection
Collection URL: http://FabrikamFiberTFS:8080/tfs/defaultcollection
Windows Service
Service Account: FabrikamFiber\BuildSVC
Service Password: ********
Advanced Settings *
Port: 9191
---------------------------------------------
Running Readiness Checks
---------------------------------------------
[1/2] System Verifications
[2/2] Build Service Verifications
---------------------------------------------
Configuring
---------------------------------------------
root
[1/4] Install Team Foundation Build Service
Installing Windows services ...
Adding service account to groups ...
Setting ACL on a windows service
[2/4] Enable Event Logging
Adding event log sources ...
Token replace a config file
RegisterBuildEtwProvider
Configuring ETW event sources ...
[3/4] Register with Team Foundation Server
Registering the build service
[4/4] Start Team Foundation Build Service
StartBuildHost
Starting Windows services ...
Marking feature configured status
[Info] [Register with Team Foundation Server] Firewall exception added for port
9191
TeamBuild completed successfully.
Logging sent to file C:\ProgramData\Microsoft\Team Foundation\Server Configuration\Logs\TFS_Build Configuration_0512_203322.log
ZipLogs
Polecenie ziplogs zostało zaprojektowane tak, aby zbierać dzienniki i usuwać plik zip w lokalizacji ProgramData\Microsoft\Azure DevOps\Server Configuration.
Pliki zip TfsConfig
TfsConfig zipLogs