informacje o wersji Azure DevOps Server 2020

| Developer Community Wymagania systemowe | Postanowienia | licencyjneDevOps Blog | SHA-1 Skróty SHA-1

Ten artykuł zawiera informacje dotyczące najnowszej wersji Azure DevOps Server.

Aby dowiedzieć się więcej na temat instalowania lub uaktualniania wdrożenia Azure DevOps Server, zobacz wymagania Azure DevOps Server. Aby pobrać produkty usługi Azure DevOps, odwiedź stronę pobierania Azure DevOps Server.

Bezpośrednie uaktualnienie do wersji Azure DevOps Server 2020 jest obsługiwane w wersji Azure DevOps Server 2019 lub Team Foundation Server 2015 lub nowszej. Jeśli wdrożenie serwera TFS jest na serwerze TFS 2010 lub starszym, przed uaktualnieniem do wersji Azure DevOps Server 2019 należy wykonać pewne kroki tymczasowe. Aby dowiedzieć się więcej, zobacz Instalowanie i konfigurowanie lokalnej usługi Azure DevOps.

---

Bezpieczne uaktualnianie z Azure DevOps Server 2019 do Azure DevOps Server 2020

Azure DevOps Server 2020 r. wprowadza nowy model przechowywania przebiegu potoku (kompilacja), który działa na podstawie ustawień na poziomie projektu.

Azure DevOps Server 2020 r. obsługuje przechowywanie kompilacji inaczej w oparciu o zasady przechowywania na poziomie potoku. Niektóre konfiguracje zasad prowadzą do usunięcia przebiegów potoku po uaktualnieniu. Uruchomienia potoków, które zostały ręcznie zachowane lub są zachowywane przez wydanie, nie zostaną usunięte po uaktualnieniu.

Przeczytaj nasz wpis w blogu, aby uzyskać więcej informacji na temat bezpiecznego uaktualniania z Azure DevOps Server 2019 do Azure DevOps Server 2020.

Azure DevOps Server 2020 Update 0.2 Patch 6 Data wydania: 14 listopada 2023 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020 Update 0.2, która zawiera poprawki dla następujących elementów.

• Rozszerzono listę dozwolonych znaków zadań programu PowerShell dla sprawdzania poprawności parametrów argumentów zadań powłoki.

Uwaga

Aby zaimplementować poprawki dla tej poprawki, należy wykonać kilka kroków w celu ręcznej aktualizacji zadań.

Instalowanie poprawek

Ważne

Opublikowaliśmy aktualizacje agenta usługi Azure Pipelines z poprawką 4 wydaną 12 września 2023 r. Jeśli aktualizacje agenta nie zostały zainstalowane zgodnie z opisem w informacjach o wersji poprawki 4, zalecamy zainstalowanie tych aktualizacji przed zainstalowaniem poprawki 6. Nowa wersja agenta po zainstalowaniu poprawki 4 będzie mieć wartość 3.225.0.

Konfigurowanie rozwiązania TFX

1. Wykonaj kroki opisane w dokumentacji przekazywania zadań do kolekcji projektów , aby zainstalować i zalogować się za pomocą narzędzia tfx-cli.

Aktualizowanie zadań przy użyciu narzędzia TFX

File	Skrót SHA-256
Tasks20231103.zip	389BA66EEBC3262FB83402E21373CE20AE040F70461B9F9EFCED5034D2E5

1. Pobierz i wyodrębnij Tasks20231103.zip.
2. Zmień katalog na wyodrębnione pliki.
3. Wykonaj następujące polecenia, aby przekazać zadania:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Wymagania dotyczące potoku

Aby można było użyć nowego zachowania, należy ustawić zmienną AZP_75787_ENABLE_NEW_LOGIC = true w potokach korzystających z zadań, których dotyczy problem.

• W wersji klasycznej:

  Zdefiniuj zmienną na karcie zmiennej w potoku.

• Przykład YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 5 Data wydania: 10 października 2023 r.

Ważne

Opublikowaliśmy aktualizacje agenta usługi Azure Pipelines z poprawką 4 wydaną 12 września 2023 r. Jeśli aktualizacje agenta nie zostały zainstalowane zgodnie z opisem w informacjach o wersji poprawki 4, zalecamy zainstalowanie tych aktualizacji przed zainstalowaniem poprawki 5. Nowa wersja agenta po zainstalowaniu poprawki 4 będzie mieć wartość 3.225.0.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020 Update 0.2, która zawiera poprawki dla następujących elementów.

• Usunięto usterkę polegającą na tym, że tożsamość "Właściciel analizy" jest wyświetlana jako nieaktywna tożsamość na maszynach uaktualnianych poprawek.

Azure DevOps Server 2020 Update 0.2 Patch 4 Data wydania: 12 września 2023 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020 Update 0.2, która zawiera poprawki dla następujących elementów.

• CVE-2023-33136: luka w zabezpieczeniach dotycząca zdalnego wykonywania kodu Azure DevOps Server.
• CVE-2023-38155: luka w zabezpieczeniach dotycząca podniesienia uprawnień Azure DevOps Server i serwera Team Foundation Server.

Ważne

Wdróż poprawkę w środowisku testowym i upewnij się, że potoki środowiska działają zgodnie z oczekiwaniami przed zastosowaniem poprawki do środowiska produkcyjnego.

Uwaga

Aby zaimplementować poprawki dla tej poprawki, należy wykonać kilka kroków w celu ręcznego zaktualizowania agenta i zadań.

Instalowanie poprawek

1. Pobierz i zainstaluj Azure DevOps Server 2020 Update 0.2 patch 4.

Aktualizowanie agenta usługi Azure Pipelines

1. Pobierz agenta z: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Aby wdrożyć agenta, wykonaj kroki opisane w dokumentacji własnych agentów systemu Windows .  

Uwaga

AZP_AGENT_DOWNGRADE_DISABLED musi być ustawiona na wartość "true", aby zapobiec obniżeniu poziomu agenta. W systemie Windows następujące polecenie może być używane w administracyjnym wierszu polecenia, po którym następuje ponowny rozruch. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Konfigurowanie rozwiązania TFX

1. Wykonaj kroki opisane w dokumentacji przekazywania zadań do kolekcji projektów , aby zainstalować i zalogować się za pomocą narzędzia tfx-cli.

Aktualizowanie zadań przy użyciu narzędzia TFX

1. Pobierz i wyodrębnij Tasks_20230825.zip.
2. Zmień katalog na wyodrębnione pliki.
3. Wykonaj następujące polecenia, aby przekazać zadania:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Wymagania dotyczące potoku

Aby można było użyć nowego zachowania, należy ustawić zmienną AZP_75787_ENABLE_NEW_LOGIC = true w potokach korzystających z zadań, których dotyczy problem.

• W wersji klasycznej:

  Zdefiniuj zmienną na karcie zmiennej w potoku.

• Przykład YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 3 Data wydania: 8 sierpnia 2023 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020 Update 0.2, która zawiera poprawki dla następujących elementów.

• Usunięto usterkę, która zakłócała wypychanie pakietów podczas uaktualniania z wersji 2018 lub starszej.

Azure DevOps Server 2020 Update 0.2 Patch 2 Data wydania: 13 czerwca 2023 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020 Update 0.2, która zawiera poprawki dla następujących elementów.

• Usunięto usterkę, która zakłócała wypychanie pakietów podczas uaktualniania z wersji 2018 lub starszej.

Azure DevOps Server 2020 Update 0.2 Patch 1 Data wydania: 18 października 2022 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020 Update 0.2, która zawiera poprawki dla następujących elementów.

• Rozwiąż problem z nowo dodanymi tożsamościami usługi AD, które nie są wyświetlane w selektorach tożsamości okna dialogowego zabezpieczeń.
• Rozwiązano problem z filtrem Żądany przez członka grupy w ustawieniach elementu webhook.
• Naprawiono błąd kompilacji zaewidencjonowania bramy, gdy ustawienia organizacji dla potoku miały zakres autoryzacji zadania skonfigurowany jako Limit zakresu autoryzacji zadania do bieżącego projektu dla potoków innych niż wydania.

Azure DevOps Server 2020.0.2 Data wydania: 17 maja 2022 r.

Azure DevOps Server 2020.0.2 to pakiet poprawek błędów. Możesz bezpośrednio zainstalować program Azure DevOps Server 2020.0.2 lub uaktualnić z wersji Azure DevOps Server 2020 lub Team Foundation Server 2013 lub nowszej.

Uwaga

Narzędzie do migracji danych będzie dostępne dla Azure DevOps Server 2020.0.2 około trzech tygodni po tej wersji. Listę wersji obecnie obsługiwanych przy importowaniu można znaleźć tutaj.

Ta wersja zawiera poprawki dla następujących elementów:

• Nie można pominąć kolejki kompilacji przy użyciu przycisku "Uruchom dalej". Wcześniej przycisk "Uruchom dalej" został włączony tylko dla administratorów kolekcji projektów.

• Odwoływanie wszystkich osobistych tokenów dostępu po wyłączeniu konta usługi Active Directory użytkownika.

Azure DevOps Server 2020.0.1 Patch 9 Data wydania: 26 stycznia 2022 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020.0.1, która zawiera poprawki dla następujących elementów.

• Email powiadomienia nie zostały wysłane podczas korzystania z kontrolki @mention w elemencie roboczym.
• Napraw błąd TF400813 podczas przełączania kont. Ten błąd wystąpił podczas uaktualniania z serwera TFS 2018 do wersji Azure DevOps Server 2020.0.1.
• Rozwiązano problem polegający na tym, że nie można załadować strony podsumowania przeglądu projektu.
• Poprawa synchronizacji użytkowników usługi Active Directory.
• Usunięto lukę w zabezpieczeniach usługi Elasticsearch, usuwając klasę jndilookup z plików binarnych log4j.

Kroki instalacji

1. Uaktualnij serwer przy użyciu poprawki 9.
2. Sprawdź wartość rejestru pod adresem HKLM:\Software\Elasticsearch\Version. Jeśli wartość rejestru nie istnieje, dodaj wartość ciągu i ustaw wartość Version na 5.4.1 (Name = Version, Value = 5.4.1).
3. Uruchom polecenie PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update aktualizacji zgodnie z opisem w pliku readme. Może zostać zwrócone ostrzeżenie, takie jak: Nie można nawiązać połączenia z serwerem zdalnym. Nie zamykaj okna, ponieważ aktualizacja jest ponawiana do momentu jej ukończenia.

Uwaga

Jeśli Azure DevOps Server i Elasticsearch są zainstalowane na różnych maszynach, wykonaj kroki opisane poniżej.

1. Uaktualnij serwer przy użyciu poprawki 9..
2. Sprawdź wartość rejestru pod adresem HKLM:\Software\Elasticsearch\Version. Jeśli wartość rejestru nie istnieje, dodaj wartość ciągu i ustaw wartość Version na 5.4.1 (Name = Version, Value = 5.4.1).
3. Skopiuj zawartość folderu o nazwie zip znajdującą się w folderze C:\Program Files\{TFS Version Folder}\Search\zip pliku zdalnego elasticsearch.
4. Uruchom polecenie Configure-TFSSearch.ps1 -Operation update na maszynie serwera Elasticsearch.

Skrót SHA-256: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

Azure DevOps Server 2020.0.1 Patch 8 Data wydania: 15 grudnia 2021 r.

Poprawka 8 dla Azure DevOps Server 2020.0.1 zawiera poprawki dla następujących elementów.

• Problem z lokalizacją dla niestandardowych stanów układu elementów roboczych.
• Problem z lokalizacją w szablonie powiadomień e-mail.
• Problem z dziennikami konsoli jest obcinany, gdy w wierszu istnieje wiele identycznych łączy.
• Problem z oceną reguł NOTSAMEAS, gdy dla pola zdefiniowano wiele reguł NOTSAMEAS.

Azure DevOps Server 2020.0.1 Patch 7 Data wydania: 26 października 2021 r.

Poprawka 7 dla Azure DevOps Server 2020.0.1 zawiera poprawki dla następujących elementów.

• Wcześniej Azure DevOps Server mogły tworzyć tylko połączenia z serwerem GitHub Enterprise Server. Dzięki tej poprawce administratorzy projektu mogą tworzyć połączenia między Azure DevOps Server i repozytoriami w GitHub.com. To ustawienie można znaleźć na stronie Połączeń usługi GitHub w obszarze Ustawienia projektu.
• Rozwiąż problem z widżetem planu testu. Raport wykonywania testu przedstawiał niepoprawnego użytkownika w wynikach.
• Rozwiązano problem polegający na tym, że nie można załadować strony podsumowania przeglądu projektu.
• Rozwiązano problem z wiadomościami e-mail, które nie są wysyłane w celu potwierdzenia uaktualnienia produktu.

Azure DevOps Server 2020.0.1 Patch 6 Data wydania: 14 września 2021 r.

Poprawka 6 dla Azure DevOps Server 2020.0.1 zawiera poprawki dla następujących elementów.

• Napraw błąd pobierania/przekazywania artefaktów.
• Rozwiąż problem z niespójnymi danymi wyników testów.

Azure DevOps Server 2020.0.1 Patch 5 Data wydania: 10 sierpnia 2021 r.

Poprawka 5 dla Azure DevOps Server 2020.0.1 zawiera poprawki dla następujących elementów.

• Napraw błąd interfejsu użytkownika definicji kompilacji.
• Zmieniono historię przeglądania tak, aby wyświetlała pliki zamiast repozytorium głównego.
• Rozwiązano problem z zadaniami dostarczania poczty e-mail dla niektórych typów elementów roboczych.

Azure DevOps Server 2020.0.1 Patch 4 Data wydania: 15 czerwca 2021 r.

Poprawka 4 dla Azure DevOps Server 2020.0.1 zawiera poprawki dla następujących elementów.

• Rozwiązano problem z importowaniem danych. Importowanie danych trwało długo dla klientów, którzy mają wiele nieaktualnych przypadków testowych. Wynikało to z odwołań, które zwiększyły rozmiar tbl_testCaseReferences tabeli. Dzięki tej poprawce usunęliśmy odwołania do nieaktualnych przypadków testowych, aby przyspieszyć proces importowania danych.

Azure DevOps Server 2020.0.1 Patch 3 Data wydania: 11 maja 2021 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020.0.1, która naprawia następujące poprawki.

• Niespójne dane wyników testów podczas korzystania z elementu Microsoft.TeamFoundation.TestManagement.Client.

Jeśli masz Azure DevOps Server 2020.0.1, zainstaluj Azure DevOps Server 2020.0.1 Patch 3.

Weryfikowanie instalacji

• Opcja 1. Uruchom polecenie devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.exe to plik pobrany z powyższego linku. Dane wyjściowe polecenia powiedzą, że poprawka została zainstalowana lub która nie jest zainstalowana.

• Opcja 2. Sprawdź wersję następującego pliku: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. program Azure DevOps Server 2020.0.1 jest instalowany domyślniec:\Program Files\Azure DevOps Server 2020. Po zainstalowaniu poprawki Azure DevOps Server 2020.0.1 Patch 3 wersja to 18.170.31228.1.

Azure DevOps Server 2020.0.1 Patch 2 Data wydania: 13 kwietnia 2021 r.

Uwaga

Jeśli masz Azure DevOps Server 2020 r., należy najpierw zaktualizować Azure DevOps Server 2020.0.1 . Raz w wersji 2020.0.1 zainstaluj Azure DevOps Server 2020.0.1 Patch 2

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020.0.1, która naprawia następujące poprawki.

• CVE-2021-27067: Ujawnienie informacji
• CVE-2021-28459: Podniesienie uprawnień

Aby zaimplementować poprawki dla tej poprawki, należy wykonać poniższe kroki instalacji poprawek ogólnych, AzureResourceGroupDeploymentV2 i AzureResourceManagerTemplateDeploymentV3 .

Ogólna instalacja poprawek

Jeśli masz Azure DevOps Server 2020.0.1, zainstaluj Azure DevOps Server 2020.0.1 Patch 2.

Weryfikowanie instalacji

• Opcja 1. Uruchom polecenie devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.exe to plik pobrany z powyższego linku. Dane wyjściowe polecenia powiedzą, że poprawka została zainstalowana lub która nie jest zainstalowana.

• Opcja 2. Sprawdź wersję następującego pliku: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. program Azure DevOps Server 2020.0.1 jest instalowany domyślniec:\Program Files\Azure DevOps Server 2020. Po zainstalowaniu poprawki Azure DevOps Server 2020.0.1 Patch 2 wersja będzie mieć wartość 18.170.31123.3.

Instalacja zadania AzureResourceGroupDeploymentV2

Uwaga

Wszystkie kroki wymienione poniżej należy wykonać na maszynie z systemem Windows

Instalowanie

1. Wyodrębnij pakiet AzureResourceGroupDeploymentV2.zip do nowego folderu na komputerze. Na przykład: D:\tasks\AzureResourceGroupDeploymentV2.

2. Pobierz i zainstaluj Node.js 14.15.1 i narzędzie npm (dołączone do pobierania Node.js) zgodnie z maszyną.

3. Otwórz wiersz polecenia w trybie administratora i uruchom następujące polecenie, aby zainstalować interfejs wiersza polecenia tfx-cli.

npm install -g tfx-cli

4. Twórca osobisty token dostępu z uprawnieniami pełnego dostępu i skopiuj go. Ten osobisty token dostępu będzie używany podczas uruchamiania polecenia logowania tfx .

5. Uruchom następujące polecenie w wierszu polecenia. Po wyświetleniu monitu wprowadź adres URL usługi i osobisty token dostępu.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Uruchom następujące polecenie, aby przekazać zadanie na serwerze. Użyj ścieżki wyodrębnionego pliku .zip z kroku 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Instalacja zadania AzureResourceManagerTemplateDeploymentV3

Uwaga

Wszystkie kroki wymienione poniżej należy wykonać na maszynie z systemem Windows

Instalowanie

1. Wyodrębnij pakiet AzureResourceManagerTemplateDeploymentV3.zip do nowego folderu na komputerze. Na przykład:D:\tasks\AzureResourceManagerTemplateDeploymentV3.

2. Pobierz i zainstaluj Node.js 14.15.1 i narzędzie npm (dołączone do pobierania Node.js) zgodnie z potrzebami komputera.

3. Otwórz wiersz polecenia w trybie administratora i uruchom następujące polecenie, aby zainstalować interfejs wiersza polecenia tfx-cli.

npm install -g tfx-cli

4. Twórca osobisty token dostępu z uprawnieniami pełnego dostępu i skopiuj go. Ten osobisty token dostępu będzie używany podczas uruchamiania polecenia logowania tfx .

5. Uruchom następujące polecenie w wierszu polecenia. Po wyświetleniu monitu wprowadź adres URL usługi i osobisty token dostępu.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Uruchom następujące polecenie, aby przekazać zadanie na serwerze. Użyj ścieżki wyodrębnionego pliku .zip z kroku 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2020.0.1 Patch 1 Data wydania: 9 lutego 2021 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020.0.1, która naprawia następujące poprawki. Zobacz wpis w blogu, aby uzyskać więcej informacji.

• Rozwiązywanie problemu zgłoszonego w tym bilecie opinii o Developer Community| Przycisk Nowy przypadek testowy nie działa
• Uwzględnij poprawki wydane z Azure DevOps Server 2020 Patch 2.

Azure DevOps Server 2020 Patch 3 Data wydania: 9 lutego 2021 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020 r., która naprawia następujące poprawki. Zobacz wpis w blogu, aby uzyskać więcej informacji.

• Rozwiązywanie problemu zgłoszonego w tym bilecie opinii o Developer Community| Przycisk Nowy przypadek testowy nie działa

Azure DevOps Server 2020.0.1 Data wydania: 19 stycznia 2021 r.

Azure DevOps Server 2020.0.1 to pakiet poprawek błędów. Możesz bezpośrednio zainstalować program Azure DevOps Server 2020.0.1 lub uaktualnić z istniejącej instalacji. Obsługiwane wersje uaktualnienia to Azure DevOps Server 2020, Azure DevOps Server 2019 i Team Foundation Server 2012 lub nowszy.

Ta wersja zawiera poprawki następujących błędów:

• Rozwiąż problem z uaktualnieniem z Azure DevOps Server 2019 r., w którym serwer proxy usługi Git może przestać działać po uaktualnieniu.
• Napraw wyjątek System.OutOfMemoryException dla kolekcji innych niż ENU przed uaktualnieniem do programu Team Foundation Server 2017 podczas uaktualniania do wersji Azure DevOps Server 2020. Rozwiązuje problem zgłoszony w tym Developer Community biletu opinii.
• Niepowodzenie obsługi spowodowane brakiem Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Rozwiązuje problem zgłoszony w tym Developer Community biletu opinii.
• Napraw nieprawidłowy błąd nazwy kolumny w usłudze Analytics podczas uaktualniania do wersji Azure DevOps Server 2020. Rozwiązuje problem zgłoszony w tym Developer Community biletu opinii.
• Przechowywane XSS podczas wyświetlania kroków przypadku testowego w wynikach przypadku testowego.
• Niepowodzenie kroku uaktualniania podczas migrowania punktów powoduje wyświetlenie danych do narzędzia TCM.

Azure DevOps Server 2020 Patch 2 Data wydania: 12 stycznia 2021 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020 r., która naprawia następujące poprawki. Zobacz wpis w blogu, aby uzyskać więcej informacji.

• Szczegóły przebiegu testu nie zawierają szczegółów kroku testu dla danych testowych migrowanych przy użyciu narzędzia OpsHub Migration
• Wyjątek dotyczący inicjatora dla polecenia "Microsoft.TeamFoundation.TestManagement.Server.TCMLogger"
• Nieretainowane kompilacje są natychmiast usuwane po migracji do Azure DevOps Server 2020 r.
• Naprawianie wyjątku dostawcy danych

Azure DevOps Server 2020 Patch 1 Data: 8 grudnia 2020 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020 r., która naprawia następujące poprawki. Zobacz wpis w blogu, aby uzyskać więcej informacji.

• CVE-2020-17145: luka w zabezpieczeniach dotycząca fałszowania usług Azure DevOps Server i Team Foundation Services

Azure DevOps Server 2020 Data wydania: 6 października 2020 r.

Azure DevOps Server 2020 r. to pakiet poprawek błędów. Zawiera wszystkie funkcje w Azure DevOps Server 2020 RC2, które wcześniej wydano.

Uwaga

Usługa Azure DevOps 2020 Server ma problem z zainstalowaniem jednego z zestawów używanych przez wirtualny system plików Git (GVFS).

Jeśli uaktualniasz usługę Azure DevOps 2019 (dowolną wersję) lub kandydata do wydania usługi Azure DevOps 2020 i instalujesz w tym samym katalogu co poprzednia wersja, zestaw Microsoft.TeamFoundation.Git.dll nie zostanie zainstalowany. Możesz sprawdzić, czy problem wystąpił, wyszukując Microsoft.TeamFoundation.Git.dll element w <Install Dir>\Version Control Proxy\Web Services\bin<Install Dir>\Application Tier\TFSJobAgent folderach i <Install Dir>\Tools . Jeśli brakuje pliku, możesz uruchomić naprawę, aby przywrócić brakujące pliki.

Aby uruchomić naprawę, przejdź do Settings -> Apps & Features Azure DevOps Server maszyny/maszyny wirtualnej i uruchom naprawę na serwerze Usługi Azure DevOps 2020. Po zakończeniu naprawy można ponownie uruchomić maszynę/maszynę wirtualną.

Azure DevOps Server 2020 RC2 Data wydania: 11 sierpnia 2020 r.

Azure DevOps Server 2020 RC2 to pakiet poprawek błędów. Zawiera wszystkie funkcje w wersji Azure DevOps Server 2020 RC1, która została wcześniej wydana.

Azure DevOps Server 2020 RC1 — data ponownego wydania: 10 lipca 2020 r.

Udostępniliśmy ponownie Azure DevOps Server 2020 RC1, aby rozwiązać ten Developer Community bilet opinii.

Wcześniej po uaktualnieniu z wersji Azure DevOps Server 2019 Update 1.1 do Azure DevOps Server 2020 RC1 nie można było wyświetlić plików w repozytoriach, potokach i witrynie typu wiki interfejsu użytkownika sieci Web. Wystąpił komunikat o błędzie wskazujący nieoczekiwany błąd w tym regionie strony. Możesz spróbować ponownie załadować ten składnik lub odświeżyć całą stronę. W tej wersji rozwiązaliśmy ten problem. Zobacz wpis w blogu, aby uzyskać więcej informacji.

Azure DevOps Server 2020 RC1 Data wydania: 30 czerwca 2020 r.

Podsumowanie nowości w Azure DevOps Server 2020 r.

Azure DevOps Server 2020 r. wprowadzono wiele nowych funkcji. Niektóre najważniejsze funkcje to:

• Potoki wieloetapowe
• Ciągłe wdrażanie w języku YAML
• Śledzenie postępu elementów nadrzędnych przy użyciu listy prac zestawień na tablicach
• Dodaj filtr "Nadrzędny element roboczy" do tablicy zadań i listy prac przebiegu
• Nowy internetowy interfejs użytkownika dla stron docelowych Azure Repos
• Administrowanie zasadami gałęzi między repozytoriami
• Strona Nowy plan testu
• Zaawansowane edytowanie stron typu wiki kodu
• Raporty dotyczące niepowodzeń i czasu trwania potoku

Możesz również przejść do poszczególnych sekcji, aby zobaczyć wszystkie nowe funkcje dla każdej usługi:

• Ogólne
• Boards
• Repos
• Pipelines
• Test Plans
• Artifacts
• Witryna Wiki
• Raportowanie

---

Ogólne

Ogólna dostępność interfejsu wiersza polecenia usługi Azure DevOps

W lutym wprowadziliśmy rozszerzenie usługi Azure DevOps dla interfejsu wiersza polecenia platformy Azure. Rozszerzenie umożliwia interakcję z usługą Azure DevOps z poziomu wiersza polecenia. Zebraliśmy Twoją opinię, która pomogła nam ulepszyć rozszerzenie i dodać więcej poleceń. Z przyjemnością ogłaszamy, że rozszerzenie jest ogólnie dostępne.

Aby dowiedzieć się więcej na temat interfejsu wiersza polecenia usługi Azure DevOps, zapoznaj się z dokumentacją tutaj.

Używanie profilu publikowania do wdrażania usługi Azure WebApps dla systemu Windows z Poziomu Centrum wdrażania

Teraz możesz użyć uwierzytelniania opartego na profilu publikowania, aby wdrożyć aplikacje internetowe platformy Azure dla systemu Windows z Poziomu Centrum wdrażania. Jeśli masz uprawnienia do wdrażania w usłudze Azure WebApp dla systemu Windows przy użyciu profilu publikowania, możesz skonfigurować potok przy użyciu tego profilu w przepływach pracy Centrum wdrażania.

Boards

Dodaj filtr "Nadrzędny element roboczy" do tablicy zadań i listy prac przebiegu

Dodaliśmy nowy filtr zarówno do tablicy przebiegu, jak i listy prac Przebiegu. Dzięki temu można filtrować elementy listy prac na poziomie wymagań (pierwsza kolumna po lewej stronie) według ich elementu nadrzędnego. Na przykład na poniższym zrzucie ekranu odfiltrowaliśmy widok, aby pokazać tylko historie użytkowników, w których element nadrzędny to "Moja duża funkcja".

Ulepszanie środowiska obsługi błędów — wymagane pola w błędzie/zadaniu

Historycznie, z tablicy Kanban, jeśli element roboczy został przeniesiony z jednej kolumny do innej, gdzie zmiana stanu wyzwoliła reguły pól, karta będzie po prostu wyświetlać czerwony komunikat o błędzie, który wymusi otwarcie elementu roboczego w celu zrozumienia głównej przyczyny. W przebiegu 170 ulepszyliśmy środowisko pracy, dzięki czemu można teraz kliknąć czerwony komunikat o błędzie, aby wyświetlić szczegóły błędu bez konieczności otwierania samego elementu roboczego.

Ponowne ładowanie elementu roboczego na żywo

Wcześniej podczas aktualizowania elementu roboczego, a drugi członek zespołu wprowadzał zmiany w tym samym elemencie roboczym, drugi użytkownik utraci zmiany. Teraz, o ile edytujesz różne pola, zobaczysz na żywo aktualizacje zmian wprowadzonych w elemencie roboczym.

Zarządzanie iteracji i ścieżkami obszaru z poziomu wiersza polecenia

Teraz można zarządzać iteracji i ścieżkami obszaru z poziomu wiersza polecenia przy użyciu az boards iteration poleceń i az boards area . Można na przykład skonfigurować iterację i ścieżki obszaru oraz zarządzać nimi interaktywnie z poziomu interfejsu wiersza polecenia lub zautomatyzować całą konfigurację przy użyciu skryptu. Aby uzyskać więcej informacji na temat poleceń i składni, zobacz dokumentację tutaj.

Kolumna nadrzędna elementu roboczego jako opcja kolumny

Teraz masz możliwość wyświetlenia elementu nadrzędnego każdego elementu roboczego na liście prac produktu lub liście prac przebiegu. Aby włączyć tę funkcję, przejdź do pozycji Opcje kolumny na żądanej liście prac, a następnie dodaj kolumnę Nadrzędna .

Zmienianie procesu używanego przez projekt

Narzędzia powinny ulec zmianie w miarę wykonywania przez zespół, można teraz przełączać projekty z dowolnego gotowego szablonu procesu do dowolnego innego gotowego procesu. Możesz na przykład zmienić projekt z metody Agile na Scrum lub Podstawowa na Agile. Pełną dokumentację krok po kroku można znaleźć tutaj.

Ukryj pola niestandardowe z układu

Teraz można ukryć pola niestandardowe z układu formularza podczas dostosowywania procesu. Pole będzie nadal dostępne z zapytań i interfejsów API REST. Jest to przydatne do śledzenia dodatkowych pól podczas integracji z innymi systemami.

Uzyskiwanie wglądu w kondycję zespołu przy użyciu trzech nowych raportów Azure Boards

Nie można naprawić tego, czego nie widzisz. W związku z tym chcesz uważnie obserwować stan i kondycję procesów pracy. Dzięki tym raportom łatwiej jest śledzić ważne metryki przy minimalnym wysiłku w Azure Boards.

Trzy nowe interaktywne raporty to: Burndown, Cumulative Flow Diagram (CFD) i Velocity(Burndown), Cumulative Flow Diagram (CFD). Raporty można wyświetlić na nowej karcie analizy.

Metryki, takie jak spalenie przebiegu, przepływ pracy i szybkości zespołu zapewniają wgląd w postęp zespołu i pomagają odpowiedzieć na pytania, takie jak:

• Ile pracy pozostawiliśmy w tym przebiegu? Czy jesteśmy na dobrej drodze, aby go ukończyć?
• Jaki krok procesu programowania trwa najdłużej? Czy możemy coś z tym zrobić?
• Na podstawie poprzednich iteracji, ile pracy powinniśmy zaplanować na następny przebieg?

Uwaga

Wykresy wyświetlane wcześniej w nagłówkach zostały zastąpione tymi rozszerzonymi raportami.

Nowe raporty są w pełni interaktywne i umożliwiają dostosowanie ich do Twoich potrzeb. Nowe raporty można znaleźć na karcie Analiza w każdym centrum.

• Wykres spalony można znaleźć w centrum Sprints .

  

• Dostęp do raportów CFD i prędkości można uzyskać na karcie Analiza w obszarze Tablice i listy prac , klikając odpowiednią kartę.

  

Dzięki nowym raportom masz większą kontrolę i informacje o zespole. Oto kilka przykładów:

• Raporty Sprint Burndown i Prędkość można ustawić tak, aby używać liczby elementów roboczych lub sumy pozostałych prac.
• Możesz dostosować przedział czasu wypalenia przebiegu bez wpływu na daty projektu. Jeśli więc twój zespół zwykle spędza pierwszy dzień każdego planowania przebiegu, możesz teraz dopasować wykres, aby to odzwierciedlić.
• Wykres Burndown ma teraz znak wodny pokazujący weekendy.
• Raport CFD umożliwia usunięcie kolumn tablicy, takich jak Projektowanie, aby uzyskać więcej uwagi na przepływie, na którym zespoły mają kontrolę.

Oto przykład raportu CFD pokazującego przepływ z ostatnich 30 dni listy prac Stories.

Wykres Prędkość można teraz śledzić dla wszystkich poziomów listy prac. Na przykład można teraz dodać funkcje i epiki, natomiast przed poprzednim wykresem obsługiwane są tylko wymagania. Oto przykład raportu prędkości dla ostatnich 6 iteracji listy prac funkcji.

Dostosowywanie kolumn tablicy zadań

Z przyjemnością ogłaszamy, że dodaliśmy opcję umożliwiającą dostosowanie kolumn na tablicy zadań. Teraz możesz dodawać, usuwać, zmieniać nazwy i zmieniać kolejność kolumn.

Aby skonfigurować kolumny na tablicy zadań, przejdź do pozycji Opcje kolumn.

Ta funkcja została priorytetowa na podstawie sugestii Developer Community.

Przełącz, aby pokazać lub ukryć ukończone podrzędne elementy robocze na liście prac

Wiele razy podczas ujmowania listy prac chcesz zobaczyć tylko elementy, które nie zostały ukończone. Teraz masz możliwość wyświetlania lub ukrywania ukończonych elementów podrzędnych na liście prac.

Jeśli przełącznik jest włączony, wszystkie elementy podrzędne będą widoczne w stanie ukończonym. Po wyłączeniu przełącznika wszystkie elementy podrzędne w stanie ukończonym będą ukryte z listy prac.

Najnowsze tagi wyświetlane podczas tagowania elementu roboczego

Podczas tagowania elementu roboczego opcja autouzupełniania będzie teraz wyświetlać maksymalnie pięć ostatnio używanych tagów. Ułatwi to dodawanie odpowiednich informacji do elementów roboczych.

Reguły tylko do odczytu i wymagane dla członkostwa w grupie

Reguły elementów roboczych umożliwiają ustawianie określonych akcji w polach elementów roboczych w celu zautomatyzowania ich zachowania. Regułę można utworzyć, aby ustawić pole na tylko do odczytu lub wymagane na podstawie członkostwa w grupie. Na przykład możesz przyznać właścicielom produktów możliwość ustawiania priorytetu funkcji podczas tworzenia jej tylko do odczytu dla wszystkich innych osób.

Dostosowywanie wartości listy wyboru systemu

Teraz można dostosować wartości dla dowolnej listy wyboru systemu (z wyjątkiem pola przyczyny), takich jak ważność, aktywność, priorytet itp. Dostosowania listy wyboru są ograniczone, aby można było zarządzać różnymi wartościami dla tego samego pola dla każdego typu elementu roboczego.

Parametr adresu URL nowego elementu roboczego

Udostępnij linki do elementów roboczych z kontekstem tablicy lub listy prac za pomocą naszego nowego parametru adresu URL elementu roboczego. Teraz możesz otworzyć okno dialogowe elementu roboczego na tablicy, liście prac lub w środowisku przebiegu, dołączając parametr ?workitem=[ID] do adresu URL.

Każda osoba, z którą udostępniasz link, zostanie wyświetlona z tym samym kontekstem, który miałeś podczas udostępniania linku!

Wzmianek o osobach, elementach roboczych i żądaniach ściągnięcia w polach tekstowych

Podczas nasłuchiwania opinii słyszeliśmy, że chcesz wspomnieć o osobach, elementach roboczych i żądaniach ściągnięcia w obszarze opisu elementu roboczego (i innych polach HTML) w elemencie roboczym, a nie tylko w komentarzach. Czasami współpracujesz z kimś w elemencie roboczym lub chcesz wyróżnić żądanie ściągnięcia w opisie elementu roboczego, ale nie masz sposobu na dodanie tych informacji. Teraz możesz wspomnieć o osobach, elementach roboczych i żądaniach ściągnięcia we wszystkich długich polach tekstowych w elemencie roboczym.

Przykład można zobaczyć tutaj.

• Aby użyć wzmianki o osobach, wpisz @ znak i nazwisko osoby, o której chcesz wspomnieć. @mentions w polach elementów roboczych będą generowane powiadomienia e-mail, takie jak to, co robi w przypadku komentarzy.
• Aby użyć wzmianek elementu roboczego, wpisz # znak, po którym następuje identyfikator lub tytuł elementu roboczego. #mentions utworzy łącze między dwoma elementami roboczymi.
• Aby użyć wzmianek żądania ściągnięcia, dodaj element ! po którym następuje identyfikator żądania ściągnięcia lub nazwa.

Reakcje na komentarze do dyskusji

Jednym z naszych głównych celów jest zwiększenie współpracy elementów roboczych dla zespołów. Niedawno przeprowadziliśmy ankietę na Twitterze , aby dowiedzieć się, jakie funkcje współpracy chcesz w dyskusjach na temat elementu roboczego. Przynosząc reakcje na komentarze wygrały ankietę, więc je dodajemy! Oto wyniki ankiety twitterowej.

Możesz dodać reakcje do dowolnego komentarza i istnieją dwa sposoby dodawania reakcji — ikona uśmiechnięć się w prawym górnym rogu dowolnego komentarza, a także w dolnej części komentarza obok wszelkich istniejących reakcji. Możesz dodać wszystkie sześć reakcji, jeśli chcesz, lub tylko jeden lub dwa. Aby usunąć twoją reakcję, kliknij reakcję na dole komentarza i zostanie usunięta. Poniżej widać doświadczenie dodawania reakcji, a także to, jak wyglądają reakcje na komentarz.

Przypinanie raportów Azure Boards do pulpitu nawigacyjnego

W aktualizacji Sprint 155 uwzględniliśmy zaktualizowane wersje raportów CFD i Velocity. Te raporty są dostępne na karcie Analiza tablic i list prac. Teraz możesz przypiąć raporty bezpośrednio do pulpitu nawigacyjnego. Aby przypiąć raporty, umieść kursor nad raportem, wybierz wielokropek "..." menu i Kopiuj do pulpitu nawigacyjnego.

Śledzenie postępu elementów nadrzędnych przy użyciu listy prac zestawień na tablicach

Kolumny zestawienia pokazują paski postępu i/lub sumy pól liczbowych lub elementów podrzędnych w hierarchii. Obiekty podrzędne odpowiadają wszystkim elementom podrzędnym w obrębie hierarchii. Do listy prac produktu lub portfela można dodać co najmniej jedną kolumnę zestawienia.

Na przykład w tym miejscu pokażemy pozycję Postęp według elementów roboczych , w którym są wyświetlane paski postępu dla rosnących elementów roboczych na podstawie procentu elementów podrzędnych, które zostały zamknięte. Elementy podrzędne epików zawierają wszystkie funkcje podrzędne i ich podrzędne lub podrzędne elementy robocze. Elementy podrzędne funkcji obejmują wszystkie podrzędne scenariusze użytkownika i podrzędne elementy robocze.

Aktualizacje na żywo tablicy zadań

Tablica zadań jest teraz automatycznie odświeżana po wystąpieniu zmian. Gdy inni członkowie zespołu przenoszą lub zmieniają kolejność kart na tablicy zadań, tablica zostanie automatycznie zaktualizowana o te zmiany. Nie trzeba już naciskać klawisza F5, aby zobaczyć najnowsze zmiany.

Obsługa pól niestandardowych w kolumnach zestawień

Pakiet zbiorczy można teraz wykonać w dowolnym polu, w tym w polach niestandardowych. Podczas dodawania kolumny zestawienia nadal możesz wybrać kolumnę zestawienia z listy Szybkie, jednak jeśli chcesz utworzyć zestawienie w polach liczbowych, które nie są częścią szablonu procesu gotowego do użycia, możesz skonfigurować własne w następujący sposób:

1. Na liście prac kliknij pozycję "Opcje kolumny". Następnie na panelu kliknij pozycję "Dodaj kolumnę zestawienia" i skonfiguruj niestandardowe zestawienie.

   

2. Wybierz między paskiem postępu a sumą.
3. Wybierz typ elementu roboczego lub poziom listy prac (zazwyczaj listy prac agregują kilka typów elementów roboczych).
4. Wybierz typ agregacji. Liczba elementów roboczych lub Suma. W obszarze Suma należy wybrać pole do podsumowania.
5. Przycisk OK spowoduje powrót do panelu opcji kolumny, w którym można zmienić kolejność nowej kolumny niestandardowej.

Pamiętaj, że nie można edytować kolumny niestandardowej po kliknięciu przycisku OK. Jeśli musisz wprowadzić zmianę, usuń kolumnę niestandardową i dodaj kolejną kolumnę zgodnie z potrzebami.

Nowa reguła ukrywania pól w formularzu elementu roboczego na podstawie warunku

Dodaliśmy nową regułę do aparatu odziedziczonych reguł, aby umożliwić ukrycie pól w formularzu elementu roboczego. Ta reguła spowoduje ukrycie pól na podstawie członkostwa w grupie użytkowników. Jeśli na przykład użytkownik należy do grupy "właściciel produktu", możesz ukryć pole specyficzne dla dewelopera. Aby uzyskać więcej informacji, zobacz dokumentację tutaj.

Niestandardowe ustawienia powiadomień o elemencie roboczym

Bycie na bieżąco z elementami roboczymi istotnych dla Ciebie lub Twojego zespołu jest niezwykle ważne. Pomaga zespołom współpracować i śledzić projekty i upewnić się, że wszystkie odpowiednie strony są zaangażowane. Jednak różne osoby biorące udział w projekcie mają różne poziomy inwestycji w różne wysiłki i uważamy, że powinno to zostać odzwierciedlone w twojej zdolności do podążania za statusem elementu roboczego.

Wcześniej, jeśli chcesz śledzić element roboczy i otrzymywać powiadomienia o wszelkich wprowadzonych zmianach, otrzymasz powiadomienia e-mail dotyczące wszystkich zmian wprowadzonych w elemencie roboczym. Po rozważeniu opinii wprowadzamy bardziej elastyczne działanie elementu roboczego dla wszystkich uczestników projektu. Teraz obok przycisku Obserwuj w prawym górnym rogu elementu roboczego zostanie wyświetlony przycisk Nowe ustawienia. Spowoduje to przejście do wyskakującego okienka, które umożliwi skonfigurowanie następujących opcji.

W obszarze Ustawienia powiadomień możesz wybrać jedną z trzech opcji powiadomień. Najpierw możesz całkowicie anulować subskrypcję. Po drugie, można w pełni subskrybować, gdzie otrzymujesz powiadomienia o wszystkich zmianach elementów roboczych. Na koniec możesz otrzymywać powiadomienia o niektórych najważniejszych i kluczowych zdarzeniach zmiany elementu roboczego. Możesz wybrać tylko jedną lub wszystkie trzy opcje. Pozwoli to członkom zespołu śledzić elementy robocze na wyższym poziomie i nie rozpraszać się przez każdą jedną zmianę, która zostanie wprowadzonych. Dzięki tej funkcji wyeliminowamy niepotrzebne wiadomości e-mail i pozwolimy skupić się na kluczowych zadaniach.

Łączenie elementów roboczych z wdrożeniami

Z przyjemnością publikujemy kontrolkę Wdrażanie w formularzu elementu roboczego. Ta kontrolka łączy elementy robocze z wydaniem i umożliwia łatwe śledzenie miejsca wdrożenia elementu roboczego. Aby dowiedzieć się więcej, zobacz dokumentację tutaj.

Importowanie elementów roboczych z pliku CSV

Do tej pory importowanie elementów roboczych z pliku CSV było zależne od korzystania z wtyczki programu Excel. W tej aktualizacji udostępniamy środowisko importowania pierwszej klasy bezpośrednio z Azure Boards, dzięki czemu można importować nowe lub aktualizować istniejące elementy robocze. Aby dowiedzieć się więcej, zapoznaj się z dokumentacją tutaj.

Dodawanie pola nadrzędnego do kart elementów roboczych

Kontekst nadrzędny jest teraz dostępny w tablicy Kanban jako nowe pole dla kart elementów roboczych. Teraz możesz dodać pole Nadrzędne do kart, pomijając konieczność użycia obejść, takich jak tagi i prefiksy.

Dodawanie pola nadrzędnego do listy prac i zapytań

Pole nadrzędne jest teraz dostępne podczas wyświetlania list prac i wyników zapytań. Aby dodać pole nadrzędne, użyj widoku Opcje kolumny .

Repos

Metryki pokrycia kodu i zasady gałęzi dla żądań ściągnięcia

Teraz można wyświetlić metryki pokrycia kodu dla zmian w widoku żądania ściągnięcia. Dzięki temu zmiany zostały odpowiednio przetestowane za pomocą testów automatycznych. Stan pokrycia będzie wyświetlany jako komentarz w przeglądzie żądania ściągnięcia. Możesz wyświetlić szczegóły informacji o pokryciu dla każdego wiersza kodu, który jest zmieniany w widoku różnic plików.

Ponadto właściciele repozytoriów mogą teraz ustawiać zasady pokrycia kodu i zapobiegać scalaniu dużych, niesprawdzonych zmian w gałęzi. Żądane progi pokrycia można zdefiniować w azurepipelines-coverage.yml pliku ustawień, który jest zaewidencjonowany w katalogu głównym repozytorium i zasad pokrycia, można zdefiniować przy użyciu istniejącej konfiguracji zasad gałęzi dla dodatkowych możliwości usług w Azure Repos.

Filtrowanie powiadomień o komentarzach z żądań ściągnięcia

Komentarze w żądaniach ściągnięcia często generują dużo szumu z powodu powiadomień. Dodaliśmy subskrypcję niestandardową, która umożliwia filtrowanie powiadomień o komentarzach subskrybowanych według wieku komentarza, komentatora, usuniętego komentarza, wymienionych użytkowników, autora żądania ściągnięcia, gałęzi docelowej i uczestników wątku. Możesz utworzyć te subskrypcje powiadomień, klikając ikonę użytkownika w prawym górnym rogu i przechodząc do pozycji Ustawienia użytkownika.

Punkty zaczepienia usługi na potrzeby komentarzy do żądania ściągnięcia

Teraz możesz tworzyć punkty zaczepienia usług dla komentarzy w żądaniu ściągnięcia na podstawie repozytorium i gałęzi docelowej.

Zasady blokowania plików z określonymi wzorcami

Administratorzy mogą teraz ustawić zasady, aby zapobiec wypychaniu zatwierdzeń do repozytorium na podstawie typów plików i ścieżek. Zasady sprawdzania poprawności nazwy pliku będą blokować wypychania zgodne z podanym wzorcem.

Rozpoznawanie elementów roboczych za pośrednictwem zatwierdzeń przy użyciu słów kluczowych

Teraz można rozpoznawać elementy robocze za pomocą zatwierdzeń w gałęzi domyślnej przy użyciu słów kluczowych, takich jak poprawka, poprawki lub naprawione. Na przykład można napisać — "ta zmiana stała #476" w komunikacie zatwierdzenia i elemencie roboczym #476 zostanie ukończona po wypchnięciu lub scaleniu zatwierdzenia z gałęzią domyślną. Aby uzyskać więcej informacji, zobacz dokumentację tutaj.

Stopień szczegółowości dla recenzentów automatycznych

Wcześniej podczas dodawania recenzentów na poziomie grupy do żądania ściągnięcia wymagane było tylko jedno zatwierdzenie z grupy, która została dodana. Teraz można ustawić zasady wymagające więcej niż jednego recenzenta od zespołu do zatwierdzenia żądania ściągnięcia podczas dodawania automatycznych recenzentów. Ponadto można dodać zasady, aby uniemożliwić żądaniom zatwierdzanie własnych zmian.

Nawiązywanie połączenia z usługą AKS przy użyciu uwierzytelniania opartego na koncie usługi

Wcześniej podczas konfigurowania usługi Azure Pipelines z Centrum wdrażania usługi AKS użyliśmy połączenia usługi Azure Resource Manager. To połączenie miało dostęp do całego klastra, a nie tylko do przestrzeni nazw, dla której skonfigurowano potok. Dzięki tej aktualizacji potoki będą używać uwierzytelniania opartego na kontach usługi w celu nawiązania połączenia z klastrem, aby mieć dostęp tylko do przestrzeni nazw skojarzonej z potokiem.

Podgląd plików markdown w żądaniu ściągnięcia różnice side-by-side

Teraz możesz zobaczyć podgląd wyglądu pliku markdown przy użyciu nowego przycisku Podgląd . Ponadto można zobaczyć pełną zawartość pliku z różnicy side-by-side, wybierając przycisk Wyświetl .

Wygaśnięcie zasad kompilacji dla kompilacji ręcznych

Zasady wymuszają standardy jakości kodu i zarządzania zmianami zespołu. Wcześniej można było ustawić zasady wygasania kompilacji dla automatycznych kompilacji. Teraz możesz również ustawić zasady wygasania kompilacji na kompilacje ręczne.

Dodawanie zasad w celu blokowania zatwierdzeń na podstawie wiadomości e-mail autora zatwierdzenia

Administratorzy mogą teraz ustawić zasady wypychania, aby zapobiec wypychaniu zatwierdzeń do repozytorium, dla którego wiadomość e-mail autora zatwierdzenia nie jest zgodna z podanym wzorcem.

Ta funkcja została priorytetowa na podstawie sugestii Developer Community w celu zapewnienia podobnego środowiska. Będziemy nadal otwierać bilet i zachęcać użytkowników do mówienia nam, jakie inne typy zasad wypychania chcesz zobaczyć.

Oznaczanie plików jako przeglądanych w żądaniu ściągnięcia

Czasami należy przejrzeć żądania ściągnięcia zawierające zmiany w dużej liczbie plików i może być trudne do śledzenia plików, które zostały już przejrzyszone. Teraz możesz oznaczyć pliki jako przeglądane w żądaniu ściągnięcia.

Plik można oznaczyć jako przeglądany przy użyciu menu rozwijanego obok nazwy pliku lub przez zatrzymanie wskaźnika myszy i kliknięcie nazwy pliku.

Uwaga

Ta funkcja jest przeznaczona tylko do śledzenia postępu podczas przeglądania żądania ściągnięcia. Nie reprezentuje głosowania na żądaniach ściągnięcia, więc te znaczniki będą widoczne tylko dla recenzenta.

Ta funkcja została priorytetowa na podstawie sugestii Developer Community.

Nowy internetowy interfejs użytkownika dla stron docelowych Azure Repos

Teraz możesz wypróbować nasze nowe nowoczesne, szybkie i mobilne strony docelowe w Azure Repos. Te strony są dostępne jako strony docelowe nowych repozytoriów. Strony docelowe zawierają wszystkie strony z wyjątkiem szczegółów żądania ściągnięcia, szczegółów zatwierdzenia i porównania gałęzi.

Internet

Aplikacje mobilne

Administrowanie zasadami gałęzi między repozytoriami

Zasady gałęzi to jedna z zaawansowanych funkcji Azure Repos, które ułatwiają ochronę ważnych gałęzi. Chociaż w interfejsie API REST istnieje możliwość ustawiania zasad na poziomie projektu, nie było dla niego interfejsu użytkownika. Teraz administratorzy mogą ustawić zasady dla określonej gałęzi lub domyślnej gałęzi we wszystkich repozytoriach w projekcie. Na przykład administrator może wymagać dwóch minimalnych recenzentów dla wszystkich żądań ściągnięcia wysyłanych do każdej gałęzi głównej w każdym repozytorium w projekcie. Funkcję Dodaj ochronę gałęzi można znaleźć w obszarze Ustawienia projektu repozytoriów.

Nowe strony docelowe konwersji platformy internetowej

Zaktualizowaliśmy środowisko użytkownika stron docelowych repozytoriów, aby było nowoczesne, szybkie i przyjazne dla urządzeń przenośnych. Poniżej przedstawiono dwa przykłady stron, które zostały zaktualizowane, będziemy nadal aktualizować inne strony w przyszłych aktualizacjach.

Środowisko internetowe:

Środowisko mobilne:

Obsługa języka Kotlin

Z przyjemnością ogłaszamy, że teraz obsługujemy wyróżnianie języka Kotlin w edytorze plików. Wyróżnianie poprawi czytelność pliku tekstowego Kotlin i pomoże szybko skanować w celu znalezienia błędów. Określiliśmy priorytety tej funkcji na podstawie sugestii z Developer Community.

Niestandardowa subskrypcja powiadomień dla roboczych żądań ściągnięcia

Aby zmniejszyć liczbę powiadomień e-mail z żądań ściągnięcia, możesz teraz utworzyć niestandardową subskrypcję powiadomień dla żądań ściągnięcia utworzonych lub zaktualizowanych w stanie roboczym. Możesz otrzymywać wiadomości e-mail przeznaczone specjalnie dla żądań ściągnięcia wersji roboczej lub odfiltrować wiadomości e-mail z roboczych żądań ściągnięcia, aby zespół nie otrzymywał powiadomień, zanim żądanie ściągnięcia będzie gotowe do przejrzenia.

Ulepszona możliwość działania żądania ściągnięcia

Jeśli masz wiele żądań ściągnięcia do przejrzenia, zrozumienie, gdzie należy najpierw podjąć działania, może być trudne. Aby zwiększyć możliwość działania żądania ściągnięcia, można teraz utworzyć wiele niestandardowych zapytań na stronie listy żądań ściągnięcia z kilkoma nowymi opcjami filtrowania według, takich jak stan wersji roboczej. Te zapytania będą tworzyć oddzielne i zwijane sekcje na stronie żądania ściągnięcia oraz "Utworzone przeze mnie" i "Przypisane do mnie". Możesz również odrzucić przejrzenie żądania ściągnięcia dodanego do programu za pośrednictwem menu Głosowanie lub menu kontekstowego na stronie listy żądań ściągnięcia. W sekcjach niestandardowych będą teraz widoczne oddzielne karty dla żądań ściągnięcia, dla których podano przegląd lub odrzucone do przejrzenia. Te zapytania niestandardowe będą działać w repozytoriach na karcie "Moje żądania ściągnięcia" na stronie głównej kolekcji. Jeśli chcesz wrócić do żądania ściągnięcia, możesz go oznaczyć flagą i pojawi się on w górnej części listy. Na koniec żądania ściągnięcia, które zostały ustawione na autouzupełnianie, zostaną oznaczone pigułką z komunikatem "Autouzupełnianie" na liście.

Pipelines

Potoki wieloetapowe

Pracujemy nad zaktualizowanym środowiskiem użytkownika w celu zarządzania potokami. Te aktualizacje sprawiają, że potoki są nowoczesne i spójne z kierunkiem usługi Azure DevOps. Ponadto te aktualizacje łączą klasyczne potoki kompilacji i wieloetapowe potoki YAML w jednym środowisku. Jest przyjazny dla urządzeń przenośnych i wprowadza różne ulepszenia sposobu zarządzania potokami. Możesz przejść do szczegółów i wyświetlić szczegóły potoku, szczegóły uruchamiania, analizę potoku, szczegóły zadania, dzienniki i nie tylko.

Nowe środowisko obejmuje następujące możliwości:

• wyświetlanie wielu etapów i zarządzanie nimi
• zatwierdzanie przebiegów potoku
• przewiń z powrotem do dzienników, gdy potok jest nadal w toku
• kondycja poszczególnych gałęzi potoku.

Ciągłe wdrażanie w języku YAML

Z przyjemnością udostępniamy funkcje ciągłego wdrażania YAML usługi Azure Pipelines. Oferujemy teraz ujednolicone środowisko YAML, dzięki czemu można skonfigurować każdy potok do wspólnego wdrażania, ciągłej integracji, ciągłej integracji lub ciągłego wdrażania. Funkcje ciągłego wdrażania YAML wprowadzają kilka nowych zaawansowanych funkcji, które są dostępne dla wszystkich kolekcji przy użyciu wieloetapowych potoków YAML. Niektóre najważniejsze funkcje to:

• Wieloetapowe potoki YAML (dla ciągłej integracji i ciągłego wdrażania)
• Zatwierdzenia i kontrole zasobów
• Środowiska i strategie wdrażania
• Zasoby platformy Kubernetes i maszyny wirtualnej w środowisku
• Przeglądanie aplikacji na potrzeby współpracy
• Odświeżony interfejs użytkownika dla połączeń usług
• Zasoby w potokach YAML

Jeśli wszystko będzie gotowe do rozpoczęcia tworzenia, zapoznaj się z dokumentacją lub blogiem dotyczącym tworzenia wieloetapowych potoków ciągłej integracji/ciągłego wdrażania.

Zarządzanie zmiennymi potoku w edytorze YAML

Zaktualizowaliśmy środowisko zarządzania zmiennymi potoku w edytorze YAML. Nie musisz już przechodzić do edytora klasycznego, aby dodać lub zaktualizować zmienne w potokach YAML.

Zatwierdzanie wydań bezpośrednio z centrum wydania

Działanie w sprawie oczekujących zatwierdzeń zostało ułatwione. Wcześniej można było zatwierdzić wydanie ze strony szczegółów wydania. Teraz możesz zatwierdzać wydania bezpośrednio z centrum Wydania.

Ulepszenia dotyczące rozpoczynania pracy z potokami

Typowym pytaniem z kreatorem wprowadzającym było możliwość zmiany nazwy wygenerowanego pliku. Obecnie jest on zaewidencjonowany jako azure-pipelines.yml w katalogu głównym repozytorium. Teraz możesz zaktualizować tę nazwę lub lokalizację do innej nazwy pliku przed zapisaniem potoku.

Na koniec będziesz mieć większą kontrolę podczas ewidencjonowania pliku w azure-pipelines.yml innej gałęzi, ponieważ możesz pominąć tworzenie żądania ściągnięcia z tej gałęzi.

Podgląd w pełni przeanalizowanego dokumentu YAML bez zatwierdzania lub uruchamiania potoku

Dodaliśmy podgląd, ale nie uruchamiamy trybu dla potoków YAML. Teraz możesz wypróbować potok YAML bez zatwierdzania go do repozytorium lub uruchamiania go. Biorąc pod uwagę istniejący potok i opcjonalny nowy ładunek YAML, ten nowy interfejs API zwróci pełny potok YAML. W przyszłych aktualizacjach ten interfejs API będzie używany w nowej funkcji edytora.

Dla deweloperów: POST do dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview z treścią JSON w następujący sposób:

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

Odpowiedź będzie zawierać renderowany kod YAML.

Harmonogramy Cron w języku YAML

Wcześniej można było użyć edytora interfejsu użytkownika do określenia zaplanowanego wyzwalacza dla potoków YAML. W tej wersji można zaplanować kompilacje przy użyciu składni cron w pliku YAML i skorzystać z następujących korzyści:

1. Konfiguracja jako kod: możesz śledzić harmonogramy wraz z potokiem w ramach kodu.
2. Expressive: Masz większą moc ekspresywną w definiowaniu harmonogramów niż to, co udało Ci się za pomocą interfejsu użytkownika. Na przykład łatwiej jest określić jeden harmonogram, który uruchamia się co godzinę.
3. Standard branżowy: wielu deweloperów i administratorów jest już zaznajomionych ze składnią cron.

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

Ułatwiliśmy również diagnozowanie problemów z harmonogramami cron. Zaplanowane przebiegi w menu Uruchamianie potoku zapewni podgląd nadchodzących kilku zaplanowanych przebiegów dla potoku, aby ułatwić diagnozowanie błędów z harmonogramami cron.

Aktualizacje do interfejsu użytkownika połączeń usług

Pracujemy nad zaktualizowanym środowiskiem użytkownika w celu zarządzania połączeniami usług. Te aktualizacje sprawiają, że środowisko połączenia z usługą jest nowoczesne i spójne z kierunkiem usługi Azure DevOps. Na początku tego roku wprowadziliśmy nowy interfejs użytkownika dla połączeń usług jako funkcję w wersji zapoznawczej. Dzięki wszystkim, którzy próbowali nowego doświadczenia i przekazali nam cenne opinie.

Oprócz odświeżania środowiska użytkownika dodaliśmy również dwie możliwości, które mają krytyczne znaczenie dla korzystania z połączeń usług w potokach YAML: autoryzacje potoków i zatwierdzenia i kontrole.

Nowe środowisko użytkownika zostanie domyślnie włączone przy użyciu tej aktualizacji. Nadal będziesz mieć możliwość rezygnacji z wersji zapoznawczej.

Uwaga

Planujemy wprowadzenie funkcji współużytkowania usług między projektami Connections jako nowej możliwości. Więcej szczegółów dotyczących środowiska udostępniania i ról zabezpieczeń można znaleźć tutaj.

Pomijanie etapów w potoku YAML

Po uruchomieniu przebiegu ręcznego czasami można pominąć kilka etapów w potoku. Jeśli na przykład nie chcesz wdrażać w środowisku produkcyjnym lub chcesz pominąć wdrażanie w kilku środowiskach produkcyjnych. Teraz możesz to zrobić za pomocą potoków YAML.

Zaktualizowany panel potoku uruchamiania przedstawia listę etapów z pliku YAML i możesz pominąć jeden lub więcej z tych etapów. Należy zachować ostrożność podczas pomijania etapów. Jeśli na przykład pierwszy etap generuje pewne artefakty potrzebne do kolejnych etapów, nie należy pomijać pierwszego etapu. Panel uruchamiania przedstawia ogólne ostrzeżenie za każdym razem, gdy pomijasz etapy, które mają zależności podrzędne. Pozostaje Ci do czynienia z tym, czy te zależności są prawdziwe zależności artefaktów, czy są one obecne tylko do sekwencjonowania wdrożeń.

Pomijanie etapu jest równoważne ponownemu wirowaniu zależności między etapami. Wszystkie natychmiastowe zależności podrzędne pominiętego etapu są wykonywane w zależności od nadrzędnego etapu pominiętego. Jeśli przebieg zakończy się niepowodzeniem i spróbujesz ponownie uruchomić etap niepowodzenia, ta próba będzie również miała takie samo zachowanie pomijania. Aby zmienić etapy, które są pomijane, musisz rozpocząć nowy przebieg.

Nowe interfejsy użytkownika połączeń usług jako środowisko domyślne

Istnieje nowy interfejs użytkownika połączeń usług. Ten nowy interfejs użytkownika jest oparty na nowoczesnych standardach projektowania i oferuje różne krytyczne funkcje do obsługi wieloetapowych potoków ciągłego wdrażania YAML, takich jak zatwierdzenia, autoryzacje i współużytkowanie między projektami.

Dowiedz się więcej o połączeniach usług tutaj.

Selektor wersji zasobu potoku w oknie dialogowym tworzenia przebiegu

Dodaliśmy możliwość ręcznego odbioru wersji zasobów potoku w oknie dialogowym tworzenia przebiegu. Jeśli używasz potoku jako zasobu w innym potoku, możesz teraz wybrać wersję tego potoku podczas tworzenia przebiegu.

az Ulepszenia interfejsu wiersza polecenia dla usługi Azure Pipelines

Polecenia zarządzania zmiennymi potoku i grupami zmiennych

Przenoszenie potoków opartych na języku YAML z jednego projektu do drugiego może być trudne, ponieważ trzeba ręcznie skonfigurować zmienne potoku i grupy zmiennych. Jednak za pomocą poleceń grupy zmiennych potoku i zarządzania zmiennymi można teraz utworzyć skrypt konfigurowania zmiennych potoku i grup zmiennych, które z kolei mogą być kontrolowane w wersji, co umożliwia łatwe udostępnianie instrukcji przenoszenia i konfigurowania potoków z jednego projektu do innego.

Uruchamianie potoku dla gałęzi żądania ściągnięcia

Podczas tworzenia żądania ściągnięcia może być trudne sprawdzenie, czy zmiany mogą przerwać działanie potoku w gałęzi docelowej. Jednak dzięki możliwości wyzwolenia uruchomienia potoku lub kolejki kompilacji dla gałęzi żądania ściągnięcia można teraz zweryfikować i zwizualizować zmiany, uruchamiając je względem potoku docelowego. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją polecenia az pipelines run i az pipelines build queue .

Pomiń pierwsze uruchomienie potoku

Podczas tworzenia potoków czasami chcesz utworzyć i zatwierdzić plik YAML, a nie wyzwolić uruchomienia potoku, ponieważ może to spowodować nieprawidłowe uruchomienie z różnych powodów — infrastruktura nie jest gotowa lub musi utworzyć i zaktualizować grupy zmiennych/zmiennych itp. Za pomocą interfejsu wiersza polecenia usługi Azure DevOps możesz teraz pominąć pierwszy zautomatyzowany przebieg potoku podczas tworzenia potoku, włączając parametr --skip-first-run. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją polecenia az pipeline create .

Rozszerzenie polecenia punktu końcowego usługi

Polecenia interfejsu wiersza polecenia punktu końcowego usługi obsługują tylko konfigurację punktu końcowego usługi Azure rm i punkt końcowy usługi github oraz zarządzanie nim. Jednak w tej wersji polecenia punktu końcowego usługi umożliwiają tworzenie dowolnego punktu końcowego usługi, zapewniając konfigurację za pośrednictwem pliku i udostępnia zoptymalizowane polecenia — az devops service-endpoint github i az devops service-endpoint azurerm, które zapewniają pierwszą klasę obsługi tworzenia punktów końcowych usługi tych typów. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją polecenia .

Zadania wdrażania

Zadanie wdrożenia to specjalny typ zadania używanego do wdrażania aplikacji w środowisku. Dzięki tej aktualizacji dodaliśmy obsługę odwołań do kroków w zadaniu wdrażania. Można na przykład zdefiniować zestaw kroków w jednym pliku i odwoływać się do niego w zadaniu wdrażania.

Dodaliśmy również obsługę dodatkowych właściwości zadania wdrażania. Na przykład poniżej przedstawiono kilka właściwości zadania wdrożenia, które można teraz ustawić,

• timeoutInMinutes — jak długo należy uruchomić zadanie przed automatycznym anulowaniem
• cancelTimeoutInMinutes — ile czasu na przekazanie polecenia "uruchom zawsze, nawet jeśli anulowano zadania" przed ich zakończeniem
• warunek — warunkowe uruchamianie zadania
• variables — wartości zakodowane na stałe można dodawać bezpośrednio lub grupy zmiennych, grup zmiennych wspieranych przez magazyn kluczy platformy Azure można odwoływać się do zestawu zmiennych zdefiniowanych w pliku.
• continueOnError — jeśli przyszłe zadania powinny być uruchamiane, nawet jeśli to zadanie wdrożenia zakończy się niepowodzeniem; wartość domyślna to "false"

Aby uzyskać więcej informacji na temat zadań wdrażania i pełnej składni w celu określenia zadania wdrożenia, zobacz Zadanie wdrażania.

Wyświetlanie informacji o skojarzonych potokach ciągłej integracji w potokach ciągłej integracji

Dodaliśmy obsługę potoków YAML ciągłego wdrażania, w których potoki ciągłej integracji są określane jako zasoby potoku. W widoku uruchamiania potoku ciągłej integracji zostanie wyświetlona nowa karta "Skojarzone potoki", na której można znaleźć wszystkie uruchomienia potoków, które korzystają z potoku i artefaktów.

Obsługa pakietów GitHub w potokach YAML

Niedawno wprowadziliśmy nowy typ zasobu o nazwie pakiety , które dodaje obsługę korzystania z pakietów NuGet i npm z usługi GitHub jako zasobu w potokach YAML. W ramach tego zasobu możesz teraz określić typ pakietu (NuGet lub npm), który ma być używany z usługi GitHub. Wyzwalacze zautomatyzowanego potoku można również włączyć po wydaniu nowej wersji pakietu. Obecnie obsługa jest dostępna tylko w przypadku korzystania z pakietów z usługi GitHub, ale planujemy rozszerzyć obsługę korzystania z pakietów z innych repozytoriów pakietów, takich jak NuGet, npm, AzureArtifacts i wiele innych. Aby uzyskać szczegółowe informacje, zapoznaj się z poniższym przykładem:

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Uwaga

Obecnie pakiety GitHub obsługują tylko uwierzytelnianie oparte na pat, co oznacza, że połączenie usługi GitHub w zasobie pakietu powinno być typu PAT. Gdy to ograniczenie zostanie zniesione, zapewnimy obsługę innych typów uwierzytelniania.

Domyślnie pakiety nie są automatycznie pobierane w zadaniach, dlatego wprowadziliśmy makro getPackage , które umożliwia korzystanie z pakietu zdefiniowanego w zasobie. Aby uzyskać szczegółowe informacje, zapoznaj się z poniższym przykładem:

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

link klastra Azure Kubernetes Service w widoku zasobów środowisk Kubernetes

Dodaliśmy link do widoku zasobów środowisk Kubernetes, aby można było przejść do bloku platformy Azure dla odpowiedniego klastra. Dotyczy to środowisk mapowanych na przestrzenie nazw w klastrach Azure Kubernetes Service.

Filtry folderów wydań w subskrypcjach powiadomień

Foldery umożliwiają organizowanie potoków w celu ułatwienia odnajdywania i kontroli zabezpieczeń. Często można skonfigurować niestandardowe powiadomienia e-mail dla wszystkich potoków wydania, które są reprezentowane przez wszystkie potoki w folderze. Wcześniej trzeba było skonfigurować wiele subskrypcji lub mieć złożone zapytanie w subskrypcjach, aby uzyskać ukierunkowane wiadomości e-mail. Dzięki tej aktualizacji można teraz dodać klauzulę folderu wydania do zdarzeń zakończonych wdrożenia i oczekujących na zatwierdzenie oraz uprościć subskrypcje.

Łączenie elementów roboczych z wieloetapowymi potokami YAML

Obecnie można automatycznie łączyć elementy robocze z kompilacjami klasycznymi. Nie było to jednak możliwe w przypadku potoków YAML. Dzięki tej aktualizacji rozwiązaliśmy tę lukę. Po pomyślnym uruchomieniu potoku przy użyciu kodu z określonej gałęzi usługa Azure Pipelines automatycznie skojarzy przebieg ze wszystkimi elementami roboczymi (które są wnioskowane za pośrednictwem zatwierdzeń w tym kodzie). Po otwarciu elementu roboczego będzie można zobaczyć uruchomienia, w których utworzono kod dla tego elementu roboczego. Aby to skonfigurować, użyj panelu ustawień potoku.

Anulowanie etapu w wieloetapowym przebiegu potoku YAML

Podczas uruchamiania wieloetapowego potoku YAML można teraz anulować wykonywanie etapu, gdy jest on w toku. Jest to przydatne, jeśli wiesz, że etap kończy się niepowodzeniem lub jeśli masz inny przebieg, który chcesz uruchomić.

Etapy ponawiania próby zakończyły się niepowodzeniem

Jedną z najbardziej żądanych funkcji w potokach wieloetapowych jest możliwość ponawiania próby etapu niepowodzenia bez konieczności rozpoczynania się od początku. Dzięki tej aktualizacji dodajemy dużą część tej funkcji.

Teraz możesz ponowić próbę wykonania etapu potoku, gdy wykonanie zakończy się niepowodzeniem. Wszystkie zadania, które zakończyły się niepowodzeniem w pierwszej próbie, i te, które zależą przechodnio od tych zadań, które zakończyły się niepowodzeniem, zostaną ponowione.

Może to pomóc zaoszczędzić czas na kilka sposobów. Na przykład w przypadku uruchamiania wielu zadań na etapie każdy etap może chcieć uruchamiać testy na innej platformie. Jeśli testy na jednej platformie kończą się niepowodzeniem, gdy inne przejdą, możesz zaoszczędzić czas, nie uruchamiając ponownie zadań, które przeszły. W innym przykładzie etap wdrażania mógł zakończyć się niepowodzeniem z powodu niestabilnego połączenia sieciowego. Ponawianie próby na tym etapie pomoże Ci zaoszczędzić czas, nie trzeba tworzyć innej kompilacji.

Ta funkcja zawiera kilka znanych luk. Na przykład nie można ponowić próby jawnego anulowania etapu. Pracujemy nad zamknięciem tych luk w przyszłych aktualizacjach.

Zatwierdzenia w wieloetapowych potokach YAML

Potoki ciągłego wdrażania YAML mogą zawierać zatwierdzenia ręczne. Właściciele infrastruktury mogą chronić swoje środowiska i szukać ręcznych zatwierdzeń przed etapem we wszystkich wdrożeniach potoków. Dzięki pełnej segregacji ról między właścicielami infrastruktury (środowiska) i aplikacji (potoku) zapewnisz ręczne wylogowanie się z wdrożenia w określonym potoku i uzyskanie centralnej kontroli podczas stosowania tych samych kontroli we wszystkich wdrożeniach w środowisku.

Uruchomienia potoku wdrażane w środowisku deweloperskim przestaną zatwierdzać na początku etapu.

Zwiększenie limitu czasu bramy i częstotliwości

Wcześniej limit czasu bramy w potokach wydania wynosił trzy dni. Dzięki tej aktualizacji limit czasu został zwiększony do 15 dni , aby umożliwić bramom dłuższy czas trwania. Zwiększyliśmy również częstotliwość bramy do 30 minut.

Nowy szablon obrazu kompilacji dla pliku Dockerfile

Wcześniej podczas tworzenia nowego potoku dla pliku Dockerfile w ramach tworzenia nowego potoku szablon zaleca wypychanie obrazu do Azure Container Registry i wdrażanie w Azure Kubernetes Service. Dodaliśmy nowy szablon umożliwiający utworzenie obrazu przy użyciu agenta bez konieczności wypychania do rejestru kontenerów.

Nowe zadanie konfigurowania ustawień aplikacji Azure App Service

Azure App Service umożliwia konfigurację za pomocą różnych ustawień, takich jak ustawienia aplikacji, parametry połączenia i inne ogólne ustawienia konfiguracji. Mamy teraz nowe zadanie usługi Azure Pipelines Azure App Service Ustawienia, które obsługuje zbiorcze konfigurowanie tych ustawień przy użyciu składni JSON w aplikacji internetowej lub w dowolnym miejscu wdrożenia. To zadanie może służyć wraz z innymi zadaniami usługi App Service do wdrażania i konfigurowania aplikacji internetowych, aplikacji funkcji lub innych konteneryzowanych usług App Services oraz zarządzania nimi.

Azure App Service obsługuje teraz zamianę za pomocą wersji zapoznawczej

Azure App Service obsługuje teraz zamianę za pomocą wersji zapoznawczej w swoich miejscach wdrożenia. Jest to dobry sposób na zweryfikowanie aplikacji przy użyciu konfiguracji produkcyjnej, zanim aplikacja zostanie faktycznie zamieniona z miejsca przejściowego na miejsce produkcyjne. Zapewni to również, że miejsce docelowe/produkcyjne nie będzie miało przestoju.

Azure App Service zadanie obsługuje teraz zamianę wielofazową za pomocą następujących nowych akcji:

• Rozpocznij zamianę z wersją zapoznawczą — inicjuje zamianę z podglądem (zamiana wielofazowa) i stosuje konfigurację miejsca docelowego (na przykład miejsca produkcyjnego) do miejsca źródłowego.
• Ukończ zamianę z podglądem — gdy wszystko będzie gotowe do ukończenia oczekującej zamiany, wybierz akcję Zakończ zamianę z podglądem.
• Anulowanie zamiany z podglądem — aby anulować oczekującą zamianę, wybierz pozycję Anuluj zamianę z podglądem.

Filtr na poziomie etapu dla artefaktów Azure Container Registry i Docker Hub

Wcześniej filtry wyrażeń regularnych dla Azure Container Registry i artefaktów Docker Hub były dostępne tylko na poziomie potoku wydania. Zostały one również dodane na poziomie etapu.

Ulepszenia zatwierdzeń w potokach YAML

Włączyliśmy konfigurowanie zatwierdzeń dla połączeń usług i pul agentów. W przypadku zatwierdzeń następuje segregacja ról między właścicielami infrastruktury a deweloperami. Dzięki skonfigurowaniu zatwierdzeń w zasobach, takich jak środowiska, połączenia usługi i pule agentów, będziesz mieć pewność, że wszystkie uruchomienia potoków używające zasobów będą najpierw wymagały zatwierdzenia.

Środowisko jest podobne do konfigurowania zatwierdzeń dla środowisk. Gdy zatwierdzenie oczekuje na zasób przywoływalny na etapie, wykonanie potoku czeka na ręczne zatwierdzenie potoku.

Obsługa testowania struktury kontenerów w usłudze Azure Pipelines

Użycie kontenerów w aplikacjach rośnie, dlatego potrzeba niezawodnego testowania i walidacji. Usługa Azure Pipelines obsługuje teraz testy struktury kontenerów. Ta struktura zapewnia wygodny i zaawansowany sposób weryfikowania zawartości i struktury kontenerów.

Możesz zweryfikować strukturę obrazu na podstawie czterech kategorii testów, które można uruchamiać razem: testy poleceń, testy istnienia plików, testy zawartości plików i testy metadanych. Możesz użyć wyników w potoku, aby podjąć decyzje dotyczące go/no go. Dane testowe są dostępne w przebiegu potoku z komunikatem o błędzie, aby ułatwić rozwiązywanie problemów z błędami.

Wprowadzanie pliku konfiguracji i szczegółów obrazu

Dane testowe i podsumowanie

Dekoratory potoków dla potoków wydania

Dekoratory potoków umożliwiają dodawanie kroków do początku i końca każdego zadania. Różni się to od dodawania kroków do pojedynczej definicji, ponieważ dotyczy wszystkich potoków w kolekcji.

Wspieraliśmy dekoratory kompilacji i potoków YAML, a klienci używają ich do centralnej kontroli kroków w swoich zadaniach. Teraz rozszerzamy również obsługę potoków wydania. Rozszerzenia można tworzyć, aby dodać kroki przeznaczone dla nowego punktu współtworzenia i zostaną dodane do wszystkich zadań agenta w potokach wydania.

Wdrażanie usługi Azure Resource Manager (ARM) na poziomie subskrypcji i grupy zarządzania

Wcześniej obsługiwano wdrożenia tylko na poziomie grupy zasobów. Dzięki tej aktualizacji dodaliśmy obsługę wdrażania szablonów usługi ARM zarówno na poziomie subskrypcji, jak i grupy zarządzania. Pomoże to podczas wdrażania zestawu zasobów razem, ale umieszcza je w różnych grupach zasobów lub subskrypcjach. Na przykład wdrożenie maszyny wirtualnej kopii zapasowej dla usługi Azure Site Recovery w oddzielnej grupie zasobów i lokalizacji.

Możliwości ciągłego wdrażania dla wieloetapowych potoków YAML

Teraz możesz korzystać z artefaktów publikowanych przez potok ciągłej integracji i włączać wyzwalacze uzupełniania potoku. W wieloetapowych potokach YAML wprowadzamy pipelines jako zasób. W języku YAML możesz teraz odwołać się do innego potoku, a także włączyć wyzwalacze ciągłego wdrażania.

Oto szczegółowy schemat YAML dla zasobu potoków.

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

Ponadto możesz pobrać artefakty opublikowane przez zasób potoku - download przy użyciu zadania .

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

Aby uzyskać więcej informacji, zobacz dokumentację pobierania artefaktów tutaj.

Organizowanie strategii wdrażania kanarowego w środowisku dla platformy Kubernetes

Jedną z kluczowych zalet ciągłego dostarczania aktualizacji aplikacji jest możliwość szybkiego wypychania aktualizacji do środowiska produkcyjnego dla określonych mikrousług. Dzięki temu można szybko reagować na zmiany wymagań biznesowych. Środowisko zostało wprowadzone jako pierwszoklasowa koncepcja umożliwiająca organizowanie strategii wdrażania i ułatwianie bez przestojów. Wcześniej obsługiwaliśmy strategię runOnce , która wykonała kroki po sekwencyjnie. Dzięki obsłudze strategii kanarowej w potokach wieloetapowych można teraz zmniejszyć ryzyko, powoli wdrażając zmianę w małym podzestawie. Po uzyskaniu większej pewności co do nowej wersji możesz rozpocząć wdrażanie go na większej infrastruktury i kierować do niej więcej użytkowników.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Strategia kanaryczna dla platformy Kuberenetes najpierw wdroży zmiany z 10% zasobnikami, a następnie 20% podczas monitorowania kondycji podczas postRouteTraffic. Jeśli wszystko pójdzie dobrze, będzie promować do 100%.

Szukamy wczesnej opinii na temat obsługi zasobu maszyny wirtualnej w środowiskach i przeprowadzania strategii wdrażania stopniowego na wielu maszynach. Skontaktuj się z nami, aby zarejestrować się.

Zasady zatwierdzania potoków YAML

W potokach YAML postępuje zgodnie z konfiguracją zatwierdzania kontrolowanego przez właściciela zasobu. Właściciele zasobów konfigurują zatwierdzenia dla zasobu i wszystkich potoków, które używają wstrzymania zasobu do zatwierdzenia przed rozpoczęciem etapu zużywania zasobu. Właściciele aplikacji opartych na protokole SOX często ograniczają żądającego wdrożenia od zatwierdzania własnych wdrożeń.

Teraz możesz użyć zaawansowanych opcji zatwierdzania , aby skonfigurować zasady zatwierdzania, takie jak żądający, nie powinny zatwierdzać, wymagają zatwierdzenia z podzestawu użytkowników i limitu czasu zatwierdzania.

Usługa ACR jako zasób potoku pierwszej klasy

Jeśli musisz użyć obrazu kontenera opublikowanego w usłudze ACR (Azure Container Registry) w ramach potoku i wyzwolić potok po opublikowaniu nowego obrazu, możesz użyć zasobu kontenera usługi ACR.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

Ponadto dostęp do metadanych obrazu usługi ACR można uzyskać przy użyciu wstępnie zdefiniowanych zmiennych. Poniższa lista zawiera zmienne usługi ACR dostępne do definiowania zasobu kontenera usługi ACR w potoku.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Ulepszenia oceny zasad sprawdzania artefaktów w potokach

Ulepszyliśmy sprawdzanie artefaktu oceny , aby ułatwić dodawanie zasad z listy nieuwzględnianych definicji zasad. Definicja zasad zostanie wygenerowana automatycznie i dodana do konfiguracji sprawdzania , która może zostać zaktualizowana w razie potrzeby.

Obsługa zmiennych wyjściowych w zadaniu wdrażania

Teraz można zdefiniować zmienne wyjściowe w punktach zaczepienia cyklu życia zadania wdrożenia i korzystać z nich w innych krokach podrzędnych i zadaniach w tym samym etapie.

Podczas wykonywania strategii wdrażania można uzyskać dostęp do zmiennych wyjściowych między zadaniami przy użyciu następującej składni.

• W przypadku strategii runOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• W przypadku strategii kanaarnej : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• W przypadku strategii stopniowej : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

Dowiedz się więcej na temat ustawiania zmiennej wyjściowej obejmującej wiele zadań

Unikanie wycofywania zmian krytycznych

W potokach wersji klasycznych często jest polegać na zaplanowanych wdrożeniach w przypadku regularnych aktualizacji. Jeśli jednak masz poprawkę krytyczną, możesz rozpocząć ręczne wdrażanie poza pasmem. W tym celu starsze wersje nadal są zaplanowane. Stanowi to wyzwanie, ponieważ wdrożenie ręczne zostanie wycofane po wznowieniu wdrożeń zgodnie z harmonogramem. Wielu z was zgłosiło ten problem i rozwiązaliśmy go. W przypadku poprawki wszystkie starsze zaplanowane wdrożenia w środowisku zostaną anulowane podczas ręcznego uruchamiania wdrożenia. Ma to zastosowanie tylko wtedy, gdy opcja kolejkowania jest zaznaczona jako "Wdróż najnowsze i anuluj inne".

Uproszczona autoryzacja zasobów w potokach YAML

Zasób jest używany przez potok, który znajduje się poza potokiem. Aby można było używać zasobów, należy autoryzować zasoby. Wcześniej w przypadku używania nieautoryzowanych zasobów w potoku YAML wystąpił błąd autoryzacji zasobu. Trzeba było autoryzować zasoby ze strony podsumowania przebiegu, który zakończył się niepowodzeniem. Ponadto potok nie powiódł się, jeśli używa zmiennej, która odwołuje się do nieautoryzowanego zasobu.

Teraz ułatwiamy zarządzanie autoryzacjami zasobów. Zamiast niepowodzenia przebiegu, uruchomienie będzie czekać na uprawnienia do zasobów na początku etapu zużywającego zasób. Właściciel zasobu może wyświetlić potok i autoryzować zasób na stronie Zabezpieczenia.

Ocena sprawdzania artefaktu

Teraz można zdefiniować zestaw zasad i dodać ocenę zasad jako sprawdzenie środowiska dla artefaktów obrazu kontenera. Po uruchomieniu potoku wykonanie zostanie wstrzymane przed rozpoczęciem etapu, który używa środowiska. Określone zasady są oceniane względem dostępnych metadanych dla wdrożonego obrazu. Sprawdzanie przechodzi po pomyślnym zakończeniu zasad i oznacza etap jako niepowodzenie, jeśli sprawdzanie zakończy się niepowodzeniem.

Aktualizacje do zadania wdrożenia szablonu usługi ARM

Wcześniej nie filtrowaliśmy połączeń usługi w zadaniu wdrażania szablonu usługi ARM. Może to spowodować niepowodzenie wdrożenia, jeśli wybierasz połączenie usługi o niższym zakresie w celu wykonania wdrożeń szablonów usługi ARM w szerszym zakresie. Teraz dodaliśmy filtrowanie połączeń usług, aby odfiltrować mniejsze połączenia usług o niższym zakresie na podstawie wybranego zakresu wdrożenia.

Przeglądanie aplikacji w środowisku

ReviewApp wdraża każde żądanie ściągnięcia z repozytorium Git w zasobie środowiska dynamicznego. Recenzenci mogą zobaczyć, jak wyglądają te zmiany, a także pracować z innymi usługami zależnymi przed scaleniem ich z gałęzią główną i wdrożoną w środowisku produkcyjnym. Ułatwi to tworzenie zasobów aplikacji i zarządzanie nimi oraz korzystanie ze wszystkich funkcji śledzenia i diagnostyki funkcji środowiska. Używając słowa kluczowego reviewApp , możesz utworzyć klon zasobu (dynamicznie utworzyć nowy zasób na podstawie istniejącego zasobu w środowisku) i dodać nowy zasób do środowiska.

Poniżej przedstawiono przykładowy fragment kodu YAML dotyczący używania funkcji reviewApp w środowiskach.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MainNamespace

Zbieranie automatycznych i określonych przez użytkownika metadanych z potoku

Teraz możesz włączyć automatyczne i określone przez użytkownika zbieranie metadanych z zadań potoku. Za pomocą metadanych można wymusić zasady artefaktów w środowisku przy użyciu sprawdzania artefaktu oceny.

Wdrożenia maszyn wirtualnych ze środowiskami

Jedną z najbardziej żądanych funkcji w środowiskach było wdrożenie maszyn wirtualnych. Dzięki tej aktualizacji włączamy zasób maszyny wirtualnej w środowiskach. Teraz można organizować wdrożenia na wielu maszynach i wykonywać aktualizacje stopniowe przy użyciu potoków YAML. Agenta można również zainstalować na każdym z serwerów docelowych bezpośrednio i przeprowadzić wdrażanie stopniowe na tych serwerach. Ponadto można użyć pełnego wykazu zadań na maszynach docelowych.

Wdrożenie stopniowe zastępuje wystąpienia poprzedniej wersji aplikacji wystąpieniami nowej wersji aplikacji na zestawie maszyn (zestaw kroczący) w każdej iteracji.

Na przykład poniżej aktualizacji wdrażania stopniowego do pięciu elementów docelowych w każdej iteracji. maxParallel określi liczbę obiektów docelowych, które można wdrożyć równolegle. Wybór odpowiada liczbie obiektów docelowych, które muszą pozostać dostępne w dowolnym momencie, z wyłączeniem miejsc docelowych, do których są wdrażane. Służy również do określania warunków powodzenia i niepowodzenia podczas wdrażania.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Uwaga

Dzięki tej aktualizacji wszystkie dostępne artefakty z bieżącego potoku i skojarzonych zasobów potoku są pobierane tylko w deploy elemencie cyklu życia. Możesz jednak wybrać opcję pobrania, określając zadanie Pobierz artefakt potoku. W tej funkcji istnieje kilka znanych luk. Na przykład ponawianie próby etapu spowoduje ponowne uruchomienie wdrożenia na wszystkich maszynach wirtualnych, a nie tylko nieudanych celów. Pracujemy nad zamknięciem tych luk w przyszłych aktualizacjach.

Dodatkowa kontrola nad wdrożeniami

Usługa Azure Pipelines od jakiegoś czasu obsługuje wdrożenia kontrolowane za pomocą zatwierdzeń ręcznych. Dzięki najnowszym ulepszeniom masz teraz dodatkową kontrolę nad wdrożeniami. Oprócz zatwierdzeń właściciele zasobów mogą teraz dodawać automatyczne checks weryfikowanie zasad zabezpieczeń i jakości. Te kontrole mogą służyć do wyzwalania operacji, a następnie oczekiwania na ich ukończenie. Korzystając z dodatkowych testów, można teraz zdefiniować kryteria kondycji na podstawie wielu źródeł i mieć pewność, że wszystkie wdrożenia przeznaczone dla zasobów są bezpieczne, niezależnie od potoku YAML wykonującego wdrożenie. Ocena każdego sprawdzania może być okresowo powtarzana na podstawie określonego interwału ponawiania dla sprawdzania. Dostępne są teraz następujące dodatkowe kontrole:

• Wywoływanie dowolnego interfejsu API REST i przeprowadzanie walidacji na podstawie treści odpowiedzi lub wywołania zwrotnego z usługi zewnętrznej
• Wywoływanie funkcji platformy Azure i przeprowadzanie walidacji na podstawie odpowiedzi lub wywołania zwrotnego z funkcji
• Wykonywanie zapytań względem reguł usługi Azure Monitor dla aktywnych alertów
• Upewnij się, że potok rozszerza co najmniej jeden szablon YAML

Powiadomienie o zatwierdzeniu

Po dodaniu zatwierdzenia do środowiska lub połączenia z usługą wszystkie potoki wieloetapowe korzystające z zasobu automatycznie czekają na zatwierdzenie na początku etapu. Wyznaczone osoby zatwierdzające muszą ukończyć zatwierdzenie przed kontynuowaniem potoku.

Dzięki tej aktualizacji osoby zatwierdzające są wysyłane powiadomienie e-mail o oczekiwaniu na zatwierdzenie. Użytkownicy i właściciele zespołów mogą zrezygnować z subskrypcji niestandardowych lub konfigurować je przy użyciu ustawień powiadomień.

Konfigurowanie strategii wdrażania z Azure Portal

Dzięki tej możliwości ułatwiliśmy konfigurowanie potoków korzystających z wybranej strategii wdrażania, na przykład Rolling, Canary lub Blue-Green. Korzystając z tych wbudowanych strategii, możesz wdrożyć aktualizacje w bezpieczny sposób i ograniczyć skojarzone zagrożenia związane z wdrażaniem. Aby uzyskać do tego dostęp, kliknij ustawienie "Ciągłe dostarczanie" na maszynie wirtualnej platformy Azure. W okienku konfiguracji zostanie wyświetlony monit o wybranie szczegółów dotyczących projektu usługi Azure DevOps, w którym zostanie utworzony potok, grupa wdrażania, potok kompilacji, który publikuje pakiet do wdrożenia i wybraną strategię wdrażania. W przyszłości skonfiguruje w pełni funkcjonalny potok, który wdraża wybrany pakiet na tej maszynie wirtualnej.

Aby uzyskać więcej informacji, zapoznaj się z naszą dokumentacją dotyczącą konfigurowania strategii wdrażania.

Parametry środowiska uruchomieniowego

Parametry środowiska uruchomieniowego umożliwiają większą kontrolę nad wartościami, które można przekazać do potoku. W przeciwieństwie do zmiennych parametry środowiska uruchomieniowego mają typy danych i nie stają się automatycznie zmiennymi środowiskowymi. Za pomocą parametrów środowiska uruchomieniowego można wykonywać następujące czynności:

• Podaj różne wartości dla skryptów i zadań w czasie wykonywania
• Typy parametrów sterowania, dozwolone zakresy i wartości domyślne
• Dynamiczne wybieranie zadań i etapów za pomocą wyrażenia szablonu

Aby dowiedzieć się więcej o parametrach środowiska uruchomieniowego, zobacz dokumentację tutaj.

Używanie słowa kluczowego extends w potokach

Obecnie potoki można uwzględnić w szablonach, promując ponowne użycie i zmniejszając kocioł. Ogólna struktura potoku została nadal zdefiniowana przez główny plik YAML. Dzięki tej aktualizacji dodaliśmy bardziej ustrukturyzowany sposób korzystania z szablonów potoków. Główny plik YAML może teraz używać słowa kluczowego , aby wskazać, że główną strukturę potoku można znaleźć w innym pliku. Pozwala to kontrolować, jakie segmenty można rozszerzyć lub zmienić oraz jakie segmenty są stałe. Ulepszyliśmy również parametry potoku z typami danych, aby wyczyścić punkty zaczepienia, które można podać.

W tym przykładzie pokazano, jak można podać proste zaczepienia dla autora potoku do użycia. Szablon zawsze uruchomi kompilację, opcjonalnie uruchomi dodatkowe kroki dostarczone przez potok, a następnie uruchomi opcjonalny krok testowania.

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Zmienne sterujące, które mogą być zastępowane w czasie kolejki

Wcześniej można było użyć interfejsu użytkownika lub interfejsu API REST, aby zaktualizować wartości dowolnej zmiennej przed rozpoczęciem nowego przebiegu. Chociaż autor potoku może oznaczyć pewne zmienne jako _settable at queue time_, system nie wymuszał tego ani nie uniemożliwiał ustawiania innych zmiennych. Innymi słowy, ustawienie było używane tylko do monitowania o dodatkowe dane wejściowe podczas uruchamiania nowego przebiegu.

Dodaliśmy nowe ustawienie kolekcji, które wymusza _settable at queue time_ parametr . Dzięki temu można kontrolować, które zmienne można zmienić podczas uruchamiania nowego przebiegu. W przyszłości nie można zmienić zmiennej, która nie jest oznaczona przez autora jako _settable at queue time_.

Uwaga

To ustawienie jest domyślnie wyłączone w istniejących kolekcjach, ale będzie ono domyślnie włączone podczas tworzenia nowej kolekcji usługi Azure DevOps.

Nowe wstępnie zdefiniowane zmienne w potoku YAML

Zmienne zapewniają wygodny sposób uzyskiwania kluczowych bitów danych do różnych części potoku. Dzięki tej aktualizacji dodaliśmy kilka wstępnie zdefiniowanych zmiennych do zadania wdrożenia. Te zmienne są automatycznie ustawiane przez system, ograniczone do określonego zadania wdrożenia i są tylko do odczytu.

• Environment.Id — identyfikator środowiska.
• Environment.Name — nazwa środowiska objętego zadaniem wdrożenia.
• Environment.ResourceId — identyfikator zasobu w środowisku docelowym przez zadanie wdrożenia.
• Environment.ResourceName — nazwa zasobu w środowisku docelowym przez zadanie wdrożenia.

Wyewidencjonuj wiele repozytoriów

Potoki często polegają na wielu repozytoriach. Możesz mieć różne repozytoria ze źródłem, narzędziami, skryptami lub innymi elementami, które należy utworzyć. Wcześniej trzeba było dodać te repozytoria jako moduły podrzędne lub jako skrypty ręczne, aby uruchomić wyewidencjonowanie git. Teraz możesz pobrać i wyewidencjonować inne repozytoria, oprócz tego, którego używasz do przechowywania potoku YAML.

Jeśli na przykład masz repozytorium o nazwie MyCode z potokiem YAML i drugim repozytorium o nazwie Narzędzia, potok YAML będzie wyglądać następująco:

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

Trzeci krok spowoduje wyświetlenie dwóch katalogów , MyCode i Tools w katalogu sources.

Azure Repos repozytoria Git są obsługiwane. Aby uzyskać więcej informacji, zobacz Wyewidencjonuj wiele repozytoriów.

Uzyskiwanie szczegółów w czasie wykonywania na temat wielu repozytoriów

Po uruchomieniu potoku usługa Azure Pipelines dodaje informacje o repozytorium, gałęzi i zatwierdzaniu, które wyzwoliły przebieg. Teraz, gdy potoki YAML obsługują wyewidencjonowanie wielu repozytoriów, warto również znać repozytorium, gałąź i zatwierdzenie, które zostały wyewidencjonowane dla innych repozytoriów. Te dane są dostępne za pośrednictwem wyrażenia środowiska uruchomieniowego, które można teraz mapować na zmienną. Na przykład:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

Zezwalaj na odwołania do repozytorium do innych kolekcji Azure Repos

Wcześniej podczas odwołwania się do repozytoriów w potoku YAML wszystkie repozytoria Azure Repos musiały znajdować się w tej samej kolekcji co potok. Teraz możesz wskazać repozytoria w innych kolekcjach przy użyciu połączenia z usługą. Na przykład:

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection wskazuje inną kolekcję usługi Azure DevOps i ma poświadczenia, które mogą uzyskiwać dostęp do repozytorium w innym projekcie. Oba repozytoria self i otherrepo, zostaną wyewidencjonowane.

Ważne

MyServiceConnectionmusi być połączeniem usługi Azure Repos /Team Foundation Server, zobacz obraz poniżej.

Metadane zasobu potoku jako wstępnie zdefiniowane zmienne

Dodaliśmy wstępnie zdefiniowane zmienne dla zasobów potoków YAML w potoku. Oto lista dostępnych zmiennych zasobów potoku.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

kustomize i kompose jako opcje pieczenia w zadaniu KubernetesManifest

kustomize (część sig-cli platformy Kubernetes) umożliwia dostosowanie nieprzetworzonych, bez szablonu plików YAML do wielu celów i pozostawienie oryginalnego kodu YAML nietkniętego. Opcja kustomize została dodana w ramach akcji bake zadania KubernetesManifest , aby każdy folder zawierający pliki kustomization.yaml mógł służyć do generowania plików manifestu używanych w akcji wdrażania zadania KubernetesManifest.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose przekształci pliki Docker Compose w zasób Kubernetes.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Obsługa poświadczeń administratora klastra w zadaniu HelmDeploy

Wcześniej zadanie HelmDeploy używało poświadczeń użytkownika klastra do wdrożeń. Spowodowało to interaktywne monity logowania i nieudane potoki dla klastra z włączoną kontrolą dostępu opartą na rolach usługi Azure Active Directory. Aby rozwiązać ten problem, dodaliśmy pole wyboru umożliwiające używanie poświadczeń administratora klastra zamiast poświadczeń użytkownika klastra.

Argumenty wejściowe w zadaniu Docker Compose

Nowe pole zostało wprowadzone w zadaniu docker Compose, aby umożliwić dodawanie argumentów, takich jak --no-cache. Argument zostanie przekazany przez zadanie podczas uruchamiania poleceń, takich jak kompilacja.

Ulepszenia zadań wydania usługi GitHub

Wprowadziliśmy kilka ulepszeń zadania wydania usługi GitHub. Teraz możesz mieć lepszą kontrolę nad tworzeniem wydania przy użyciu pola wzorca tagu, określając wyrażenie regularne tagu, a wydanie zostanie utworzone tylko wtedy, gdy zatwierdzenie wyzwalające zostanie oznaczone pasującym ciągiem.

Dodaliśmy również możliwości dostosowywania tworzenia i formatowania dziennika zmian. W nowej sekcji konfiguracji dziennika zmian można teraz określić wydanie, względem którego ma zostać porównana bieżąca wersja. Porównanie z wydaniem może być ostatnią pełną wersją (wyklucza wersje wstępne), ostatnią wersją inną niż wersja robocza lub dowolną poprzednią wersją zgodną z podanym tagiem wydania. Ponadto zadanie udostępnia pole typu dziennika zmian, aby sformatować dziennik zmian. Na podstawie zaznaczenia dziennik zmian wyświetli listę zatwierdzeń lub listę problemów/żądania ściągnięcia podzielone na kategorie na podstawie etykiet.

Otwórz zadanie instalatora agenta zasad

Open Policy Agent to aparat zasad open source ogólnego przeznaczenia, który umożliwia ujednolicone wymuszanie zasad obsługujących kontekst. Dodaliśmy zadanie instalatora Open Policy Agent. Jest to szczególnie przydatne w przypadku wymuszania zasad potoku w odniesieniu do infrastruktury jako dostawców kodu.

Na przykład program Open Policy Agent może ocenić pliki zasad Rego i plany programu Terraform w potoku.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Obsługa skryptów programu PowerShell w zadaniu interfejsu wiersza polecenia platformy Azure

Wcześniej można było wykonać skrypty wsadowe i bash w ramach zadania interfejsu wiersza polecenia platformy Azure. Dzięki tej aktualizacji dodaliśmy obsługę skryptów podstawowych programu PowerShell i programu PowerShell do zadania.

Wdrożenia kanary oparte na interfejsie usługi Service Mesh w zadaniu KubernetesManifest

Wcześniej, gdy strategia kanaryczna została określona w zadaniu KubernetesManifest, zadanie tworzyłoby obciążenia bazowe i kanarowe, których repliki równały się procentowi replik używanych do stabilnych obciążeń. Nie było to dokładnie takie samo, jak dzielenie ruchu do żądanej wartości procentowej na poziomie żądania. Aby rozwiązać ten problem, dodaliśmy obsługę wdrożeń kanarowych opartych na interfejsie usługi Service Mesh do zadania KubernetesManifest.

Abstrakcja interfejsu usługi Service Mesh umożliwia konfigurowanie wtyczek i odtwarzania z dostawcami usług, takimi jak Linkerd i Istio. Teraz zadanie KubernetesManifest zabiera ciężką pracę mapowania obiektów SMI TrafficSplit na stabilne, bazowe i kanary usług w cyklu życia strategii wdrażania. Żądany procent podziału ruchu między stabilnym, bazowym i kanarowym jest dokładniejszy, ponieważ podział ruchu procentowego jest kontrolowany na żądaniach na płaszczyźnie siatki usług.

Poniżej przedstawiono przykład wykonywania wdrożeń kanarowych opartych na protokole SMI w sposób kroczący.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Zadanie kopiowania plików platformy Azure obsługuje teraz narzędzie AzCopy w wersji 10

Zadanie kopiowania plików platformy Azure może być używane w potoku kompilacji lub wydania w celu kopiowania plików do obiektów blob magazynu Firmy Microsoft lub maszyn wirtualnych. Zadanie używa narzędzia AzCopy, kompilowania narzędzia wiersza polecenia w celu szybkiego kopiowania danych z kont i do kont usługi Azure Storage. Dzięki tej aktualizacji dodaliśmy obsługę narzędzia AzCopy v10, która jest najnowszą wersją narzędzia AzCopy.

Polecenie azcopy copy obsługuje tylko skojarzone z nim argumenty . Ze względu na zmianę składni narzędzia AzCopy niektóre z istniejących możliwości nie są dostępne w narzędziu AzCopy v10. Są one następujące:

• Określanie lokalizacji dziennika
• Czyszczenie plików dziennika i planowania po skopiowaniu
• Wznów kopiowanie, jeśli zadanie zakończy się niepowodzeniem

Dodatkowe możliwości obsługiwane w tej wersji zadania to:

• Symbole wieloznaczne w nazwie/ścieżce pliku źródłowego
• Wnioskowanie typu zawartości na podstawie rozszerzenia pliku, gdy nie podano żadnych argumentów
• Definiowanie szczegółowości dziennika dla pliku dziennika przez przekazanie argumentu

Zwiększanie zabezpieczeń potoku przez ograniczenie zakresu tokenów dostępu

Każde zadanie uruchamiane w usłudze Azure Pipelines otrzymuje token dostępu. Token dostępu jest używany przez zadania i skrypty do wywołania z powrotem do usługi Azure DevOps. Na przykład używamy tokenu dostępu do pobierania kodu źródłowego, przekazywania dzienników, wyników testów, artefaktów lub wywołań REST do usługi Azure DevOps. Nowy token dostępu jest generowany dla każdego zadania i wygasa po zakończeniu zadania. Dzięki tej aktualizacji dodaliśmy następujące ulepszenia.

• Uniemożliwianie tokenowi uzyskiwania dostępu do zasobów poza projektem zespołowym

  Do tej pory domyślnym zakresem wszystkich potoków była kolekcja projektów zespołowych. Zakres można zmienić tak, aby był projektem zespołowym w klasycznych potokach kompilacji. Nie masz jednak tej kontroli dla potoków klasycznej wersji lub YAML. Dzięki tej aktualizacji wprowadzamy ustawienie kolekcji, aby wymusić, że każde zadanie będzie pobierać token o zakresie projektu niezależnie od tego, co jest skonfigurowane w potoku. Dodaliśmy również ustawienie na poziomie projektu. Teraz każdy nowy projekt i utworzona kolekcja będą automatycznie miały włączone to ustawienie.

  Uwaga

  Ustawienie kolekcji zastępuje ustawienie projektu.

  Włączenie tego ustawienia w istniejących projektach i kolekcjach może spowodować niepowodzenie niektórych potoków, jeśli potoki uzyskują dostęp do zasobów spoza projektu zespołowego przy użyciu tokenów dostępu. Aby wyeliminować błędy potoku, możesz jawnie przyznać użytkownikowi Project Build Service Account dostęp do żądanego zasobu. Zdecydowanie zalecamy włączenie tych ustawień zabezpieczeń.

• Ograniczanie dostępu do zakresu repozytoriów usługi kompilacji

  Opierając się na ulepszaniu zabezpieczeń potoku przez ograniczenie zakresu tokenu dostępu, usługa Azure Pipelines może teraz ograniczyć zakres dostępu do repozytoriów wymaganych do potoku opartego na języku YAML. Oznacza to, że jeśli token dostępu potoków miał wyciekć, będzie on mógł zobaczyć tylko repozytoria używane w potoku. Wcześniej token dostępu był dobry dla każdego repozytorium Azure Repos w projekcie lub potencjalnie całej kolekcji.

  Ta funkcja będzie domyślnie włączona dla nowych projektów i kolekcji. W przypadku istniejących kolekcji należy ją włączyć wobszarze Ustawienia>potoków ustawień kolekcji>. W przypadku korzystania z tej funkcji wszystkie repozytoria wymagane przez kompilację (nawet klonowane przy użyciu skryptu) muszą być uwzględnione w zasobach repozytorium potoku.

• Usuwanie niektórych uprawnień dla tokenu dostępu

  Domyślnie udzielamy wielu uprawnień do tokenu dostępu. Jednym z tych uprawnień jest kompilacja kolejki. Dzięki tej aktualizacji usunęliśmy to uprawnienie do tokenu dostępu. Jeśli potoki potrzebują tego uprawnienia, możesz jawnie udzielić go na konto usługi kompilacji projektu lub konto usługi kompilacji kolekcji projektów w zależności od używanego tokenu.

Zabezpieczenia na poziomie projektu dla połączeń usług

Dodaliśmy zabezpieczenia na poziomie centrum dla połączeń usług. Teraz możesz dodawać/usuwać użytkowników, przypisywać role i zarządzać dostępem w scentralizowanym miejscu dla wszystkich połączeń usługi.

Określanie celu krokowego i izolacja poleceń

Usługa Azure Pipelines obsługuje uruchamianie zadań w kontenerach lub na hoście agenta. Wcześniej całe zadanie zostało ustawione na jeden z tych dwóch celów. Teraz poszczególne kroki (zadania lub skrypty) mogą być uruchamiane w wybranym obiekcie docelowym. Kroki mogą również dotyczyć innych kontenerów, więc potok może uruchamiać każdy krok w wyspecjalizowanym, utworzonym przez przeznaczenie kontenerze.

Kontenery mogą działać jako granice izolacji, uniemożliwiając kodowi wprowadzanie nieoczekiwanych zmian na maszynie hosta. Sposób komunikowania się z usługami i uzyskiwania do niego dostępu z agenta nie ma wpływu na kroki izolacji w kontenerze. W związku z tym wprowadzamy również tryb ograniczeń poleceń, którego można użyć z elementami docelowymi kroków. Włączenie tej opcji spowoduje ograniczenie usług, których krok może zażądać od agenta. Nie będzie już można dołączać dzienników, przekazywać artefaktów i niektórych innych operacji.

Oto kompleksowy przykład przedstawiający uruchamianie kroków na hoście w kontenerze zadań i w innym kontenerze:

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

Zmienne tylko do odczytu

Zmienne systemowe zostały udokumentowane jako niezmienne, ale w praktyce mogą zostać zastąpione przez zadanie, a podrzędne zadania będą pobierać nową wartość. Dzięki tej aktualizacji zaostrzymy zabezpieczenia wokół zmiennych potoku, aby zmienne systemowe i zmienne czasu kolejki tylko do odczytu. Ponadto można utworzyć zmienną YAML tylko do odczytu, zaznaczając ją w następujący sposób.

variables:
- name: myVar
  value: myValue
  readonly: true

Dostęp oparty na rolach dla połączeń usług

Dodaliśmy dostęp oparty na rolach dla połączeń usług. Wcześniej zabezpieczenia połączenia z usługą mogły być zarządzane tylko za pośrednictwem wstępnie zdefiniowanych grup usługi Azure DevOps, takich jak administratorzy punktu końcowego i twórcy punktu końcowego.

W ramach tej pracy wprowadziliśmy nowe role Czytelnik, Użytkownik, Twórca i Administrator. Te role można ustawić za pośrednictwem strony połączeń usług w projekcie i są dziedziczone przez poszczególne połączenia. W każdym połączeniu z usługą można włączyć lub wyłączyć dziedziczenie i zastąpić role w zakresie połączenia z usługą.

Dowiedz się więcej o zabezpieczeniach połączeń usług tutaj.

Współużytkowanie połączeń usług między projektami

Włączyliśmy obsługę udostępniania połączeń z usługą w różnych projektach. Teraz możesz bezpiecznie i bezpiecznie udostępniać swoje połączenia z usługami.

Dowiedz się więcej o udostępnianiu połączeń usług tutaj.

Śledzenie potoków i zasobów usługi ACR

Zapewniamy pełną możliwość śledzenia E2E, gdy potoki i zasoby kontenera usługi ACR są używane w potoku. Dla każdego zasobu używanego przez potok YAML można śledzić z powrotem do zatwierdzeń, elementów roboczych i artefaktów.

W widoku podsumowania przebiegu potoku można zobaczyć:

• Wersja zasobu, która wyzwoliła przebieg. Teraz potok można wyzwolić po zakończeniu innego uruchomienia potoku platformy Azure lub wypchnięciu obrazu kontenera do usługi ACR.

  

• Zatwierdzenia, które są używane przez potok. Możesz również znaleźć podział zatwierdzeń przez każdy zasób używany przez potok.

  

• Elementy robocze skojarzone z każdym zasobem używanym przez potok.

• Artefakty, które są dostępne do użycia przez przebieg.

  

W widoku wdrożeń środowiska można zobaczyć zatwierdzenia i elementy robocze dla każdego zasobu wdrożonego w środowisku.

Obsługa dużych załączników testowych

Zadanie publikowania wyników testów w usłudze Azure Pipelines umożliwia publikowanie wyników testów po wykonaniu testów w celu zapewnienia kompleksowego środowiska raportowania testów i analizy. Do tej pory istniał limit 100 MB dla załączników testowych zarówno dla wyników testu, jak i testów. Ogranicza to przekazywanie dużych plików, takich jak zrzuty awaryjne lub filmy wideo. Dzięki tej aktualizacji dodaliśmy obsługę dużych załączników testowych, co pozwala na uzyskanie wszystkich dostępnych danych w celu rozwiązywania problemów z testami, które zakończyły się niepowodzeniem.

W dziennikach może zostać wyświetlone zadanie VSTest lub Zadanie publikowania wyników testu zwracające błąd 403 lub 407. Jeśli używasz własnych kompilacji lub agentów wydania za zaporą, która filtruje żądania wychodzące, musisz wprowadzić pewne zmiany konfiguracji, aby móc korzystać z tej funkcji. ​

Aby rozwiązać ten problem, zalecamy zaktualizowanie zapory dla żądań wychodzących do https://*.vstmrblob.vsassets.iousługi . Informacje dotyczące rozwiązywania problemów można znaleźć w dokumentacji tutaj. ​

Uwaga

Jest to wymagane tylko wtedy, gdy używasz własnych agentów usługi Azure Pipelines i znajdujesz się za zaporą, która filtruje ruch wychodzący. Jeśli używasz agentów hostowanych przez firmę Microsoft w chmurze lub nie filtrujesz ruchu sieciowego wychodzącego, nie musisz podejmować żadnych działań.

Pokaż poprawne informacje o puli dla każdego zadania

Wcześniej, gdy macierz została użyta do rozwinięcia zadań lub zmiennej w celu zidentyfikowania puli, czasami rozwiązaliśmy nieprawidłowe informacje o puli na stronach dzienników. Te problemy zostały rozwiązane.

Wyzwalacze ciągłej integracji dla nowych gałęzi

Od dawna oczekujące żądanie nie wyzwala kompilacji ciągłej integracji po utworzeniu nowej gałęzi i gdy ta gałąź nie ma zmian. Rozważmy następujące przykłady:

• Interfejs internetowy służy do tworzenia nowej gałęzi na podstawie istniejącej gałęzi. Spowoduje to natychmiastowe wyzwolenie nowej kompilacji ciągłej integracji, jeśli filtr gałęzi jest zgodny z nazwą nowej gałęzi. Jest to niepożądane, ponieważ zawartość nowej gałęzi jest taka sama w porównaniu z istniejącą gałęzią.
• Masz repozytorium z dwoma folderami — aplikacją i dokumentami. Skonfigurowaliśmy filtr ścieżki dla ciągłej integracji, aby pasować do "aplikacji". Innymi słowy, nie chcesz tworzyć nowej kompilacji, jeśli zmiana została wypchnięta do dokumentów. Tworzysz nową gałąź lokalnie, wprowadzasz pewne zmiany w dokumentach, a następnie wypychasz gałąź do serwera. Kiedyś wyzwalaliśmy nową kompilację ciągłej integracji. Jest to niepożądane, ponieważ jawnie poproszono o nie wyszukiwanie zmian w folderze dokumentów. Jednak ze względu na sposób obsługi nowego zdarzenia gałęzi wydaje się, że zmiana została również wprowadzona do folderu aplikacji.

Teraz mamy lepszy sposób obsługi ciągłej integracji dla nowych gałęzi, aby rozwiązać te problemy. Podczas publikowania nowej gałęzi jawnie szukamy nowych zatwierdzeń w tej gałęzi i sprawdzamy, czy są one zgodne z filtrami ścieżek.

Zadania mogą uzyskiwać dostęp do zmiennych wyjściowych z poprzednich etapów

Zmienne wyjściowe mogą być teraz używane między etapami w potoku opartym na języku YAML. Pomaga to przekazać przydatne informacje, takie jak decyzja go/no-go lub identyfikator wygenerowanego danych wyjściowych, od jednego etapu do następnego. Wynik (stan) poprzedniego etapu i jego zadania są również dostępne.

Zmienne wyjściowe są nadal tworzone przez kroki wewnątrz zadań. Zamiast odwoływać się do dependencies.jobName.outputs['stepName.variableName'], etapy odwołują się do stageDependencies.stageName.jobName.outputs['stepName.variableName']elementu .

Uwaga

Domyślnie każdy etap w potoku zależy od tego, który jest tuż przed nim w pliku YAML. W związku z tym każdy etap może używać zmiennych wyjściowych z poprzedniego etapu. Możesz zmienić wykres zależności, który również zmieni dostępne zmienne wyjściowe. Jeśli na przykład etap 3 wymaga zmiennej z etapu 1, należy zadeklarować jawną zależność od etapu 1.

Wyłączanie uaktualnień automatycznych agentów na poziomie puli

Obecnie agenci potoków będą automatycznie aktualizować do najnowszej wersji, jeśli jest to wymagane. Zwykle dzieje się tak, gdy jest dostępna nowa funkcja lub zadanie, które wymaga poprawnego działania nowszej wersji agenta. Dzięki tej aktualizacji dodajemy możliwość wyłączania automatycznych uaktualnień na poziomie puli. W tym trybie, jeśli żaden agent poprawnej wersji nie jest połączony z pulą, potoki nie będą działać z wyraźnym komunikatem o błędzie zamiast żądać aktualizacji agentów. Ta funkcja jest przede wszystkim interesująca dla klientów korzystających z pul hostowanych samodzielnie i bardzo rygorystycznych wymagań dotyczących kontroli zmian. Aktualizacje automatyczne są domyślnie włączone i nie zalecamy, aby większość klientów je wyłączyła.

Diagnostyka agenta

Dodaliśmy diagnostykę wielu typowych problemów związanych z agentem, takich jak wiele problemów z siecią i typowe przyczyny błędów uaktualniania. Aby rozpocząć pracę z diagnostyką, użyj run.sh --diagnostics lub run.cmd --diagnostics w systemie Windows.

Punkty zaczepienia usługi dla potoków YAML

Integrowanie usług z potokami YAML po prostu stało się łatwiejsze. Za pomocą zdarzeń punktów zaczepienia usługi dla potoków YAML można teraz napędzać działania w niestandardowych aplikacjach lub usługach na podstawie postępu przebiegów potoku. Możesz na przykład utworzyć bilet pomocy technicznej, gdy jest wymagane zatwierdzenie, zainicjować przepływ pracy monitorowania po zakończeniu etapu lub wysłać powiadomienie wypychane na urządzenia przenośne zespołu, gdy etap zakończy się niepowodzeniem.

Filtrowanie nazwy potoku i nazwy etapu jest obsługiwane dla wszystkich zdarzeń. Zdarzenia zatwierdzania można również filtrować dla określonych środowisk. Podobnie zdarzenia zmiany stanu można filtrować według nowego stanu uruchomienia potoku lub etapu.

Optymalizacja integracji

Optymalizowanie to zaawansowana platforma testowania A/B i flagowania funkcji dla zespołów produktów. Integracja usługi Azure Pipelines z platformą optymalizowania eksperymentów umożliwia zespołom produktów testowanie, uczenie się i wdrażanie w przyspieszonym tempie, a jednocześnie uzyskiwanie wszystkich korzyści usługi DevOps z usługi Azure Pipelines.

Rozszerzenie Optimizely dla usługi Azure DevOps dodaje kroki wdrażania eksperymentów i flag funkcji do potoków kompilacji i wydania, dzięki czemu można stale iterować, wdrażać funkcje i przywracać je przy użyciu usługi Azure Pipelines.

Dowiedz się więcej o rozszerzeniu Azure DevOps Optimizely tutaj.

Dodawanie wydania usługi GitHub jako źródła artefaktu

Teraz możesz połączyć wersje usługi GitHub jako źródło artefaktu w potokach wydań usługi Azure DevOps. Umożliwi to korzystanie z wersji usługi GitHub w ramach wdrożeń.

Po kliknięciu przycisku Dodaj artefakt w definicji potoku wydania znajdziesz nowy typ źródła wydania usługi GitHub . Możesz udostępnić połączenie z usługą i repozytorium GitHub, aby korzystać z wersji usługi GitHub. Możesz również wybrać domyślną wersję wersji usługi GitHub do użycia jako najnowszą, konkretną wersję tagu lub wybrać w czasie tworzenia wydania. Po połączeniu wersji usługi GitHub zostanie ona automatycznie pobrana i udostępniona w zadaniach wydania.

Integracja narzędzia Terraform z usługą Azure Pipelines

Terraform to narzędzie typu open source do opracowywania, zmieniania i przechowywania wersji infrastruktury bezpiecznie i wydajnie. Narzędzie Terraform koduje interfejsy API do deklaratywnych plików konfiguracji, co umożliwia definiowanie i aprowizowanie infrastruktury przy użyciu języka konfiguracji wysokiego poziomu. Za pomocą rozszerzenia Terraform można tworzyć zasoby dla wszystkich głównych dostawców infrastruktury: Azure, Amazon Web Services (AWS) i Google Cloud Platform (GCP).

Aby dowiedzieć się więcej na temat rozszerzenia Terraform, zapoznaj się z dokumentacją tutaj.

Integracja z usługą Google Analytics

Struktura eksperymentów usługi Google Analytics pozwala przetestować niemal dowolną zmianę lub odmianę witryny internetowej lub aplikacji, aby zmierzyć jej wpływ na konkretny cel. Na przykład możesz mieć działania, które mają zostać ukończone przez użytkowników (np. dokonać zakupu, zarejestrować się w biuletynie) i/lub metryki, które chcesz poprawić (np. przychód, czas trwania sesji, wskaźnik odbijania). Te działania umożliwiają zidentyfikowanie zmian, które warto wdrożyć w oparciu o bezpośredni wpływ na wydajność funkcji.

Rozszerzenie eksperymentów usługi Google Analytics dla usługi Azure DevOps dodaje kroki eksperymentowania do potoków kompilacji i wydania, dzięki czemu można stale iterować, uczyć się i wdrażać w przyspieszonym tempie, zarządzając eksperymentami w sposób ciągły przy jednoczesnym uzyskaniu wszystkich korzyści z usługi Azure Pipelines.

Rozszerzenie eksperymentów usługi Google Analytics można pobrać z witryny Marketplace.

Zaktualizowano integrację usługi ServiceNow z usługą Azure Pipelines

Aplikacja Azure Pipelines dla usługi ServiceNow pomaga zintegrować usługi Azure Pipelines i ServiceNow Change Management. Dzięki tej aktualizacji możesz zintegrować się z wersją usługi ServiceNow w Nowym Jorku. Uwierzytelnianie między dwiema usługami można teraz przeprowadzić przy użyciu uwierzytelniania OAuth i uwierzytelniania podstawowego. Ponadto można teraz skonfigurować zaawansowane kryteria powodzenia, aby można było użyć dowolnej właściwości zmiany w celu określenia wyniku bramy.

Twórca usługi Azure Pipelines z programu VSCode

Dodaliśmy nową funkcję do rozszerzenia usługi Azure Pipelines dla programu VSCode. Teraz będzie można utworzyć usługę Azure Pipelines bezpośrednio z poziomu programu VSCode bez opuszczania środowiska IDE.

Flaky bug management and resolution (Zarządzanie usterami i rozwiązywanie problemów)

Wprowadziliśmy niestabilne zarządzanie testami w celu obsługi kompleksowego cyklu życia dzięki wykrywaniu, raportowaniu i rozwiązywaniu problemów. Aby ulepszyć go dalej, dodajemy niestabilne zarządzanie usterek testowych i ich rozwiązywanie.

Podczas badania niestabilnego testu możesz utworzyć usterkę przy użyciu akcji Usterka , którą następnie można przypisać deweloperowi, aby dokładniej zbadać główną przyczynę niestabilnego testu. Raport o błędach zawiera informacje o potoku, takie jak komunikat o błędzie, ślad stosu i inne informacje skojarzone z testem.

Po rozwiązaniu lub zamknięciu raportu o usterce automatycznie anulujemy oznaczenie testu jako nieoczyszkowanego.

Ustaw zadania VSTest na niepowodzenie, jeśli minimalna liczba testów nie zostanie uruchomiona

Zadanie VSTest odnajduje i uruchamia testy przy użyciu danych wejściowych użytkownika (plików testowych, kryteriów filtrowania itd.), a także adaptera testowego specyficznego dla używanej platformy testowej. Zmiany danych wejściowych użytkownika lub adaptera testowego mogą prowadzić do przypadków, w których testy nie są odnajdywane i są uruchamiane tylko podzbiór oczekiwanych testów. Może to prowadzić do sytuacji, w których potoki kończą się powodzeniem, ponieważ testy są pomijane, a nie dlatego, że kod jest wystarczająco wysokiej jakości. Aby uniknąć tej sytuacji, dodaliśmy nową opcję w zadaniu VSTest, która umożliwia określenie minimalnej liczby testów, które muszą zostać uruchomione, aby zadanie zostało zakończone pomyślnie.

Opcja VSTest TestResultsDirectory jest dostępna w interfejsie użytkownika zadania

Zadanie VSTest przechowuje wyniki testów i skojarzone pliki w folderze $(Agent.TempDirectory)\TestResults . Dodaliśmy opcję do interfejsu użytkownika zadania, aby umożliwić skonfigurowanie innego folderu do przechowywania wyników testów. Teraz wszystkie kolejne zadania, które wymagają plików w określonej lokalizacji, mogą ich używać.

Obsługa języka Markdown w komunikatach o błędach testów automatycznych

Dodaliśmy obsługę języka Markdown do komunikatów o błędach w przypadku testów automatycznych. Teraz możesz łatwo sformatować komunikaty o błędach zarówno dla przebiegu testu, jak i wyniku testu, aby zwiększyć czytelność i ułatwić rozwiązywanie problemów z niepowodzeniem testu w usłudze Azure Pipelines. Obsługiwaną składnię języka Markdown można znaleźć tutaj.

Używanie dekoratorów potoków do automatycznego wstrzykiwania kroków w zadaniu wdrożenia

Teraz można dodawać dekoratory potoków do zadań wdrażania. Każdy krok niestandardowy (np. skaner luk w zabezpieczeniach) może być automatycznie wstrzykiwany do każdego wykonania każdego zadania wdrożenia w ramach cyklu życia . Ponieważ dekoratory potoków można stosować do wszystkich potoków w kolekcji, można je wykorzystać w ramach wymuszania bezpiecznych praktyk wdrażania.

Ponadto zadania wdrażania można uruchamiać jako zadanie kontenera wraz z samochodem bocznym usług , jeśli zostały zdefiniowane.

Test Plans

Strona Nowy plan testu

Nowa strona Test Plans (Test Plans *) jest dostępna dla wszystkich kolekcji usługi Azure DevOps. Nowa strona zawiera usprawnione widoki, które ułatwiają skoncentrowanie się na zadaniu — planowanie testów, tworzenie lub wykonywanie. Jest ona również bezpłatna i spójna z resztą oferty usługi Azure DevOps.

Pomóż mi zrozumieć nową stronę

Nowa strona Test Plans zawiera łącznie 6 sekcji, z których pierwsze 4 są nowe, a sekcje Wykresy & rozszerzalności są istniejącymi funkcjami.

1. Nagłówek planu testów: służy do lokalizowania, ulubionych, edytowania, kopiowania lub klonowania planu testu.
2. Drzewo zestawów testów: służy do dodawania zestawów testów, zarządzania nimi, eksportowania lub zamawiania. Skorzystaj z tej funkcji, aby przypisać konfiguracje i przeprowadzić testowanie akceptacyjne użytkowników.
3. Definiowanie karty: Sortowanie, dodawanie przypadków testowych i zarządzanie nimi w wybranym zestawie testów za pomocą tej karty.
4. Karta Wykonywanie: przypisz i wykonaj testy za pomocą tej karty lub znajdź wynik testu, aby przejść do szczegółów.
5. Karta wykresu: Śledzenie wykonywania testów i stanu za pomocą wykresów, które można również przypiąć do pulpitów nawigacyjnych.
6. Rozszerzalność: obsługuje bieżące punkty rozszerzalności w produkcie.

Przyjrzyjmy się szerokiej grupie pociągnięć z poniższych nowych sekcji.

1. Nagłówek planu testu

Zadania

Nagłówek Plan testu umożliwia wykonywanie następujących zadań:

• Oznaczanie planu testowego jako ulubionego
• Anulowanie oznaczenia ulubionego planu testu
• Łatwe nawigowanie po ulubionych planach testów
• Wyświetl ścieżkę iteracji planu testów, która wyraźnie wskazuje, czy plan testu ma wartość Bieżąca lub Przeszłości
• Wyświetlanie szybkiego podsumowania raportu postępu testu z linkiem umożliwiającym przejście do raportu
• Przejdź z powrotem do strony Wszystkie/Moje Test Plans

Opcje menu kontekstowego

Menu kontekstowe w nagłówku Plan testu udostępnia następujące opcje:

• Kopiuj plan testu: jest to nowa opcja, która umożliwia szybkie skopiowanie bieżącego planu testu. Szczegółowe informacje można znaleźć poniżej.
• Edytuj plan testu: ta opcja umożliwia edytowanie formularza elementu roboczego Plan testu w celu zarządzania polami elementu roboczego.
• Ustawienia planu testów: Ta opcja umożliwia skonfigurowanie ustawień przebiegu testu (w celu skojarzenia potoków kompilacji lub wydania) i ustawień wyniku testu

Kopiuj plan testu (nowa możliwość)

Zalecamy utworzenie nowego planu testów na przebieg/wydanie. W tym celu ogólnie plan testu dla poprzedniego cyklu można skopiować i z kilkoma zmianami skopiowany plan testu jest gotowy do nowego cyklu. Aby ten proces był łatwy, włączyliśmy funkcję "Kopiuj plan testu" na nowej stronie. Korzystając z niego, można kopiować lub klonować plany testów. Interfejs API REST jest tu omówiony, a interfejs API umożliwia również kopiowanie/klonowanie planu testów między projektami.
Aby uzyskać więcej wskazówek dotyczących Test Plans użycia, zobacz tutaj.

2. Drzewo zestawów testów

Zadania

Nagłówek Zestawu testów umożliwia wykonywanie następujących zadań:

• Rozwiń/zwiń: te opcje paska narzędzi umożliwiają rozwijanie lub zwijanie drzewa hierarchii pakietu.
• Pokaż punkty testowe z zestawów podrzędnych: ta opcja paska narzędzi jest widoczna tylko wtedy, gdy jesteś na karcie "Wykonaj". Dzięki temu można wyświetlić wszystkie punkty testowe dla danego zestawu i jego elementów podrzędnych w jednym widoku, aby ułatwić zarządzanie punktami testowymi bez konieczności przechodzenia do poszczególnych zestawów pojedynczo.
• Zestawy zamówień: można przeciągać/upuszczać zestawy, aby zmienić kolejność hierarchii zestawów lub przenieść je z jednej hierarchii pakietów do innej w ramach planu testu.

Opcje menu kontekstowego

Menu kontekstowe w drzewie Zestawy testów udostępnia następujące opcje:

• Twórca nowych zestawów: możesz utworzyć 3 różne typy zestawów w następujący sposób:
  • Organizowanie testów przy użyciu pakietu statycznego lub pakietu folderów.
  • Użyj pakietu opartego na wymaganiach, aby bezpośrednio połączyć się z wymaganiami/scenariuszami użytkownika w celu zapewnienia bezproblemowej możliwości śledzenia.
  • Użyj opartego na zapytaniach, aby dynamicznie organizować przypadki testowe spełniające kryteria zapytania.
• Przypisywanie konfiguracji: konfiguracje pakietu można przypisać (na przykład: Chrome, Firefox, EdgeChromium), a następnie mieć zastosowanie do wszystkich istniejących przypadków testowych lub nowych przypadków testowych, które zostaną dodane później do tego pakietu.
• Eksportuj jako plik PDF/wiadomość e-mail: wyeksportuj właściwości planu testów, właściwości zestawu testów wraz ze szczegółami przypadków testowych i punktów testowych jako "wiadomość e-mail" lub "drukuj do formatu PDF".
• Otwórz element roboczy zestawu testów: ta opcja umożliwia edytowanie formularza elementu roboczego zestawu testów w celu zarządzania polami elementu roboczego.
• Przypisz testerów do uruchamiania wszystkich testów: ta opcja jest bardzo przydatna w scenariuszach testowania akceptacyjnego (UAT), w których ten sam test musi być uruchamiany/wykonywany przez wielu testerów, zazwyczaj należących do różnych działów.
• Zmień nazwę/usuń: te opcje umożliwiają zarządzanie nazwą pakietu lub usuwanie pakietu i jego zawartości z planu testu.

3. Definiowanie karty

Karta Definiowanie umożliwia sortowanie, dodawanie przypadków testowych i zarządzanie nimi dla zestawu testów. Podczas gdy karta wykonywania służy do przypisywania punktów testowych i wykonywania ich.

Karta Definiowanie i niektóre operacje są dostępne tylko dla użytkowników z poziomem dostępu Podstawowe i Test Plans lub równoważne. Wszystko inne powinno być możliwe dla użytkownika z poziomem dostępu "Podstawowy".

Zadania

Karta Definiowanie umożliwia wykonywanie następujących zadań:

• Dodaj nowy przypadek testowy przy użyciu formularza elementu roboczego: ta opcja umożliwia utworzenie nowego przypadku testowego przy użyciu formularza elementu roboczego. Utworzony przypadek testowy zostanie automatycznie dodany do pakietu.
• Dodaj nowy przypadek testowy przy użyciu siatki: ta opcja umożliwia utworzenie co najmniej jednego przypadku testowego przy użyciu widoku siatki przypadków testowych. Utworzone przypadki testowe zostaną automatycznie dodane do zestawu.
• Dodaj istniejące przypadki testowe przy użyciu zapytania: ta opcja umożliwia dodawanie istniejących przypadków testowych do pakietu przez określenie zapytania.
• Porządkowanie przypadków testowych przez przeciąganie/upuszczanie: możesz zmienić kolejność przypadków testowych, przeciągając/upuszczając co najmniej jeden przypadek testowy w danym zestawie. Kolejność przypadków testowych ma zastosowanie tylko do przypadków testowych ręcznych, a nie do testów automatycznych.
• Przenoszenie przypadków testowych z jednego zestawu do drugiego: za pomocą przeciągania/upuszczania można przenosić przypadki testowe z jednego zestawu testów do innego.
• Pokaż siatkę: możesz użyć trybu siatki do wyświetlania/edytowania przypadków testowych wraz z krokami testu.
• Widok pełnoekranowy: zawartość całej karty Definiuj można wyświetlić w trybie pełnoekranowym przy użyciu tej opcji.
• Filtrowanie: przy użyciu paska filtru można filtrować listę przypadków testowych przy użyciu pól "tytuł przypadku testowego", "przypisany do" i "state". Możesz również posortować listę, klikając nagłówki kolumn.
• Opcje kolumn: możesz zarządzać listą kolumn widocznych na karcie Zdefiniuj przy użyciu opcji kolumny. Lista kolumn dostępnych do wyboru to przede wszystkim pola z formularza elementu roboczego przypadku testowego.

Opcje menu kontekstowego

Menu kontekstowe w węźle Przypadek testowy na karcie Zdefiniuj udostępnia następujące opcje:

• Otwórz/edytuj formularz elementu roboczego przypadku testowego: ta opcja umożliwia edytowanie przypadku testowego przy użyciu formularza elementu roboczego, w którym można edytować pola elementu roboczego, w tym kroki testowe.
• Edytuj przypadki testowe: ta opcja umożliwia zbiorcze edytowanie pól elementu roboczego przypadku testowego. Nie można jednak użyć tej opcji do zbiorczego edytowania kroków testu.
• Edytuj przypadki testowe w siatce: ta opcja umożliwia zbiorcze edytowanie wybranych przypadków testowych, w tym kroków testowych przy użyciu widoku siatki.
• Przypisz konfiguracje: ta opcja umożliwia zastąpienie konfiguracji na poziomie pakietu przy użyciu konfiguracji na poziomie przypadku testowego.
• Usuń przypadki testowe: ta opcja umożliwia usunięcie przypadków testowych z danego zestawu. Nie zmienia jednak bazowego elementu roboczego przypadku testowego.
• Twórca kopii/klonowania przypadków testowych: ta opcja umożliwia utworzenie kopii/klonowania wybranych przypadków testowych. Aby uzyskać więcej informacji, zobacz poniżej.
• Wyświetl połączone elementy: ta opcja umożliwia przeglądanie połączonych elementów dla danego przypadku testowego. Aby uzyskać więcej informacji, zobacz poniżej.

Przypadki testowe kopiowania/klonowania (nowa możliwość)

W scenariuszach, w których chcesz skopiować/sklonować przypadek testowy, możesz użyć opcji "Kopiuj przypadek testowy". Można określić projekt docelowy, docelowy plan testu i docelowy zestaw testów, w którym ma zostać utworzony przypadek testowy kopiowania/klonowania. Ponadto można również określić, czy chcesz dołączyć istniejące linki/załączniki do przepływu do sklonowanej kopii.

Wyświetlanie połączonych elementów (nowa funkcja)

Możliwość śledzenia między artefaktami testowymi, wymaganiami i usterkami jest krytyczną propozycją produktu Test Plans. Korzystając z opcji "Wyświetl połączone elementy", można łatwo sprawdzić wszystkie połączone wymagania, z którymi jest połączony ten przypadek testowy, wszystkie zestawy testów/plany testów, w których użyto tego przypadku testowego i wszystkie usterki, które zostały złożone w ramach wykonywania testu.

4. Karta Wykonywanie

Karta Definiowanie umożliwia sortowanie, dodawanie przypadków testowych i zarządzanie nimi dla zestawu testów. Podczas gdy karta wykonywania służy do przypisywania punktów testowych i wykonywania ich.

Co to jest punkt testowy? Przypadki testowe same w sobie nie są wykonywalne. Po dodaniu przypadku testowego do zestawu testów są generowane punkty testowe. Punkt testu to unikatowa kombinacja przypadku testowego, zestawu testów, konfiguracji i testera. Przykład: jeśli masz przypadek testowy jako "Funkcje logowania testowego" i dodasz do niego 2 konfiguracje jako przeglądarkę Microsoft Edge i Chrome, spowoduje to wyświetlenie 2 punktów testowych. Teraz można wykonać te punkty testowe. Podczas wykonywania generowane są wyniki testów. Za pomocą widoku wyników testu (historii wykonywania) można wyświetlić wszystkie wykonania punktu testowego. Najnowsze wykonanie punktu testowego jest widoczne na karcie wykonywania.
W związku z tym przypadki testowe są jednostkami wielokrotnego użytku. Po uwzględnieniu ich w planie testu lub zestawie generowane są punkty testowe. Wykonując punkty testowe, określasz jakość opracowywanego produktu lub usługi.

Jedną z podstawowych zalet nowej strony jest to, że użytkownicy, którzy głównie wykonują testy wykonywania/śledzenia (muszą mieć tylko poziom dostępu "Podstawowy"), nie są przeciążeni złożonością zarządzania pakietem (karta definiowania jest ukryta dla takich użytkowników).

Karta Definiowanie i niektóre operacje są dostępne tylko dla użytkowników z poziomem dostępu Podstawowe i Test Plans lub równoważne. Wszystkie inne elementy, w tym karta "Wykonaj" powinny być wykonywane przez użytkownika z poziomem dostępu "Podstawowy".

Zadania

Karta Wykonywanie umożliwia wykonywanie następujących zadań:

• Zbiorcze oznaczanie punktów testowych: ta opcja umożliwia szybkie oznaczenie wyniku punktów testowych — powodzenia, niepowodzenia, zablokowania lub braku zastosowania bez konieczności uruchamiania przypadku testowego za pośrednictwem modułu uruchamiającego testy. Wynik można oznaczyć dla jednego lub wielu punktów testowych w jednym miejscu.
• Uruchamianie punktów testowych: ta opcja umożliwia uruchamianie przypadków testowych przez indywidualne przechodzenie przez każdy krok testu i oznaczanie ich powodzeniem/niepowodzeniem przy użyciu modułu uruchamiającego testy. W zależności od testowej aplikacji można użyć "Moduł uruchamiający w sieci Web" do testowania "aplikacji internetowej" lub "modułu uruchamiającego aplikacje klasyczne" na potrzeby testowania aplikacji klasycznych i/lub internetowych. Można również wywołać polecenie "Uruchom z opcjami", aby określić kompilację, dla której chcesz wykonać testy.
• Opcje kolumn: możesz zarządzać listą kolumn widocznych na karcie Wykonywanie przy użyciu opcji kolumny. Lista kolumn dostępnych do wyboru jest skojarzona z punktami testowymi, takimi jak Run by, Assigned Tester, Configuration itp.
• Widok pełnoekranowy: zawartość całej karty Wykonywanie można wyświetlić w trybie pełnoekranowym przy użyciu tej opcji.
• Filtrowanie: przy użyciu paska filtru można filtrować listę punktów testowych przy użyciu pól "tytuł przypadku testowego", "przypisany do", "stan", "wynik testu", "Tester" i "Konfiguracja". Możesz również posortować listę, klikając nagłówki kolumn.

Opcje menu kontekstowego

Menu kontekstowe w węźle Punkt testowy na karcie Wykonywanie udostępnia następujące opcje:

• Oznacz wynik testu: taki sam jak powyżej, umożliwia szybkie oznaczenie wyniku punktów testowych — powodzenie, niepowodzenie, zablokowanie lub nie dotyczy.
• Uruchamianie punktów testowych: tak samo jak powyżej umożliwia uruchamianie przypadków testowych za pośrednictwem modułu uruchamiającego testy.
• Resetuj test do aktywnego: ta opcja umożliwia zresetowanie wyniku testu do aktywnego, ignorując ostatni wynik punktu testowego.
• Otwórz/edytuj formularz elementu roboczego przypadku testowego: ta opcja umożliwia edytowanie przypadku testowego przy użyciu formularza elementu roboczego, w którym można edytować pola elementu roboczego, w tym kroki testowe.
• Przypisz testera: ta opcja umożliwia przypisanie punktów testowych do testerów na potrzeby wykonywania testów.
• Wyświetl wynik testu: ta opcja umożliwia wyświetlenie najnowszych szczegółów wyniku testu, w tym wyniku każdego kroku testu, komentarzy dodanych lub złożonych usterek.
• Wyświetl historię wykonywania: ta opcja umożliwia wyświetlenie całej historii wykonywania dla wybranego punktu testowego. Zostanie otwarta nowa strona, na której można dostosować filtry, aby wyświetlić historię wykonywania nie tylko wybranego punktu testowego, ale także dla całego przypadku testowego.

raport o postępie Test Plans

Ten wbudowany raport ułatwia śledzenie wykonywania i stanu co najmniej jednego Test Plans w projekcie. Odwiedź stronę Test Plans > Raport o postępie*, aby rozpocząć korzystanie z raportu.

Trzy sekcje raportu obejmują następujące elementy:

1. Podsumowanie: przedstawia skonsolidowany widok dla wybranych planów testów.
2. Trend wyniku: renderuje codzienną migawkę, aby zapewnić wykonywanie i linię trendu stanu. Dane mogą być wyświetlane przez 14 dni (ustawienie domyślne), 30 dni lub zakres niestandardowy.
3. Szczegóły: ta sekcja umożliwia przechodzenie do szczegółów poszczególnych planów testów i zapewnia ważne analizy dla każdego zestawu testów.

Artifacts

Uwaga

Azure DevOps Server 2020 nie importuje źródeł danych, które znajdują się w Koszu podczas importowania danych. Jeśli chcesz zaimportować źródła danych, które znajdują się w koszu, przywróć je z kosza przed rozpoczęciem importowania danych.

Wyrażenia licencji i licencje osadzone

Teraz możesz zobaczyć szczegóły informacji o licencji pakietów NuGet przechowywanych w usłudze Azure Artifacts podczas przeglądania pakietów w programie Visual Studio. Dotyczy to licencji reprezentowanych przy użyciu wyrażeń licencji lub osadzonych licencji. Teraz możesz wyświetlić link do informacji o licencji na stronie szczegółów pakietu programu Visual Studio (czerwona strzałka na poniższej ilustracji).

Kliknięcie linku spowoduje przejście do strony internetowej, na której można wyświetlić szczegóły licencji. To środowisko jest takie samo w przypadku wyrażeń licencji i licencji osadzonych, więc można wyświetlić szczegóły licencji dla pakietów przechowywanych w usłudze Azure Artifacts w jednym miejscu (w przypadku pakietów, które określają informacje o licencji i są obsługiwane przez program Visual Studio).

Uproszczone zadania uwierzytelniania

Teraz można uwierzytelniać się za pomocą popularnych menedżerów pakietów z usługi Azure Pipelines przy użyciu lekkich zadań uwierzytelniania. Obejmuje to narzędzia NuGet, npm, PIP, Twine i Maven. Wcześniej można było uwierzytelniać się za pomocą tych menedżerów pakietów przy użyciu zadań, które udostępniały dużą ilość funkcji, w tym możliwość publikowania i pobierania pakietów. Jest to jednak wymagane przy użyciu tych zadań dla wszystkich działań, które współdziałały z menedżerami pakietów. Jeśli masz własne skrypty do uruchamiania na potrzeby wykonywania zadań, takich jak publikowanie lub pobieranie pakietów, nie będzie można ich używać w potoku. Teraz możesz użyć skryptów własnego projektu w potoku YAML i przeprowadzić uwierzytelnianie przy użyciu tych nowych lekkich zadań. Przykład użycia narzędzia npm:

Użycie polecenia "ci" i "publish" na tej ilustracji jest dowolne. Można użyć dowolnych poleceń obsługiwanych przez usługę Azure Pipelines YAML. Dzięki temu można mieć pełną kontrolę nad wywołaniem polecenia i ułatwia korzystanie z udostępnionych skryptów w konfiguracji potoku. Aby uzyskać więcej informacji, zobacz dokumentację zadań uwierzytelniania nuGet, npm, PIP, Twine i Maven .

Ulepszenia czasu ładowania strony kanału informacyjnego

Z przyjemnością ogłaszamy, że poprawiliśmy czas ładowania strony kanału informacyjnego. Średni czas ładowania strony kanału informacyjnego zmniejszył się o 10%. Największe kanały informacyjne odnotowały największą poprawę czasu ładowania strony kanału informacyjnego 99. percentyla (czasy ładowania w najwyższym 99% wszystkich kanałów informacyjnych) zmniejszyły się o 75%.

Publiczne udostępnianie pakietów za pomocą publicznych źródeł danych

Teraz możesz tworzyć i przechowywać pakiety w publicznych kanałach informacyjnych. Pakiety przechowywane w publicznych kanałach informacyjnych są dostępne dla wszystkich użytkowników w Internecie bez uwierzytelniania, niezależnie od tego, czy znajdują się one w kolekcji, czy nawet zalogowały się do kolekcji usługi Azure DevOps. Dowiedz się więcej o publicznych kanałach informacyjnych w naszej dokumentacji kanałów informacyjnych lub przejdź bezpośrednio do naszego samouczka dotyczącego udostępniania pakietów publicznie.

Konfigurowanie nadrzędnych strumieni w różnych kolekcjach w dzierżawie usługi AAD

Teraz możesz dodać kanał informacyjny w innej kolekcji skojarzonej z dzierżawą usługi Azure Active Directory (AAD) jako źródło nadrzędne do źródła artefaktów. Kanał informacyjny może znajdować i używać pakietów z kanałów informacyjnych skonfigurowanych jako źródła nadrzędne, co umożliwia łatwe udostępnianie pakietów między kolekcjami skojarzonymi z dzierżawą usługi AAD. Zobacz, jak to skonfigurować w dokumentacji.

Używanie dostawcy poświadczeń języka Python do uwierzytelniania potoku i reprezentacji bliźniaczej za pomocą źródeł danych usługi Azure Artifacts

Teraz możesz zainstalować i użyć dostawcy poświadczeń języka Python (artifacts-keyring), aby automatycznie skonfigurować uwierzytelnianie do publikowania lub używania pakietów języka Python do lub z kanału informacyjnego usługi Azure Artifacts. W przypadku dostawcy poświadczeń nie trzeba konfigurować żadnych plików konfiguracji (pip.ini/pip.conf/.pypirc), po prostu zostanie wykonany przepływ uwierzytelniania w przeglądarce internetowej podczas wywoływania narzędzia pip lub twine po raz pierwszy. Zobacz więcej informacji w dokumentacji.

Źródła danych usługi Azure Artifacts w Menedżerze pakietów programu Visual Studio

Teraz pokazujemy ikony pakietów, opisy i autorzy w Menedżerze pakietów NuGet programu Visual Studio dla pakietów obsługiwanych z kanałów informacyjnych usługi Azure Artifacts. Wcześniej większość tych metadanych nie została dostarczona do programu VS.

Zaktualizowano środowisko nawiązywania połączenia z kanałem informacyjnym

Okno dialogowe Łączenie z kanałem informacyjnym to wejście do korzystania z usługi Azure Artifacts; Zawiera informacje na temat konfigurowania klientów i repozytoriów w celu wypychania i ściągania pakietów ze źródeł danych w usłudze Azure DevOps. Zaktualizowaliśmy okno dialogowe, aby dodać szczegółowe informacje o konfiguracji i rozszerzyć narzędzia, dla których udostępniamy instrukcje.

Publiczne kanały informacyjne są teraz ogólnie dostępne z obsługą nadrzędną

Publiczna wersja zapoznawcza publicznych kanałów informacyjnych otrzymała wielką akceptację i opinie. W tej wersji rozszerzyliśmy dodatkowe funkcje do ogólnej dostępności. Teraz możesz ustawić publiczne źródło danych jako źródło nadrzędne z prywatnego kanału informacyjnego. Pliki konfiguracji mogą być proste, ponieważ mogą być przesyłane strumieniowo zarówno do kanałów prywatnych, jak i z kanałów informacyjnych o zakresie projektu.

Twórca źródeł danych o zakresie projektu z portalu

Po udostępnieniu publicznych kanałów informacyjnych udostępniliśmy również kanały informacyjne o zakresie projektu. Do tej pory źródła danych o zakresie projektu można tworzyć za pośrednictwem interfejsów API REST lub przez utworzenie publicznego kanału informacyjnego, a następnie włączenie prywatnego projektu. Teraz możesz tworzyć źródła danych o zakresie projektu bezpośrednio w portalu z dowolnego projektu, jeśli masz wymagane uprawnienia. Możesz również zobaczyć, które źródła danych są projektem i które są objęte zakresem kolekcji w selektorze kanału informacyjnego.

Ulepszenia wydajności narzędzia npm

Wprowadziliśmy zmiany w naszym podstawowym projekcie, aby poprawić sposób przechowywania i dostarczania pakietów npm w kanałach informacyjnych usługi Azure Artifacts. Pomogło nam to osiągnąć maksymalnie 10-krotne zmniejszenie opóźnienia dla niektórych z najbardziej używanych interfejsów API dla npm.

Usprawnienia w zakresie ułatwień dostępu

Wdrożyliśmy poprawki, aby rozwiązać problemy z ułatwieniami dostępu na naszej stronie kanałów informacyjnych. Poprawki obejmują następujące elementy:

• Środowisko kanału informacyjnego Twórca
• Środowisko ustawień globalnego kanału informacyjnego
• Nawiązywanie połączenia ze środowiskiem kanału informacyjnego

Witryna Wiki

Zaawansowane edytowanie stron typu wiki kodu

Wcześniej podczas edytowania strony typu wiki kodu nastąpi przekierowanie do centrum Azure Repos do edycji. Obecnie centrum Repozytorium nie jest zoptymalizowane pod kątem edytowania kodu markdown.

Teraz możesz edytować stronę typu wiki kodu w edytorze równoległym wewnątrz strony typu wiki. Dzięki temu możesz użyć zaawansowanego paska narzędzi języka znaczników markdown, aby utworzyć zawartość, dzięki czemu środowisko edycji będzie identyczne z tym w witrynie typu wiki projektu. Nadal możesz edytować repozytoria, wybierając opcję Edytuj w repozytoriach w repozytoriach w menu kontekstowym.

Twórca i osadzanie elementów roboczych ze strony typu wiki

Podczas nasłuchiwania opinii słyszeliśmy, że używasz witryny typu wiki do przechwytywania dokumentów burzy mózgów, planowania dokumentów, pomysłów na funkcje, dokumentów specyfikacji, protokołów spotkania. Teraz możesz łatwo tworzyć funkcje i scenariusze użytkowników bezpośrednio z dokumentu planowania bez opuszczania strony typu wiki.

Aby utworzyć element roboczy, wybierz tekst na stronie typu wiki, na której chcesz osadzić element roboczy, a następnie wybierz pozycję Nowy element roboczy. Pozwala to zaoszczędzić czas, ponieważ nie trzeba najpierw tworzyć elementu roboczego, przejść do edycji, a następnie znaleźć element roboczy, aby go osadzić. Zmniejsza również przełącznik kontekstu, ponieważ nie wychodzisz z zakresu wiki.

Aby dowiedzieć się więcej na temat tworzenia i osadzania elementu roboczego na stronie typu wiki, zobacz naszą dokumentację tutaj.

Komentarze na stronach typu wiki

Wcześniej nie było możliwości interakcji z innymi użytkownikami wiki w witrynie typu wiki. To sprawiło, że współpraca nad zawartością i uzyskanie odpowiedzi na pytania było wyzwaniem, ponieważ konwersacje musiały nastąpić za pośrednictwem poczty lub kanałów czatu. Komentarze umożliwiają teraz współpracę z innymi osobami bezpośrednio w witrynie typu wiki. Możesz wykorzystać @mention funkcje użytkowników w komentarzach, aby zwrócić uwagę innych członków zespołu. Ta funkcja została priorytetowa na podstawie tego biletu sugestii. Aby uzyskać więcej informacji na temat komentarzy, zapoznaj się z naszą dokumentacją tutaj.

Ukryj foldery i pliki rozpoczynające się od "." w drzewie typu wiki

Do tej pory drzewo wiki pokazywało wszystkie foldery i pliki rozpoczynające się kropką (.) w drzewie wiki. W scenariuszach typu wiki kodu spowodowało to wyświetlanie folderów takich jak .vscode, które mają być ukryte, w drzewie wiki. Teraz wszystkie pliki i foldery rozpoczynające się od kropki pozostaną ukryte w drzewie wiki, co zmniejsza niepotrzebne bałagan.

Ta funkcja została priorytetowa na podstawie tego biletu sugestii.

Krótkie i czytelne adresy URL stron typu wiki

Nie musisz już używać wielowierszowego adresu URL do udostępniania linków stron typu wiki. Używamy identyfikatorów stron w adresie URL do usuwania parametrów, dzięki czemu adres URL jest krótszy i łatwiejszy do odczytania.

Nowa struktura adresów URL będzie wyglądać następująco:

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Jest to przykład nowego adresu URL strony wiki witamy w usłudze Azure DevOps :

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Jest to priorytetowe na podstawie tego biletu sugestii funkcji z Developer Community.

Synchroniczne przewijanie do edytowania stron typu wiki

Edytowanie stron typu wiki jest teraz łatwiejsze dzięki synchronicznej przewijaniu między edycją a okienkiem podglądu. Przewijanie po jednej stronie spowoduje automatyczne przewinięcie drugiej strony, aby zamapować odpowiednie sekcje. Możesz wyłączyć synchroniczne przewijanie za pomocą przycisku przełącznika.

Uwaga

Stan przełącznika przewijania synchronicznego jest zapisywany dla użytkownika i konta.

Wizyty na stronach typu wiki

Teraz możesz uzyskać szczegółowe informacje na temat wizyt na stronie dla stron typu wiki. Interfejs API REST umożliwia dostęp do informacji o odwiedzinach strony w ciągu ostatnich 30 dni. Te dane umożliwiają tworzenie raportów dla stron typu wiki. Ponadto możesz przechowywać te dane w źródle danych i tworzyć pulpity nawigacyjne, aby uzyskać szczegółowe informacje, takie jak najczęściej wyświetlane strony.

Na każdej stronie zostanie również wyświetlona zagregowana liczba wizyt na stronie z ostatnich 30 dni.

Uwaga

Wizyta strony jest definiowana jako widok strony przez danego użytkownika w 15-minutowym interwale.

Raportowanie

Raporty dotyczące niepowodzeń i czasu trwania potoku

Metryki i szczegółowe informacje pomagają w ciągłym ulepszaniu przepływności i stabilności potoków. Dodaliśmy dwa nowe raporty, aby zapewnić szczegółowe informacje o potokach.

1. Raport o niepowodzeniu potoku przedstawia współczynnik przebiegu kompilacji i trend niepowodzenia. Ponadto pokaże również trend niepowodzeń zadań w celu udostępnienia szczegółowych informacji o tym, które zadanie w potoku przyczynia się do maksymalnej liczby błędów.

2. Raport czasu trwania potoku przedstawia trend czasu potrzebny na uruchomienie potoku. Pokazuje również, które zadania w potoku zajmują najwięcej czasu.

Poprawa widżetu wyników zapytania

Widżet wyników zapytania jest jednym z naszych najpopularniejszych widżetów i z jakiegoś powodu. Widżet wyświetla wyniki zapytania bezpośrednio na pulpicie nawigacyjnym i jest przydatny w wielu sytuacjach.

Dzięki tej aktualizacji wprowadziliśmy wiele długo oczekiwanych ulepszeń:

• Teraz możesz wybrać dowolną liczbę kolumn, które mają być wyświetlane w widżecie. Nie ma więcej limitu 5 kolumn!
• Widżet obsługuje wszystkie rozmiary od 1x1 do 10x10.
• Zmiana rozmiaru kolumny spowoduje zapisanie szerokości kolumny.
• Widżet można rozwinąć do widoku pełnoekranowego. Po rozwinięciu zostaną wyświetlone wszystkie kolumny zwrócone przez zapytanie.

Zaawansowane filtrowanie widżetów Czasu potencjalnych klientów i cyklu

Czas realizacji i cyklu jest używany przez zespoły, aby zobaczyć, jak długo trwa przepływ pracy przez potoki programowania, a ostatecznie dostarcza wartość klientom.

Do tej pory widżety czasu ołowiu i cyklu nie obsługiwały zaawansowanych kryteriów filtrowania, aby zadawać pytania, takie jak: "jak długo trwa zamknięcie elementów o wyższym priorytcie?"

Na te pytania dotyczące aktualizacji można odpowiedzieć, filtrując tor tablicy.

Uwzględniliśmy również filtry elementów roboczych, aby ograniczyć elementy robocze wyświetlane na wykresie.

Wbudowane wypalenia przebiegu przy użyciu punktów scenariuszy

Twoje burndown przebiegu może teraz spalony przez Stories. Dotyczy to opinii użytkowników z Developer Community.

W centrum Sprint wybierz kartę Analiza. Następnie skonfiguruj raport w następujący sposób:

1. Wybierz listę prac scenariuszy
2. Wybierz, aby wypalić w obszarze Suma punktów historii

Widżet Sprint Burndown z wszystkim, o co prosiłeś

Nowy widżet Postępu przebiegu obsługuje wypalanie według punktów historii, liczby zadań lub sumowania pól niestandardowych. Można nawet utworzyć przebieg dla funkcji lub epików. Widżet wyświetla średnie spalenie, procent ukończenia i zwiększenie zakresu. Możesz skonfigurować zespół, umożliwiając wyświetlanie postępu przebiegu dla wielu zespołów na tym samym pulpicie nawigacyjnym. Dzięki tym wszystkim doskonałym informacjom do wyświetlenia można zmienić jego rozmiar do 10x10 na pulpicie nawigacyjnym.

Aby go wypróbować, możesz dodać go z katalogu widżetów lub edytując konfigurację istniejącego widżetu Sprint Burndown i zaznaczając pole Wypróbuj nową wersję teraz .

Uwaga

Nowy widżet używa analizy. Zachowaliśmy starsze burndown przebiegu w przypadku, gdy nie masz dostępu do usługi Analytics.

Wbudowana miniatura przebiegu przebiegu

Sprint Burndown powraca! Kilka przebiegów temu usunęliśmy postęp przebiegu w kontekście z nagłówków Sprint Burndown i Taskboard. W oparciu o Twoją opinię ulepszyliśmy i ponownie wprowadziliśmy miniaturę postępu przebiegu.

Kliknięcie miniatury spowoduje natychmiastowe wyświetlenie większej wersji wykresu z opcją wyświetlenia pełnego raportu na karcie Analiza. Wszelkie zmiany wprowadzone w pełnym raporcie zostaną odzwierciedlone na wykresie wyświetlanym w nagłówku. Teraz można skonfigurować je tak, aby można było je spalić na podstawie historii, punktów historii lub liczby zadań, a nie tylko ilości pozostałej pracy.

Twórca pulpitu nawigacyjnego bez zespołu

Teraz możesz utworzyć pulpit nawigacyjny bez kojarzenia go z zespołem. Podczas tworzenia pulpitu nawigacyjnego wybierz typ pulpitu nawigacyjnego projektu .

Pulpit nawigacyjny projektu jest jak pulpit nawigacyjny zespołu, z wyjątkiem tego, że nie jest skojarzony z zespołem i możesz zdecydować, kto może edytować pulpit nawigacyjny i zarządzać nim. Podobnie jak pulpit nawigacyjny zespołu, jest on widoczny dla wszystkich w projekcie.

Wszystkie widżety usługi Azure DevOps, które wymagają kontekstu zespołu, zostały zaktualizowane, aby umożliwić wybranie zespołu w konfiguracji. Możesz dodać te widżety do pulpitów nawigacyjnych projektu i wybrać odpowiedni zespół.

Uwaga

W przypadku widżetów niestandardowych lub innych firm pulpit nawigacyjny projektu przekaże domyślny kontekst zespołu do tych widżetów. Jeśli masz niestandardowy widżet, który opiera się na kontekście zespołu, zaktualizuj konfigurację, aby umożliwić wybranie zespołu.

---

Opinia

Chcemy poznać Twoją opinię! Możesz zgłosić problem lub przekazać pomysł i śledzić go przez Developer Community i uzyskać porady w witrynie Stack Overflow.

---

Góra strony