Notatki o wydaniu Azure DevOps Server 2020

Developer Community | Wymagania systemowe | postanowienia licencyjne | DevOps blog | skróty SHA-1

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

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

Bezpośrednie uaktualnienie do usługi Azure DevOps Server 2020 jest obsługiwane z poziomu programu Azure DevOps Server 2019 lub Team Foundation Server 2015 lub nowszego. Jeśli wdrożenie serwera TFS jest na serwerze TFS 2010 lub starszym, przed uaktualnieniem do usługi 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 usługi Azure DevOps Server 2019 do usługi Azure DevOps Server 2020

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

Usługa Azure DevOps Server 2020 obsługuje przechowywanie kompilacji inaczej na podstawie zasad przechowywania na poziomie potoku. Niektóre konfiguracje ustawień prowadzą do usunięcia przebiegów potoku po uaktualnieniu. Przebiegi 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 usługi Azure DevOps Server 2019 do usługi Azure DevOps Server 2020.

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

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

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

Notatka

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

Instalowanie poprawek

Ważny

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 , aby przesłać zadania do dokumentacji kolekcji projektowej, zainstalować i zalogować się za pomocą tfx-cli.

Aktualizowanie zadań przy użyciu narzędzia TFX

Plik	Skrót SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9EFCED5034D2E5

1. Pobierz i wyodrębnij Tasks20231103.zip.
2. Zmień katalog na ten zawierający 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 rurociągu

Aby użyć nowego zachowania, zmienna AZP_75787_ENABLE_NEW_LOGIC = true musi być ustawiona w potokach korzystających z zadań, których dotyczy problem.

• W wersji klasycznej:

  Zdefiniuj zmienną w zakładce 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żny

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 usługi 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 uaktualnień poprawek.

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

Opublikowaliśmy poprawkę dla usługi 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 serwera Azure DevOps Server.
• CVE-2023-38155: Luka w zabezpieczeniach dotycząca podniesienia uprawnień serwera Azure DevOps Server i serwera Team Foundation Server.

Ważny

Wdróż aktualizację w środowisku testowym i upewnij się, że potoki w tym środowisku działają zgodnie z oczekiwaniami, zanim zastosujesz rozwiązanie w środowisku produkcyjnym.

Notatka

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 program 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 agentów Windows działających lokalnie.  

Notatka

AZP_AGENT_DOWNGRADE_DISABLED musi być ustawiona na wartość "true", aby zapobiec obniżeniu poziomu agenta. W systemie Windows można użyć następującego polecenia w wierszu polecenia administracyjnego, a następnie należy ponownie uruchomić system. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Konfigurowanie rozwiązania TFX

1. Wykonaj kroki opisane w zadaniach przesyłania do dokumentacji kolekcji projektów, aby zainstalować i zalogować się przy użyciu 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 załadować 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 rurociągu

Aby użyć nowego zachowania, zmienna AZP_75787_ENABLE_NEW_LOGIC = true musi być ustawiona w potokach korzystających z zadań, których dotyczy problem.

• W wersji klasycznej:

  Zdefiniuj zmienną w zakładce zmiennych 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 usługi Azure DevOps Server 2020 Update 0.2, która zawiera poprawki dla następujących elementów.

• Usunięto błąd zakłócający przesyłanie 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 usługi Azure DevOps Server 2020 Update 0.2, która zawiera poprawki dla następujących elementów.

• Usunięto usterkę zakłócającą 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 usługi 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 Active Directory, które nie są wyświetlane w selektorach tożsamości okna dialogowego zabezpieczeń.
• Naprawiono problem z filtrem 'Żądane przez członka grupy' w ustawieniach webhooka.
• Naprawiono błąd kompilacji z kontrolowanym zaewidencjonowaniem, gdy ustawienia organizacji dla potok miały zakres autoryzacji zadania skonfigurowany jako Limit zakresu autoryzacji zadania do bieżącego projektu dla potoków innych niż dla wydań.

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

Azure DevOps Server 2020.0.2 jest zestawieniem poprawek błędów. Możesz bezpośrednio zainstalować program Azure DevOps Server 2020.0.2 lub uaktualnić z programu Azure DevOps Server 2020 lub Team Foundation Server 2013 lub nowszego.

Notatka

Narzędzie do migracji danych będzie dostępne dla usługi Azure DevOps Server 2020.0.2 około trzech tygodni po tej wersji. Listę aktualnie obsługiwanych wersji do importowania 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 usługi Azure DevOps Server 2020.0.1, która zawiera poprawki dla następujących elementów.

• Powiadomienia e-mail 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 usługi Azure DevOps Server 2020.0.1.
• Rozwiązano problem z niepowodzeniem ładowania 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 Patch 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 aktualizacji PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update podane 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 wykonuje ponowną próbę, dopóki nie zostanie ukończona.

Notatka

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

1. Uaktualnij serwer przy użyciu poprawki Patch 9..
2. Sprawdź wartość rejestru dla 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ącego się na C:\Program Files\{TFS Version Folder}\Search\zip, do zdalnego folderu Elasticsearch.
4. Uruchom 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.

Patch 8 dla usługi Azure DevOps Server 2020.0.1 zawiera poprawki dla następujących elementów.

• Problem z lokalizacją niestandardowych konfiguracji stanów elementów roboczych.
• Problem z lokalizacją w szablonie powiadomień e-mail.
• Problem z dziennikami konsoli zostają obcięte, gdy istnieje wiele identycznych łączy pod rząd.
• 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.

Patch 7 dla usługi Azure DevOps Server 2020.0.1 zawiera poprawki dla następujących elementów.

• Wcześniej serwer Azure DevOps Server mógł tworzyć połączenia tylko z serwerem GitHub Enterprise Server. Dzięki tej poprawce administratorzy projektu mogą tworzyć połączenia między serwerem Usługi Azure DevOps i repozytoriami w GitHub.com. To ustawienie można znaleźć na stronie połączenia z GitHub w obszarze Ustawienia projektu.
• Rozwiąż problem z widżetem planu testów. Raport wykonywania testu przedstawiał niepoprawnego użytkownika w wynikach.
• Rozwiązano problem z niepowodzeniem ładowania 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.

Patch 6 dla usługi Azure DevOps Server 2020.0.1 zawiera poprawki dla następujących elementów.

• Napraw awarię 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.

Patch 5 dla usługi Azure DevOps Server 2020.0.1 zawiera poprawki dla następujących elementów.

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

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

Patch 4 dla usługi 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 tabeli tbl_testCaseReferences. 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 usługi 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 usługę Azure DevOps Server 2020.0.1, zainstaluj azure DevOps Server 2020.0.1 Patch 3.

weryfikowanie instalacji

• opcja 1: Uruchom devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.exe to plik pobrany z powyższego linku. Wynik polecenia pokaże, czy poprawka została zainstalowana, czy nie.

• 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ślnie w c:\Program Files\Azure DevOps Server 2020. Po zainstalowaniu poprawki 3 programu Azure DevOps Server 2020.0.1 wersja będzie mieć wartość 18.170.31228.1.

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

Notatka

Jeśli masz usługę Azure DevOps Server 2020, musisz najpierw zaktualizować usługę Azure DevOps Server 2020.0.1. Najpierw w wersji 2020.0.1 zainstaluj Azure DevOps Server 2020.0.1 Patch 2

Opublikowaliśmy poprawkę dla usługi 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 aktualizacji, należy wykonać kroki wymienione poniżej dla instalacji ogólnych , instalacji zadań AzureResourceGroupDeploymentV2 i instalacji zadań AzureResourceManagerTemplateDeploymentV3.

Ogólna instalacja poprawek

Jeśli masz usługę Azure DevOps Server 2020.0.1, zainstaluj Azure DevOps Server 2020.0.1 Patch 2.

Weryfikowanie instalacji

• opcja 1: Uruchom devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.exe to plik pobrany z powyższego linku. Wynik polecenia poinformuje, że poprawka została zainstalowana lub że nie została zainstalowana.

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

Instalacja zadania AzureResourceGroupDeploymentV2

Notatka

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

Instalować

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 oraz npm (które jest dołączone do pobierania Node.js) odpowiednio do Twojej maszyny.

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

npm install -g tfx-cli

4. Utwórz 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 tfx login.

5. Uruchom następujące polecenie w oknie wiersza 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 przesłać zadanie na serwer. 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

Nota

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

Instalować

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 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ć tfx-cli.

npm install -g tfx-cli

4. Utwórz 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 tfx login.

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 załadować zadanie do serwera. 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 usługi Azure DevOps Server 2020.0.1, która naprawia następujące poprawki. Aby uzyskać więcej informacji, zobacz wpis w blogu .

• Rozwiąż problem zgłoszony w zgłoszeniu opinii społeczności deweloperów dotyczącym| Przycisk "Nowy przypadek testowy" nie działa
• Uwzględnij poprawki wprowadzone w Azure DevOps Server 2020 Patch 2.

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

Opublikowaliśmy poprawkę dla usługi Azure DevOps Server 2020, która naprawia następujące problemy. Aby uzyskać więcej informacji, zobacz wpis w blogu .

• Rozwiąż problem zgłoszony w w tym bilecie opinii społeczności deweloperów| 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 zestawienie 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 usterek:

• Rozwiąż problem z uaktualnieniem z serwera Azure DevOps Server 2019, 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 serwera Team Foundation Server 2017 do usługi Azure DevOps Server 2020. Rozwiązuje problem zgłoszony w w tym zgłoszeniu opinii społeczności deweloperów.
• Niepowodzenie obsługi spowodowane brakiem Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Rozwiązuje problem zgłoszony w zgłoszeniu opinii wspólnoty deweloperów .
• Napraw błąd związany z nieprawidłową nazwą kolumny w module Analytics podczas uaktualniania do Azure DevOps Server 2020. Rozwiązuje problem zgłoszony w tym bilecie opinii społeczności deweloperów .
• Przechowywane XSS podczas wyświetlania kroków przypadku testowego w wynikach testu.
• Podczas migracji danych wyników punktów do TCM wystąpiło niepowodzenie kroku uaktualniania.

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

Opublikowaliśmy poprawkę dla Azure DevOps Server 2020, która rozwiązuje następujące problemy. Aby uzyskać więcej informacji, zobacz wpis w blogu .

• Szczegóły przebiegu testu nie zawierają szczegółów kroku testu dla danych testowych migrowanych przy użyciu migracji platformy OpsHub
• Wyjątek dotyczący inicjatora dla 'Microsoft.TeamFoundation.TestManagement.Server.TCMLogger'
• Nieretainowane kompilacje są natychmiast usuwane po migracji do usługi Azure DevOps Server 2020
• Napraw wyjątek dostawcy danych

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

Opublikowaliśmy poprawkę i dla usługi Azure DevOps Server 2020, która naprawia następujące problemy. Aby uzyskać więcej informacji, zobacz wpis w blogu .

• CVE-2020-17145: Luka umożliwiająca fałszowanie tożsamości w Azure DevOps Server i Team Foundation Services

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

Azure DevOps Server 2020 to zestawienie poprawek błędów. Obejmuje ona wszystkie funkcje w wcześniej wydanym serwerze Azure DevOps Server 2020 RC2.

Uwaga

Serwer Usługi Azure DevOps 2020 ma problem z instalacją jednego z zestawów używanych przez wirtualny system plików Git (GVFS).

Jeśli uaktualniasz usługę Azure DevOps 2019 (dowolną wersję) lub wersję kandydata do wydania usługi Azure DevOps 2020 i instalujesz ją w tym samym katalogu co poprzednia wersja, biblioteka Microsoft.TeamFoundation.Git.dll nie zostanie zainstalowana. Możesz sprawdzić, czy problem wystąpił, wyszukując Microsoft.TeamFoundation.Git.dll w folderach <Install Dir>\Version Control Proxy\Web Services\bin, <Install Dir>\Application Tier\TFSJobAgent 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 na maszynie/maszynie wirtualnej serwera Azure DevOps Server i uruchom naprawę na serwerze 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 zestawienie poprawek błędów. Obejmuje ona wszystkie funkcje programu Azure DevOps Server 2020 RC1, które wcześniej wydano.

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

Ponownie wydaliśmy usługę Azure DevOps Server 2020 RC1, aby rozwiązać problem zgodnie z uwagami społeczności deweloperów.

Wcześniej po uaktualnieniu z usługi Azure DevOps Server 2019 Update 1.1 do usługi Azure DevOps Server 2020 RC1 nie można było wyświetlić plików w repozytoriach, potokach i witrynach typu wiki interfejsu użytkownika sieci Web. Wystąpił komunikat o błędzie wskazujący, wystąpił 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. Aby uzyskać więcej informacji, zobacz wpis w blogu .

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

Podsumowanie nowości w usłudze Azure DevOps Server 2020

Usługa Azure DevOps Server 2020 wprowadza wiele nowych funkcji. Niektóre z najważniejszych elementów to:

• potoki wieloetapowe
• ciągłe wdrażanie w YAML
• Śledzenie postępu elementów nadrzędnych za pomocą rollupu na backlogu tablic
• dodaj filtr "Nadrzędny element roboczy" do tablicy zadań i listy prac przebiegu
• nowy internetowy interfejs użytkownika dla stron docelowych usługi Azure Repos
• administrowanie zasadami gałęzi między repozytoriami
• Strona nowego planu testów
• rozbudowane edytowanie stron wiki dotyczących kodu
• Raporty dotyczące awarii pipeline i czasu trwania

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

• Ogólne
• tablic
• repozytoriów
• rurociągi
• Plany testów
• Artefakty
• Wiki
• Raportowanie

---

Ogólne

Ogólna dostępność Azure DevOps CLI

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, zobacz dokumentację tutaj.

Użyj profilu publikowania, aby wdrożyć aplikacje internetowe platformy Azure dla systemu Windows z Centrum wdrażania.

Teraz możesz użyć uwierzytelniania opartego na profilu publikacji, aby wdrożyć usługę Azure WebApps dla systemu Windows z 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.

Deski

Dodaj filtr "Nadrzędny element roboczy" do tablicy zadań i backlogu sprintu

Dodaliśmy nowy filtr zarówno do tablicy Sprintu, jak i listy prac Sprintu. Dzięki temu można filtrować elementy backlogu na poziomie wymagań (pierwsza kolumna po lewej stronie) według ich rodzica. Na przykład na poniższym zrzucie ekranu przefiltrowaliśmy widok, aby wyświetlić tylko scenariusze użytkownika, w których element nadrzędny to "Moja duża funkcja".

Ulepszanie środowiska obsługi błędów — wymagane pola dotyczące usterki/zadania

Dawniej na tablicy Kanban, jeśli element roboczy został przesunięty z jednej kolumny do drugiej, gdzie zmiana statusu wyzwalała reguły pól, karta była wyświetlana z czerwonym komunikatem o błędzie, który wymuszał otwarcie elementu roboczego, aby zrozumieć główną przyczynę. Podczas sprintu 170 ulepszyliśmy doświadczenie, 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 dynamiczne aktualizacje zmian wprowadzonych w elemencie roboczym.

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

Teraz można zarządzać iteracjami i ścieżkami obszaru z poziomu wiersza polecenia przy użyciu poleceń az boards iteration i az boards area. Na przykład można 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

Masz teraz możliwość wyświetlania nadrzędnego elementu każdego zadania w backlogu produktu lub backlogu sprintu. Aby włączyć tę funkcję, przejdź do 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, tak jak robi to twój zespół. Teraz możesz przełączać projekty z dowolnego gotowego szablonu procesu do dowolnego innego gotowego procesu. Na przykład możesz zmienić projekt z używania metody Agile na Scrum lub Basic na Agile. Pełną dokumentację krok po kroku można znaleźć tutaj.

Ukryj pola niestandardowe z układu

Teraz możesz ukryć pola niestandardowe w układzie 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 szczegółowych informacji na temat kondycji zespołu przy użyciu trzech nowych raportów usługi 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 nakładzie pracy w usłudze Azure Boards.

Trzy nowe interaktywne raporty to: Burndown, Skumulowany diagram przepływu (CFD) i Velocity. Raporty można wyświetlić na nowej karcie analizy.

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

• Ile pracy pozostało w tym sprincie? 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 sprint?

Notatka

Wykresy pokazane 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 Analytics w każdym centrum.

• Wykres postępu można znaleźć w centrum Sprints Hub.

  

• Raporty CFD i Velocity są dostępne na karcie Analytics w sekcji Boards i Backlogs, poprzez kliknięcie odpowiedniej karty.

  

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

• Raporty Sprint Burndown i Velocity można ustawić tak, aby używać liczby elementów pracy lub sumy pozostałej pracy.
• Możesz dostosować przedział czasowy wykresu sprintu bez wpływu na daty projektu. Jeśli zazwyczaj twój zespół spędza pierwszy dzień każdego sprintu na planowaniu, możesz teraz dopasować wykres, aby to odzwierciedlić.
• Wykres Burndown ma teraz tło pokazujące weekendy.
• Raport CFD umożliwia usuwanie kolumn tablicy, takich jak Design, aby skupić się bardziej na przepływem, który jest pod kontrolą zespołów.

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

Wykres prędkości można teraz śledzić dla wszystkich poziomów zaległości. Na przykład teraz można dodać zarówno funkcje, jak i epiki, podczas gdy wcześniejszy diagram obsługiwał tylko wymagania. Oto przykład raportu szybkości dla ostatnich 6 iteracji rejestru 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 Opcje kolumn.

Ta funkcja została o priorytyzowana na podstawie sugestii społeczności deweloperów.

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

Wiele razy, gdy dopracowujesz listę zadań, chcesz zobaczyć tylko elementy, które nie zostały ukończone. Teraz masz możliwość pokazywania 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. Gdy przełącznik jest wyłączony, 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 tylko do odczytu lub wymagane na podstawie członkostwa w grupie. Na przykład możesz przyznać właścicielom produktów możliwość ustalania priorytetu funkcji, podczas gdy dla wszystkich innych będzie ona tylko do odczytu.

Dostosowywanie wartości listy wyboru systemu

Teraz można dostosować wartości dla dowolnej systemowej listy wyboru (z wyjątkiem pola przyczyny), takich jak Ważność, Aktywność, Priorytet itp. Dostosowania list wyboru mają określony zakres, co umożliwia zarządzanie różnymi wartościami dla tego samego pola w zależności od typu elementu roboczego.

Parametr adresu URL nowego elementu roboczego

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

Każda osoba, z którą udostępniasz link, trafi do tego samego kontekstu, który miałeś po udostępnieniu linku!

Wspominaj osoby, elementy robocze i PR-y w polach tekstowych

Słuchając Waszych opinii, usłyszeliśmy, że chcecie mieć możliwość wspomnienia o osobach, elementach roboczych i pull requestach w polu opisu elementu roboczego oraz innych polach HTML, a nie tylko do komentowania. Czasami współpracujesz z kimś nad elementem roboczym lub chcesz wyróżnić PR w opisie elementu roboczego, ale nie masz możliwości dodania tych informacji. Teraz możesz wspominać o osobach, elementach roboczych i pull requestach we wszystkich dłuższych 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 wygeneruje powiadomienia e-mail, takie jak w przypadku komentarzy.
• Aby użyć wzmianek o elemencie roboczym, wpisz znak #, a następnie identyfikator lub tytuł elementu roboczego. #mentions utworzy łącze między dwoma elementami roboczymi.
• Aby użyć wzmianek PR, dodaj !, a następnie swój identyfikator PR lub nazwę.

Reakcje na komentarze do dyskusji

Jednym z naszych głównych celów jest uczynienie zadań roboczych bardziej współpracującymi dla zespołów. Niedawno przeprowadziliśmy ankietę na Twitterze, aby dowiedzieć się, jakie funkcje współpracy chcesz podczas dyskusji dotyczących zadania. Wprowadzenie reakcji na komentarze wygrało w ankiecie, dlatego je dodajemy! Oto wyniki ankiety twitterowej.

Możesz dodać reakcje do dowolnego komentarza i istnieją dwa sposoby dodawania reakcji — ikona uśmiechnięć 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ąć reakcję, kliknij reakcję na dole komentarza i zostanie usunięta. Poniżej widać doświadczenie dodawania reakcji, a także jak wyglądają reakcje na komentarz.

Przypinanie raportów usługi Azure Boards do pulpitu nawigacyjnego

W aktualizacji Sprint 155 dołączyliś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 menu z wielokropkiem "...", a następnie Kopiuj do pulpitu nawigacyjnego.

Śledź postęp elementów nadrzędnych, korzystając z funkcji Rollup na backlogu tablic

Kolumny zestawienia pokazują paski postępu i/lub sumy pól liczbowych lub elementów potomnych w hierarchii. Elementy potomne odpowiadają wszystkim elementom podrzędnym w hierarchii. Do backlogu produktu lub portfela można dodać jedną lub więcej kolumn.

Na przykład pokazujemy tutaj Postęp według elementów roboczych, gdzie wyświetlane są paski postępu dla elementów nadrzędnych, w zależności od procentu zamkniętych elementów podrzędnych. Elementy potomne dla epików zawierają wszystkie funkcje podrzędne oraz ich elementy robocze podrzędne lub potomne. 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. Aby zobaczyć najnowsze zmiany, nie trzeba już naciskać F5.

Obsługa pól niestandardowych w kolumnach Rollup

Zestawienie może być teraz wykonane na dowolnym polu, w tym na polach niestandardowych. Podczas dodawania kolumny zestawienia nadal można wybrać kolumnę zestawienia z listy szybkiego wyboru. Jednak jeśli chcesz utworzyć zestawienie w polach liczbowych, które nie są częścią wbudowanego szablonu procesu, możesz skonfigurować własne w następujący sposób:

1. Na backlogu kliknij "Opcje kolumny". Następnie na panelu kliknij pozycję "Dodaj kolumnę zestawienia" i Skonfiguruj niestandardowe zestawienie.

   

2. Wybierz między paska postępu a total.
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 polu Sum należy wybrać pole, które ma zostać podsumowane.
5. Przycisk OK przeniesie cię z powrotem do panelu opcji kolumn, gdzie możesz zmienić kolejność swojej nowej niestandardowej kolumny.

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 w zależności od warunku

Dodaliśmy nową regułę do aparatu reguł dziedziczych, 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

Aktualizowanie elementów roboczych 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óżni interesariusze mają różne poziomy inwestycji w różne inicjatywy i uważamy, że powinno to odzwierciedlać twoją zdolność do śledzenia statusu zadania.

Wcześniej, jeśli chcesz postępować zgodnie z elementem roboczym i otrzymywać powiadomienia o wszelkich wprowadzonych zmianach, otrzymasz powiadomienia e-mail dotyczące wszystkich zmian wprowadzonych w elemencie roboczym. Po uwzględnieniu twojej opinii, uczynimy zadanie robocze bardziej elastycznym dla wszystkich interesariuszy. 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 kolejnych opcji.

W ustawieniach powiadomieńmożna wybrać jedną z trzech dostępnych opcji powiadamiania. Najpierw możesz całkowicie anulować subskrypcję. Po drugie, możesz mieć pełną subskrypcję, dzięki której 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 wprowadzona. 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 kontrolę wdrażania na formularzu elementu roboczego. Ta kontrolka łączy elementy robocze z wydaniem i pozwala łatwo śledzić, gdzie został wdrożony element roboczy. 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 usługi Azure Boards, dzięki czemu można zaimportować nowe lub zaktualizować istniejące elementy robocze. Aby dowiedzieć się więcej, zobacz dokumentację tutaj.

Dodaj pole nadrzędne do kart elementów roboczych

Kontekst nadrzędny jest teraz dostępny w tablicy Kanban jako nowe pole dla kart zadań. 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 backlogów i wyników zapytań. Aby dodać pole nadrzędne, użyj opcji kolumny widoku.

Repos

Metryki pokrycia kodu i polityka gałęzi dla żądań przeciągnięcia

Teraz możesz wyświetlić metryki pokrycia kodu dla zmian w widoku pull request (PR). Dzięki temu zmiany zostały odpowiednio przetestowane za pomocą testów automatycznych. Status pokrycia będzie wyświetlany jako komentarz w przeglądzie PR. Możesz wyświetlić szczegółowe informacje o pokryciu dla każdego wiersza kodu, który został zmieniony, w widoku porównania plików.

Ponadto właściciele repozytoriów mogą teraz definiować zasady pokrycia kodu i zapobiegać scalaniu dużych, nietestowanych zmian do gałęzi. Żądane progi pokrycia można zdefiniować w pliku ustawień azurepipelines-coverage.yml, który jest zaewidencjonowany w katalogu głównym repozytorium, a polityka pokrycia może być określona przy użyciu istniejącej funkcji konfigurowania zasad gałęzi dla dodatkowych usług w usłudze Azure Repos.

Filtruj powiadomienia o komentarzach z pull requests

Komentarze w żądaniach zatwierdzenia często generują dużo hałasu z powodu powiadomień. Dodaliśmy niestandardową subskrypcję, która umożliwia filtrowanie powiadomień o komentarzach, na które subskrybujesz, według wieku komentarzy, autora komentarza, usuniętego komentarza, wymienionych użytkowników, autora pull requesta, 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.

Haki usługi dla komentarzy do pull requestów

Teraz możesz tworzyć hooki serwisowe dla komentarzy w pull request na podstawie repozytorium i gałęzi docelowej.

Zasady blokowania plików z określonymi wzorcami

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

Rozwiązywanie elementów roboczych przez zatwierdzenia przy użyciu słów kluczowych

Elementy robocze można teraz rozwiązywać za pomocą zatwierdzeń w gałęzi domyślnej, używając słów kluczowych, takich jak naprawa, naprawialub naprawiono. Na przykład można napisać: "ta zmiana naprawia #476" w wiadomości zatwierdzenia, a element roboczy #476 zostanie ukończony po wysłaniu lub scaleniu zatwierdzenia z gałęzią domyślną. Aby uzyskać więcej informacji, zobacz dokumentację tutaj.

Stopień szczegółowości dla weryfikatoró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 skonfigurować zasady wymagające, aby więcej niż jeden recenzent z zespołu zatwierdził żądanie ściągnięcia w momencie dodawania automatycznych recenzentów. Ponadto można dodać zasady, aby uniemożliwić żądającemu 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 nasze strumienie danych będą używać uwierzytelniania opartego na kontach serwisowych w celu nawiązania połączenia z klastrem, aby mieć dostęp wyłącznie do przestrzeni nazw skojarzonej z tym strumieniem.

Podgląd plików Markdown w żądaniu przeniesienia porównywanie równoległe

Teraz możesz zobaczyć podgląd wyglądu pliku markdown przy użyciu nowego przycisku Preview. 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ą jakość kodu zespołu i standardy zarządzania zmianami. Wcześniej można było ustawić zasady wygasania kompilacji dla automatycznych kompilacji. Teraz możesz ustawić zasady wygasania również dla kompilacji ręcznych.

Dodaj zasadę blokowania zatwierdzeń na podstawie adresu e-mail autora zatwierdzenia

Administratorzy mogą teraz ustawić zasady push, aby zapobiec wypychaniu zatwierdzeń do repozytorium, dla którego adres e-mail autora nie jest zgodny z podanym wzorcem.

Ta funkcja została uprzywilejowana na podstawie sugestii ze społeczności deweloperów w celu zapewnienia podobnego doświadczenia. Będziemy nadal trzymać zgłoszenie otwarte i zachęcać użytkowników do dzielenia się z nami, jakie inne typy polityk powiadomień push chcielibyście zobaczyć.

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

Czasami trzeba przejrzeć pull requesty zawierające zmiany w dużej liczbie plików i może być trudno śledzić, które pliki zostały już przejrzane. 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 po umieszczeniu wskaźnika myszy i kliknięciu nazwy pliku.

Notatka

Ta funkcja jest przeznaczona tylko do śledzenia postępu podczas przeglądania pull requestu. Nie reprezentuje głosowania w prośbach o ściągnięcie, więc te oznaczenia będą widoczne tylko dla recenzenta.

Ta funkcja została priorytetyzowana na podstawie sugestii od Developer Community.

Nowy internetowy interfejs użytkownika dla stron docelowych usługi Azure Repos

Teraz możesz wypróbować nowe nowoczesne, szybkie i przyjazne dla urządzeń przenośnych strony docelowe w usłudze 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.

Sieć

Mobilny

Administrowanie zasadami między repozytoriami

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

Nowe strony docelowe dla konwersji na platformie 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. Nadaliśmy tej funkcji priorytety na podstawie sugestii Developer Community.

Subskrypcja powiadomień niestandardowych 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 stanu wersji roboczej. Możesz otrzymywać wiadomości e-mail przeznaczone specjalnie dla żądań ściągnięcia wersji roboczej lub odfiltrować wiadomości e-mail z żądań ściągnięcia, aby zespół nie otrzymywał powiadomień, zanim żądanie ściągnięcia będzie gotowe do przejrzenia.

Ulepszona wykonalność żą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ć użyteczność żądań zmian, możesz teraz utworzyć wiele niestandardowych zapytań na stronie listy żądań zmian z kilkoma nowymi opcjami filtrowania, takimi jak stan wersji roboczej. Te wyszukiwania będą tworzyć składane i oddzielne sekcje na stronie pull request oprócz „Utworzone przeze mnie” i „Przypisane do mnie”. Możesz również odmówić przeglądu prośby o scalenie, do której zostałeś dodany, korzystając z menu Głosowanie lub menu kontekstowego na stronie listy próśb o scalenie. W niestandardowych sekcjach teraz zobaczysz oddzielne karty dla pull requestów, dla których przeprowadzono recenzję lub odmówiono przeglądu. Te niestandardowe zapytania będą działać w repozytoriach na karcie "Moje zgłoszenia" na stronie głównej kolekcji. Jeśli chcesz wrócić do pull requesta, możesz go oznaczyć i pojawią się na górze listy. Na koniec żądania ściągnięcia ustawione na autouzupełnianie zostaną oznaczone pigułką z napisem "Autouzupełnianie" na liście.

Rurociągi

Potoki wieloetapowe

Pracowaliśmy nad zaktualizowanym doświadczeniem użytkownika , aby zarządzać swoimi pipeline'ami. Dzięki tym aktualizacjom doświadczenie związane z obsługą potoków staje się nowoczesne i zgodne z kierunkiem rozwoju Azure DevOps. Ponadto te aktualizacje łączą klasyczne potoki kompilacji i wieloetapowe potoki YAML w jedno środowisko. Jest przyjazny dla urządzeń mobilnych i wprowadza różnorodne usprawnienia w zarządzaniu potokami. Możesz zgłębić temat i wyświetlić szczegóły przepływu danych, detale dotyczące uruchomień, analizę procesów, szczegóły zadań, dzienniki i inne.

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

• wyświetlanie wielu etapów i zarządzanie nimi
• zatwierdzanie przebiegów potoków
• przewijaj wszystkie logi do początku, gdy pipeline jest nadal w toku
• stan zdrowia poszczególnych gałęzi pipeline'u.

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

Z radością udostępniamy funkcje CD YAML w usłudze Azure Pipelines. Oferujemy teraz zintegrowane doświadczenie z YAML, które umożliwia skonfigurowanie każdego z potoków do ciągłej integracji (CI), ciągłego wdrażania (CD) lub zarówno CI, jak i CD razem. Zaawansowane funkcje YAML CD wprowadzają kilka nowych możliwości dostępnych dla wszystkich zestawów przy użyciu wieloetapowych potoków YAML. Niektóre z najważniejszych elementów to:

• wieloetapowe potoki YAML (dla Ciągłej Integracji i Ciągłego Wdrażania)
• zatwierdzenia i sprawdzanie zasobów
• Środowiska i strategie wdrażania
• zasoby platformy Kubernetes i zasoby maszyn wirtualnych w środowisku
• Przeglądanie aplikacji na potrzeby współpracy
• Odnowiony interfejs użytkownika połączeń usług
• Zasoby w potokach YAML

Jeśli jesteś gotowy do rozpoczęcia budowania, zapoznaj się z dokumentacją lub blogiem w celu tworzenia wieloetapowych potoków CI/CD.

Zarządzanie zmiennymi pipeline'u w edytorze YAML

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

Zatwierdzaj wydania bezpośrednio z centrum wydań

Działanie w przypadku oczekujących zatwierdzeń stało się łatwiejsze. Wcześniej można było zatwierdzić wydanie, przechodząc na stronę szczegółów tego wydania. Teraz możesz zatwierdzać wydania bezpośrednio z centrum wydań.

Ulepszenia dotyczące rozpoczynania korzystania z potoków

Typowym pytaniem kreatora rozpoczynania pracy było możliwość zmiany nazwy wygenerowanego pliku. Obecnie jest obecny jako azure-pipelines.yml w głównym katalogu repozytorium. Teraz możesz zaktualizować ten plik, zmieniając jego nazwę lub lokalizację, zanim zapiszesz potok.

Na koniec będziesz mieć większą kontrolę podczas wprowadzania pliku azure-pipelines.yml do innej gałęzi, ponieważ możesz pominąć tworzenie pull requesta z tej gałęzi.

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

Dodaliśmy podgląd , ale nie włączamy trybu dla potoków YAML. Teraz możesz wypróbować pipeline YAML bez zatwierdzania go do repozytorium ani uruchamiania. Ten nowy interfejs API, uwzględniając istniejący pipeline i opcjonalny nowy ładunek YAML, zwróci Ci pełny pipeline 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 ciałem JSON w następującej formie:

{
  "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 zachować kontrolę nad harmonogramami wraz z potokiem w ramach kodu źródłowego.
2. Ekspresyjna: Masz większą wyrazistą moc w definiowaniu harmonogramów niż to, co było w stanie za pomocą interfejsu użytkownika. Na przykład łatwiej jest określić pojedynczy harmonogram, który uruchamia się co godzinę.
3. Standard branżowy: wielu deweloperów i administratorów zna już 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 uruchomienia w menu Uruchamianie potoku zapewnią podgląd nadchodzących kilku zaplanowanych uruchomień potoku, aby ułatwić diagnozowanie błędów z harmonogramami cron.

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

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

Oprócz odświeżenia doświadczenia użytkownika dodaliśmy również dwie funkcje, które są krytyczne dla korzystania z połączeń usług w potokach YAML: autoryzacje potoków oraz zatwierdzenia i kontrole.

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

Notatka

Planujemy wprowadzenie współdzielenia połączeń usługowych między projektami jako nowej funkcji. Więcej szczegółów na temat środowiska udostępniania i ról zabezpieczeń można znaleźć tutaj.

Pomijanie etapów w potoku YAML

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

Zaktualizowany panel rurociągu wykonywania przedstawia listę etapów pochodzących z pliku YAML, a Ty możesz pominąć jeden lub więcej z tych etapów. Podczas pomijania etapów należy zachować ostrożność. Jeśli na przykład pierwszy etap generuje pewne artefakty potrzebne do kolejnych etapów, nie należy pomijać pierwszego etapu. Panel uruchamiania wyświetla ogólne ostrzeżenie za każdym razem, gdy pomijasz etapy, które mają zależności podrzędne. Zostawiamy to tobie, czy te zależności są prawdziwymi zależnościami artefaktowymi, czy są one obecne tylko dla ustalenia kolejności wdrożeń.

Pomijanie etapu jest równoważne ponownemu wirowaniu zależności między etapami. Wszelkie natychmiastowe zależności podrzędne pominiętego etapu są zależne od nadrzędnego etapu pominiętego. Jeśli przebieg zakończy się niepowodzeniem i spróbujesz ponownie uruchomić nieudany etap, ta próba również będzie pomijana w ten sam sposób. Aby zmienić, które etapy są pomijane, musisz rozpocząć nowy przebieg.

Nowy interfejs użytkownika połączeń z 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 zawiera 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 zasobów potoku w oknie dialogowym tworzenia przebiegu

Dodaliśmy możliwość ręcznego pobrania wersji zasobów potoku w oknie dialogowym uruchamiania. Jeśli używasz przepływu jako zasobu w innym przepływie, możesz teraz wybrać wersję tego przepływu podczas tworzenia uruchomienia.

Ulepszenia CLI az dla usługi Azure Pipelines

Polecenia zarządzania grupami zmiennych potoków i zmiennymi

Przenoszenie potoków opartych na języku YAML z jednego projektu do innego może być trudne, ponieważ należy ręcznie skonfigurować zmienne potoku i grupy zmiennych. Jednak dzięki poleceniom zarządzania grupami zmiennych potoków i zmiennych , można teraz tworzyć skrypty do konfiguracji zmiennych potoku oraz grup zmiennych, które z kolei mogą być kontrolowane pod kątem wersji, co pozwala na łatwe udostępnianie instrukcji dotyczących przenoszenia i konfigurowania potoków między projektami.

Uruchom potok dla gałęzi pull requestu

Podczas tworzenia żądania ściągnięcia może być trudne zweryfikowanie, czy zmiany mogą spowodować zakłócenie działania pipeline'u w gałęzi docelowej. Jednak dzięki możliwości wyzwolenia uruchomienia potoku lub zainicjowania kompilacji dla gałęzi PR, można teraz zweryfikować i zwizualizować zmiany, uruchamiając go w docelowym potoku. Zobacz dokumentację poleceń dla az pipelines run i az pipelines build queue, aby uzyskać więcej informacji.

Pomiń pierwsze uruchomienie potoku

Podczas tworzenia potoków zdarza się, że chcemy utworzyć i zatwierdzić plik YAML, ale uniknąć uruchomienia potoku, ponieważ może to prowadzić do błędnego uruchomienia z różnych powodów - infrastruktura może nie być gotowa lub konieczne jest utworzenie i zaktualizowanie zmiennych czy grup zmiennych. Korzystając z interfejsu wiersza polecenia Azure DevOps, można teraz pominąć pierwsze automatyczne uruchomienie potoku przy jego tworzeniu, uwzględniając parametr --skip-first-run. Aby uzyskać więcej informacji, zobacz dokumentację polecenia az pipeline create.

Udoskonalenie 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 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ępniają zoptymalizowane polecenia — az devops service-endpoint github i az devops service-endpoint azurerm, które zapewniają wysokiej klasy wsparcie dla tworzenia punktów końcowych usługi dla tych typów. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją polecenia .

Zadania dotyczące wdrożeń

Zadanie wdrożenia jest specjalnym typem 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łać się do niego w zadaniu wdrażania.

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

• limit czasu w minutach — jak długo uruchamiać zadanie przed automatycznym anulowaniem
• cancelTimeoutInMinutes — ile czasu ma upłynąć przed zakończeniem zadań, które mają być uruchamiane zawsze, nawet jeśli zostały anulowane
• warunek — warunkowe uruchamianie zadania
• zmienne — wartości zakodowane na stałe można dodawać bezpośrednio lub do grup zmiennych, grup zmiennych wspieranych repozytorium Azure Key Vault, można odwołać się do zestawu zmiennych zdefiniowanych w pliku.
• continueOnError — jeśli przyszłe zadania powinny zostać uruchomione, 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łego wdrażania w potokach ciągłej integracji

Dodaliśmy obsługę szczegółów potoków YAML CD, gdzie potoki CI są określane jako zasoby potoku. W widoku uruchamiania potoku ciągłej integracji pojawi się teraz nowa karta "Skojarzone potoki", na której można znaleźć wszystkie uruchomienia potoków, które wykorzystują Twój potok i artefakty z niego.

Obsługa pakietów GitHub w potokach YAML

Niedawno wprowadziliśmy nowy typ zasobów o nazwie pakiety , który umożliwia korzystanie z pakietów NuGet i npm z usługi GitHub jako zasobu w potokach YAML. W ramach tego zasobu można teraz określić typ pakietu (NuGet lub npm), który ma być używany z usługi GitHub. Możesz również włączyć automatyczne wyzwalacze potoku 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

Notatka

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 getPackage makro, 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 usługi 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 przypisanych do przestrzeni nazw w klastrach usługi Azure Kubernetes Service.

pl-PL:

Filtry folderów wydania w subskrypcjach powiadomień

Foldery umożliwiają organizowanie potoków dla łatwiejszego odnajdywania i kontroli bezpieczeństwa. Często możesz chcieć skonfigurować niestandardowe powiadomienia e-mail dla wszystkich potoków wydania, reprezentowanych 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ń, takich jak ukończenie wdrożenia oraz oczekiwanie na zatwierdzenie , i uprościć subskrypcje.

Łączenie elementów roboczych z wieloetapowymi potokami YAML

Obecnie możesz automatycznie łączyć elementy robocze z kompilacjami klasycznymi. Jednak nie było to 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 został skompilowany kod 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ć.

Ponów nieudane etapy

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

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

Może to pomóc zaoszczędzić czas na kilka sposobów. Na przykład po uruchomieniu wielu zadań na etapie można chcieć, aby każdy etap uruchamiał testy na innej platformie. Jeśli testy na jednej platformie kończą się niepowodzeniem, podczas gdy inne przechodzą, możesz zaoszczędzić czas, nie uruchamiając ponownie przekazanych zadań. W innym przykładzie etap wdrażania mógł zakończyć się niepowodzeniem z powodu niestabilnego połączenia sieciowego. Ponowne próby na tym etapie pomogą zaoszczędzić czas, ponieważ nie trzeba tworzyć nowej kompilacji.

Istnieje kilka znanych luk w tej funkcji. Na przykład nie można ponowić etapu, który został jawnie anulowany. 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 uzyskiwać ręczne zatwierdzenia przed etapem w każdym potoku zanim zostaną wdrożone. Dzięki pełnej segregacji ról między właścicielami infrastruktury (środowiska) a aplikacji (potoku), zapewnisz ręczną akceptację wdrożeń w określonym potoku oraz uzyskasz centralną kontrolę nad stosowaniem tych samych sprawdzeń we wszystkich wdrożeniach do środowiska.

Uruchomienia potoku wdrażane do środowiska deweloperskiego zatrzymają się na początku etapu w celu zatwierdzenia.

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

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ższe działanie. Zwiększyliśmy również częstotliwość otwierania bramy do co 30 minut.

Szablon nowego obrazu kompilacji dla pliku Dockerfile

Wcześniej podczas tworzenia nowego potoku dla Dockerfile, szablon zalecał przesyłanie obrazu do usługi Azure Container Registry i wdrażanie na Azure Kubernetes Service. Dodaliśmy nowy szablon, który pozwala na utworzenie obrazu przy użyciu agenta, bez potrzeby przesyłania go do rejestru kontenerów.

Nowe zadanie konfigurowania ustawień aplikacji usługi Azure App Service

Usługa Azure App Service umożliwia konfigurację za pośrednictwem różnych ustawień , takich jak ustawienia aplikacji, parametry połączenia i inne ogólne ustawienia konfiguracji. Mamy teraz nowe zadanie Azure Pipelines Ustawienia Azure App Service, które obsługują zbiorcze konfigurowanie tych ustawień przy użyciu składni JSON w aplikacji internetowej lub w którymkolwiek z jej slotów wdrożeniowych. Tego zadania można używać wraz z innymi zadaniami usługi App Service, aby wdrożyć, zarządzać i konfigurować aplikacje internetowe, aplikacje funkcji lub inne konteneryzowane usługi App Services.

Usługa Azure App Service obsługuje teraz funkcję zamiany w wersji zapoznawczej

Usługa Azure App Service teraz obsługuje funkcję Swap w wersji zapoznawczej na swoich miejscach wdrożeniowych. Jest to dobry sposób na zweryfikowanie aplikacji z konfiguracją produkcyjną przed faktycznym zamienieniem jej z slotu testowego na slot produkcyjny. Zapewni to również, że miejsce docelowe/produkcyjne nie doświadczy przestoju.

Zadanie usługi Azure App Service obsługuje teraz wielofazowe przełączanie za pomocą następujących nowych akcji:

• Rozpocznij zamianę z podglądem — inicjuje zamianę z podglądem (zamiana wielofazowa) i stosuje konfigurację miejsca docelowego (na przykład miejsce produkcyjne) do miejsca źródłowego.
• Zakończ zamianę z podglądem — gdy jesteś gotowy na ukończenie oczekującej zamiany, wybierz opcję Zakończ zamianę z podglądem.
• Anuluj zamianę za pomocą wersji zapoznawczej — aby anulować oczekującą zamianę, wybierz pozycję Anuluj zamianę z wersją zapoznawczą.

Filtr poziomu etapu dla artefaktów usługi Azure Container Registry i Docker Hub

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

Udoskonalenia procesów zatwierdzania w potokach YAML

Włączyliśmy konfigurowanie zatwierdzeń połączeń usług i pul agentów. W przypadku zatwierdzeń stosujemy segregację ról między właścicielami infrastruktury a deweloperami. Konfigurując zatwierdzenia dla zasobów, takich jak środowiska, połączenia usług i pule agentów, będziesz mieć pewność, że wszystkie uruchomienia potoków używające zasobów będą wymagały uprzedniego zatwierdzenia.

Doświadczenie jest podobne do konfigurowania zatwierdzeń dla środowisk. Gdy oczekuje się zatwierdzenia zasobu odniesionego w 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, a tym samym zapotrzebowanie na niezawodne testowanie i walidację. 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żna zweryfikować strukturę obrazu na podstawie czterech kategorii testów, które można uruchomić razem: testy poleceń, testy istnienia plików, testy zawartości plików i testy metadanych. Możesz użyć wyników w procesie, aby podjąć decyzje o kontynuacji lub przerwaniu. Dane testowe są dostępne w przebiegu potoku z komunikatem o błędzie, aby ułatwić rozwiązywanie problemów z błędami.

Wprowadź szczegóły pliku konfiguracji i obrazu

Testowanie danych i podsumowanie

Dekoratory potoków wdrożeniowych

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 ona wszystkich potoków w kolekcji.

Od dłuższego czasu wspieramy dekoratory dla kompilacji i potoków YAML, a klienci używają ich do centralnego zarządzania krokami w swoich zadaniach. Teraz rozszerzamy również obsługę potoków wydań. Możesz utworzyć rozszerzenia, aby dodać kroki przeznaczone dla nowego punktu współtworzenia, a następnie będą one dodawane 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. Ułatwi to wspólne wdrożenie zestawu zasobów i umieszczenie ich w różnych grupach zasobów lub w różnych 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 i włączać wyzwalacze zakończenia potoku. W wieloetapowych potokach YAML wprowadzamy pipelines jako zasób. W języku YAML możesz teraz odwoływać się do innego potoku, a także włączyć wyzwalacze CD.

Oto szczegółowy schemat YAML dla zasobu pipelinó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 źródło potoku, używając zadania - download.

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.

Orkiestracja strategii kanaryjnego wdrożenia w środowisku 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. Environment wprowadzono jako nowatorską koncepcję pierwszej klasy, umożliwiającą orkiestrację strategii wdrażania i ułatwiającą wydania bez przestojów. Wcześniej obsługiwaliśmy strategię runOnce, która wykonała kroki sekwencyjnie. Dzięki obsłudze strategii kanarowej w potokach wieloetapowych można teraz zmniejszyć ryzyko, powoli wdrażając zmianę w małym podzestawie. Gdy zyskujesz większą pewność co do nowej wersji, możesz zacząć wdrażać ją na większej infrastruktury serwerów 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 kanarkowej dla Kubernetes najpierw wdroży zmiany z 10 zasobnikami%, a następnie 20%, monitorując stan podczas postRouteTraffic. Jeśli wszystko pójdzie dobrze, zostanie podniesione do 100%.

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

Zasady zatwierdzania dla potoków YAML

W potokach YAML stosujemy konfigurację zatwierdzania, które jest kontrolowane przez właściciela zasobu. Właściciele zasobów konfigurują zatwierdzenia zasobów oraz wszystkich potoków, które zatrzymują się na zatwierdzenie przed rozpoczęciem etapu, który korzysta z zasobu. Właściciele aplikacji opartych na protokole SOX często ograniczają osoby żądające wdrożenia od zatwierdzania własnych wdrożeń.

Teraz możesz użyć zaawansowanych opcji zatwierdzania, aby skonfigurować zasady zatwierdzania, takie jak wnioskodawca nie powinien zatwierdzać, wymagać zatwierdzenia przez wybraną grupę użytkowników oraz limit czasu na zatwierdzenie.

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 za każdym razem, gdy zostanie opublikowany nowy obraz, 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 obrazów usługi ACR można uzyskać przy użyciu wstępnie zdefiniowanych zmiennych. Poniższa lista zawiera zmienne ACR dostępne do zdefiniowania zasobu kontenerowego 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 funkcję sprawdzania artefaktu , aby ułatwić dodawanie zasad z listy standardowych definicji polityk. Definicja zasad zostanie wygenerowana automatycznie i dodana do konfiguracji kontrolnej, którą można zaktualizować 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>']]
• Strategia kanarek: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Dla strategii toczącej się : $[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 o tym, jak ustawić zmienną wyjściową dla wielu prac

Unikaj wycofywania zmian krytycznych

W klasycznych pipeline'ach wydania często polega się na zaplanowanych wdrożeniach regularnych aktualizacji. Jeśli jednak masz poprawkę krytyczną, możesz rozpocząć ręczne wdrażanie poza pasmem. W związku z tym starsze wersje nadal pozostają w harmonogramie. 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 teraz go rozwiązaliśmy. Po rozwiązaniu problemu wszystkie starsze zaplanowane wdrożenia w środowisku zostaną anulowane po ręcznym uruchomieniu wdrożenia. Ma to zastosowanie tylko wtedy, gdy opcja kolejkowania jest wybrana jako "Wdróż najnowszą i anuluj inne".

Uproszczona autoryzacja zasobów w potokach YAML

Zasób to wszystko, co jest używane przez potok, a znajduje się poza potokiem. Zasoby muszą być autoryzowane, zanim będą mogły być używane. Wcześniej w przypadku korzystania z nieautoryzowanych zasobów w potoku YAML wystąpił błąd autoryzacji zasobu. Musiałeś autoryzować zasoby ze strony podsumowania przebiegu, który zakończył się niepowodzeniem. Ponadto potok przetwarzania nie powiódł się, jeśli używał zmiennej, która odwoływała się do nieautoryzowanego zasobu.

Teraz ułatwiamy zarządzanie autoryzacjami zasobów. Zamiast, aby przebieg zakończył się niepowodzeniem, będzie on czekać na uprawnienia do zasobów na początku etapu korzystającego z zasobu. Właściciel zasobu może wyświetlić przepływ i przyznać dostęp do zasobu na stronie Zabezpieczeń.

Ocena weryfikacji artefaktów

Teraz możesz zdefiniować zestaw zasad i dodać ocenę zasad jako kontrolę środowiska dla artefaktów obrazu kontenera. Po uruchomieniu potoku wykonanie jest wstrzymywane przed rozpoczęciem etapu korzystającego ze środowiska. Określone zasady są oceniane względem dostępnych metadanych dla wdrażanego obrazu. Sprawdzanie przechodzi, gdy polityka odniosła sukces, i oznacza etap jako niepowodzenie, jeśli sprawdzanie zakończy się niepowodzeniem.

Aktualizacje zadania wdrażania szablonu usługi ARM

Wcześniej nie filtrowaliśmy połączeń usług w zadaniu wdrażania szablonu 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 w celu filtrowania połączeń usług o niższym zakresie na podstawie wybranego zakresu wdrożenia.

RecenzjaAplikacji w środowisku

ReviewApp wdraża każde pull request z repozytorium Git w dynamiczne środowisko zasobowe. Recenzenci mogą zobaczyć, jak te zmiany wyglądają, a także pracować z innymi usługami zależnymi przed ich scaleniem z gałęzią główną i wdrożeniem w środowisku produkcyjnym. Ułatwi to tworzenie i zarządzanie zasobami aplikacji reviewApp oraz korzystanie ze wszystkich możliwości śledzenia i diagnostyki funkcji środowiska. Korzystając ze 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 kanału

Teraz możesz włączyć automatyczne i ustalone przez użytkownika zbieranie metadanych z zadań w potoku. Metadane umożliwiają wymuszanie zasad artefaktów w środowisku przy użyciu oceny sprawdzania artefaktu.

Wdrażanie maszyn wirtualnych w kontekście środowisk

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 koordynować wdrożenia na wielu maszynach i wykonywać stopniowe aktualizacje z użyciem potoków YAML. Agenta można również zainstalować na każdym z serwerów docelowych bezpośrednio i przeprowadzić wdrożenie 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 w zestawie maszyn (zestaw kroczący) w każdej iteracji.

Na przykład, w poniższym procesie wdrażania sekwencyjnego, aktualizowane jest maksymalnie pięć 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 obiektów 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...

Nota

Dzięki tej aktualizacji wszystkie dostępne artefakty z bieżącego potoku i skojarzonych zasobów potoku są pobierane tylko w cyklu życia deploy. Można jednak wybrać pobranie, określając zadanie Pobierz artefakt potoku. Istnieje kilka znanych luk w tej funkcji. Na przykład, gdy ponownie uruchomisz etap, wdrożenie zostanie powtórzone na wszystkich maszynach wirtualnych, a nie tylko na tych, które zakończyły się niepowodzeniem. Pracujemy nad zamknięciem tych luk w przyszłych aktualizacjach.

Dodatkowa kontrola wdrożeń

Usługa Azure Pipelines od jakiegoś czasu obsługuje wdrożenia kontrolowane za pomocą ręcznych zatwierdzeń. Dzięki najnowszym ulepszeniom masz teraz dodatkową kontrolę nad wdrożeniami. Oprócz zatwierdzeń właściciele zasobów mogą teraz dodawać zautomatyzowane checks, aby zweryfikować zasady zabezpieczeń i jakości. Te kontrole mogą być używane do wywoływania operacji, a następnie czekania na ich zakoń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żdej kontroli może być okresowo powtarzana zgodnie z określonym interwałem ponawiania prób . 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
• Wyszukiwanie reguł Azure Monitor dla aktywnych alertów
• Upewnij się, że pipeline rozszerza co najmniej jeden szablon YAML lub więcej szablonów YAML.

Powiadomienie o zatwierdzeniu

Po dodaniu zatwierdzenia do środowiska lub połączenia z usługą wszystkie potoki wieloetapowe, które używają zasobu, automatycznie czekają na zatwierdzenie na początku etapu. Wyznaczone osoby zatwierdzające muszą ukończyć zatwierdzenie, zanim rurociąg będzie mógł kontynuować.

Dzięki tej aktualizacji osoby zatwierdzające otrzymują powiadomienie e-mail dotyczące oczekującego zatwierdzenia. Użytkownicy i właściciele zespołów mogą zrezygnować z subskrypcji niestandardowych lub skonfigurować je przy użyciu ustawień powiadomień .

Konfigurowanie strategii wdrażania w witrynie Azure Portal

Dzięki tej funkcji ułatwiliśmy konfigurację potoków, które wykorzystują strategię wdrażania według twojego wyboru, na przykład Rolling, Canarylub Blue-Green. Korzystając z tych wbudowanych strategii, możesz wdrażać aktualizacje w bezpieczny sposób i ograniczać powiązane zagrożenia związane z wdrażaniem. Aby uzyskać dostęp do tego, 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 Azure DevOps, w którym zostanie utworzony potok. Będziesz także musiał wybrać grupę wdrożenia, potok kompilacji publikujący pakiet do wdrożenia oraz preferowaną strategię wdrażania. Kontynuując, zostanie skonfigurowany w pełni funkcjonalny pipeline, który wdraża wybrany pakiet na 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 skryptów i zadań w czasie wykonywania
• Kontrolowanie typów parametrów, dozwolonych zakresów i wartości domyślnych
• 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 pipelines można rozbić na szablony, sprzyjając ponownemu wykorzystaniu i zmniejszając zbędny kod. 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 pipeline. Plik root YAML może teraz używać słowa kluczowego extends, aby wskazać, że główną strukturę potoku można znaleźć w innym pliku. Dzięki temu możesz kontrolować, które segmenty można rozszerzyć lub zmienić oraz jakie segmenty są stałe. Ulepszyliśmy również parametry potoku za pomocą typów danych, aby wyjaśnić dostępne zaczepy, które możesz dostarczyć.

W tym przykładzie pokazano, jak można udostępnić proste zaczepienia dla autora potoku do użycia. Szablon będzie zawsze uruchamiał kompilację, opcjonalnie uruchomi dodatkowe kroki określone w ciągu pipeline, a następnie opcjonalnie uruchomi 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 można zastąpić 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 uruchomienia. Chociaż autor rurociągu może oznaczyć pewne zmienne jako _settable at queue time_, system tego nie wymuszał, ani nie uniemożliwiał ustawiania innych zmiennych. Innymi słowy, to ustawienie było używane tylko do pobierania dodatkowych danych wejściowych podczas uruchamiania nowej operacji.

Dodaliśmy nowe ustawienie kolekcji wymuszające parametr _settable at queue time_. Dzięki temu możesz kontrolować, które zmienne można zmienić przy rozpoczynaniu nowego zadania. W przyszłości nie można zmienić zmiennej, która nie jest oznaczona przez autora jako _settable at queue time_.

Notatka

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 pipeline YAML

Zmienne umożliwiają wygodne pobieranie 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 wdrażania.
• Environment.ResourceName — nazwa zasobu w środowisku, do którego odnosi się zadanie wdrożenia.

Wyewidencjonuj wiele repozytoriów

Potoki często korzystają z wielu repozytoriów. Możesz mieć różne repozytoria ze źródłem, narzędziami, skryptami lub innymi elementami, które należy skompilować. Wcześniej trzeba było dodać te repozytoria jako moduły podrzędne lub jako skrypty ręczne, aby wykonać git checkout. Teraz możesz pobrać dane z i pracować z innymi repozytoriami, oprócz tego, którego używasz do przechowywania pipeline YAML.

Jeśli na przykład masz repozytorium o nazwie MyCode z potokiem YAML i drugim repozytorium o nazwie Tools, 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.

Obsługiwane są repozytoria Git usługi Azure Repos. Aby uzyskać więcej informacji, zobacz wyewidencjonowanie z wielu repozytoriów.

Uzyskiwanie szczegółów podczas działania programu dotyczących wielu repozytoriów

Po uruchomieniu potoku usługa Azure Pipelines dodaje informacje o repozytorium, gałęzi i zatwierdzeniu, 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 repozytorium do innych kolekcji usługi Azure Repos

Wcześniej podczas odwoływania się do repozytoriów w potoku YAML wszystkie repozytoria usługi 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 zawiera poświadczenia, które mogą uzyskiwać dostęp do repozytorium w innym projekcie. Oba repozytoria, self i otherrepo, zostaną wyewidencjonowane.

Ważny

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

Metadane zasobów potoku jako wstępnie zdefiniowane zmienne

Dodaliśmy wstępnie zdefiniowane zmienne dla zasobów stosowanych w potokach YAML. 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 'bake' w zadaniu KubernetesManifest

kustomize (część rozwiązania Kubernetes sig-cli) umożliwia dostosowanie nieprzetworzonych, bez szablonów plików YAML do wielu celów i pozostawienie oryginalnego nietkniętego kodu YAML. 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 na potrzeby wdrożeń. Spowodowało to interaktywne monity logowania i błędy w potokach 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ń dotyczących wydania na GitHubie

Wprowadziliśmy kilka ulepszeń do zadania wydania na GitHubie. 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 dotyczącej konfiguracji dziennika zmian można teraz określić wydanie, względem którego ma być porównywana bieżąca wersja. Porównanie do wersji może dotyczyć ostatniej pełnej wersji (z wyłączeniem wersji wstępnych), ostatniej wersji nienależącej do wersji roboczych lub jakiejkolwiek poprzedniej wersji pasującej do podanego tagu wydania. Ponadto zadanie udostępnia pole typu changelog w celu sformatowania dziennika zmian. Na podstawie zaznaczenia dziennik zmian wyświetli listę zatwierdzeń lub listę problemów/żądania ściągnięcia podzielone na kategorie na podstawie etykiet.

Zadanie instalacji Open Policy Agent

Open Policy Agent to open source'owy, uniwersalny silnik polityki, który umożliwia ujednolicone i kontekstowe egzekwowanie zasad. Dodaliśmy zadanie instalatora Open Policy Agent. Jest to szczególnie przydatne do egzekwowania zasad w ramach potoku przy użyciu podejścia Infrastructure as Code.

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

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

Obsługa skryptów PowerShell w zadaniu Azure CLI

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

Wdrożenia kanarkowe oparte na Interfejsie Service Mesh w zadaniu KubernetesManifest

Wcześniej, gdy strategia kanaryczna została określona w zadaniu KubernetesManifest, zadanie tworzyłoby obciążenia bazowe i kanary, których repliki były równe procentowi replik używanych na potrzeby stabilnych obciążeń. Nie było to dokładnie to samo, co dzielenie ruchu do osiągnięcia żądanej wartości procentowej na poziomie zapytań. Aby rozwiązać ten problem, dodaliśmy obsługę Interfejsu Service Mesh wdrożeń kanarowych do zadania KubernetesManifest.

Abstrakcja interfejsu siatki usług umożliwia konfigurację typu plug-and-play z dostawcami siatki usług, takimi jak Linkerd i Istio. Teraz zadanie KubernetesManifest zabiera ciężką pracę mapowania obiektów SMI TrafficSplit do stabilnych, bazowych i kanarowych 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 stopniowy.

- 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 przepływie pracy dla kompilacji lub wdrożenia, aby kopiować pliki do obiektów blob w magazynie Microsoft lub maszyn wirtualnych Microsoftu. Zadanie używa narzędzia AzCopy, kompilowania narzędzia wiersza polecenia w celu szybkiego kopiowania danych z kont magazynu i do kont usługi Azure Storage. Dzięki tej aktualizacji dodaliśmy obsługę narzędzia AzCopy w wersji 10, która jest najnowszą wersją narzędzia AzCopy.

Polecenie azcopy copy obsługuje tylko argumenty skojarzone z nim. 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. Należą do nich:

• Określanie lokalizacji dziennika
• Czyszczenie plików dziennika i planu po kopii
• Wznowienie kopiowania, jeśli zadanie się nie powiedzie

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
• Ustawianie poziomu szczegółowości dziennika dla pliku dziennika przez przekazanie argumentu

Zwiększ bezpieczeństwo pipelines, ograniczając zakres 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żyjemy tokenu dostępu, aby uzyskać kod źródłowy, przekazać dzienniki, wyniki testów, artefakty lub wykonać wywołania 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 spoza projektu zespołowego

  Do tej pory domyślnym zakresem dla wszystkich potoków była kolekcja projektów zespołu. Można zmienić zakres, aby był projektem zespołowym w klasycznych potokach kompilacji. Nie masz jednak tej kontroli dla klasycznych potoków wydania ani potoków YAML. Dzięki tej aktualizacji wprowadzamy ustawienie w ramach kolekcji, wymuszające przypisanie tokenu z zakresem projektu do każdego zadania, niezależnie od skonfigurowanych ustawień 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.

  Notatka

  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 zminimalizować awarie potoku, możesz jawnie przyznać kontu usługi budowania projektu dostęp do żądanego zasobu. Zdecydowanie zalecamy włączenie tych ustawień zabezpieczeń.

• Ogranicz zakres dostępu do 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 w przypadku wycieku tokenu dostępu do potoku, będzie można zobaczyć tylko repozytorium/repozytoria używane w tym potoku. Wcześniej token dostępu był dobry dla dowolnego repozytorium usługi 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 tę opcję włączyć w Ustawienia kolekcji>Rurociągi>Ustawienia. W przypadku korzystania z tej funkcji wszystkie repozytoria wymagane przez kompilację (nawet te klonowane przy użyciu skryptu) muszą być uwzględnione w zasobach repozytorium potoku.

• Usuń pewne uprawnienia dla tokenu dostępu

  Domyślnie udzielamy wielu uprawnień do tokenu dostępu. Jednym z tych uprawnień jest uruchamianie kompilacji w kolejce. Dzięki tej aktualizacji usunęliśmy to uprawnienie do tokenu dostępu. Jeśli potoki potrzebują tego uprawnienia, możesz jawnie przyznać je konto usługi kompilacji projektu lub konto usługi budowania kolekcji projektów w zależności od tokenu, którego używasz.

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 wartości docelowej kroków i izolacja poleceń

Usługa Azure Pipelines obsługuje uruchamianie zadań w kontenerach lub na hoście agenta. Wcześniej całe zadanie było przypisane do jednego 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 pipeline może uruchamiać każdy krok w wyspecjalizowanym, kontenerze stworzonym do konkretnego celu.

Kontenery mogą działać jako granice izolacji, uniemożliwiając kodowi wprowadzanie nieoczekiwanych zmian na maszynie hosta. Sposób, w jaki kroki komunikują się z agentem i uzyskują dostęp do jego usług, nie jest wpływany przez izolowanie kroków w kontenerze. W związku z tym wprowadzamy również tryb ograniczeń poleceń, którego można używać z celami 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 załączać logów, przekazywać artefaktów ani wykonywać 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 były nadpisywane przez zadanie, a kolejne zadania przyjmowały nową wartość. Dzięki tej aktualizacji zaostrzymy zabezpieczenia wokół zmiennych potoku w celu tworzenia zmiennych systemowych i zmiennych czasu kolejki tylko do odczytu. Ponadto można utworzyć zmienną YAML tylko do odczytu, oznaczając ją w następujący sposób.

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

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

Dodaliśmy dostęp oparty na rolach dla połączeń usług. Wcześniej zabezpieczenia połączenia usługi można było zarządzać tylko za pośrednictwem wstępnie zdefiniowanych grup usługi Azure DevOps, takich jak administratorzy punktów końcowych i twórcy punktów końcowych.

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ą one dziedziczone przez poszczególne połączenia. W ramach każdego połączenia z usługą możesz włączyć lub wyłączyć dziedziczenie oraz nadpisać role w jego zakresie.

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

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

Włączyliśmy obsługę współdzielenia połączeń serwisowych między projektami. Teraz możesz bezpiecznie udostępniać swoje połączenia usługowe swoim projektom.

Dowiedz się więcej na temat udostępniania połączeń usług tutaj.

Możliwość śledzenia potoków i zasobów usługi ACR

Zapewniamy pełną możliwość śledzenia E2E, gdy potoki i zasoby kontenerowe ACR są używane w jednym potoku. Dla każdego zasobu używanego przez potok YAML można śledzić zatwierdzenia, elementy robocze i artefakty.

W widoku podsumowania przebiegu potoku można zobaczyć:

• Wersja zasobu , która wyzwoliła przebieg. Teraz można uruchomić potok po zakończeniu innego uruchomienia potoku w Azure lub po przesłaniu obrazu kontenera do ACR.

  

• zatwierdza używane przez potok. Możesz również znaleźć podział commitów w zależności od zużytego zasobu przez potok.

  

• Elementy robocze , które są skojarzone z każdym zasobem używanym przez pipeline.

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

  

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

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 podczas wykonywania 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 przebiegu 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 wykorzystanie wszystkich dostępnych danych do rozwiązywania problemów z testami, które zakończyły się niepowodzeniem.

W dziennikach może pojawić się zadanie VSTest lub zadanie publikacji wyników testów zwracające błąd 403 lub 407. Jeśli używasz własnych serwerowych kompilacji lub agentów wydania za zaporą sieciową, która filtruje żądania wychodzące, musisz wprowadzić pewne zmiany konfiguracji, aby móc korzystać z tej funkcjonalności. ​

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

Notatka

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ż prawidłowe informacje o puli w każdym zadaniu

Wcześniej, gdy używano macierzy do rozwijania zadań lub zmiennej do identyfikacji puli, czasami wprowadzaliśmy nieprawidłowe informacje o puli w logach. Te problemy zostały rozwiązane.

Wyzwalacze CI dla nowych gałęzi

To od dawna zgłaszane żądanie, aby nie uruchamiać procesu ciągłej integracji po utworzeniu nowej gałęzi, jeśli w tej gałęzi 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, jeśli filtr gałęzi pasuje do nazwy 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 — app i docs. Skonfigurowałeś filtr ścieżki dla CI tak, aby odpowiadał folderowi "app". Innymi słowy, nie chcesz tworzyć nowej kompilacji, jeśli zmiana została wypchnięta do dokumentacji. Tworzysz nową gałąź lokalnie, wprowadzasz pewne zmiany w dokumentacji, a następnie wypychasz gałąź do serwera. Kiedyś uruchamialiśmy nowy proces ciągłej integracji. Jest to niepożądane, ponieważ zostałeś poproszony o niewyszukiwanie zmian w folderze dokumentacji. Jednak ze względu na sposób, w jaki zarządzaliśmy nowym zdarzeniem gałęzi, może się wydawać, że wprowadzono zmianę w folderze aplikacji.

Teraz mamy lepszą metodę zarządzania ciągłą integracją dla nowych gałęzi, aby rozwiązać te problemy. Podczas publikowania nowej gałęzi jawnie wyszukujemy nowe zatwierdzenia 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 w różnych etapach w potoku opartym na języku YAML. Ułatwia to przekazywanie przydatnych informacji, takich jak decyzja go/no-go lub identyfikator wygenerowanego wyniku, od jednego etapu do następnego. Wynik (stan) poprzedniego etapu i jego zadania są również dostępne.

Zmienne wyjściowe są nadal generowane przez kroki w ramach zadań. Zamiast odwoływać się do dependencies.jobName.outputs['stepName.variableName'], etapy odnoszą się do stageDependencies.stageName.jobName.outputs['stepName.variableName'].

Notatka

Domyślnie każdy krok w pipeline zależy od tego, który go bezpośrednio poprzedza w pliku YAML. W związku z tym każdy etap może używać zmiennych wyjściowych z poprzedniego etapu. Możesz zmienić graf 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łącz automatyczne aktualizacje 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 dodamy 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 zakończą się niepowodzeniem, wyświetlając jasny komunikat o błędzie, zamiast żądać aktualizacji agentów. Ta funkcja jest szczególnie interesująca dla klientów z własnymi pulami i bardzo rygorystycznymi wymaganiami dotyczącymi kontroli zmian. Aktualizacje automatyczne są domyślnie włączone i nie zalecamy, aby większość klientów je wyłączał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

Integracja usług z potokami YAML jest teraz łatwiejsza. Za pomocą zdarzeń hooków usługi dla potoków YAML możesz teraz sterować działaniami w niestandardowych aplikacjach lub usługach w oparciu o postęp uruchomień potoków. Możesz na przykład utworzyć zgłoszenie do helpdesku, gdy jest wymagane zatwierdzenie, zainicjować przepływ monitorowania po zakończeniu etapu lub wysłać powiadomienie push na mobilne urządzenia zespołu, gdy etap zakończy się niepowodzeniem.

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

Integracja z Optimizely

Optimizely to potężna platforma testowania A/B i zarządzania funkcjami dla zespołów produktowych. Integracja usługi Azure Pipelines z platformą Optimizely umożliwia zespołom produktowym testowanie, uczenie się i wdrażanie w przyspieszonym tempie, przy jednoczesnym uzyskaniu wszystkich korzyści DevOps z 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 wycofywać je przy użyciu usługi Azure Pipelines.

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

Dodaj wydanie GitHub jako źródło artefaktów

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

Po kliknięciu Dodaj artefakt w definicji potoku wydania zostanie wyświetlony nowy typ źródła GitHub Release. 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ę wydania GitHub do użycia jako najnowszą, wersję oznaczoną określonym tagiem lub wybrać podczas tworzenia wydania. Po przypisaniu wydania w GitHub, jest automatycznie pobierane i udostępniane w zadaniach wydania.

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

Terraform to narzędzie typu open source do bezpiecznego i wydajnego tworzenia, zmieniania i przechowywania wersji infrastruktury. Terraform przekształca interfejsy API w deklaratywne pliki konfiguracyjne, co umożliwia definiowanie i aprowizowanie infrastruktury za pomocą 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 o rozszerzeniu Terraform, zobacz 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. przychody, czas trwania sesji, wskaźnik odbicia). Te działania umożliwiają zidentyfikowanie zmian, które warto wdrożyć w oparciu o bezpośredni wpływ na wydajność funkcji.

Rozszerzenie do eksperymentów Google Analytics dla 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, korzystając ze wszystkich zalet DevOps oferowanych przez Azure Pipelines.

Rozszerzenie eksperymentów 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 protokołu OAuth i uwierzytelniania podstawowego. Ponadto można teraz skonfigurować zaawansowane kryteria powodzenia, co pozwala na wykorzystanie dowolnej właściwości zmiany do określenia wyniku bramy.

Tworzenie usługi Azure Pipelines z poziomu 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.

Niestabilne zarządzanie błędami i rozwiązywanie problemów.

Wprowadziliśmy zarządzanie testami o niestabilnym charakterze w celu wsparcia kompleksowego cyklu życia, poprzez wykrywanie, raportowanie i rozwiązywanie problemów. Aby dodatkowo to udoskonalić, dodajemy zarządzanie i rozwiązywanie problemów niestabilnych testów.

Podczas badania niestabilnego testu można utworzyć błąd przy użyciu akcji Błąd, który następnie można przypisać deweloperowi, aby dokładniej zbadać główną przyczynę niestabilnego testu. Raport o błędach zawiera informacje o potoku danych, takie jak komunikat o błędzie, ścieżka stosu i inne informacje powiązane z testem.

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

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 w danych wejściowych użytkownika lub w adapterze testowym mogą prowadzić do sytuacji, gdy testy nie są wykrywane i uruchamiany jest jedynie podzbiór oczekiwanych testów. Może to prowadzić do sytuacji, w których potoki odnoszą sukcesy nie dlatego, że kod jest wystarczająco wysokiej jakości, ale dlatego, że testy są pomijane. 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 wykonane.

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 na potrzeby 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.

Automatyczne wstrzykiwanie kroków w zadaniu wdrożenia za pomocą dekoratorów potoków

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 wykonywania każdego haka cyklu życia każdej pracy wdrożeniowej. Ponieważ dekoratory potoków można stosować do wszystkich potoków w kolekcji, można je wykorzystać do egzekwowania bezpiecznych praktyk wdrażania.

Ponadto zadania wdrażania można uruchamiać jako zadanie kontenera wraz z kontenerem pomocniczym , jeśli jest zdefiniowany.

Plany testów

Strona nowego planu testowego

Nowa strona planów testów (plany testów *) jest dostępna dla wszystkich kolekcji usługi Azure DevOps. Nowa strona zawiera usprawnione widoki ułatwiające skoncentrowanie się na zadaniu — planowanie testów, tworzenie lub wykonywanie. Jest ona również pozbawiona zbędnych elementów i spójna z resztą oferty Azure DevOps.

Pomóż mi zrozumieć nową stronę

strona przeglądu planu testów

Nowa strona Planów testów zawiera łącznie 6 sekcji, z których pierwsze 4 są nowe, podczas gdy sekcje Wykresy & rozszerzalności są istniejącymi funkcjami.

1. nagłówek planu testowego: służy do lokalizowania, dodawania do ulubionych, edytowania, kopiowania lub klonowania planu testowego.
2. Drzewo zestawów testów: Służy do dodawania, zarządzania, eksportowania lub zamawiania zestawów testów. Skorzystaj z tego, aby przypisać konfiguracje i przeprowadzić testowanie akceptacyjne użytkowników.
3. Definiuj kartę: zestawianie, dodawanie i zarządzanie przypadkami testowymi w wybranym zestawie testów za pomocą tej karty.
4. karta Wykonaj: przypisz i wykonaj testy za pomocą tej karty lub znajdź wynik testu, aby przejść do szczegółów.
5. karta Wykres: śledzenie wykonywania testów i stanu za pomocą wykresów, które mogą być również przypięte do pulpitów nawigacyjnych.
6. rozszerzalność: obsługuje bieżące punkty rozszerzalności produktu.

Przyjrzyjmy się ogólnie tym nowym sekcjom poniżej.

1. nagłówek planu testów

strona nagłówka planu testów

Zadania

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

• Oznaczanie planu testowego jako ulubionego
• Anulowanie oznaczania ulubionego planu testowego
• Łatwe nawigowanie między ulubionymi planami testów
• Wyświetl ścieżkę iteracji planu testów, która wyraźnie wskazuje, czy plan testu jest Bieżący czy Przeszły.
• Wyświetlanie szybkiego podsumowania raportu Postępu testu z linkiem umożliwiającym przejście do raportu
• Przejdź z powrotem do strony Wszystkie/Plany testów kopalni

opcje menu kontekstowego

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

• Kopiuj plan testu: jest to nowa opcja umożliwiająca szybkie skopiowanie bieżącego planu testu. Więcej szczegółów znajduje się poniżej.
• Edytuj plan testu: ta opcja umożliwia edytowanie formularza elementu roboczego planu testów 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ść)

strona kopiowania planu testowego

Zalecamy utworzenie nowego planu testowego na każdy sprint lub wydanie. Ogólnie rzecz biorąc, plan testów 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żesz skopiować lub sklonować plany testów. Jego interfejs API REST jest omówiony tutaj, a interfejs API umożliwia kopiowanie/klonowanie planu testu między projektami.
Aby uzyskać więcej wskazówek dotyczących użycia planów testów, zobacz tutaj.

2. Drzewo pakietów testowych

strona drzewa zestawów testowych

Zadania

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

• rozwiń/zwiń: ta opcja paska narzędzi umożliwia rozwinięcie lub zwinięcie drzewa hierarchii pakietu.
• Pokaż punkty testowe z zestawów podrzędnych: ta opcja paska narzędzi jest widoczna tylko wtedy, gdy znajdujesz się 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.
• Zestawy testowe: można przeciągać i upuszczać pakiety testowe, aby zmienić kolejność ich hierarchii lub przenieść je z jednej hierarchii pakietów do innej w ramach planu testowego.

opcje menu kontekstowego

Menu kontekstowe w drzewie zestawów testów dostarcza następujące opcje:

• Utwórz nowe zestawy: 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 zestawu 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 systemu do dynamicznego organizowania przypadków testowych, które spełniają kryteria zapytania.
• Przypisz konfiguracje: Można przypisać konfiguracje dla zestawu (na przykład: Chrome, Firefox, EdgeChromium), które będą miały zastosowanie do wszystkich istniejących przypadków testowych lub nowych przypadków testowych dodanych później do tego zestawu.
• Eksportuj jako plik PDF/wiadomość e-mail: Eksportuj 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 PDF".
• otwórz element roboczy pakietu 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 testowego.

3. Zdefiniuj zakładkę

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.

Zakładka Definiowanie i niektóre operacje są dostępne tylko dla użytkowników z poziomem dostępu podstawowym + Planami testów lub równoważnym. Wszystkie inne elementy powinny 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życiusiatki: 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 pakietu.
• 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żna zmienić kolejność przypadków testowych, przeciągając/upuszczając jeden lub więcej przypadków testowych w danym zbiorze. Kolejność przypadków testowych ma zastosowanie tylko do przypadków testowych ręcznych, a nie do testów automatycznych.
• Przenieś przypadki testowe z jednego zestawu do innego: przy użyciu 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 testowymi.
• Widok pełnoekranowy: Możesz wyświetlić zawartość całej zakładki Definiuj w trybie pełnoekranowym przy użyciu tej opcji.
• Filtrowanie: Korzystając z paska filtru, można przefiltrować listę przypadków testowych, wykorzystując pola "tytuł przypadku testowego", "przypisane do" i "stan". Listę można również posortować, klikając nagłówki kolumn.
• opcje kolumn: Możesz zarządzać listą kolumn widocznych na karcie Definicja przy użyciu opcji kolumn. Lista kolumn dostępnych do wyboru to przede wszystkim pola formularza elementu roboczego przypadku testowego.

opcje menu kontekstowego

Menu kontekstowe w węźle Przypadek testowy na karcie Definiowanie zawiera 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 elementów roboczych przypadku testowego. Nie można jednak użyć tej opcji, aby zbiorczo edytować kroki testu.
• Edytowanie przypadków testowych wsiatki: 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 pakietu. Nie zmienia jednak bazowego elementu roboczego przypadku testowego.
• Utwórz kopię/klon przypadków testowych: ta opcja umożliwia utworzenie kopii/klonowania wybranych przypadków testowych. Zobacz poniżej, aby uzyskać więcej informacji.
• Wyświetl połączone elementy: ta opcja umożliwia przeglądanie połączonych elementów dla danego przypadku testowego. Zobacz poniżej, aby uzyskać więcej informacji.

przypadki testowe kopiowania/klonowania (nowe możliwości)

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 określić, czy chcesz uwzględnić istniejące linki/załączniki w kopiowanej kopii.

Wyświetl połączone elementy (nowe możliwości)

Możliwość śledzenia artefaktów testowych, wymagań i usterek jest kluczową wartością dodaną produktu Test Plans. Za pomocą opcji "Wyświetl połączone elementy" można łatwo przyjrzeć się wszystkim połączonym wymaganiom, 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. Wykonaj zakładkę

karta wykonywania zakładki

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? Samodzielnie przypadki testowe nie są możliwe do wykonania. Po dodaniu przypadku testowego do zestawu testów są generowane punkty testowe. Punkt testowy to unikatowa kombinacja przypadków testowych, zestawu testów, konfiguracji i testera. Przykład: jeśli masz przypadek testowy jako "Przetestuj funkcję logowania" i dodasz do niego 2 konfiguracje, takie jak Edge i Chrome, daje to 2 punkty testowe. Teraz można wykonać te punkty testowe. Podczas wykonywania są generowane wyniki testów. Za pomocą widoku wyników testu (historii wykonywania) można zobaczyć wszystkie wykonania punktu testowego. Najnowsze wykonanie punktu testowego to to, co widzisz na zakładce wykonania.
W związku z tym przypadki testowe to jednostki wielokrotnego użytku. Po uwzględnieniu ich w planie testu lub zestawie punkty testowe są generowane. 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 zajmują się wykonywaniem lub śledzeniem testów i mają tylko poziom dostępu "Podstawowy", nie są przytłoczeni złożonością zarządzania pakietami, ponieważ karta definiowania jest dla nich ukryta.

Karta Definiuj i tylko niektóre operacje są dostępne wyłącznie dla użytkowników z poziomem dostępu Podstawowy + Test Plany lub równoważnym. Wszystkie inne elementy, w tym karta "Wykonaj" powinny być możliwe dla użytkownika z poziomem dostępu "Podstawowa".

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 — czy zakończyły się powodzeniem, niepowodzeniem, są zablokowane lub nie mają zastosowania, bez konieczności uruchamiania przypadku testowego za pomocą modułu uruchamiania testów. Wynik można oznaczyć dla jednego lub wielu punktów testowych jednocześnie.
• Uruchamianie punktów testowych: Ta opcja umożliwia uruchamianie przypadków testowych poprzez indywidualne przechodzenie przez każdy krok testu i oznaczanie ich jako powodzenie/niepowodzenie przy użyciu uruchamiacza testów. W zależności od aplikacji, którą testujesz, możesz użyć "Web Runnera" do testowania aplikacji internetowej lub "Desktop Runnera" do testowania aplikacji klasycznych i/lub internetowych. Można również wywołać polecenie "Uruchom z opcjami", aby określić kompilację, dla której ma zostać wykonane testowanie.
• Opcje kolumn: możesz zarządzać listą kolumn widocznych na karcie Wykonywanie przy użyciu opcji kolumn. Lista kolumn dostępnych do wyboru jest skojarzona z punktami testowymi, takimi jak Run by, Assigned Tester, Configuration itp.
• Full screen view: możesz wyświetlić zawartość całej karty "Wykonywanie" w trybie pełnoekranowym, korzystając z 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". Listę można również posortować, 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 jak powyżej, pozwala szybko oznaczyć wynik punktów testowych — zaliczony, niezaliczony, zablokowany lub nie dotyczy.
• Uruchamianie punktów testowych: tak samo jak powyżej, umożliwia uruchamianie przypadków testowych za pośrednictwem modułu wykonującego testy.
• Resetuj test na aktywny: Ta opcja umożliwia zresetowanie wyniku testu na aktywny, ignorując ostatni wynik testowy.
• 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.
• Przypisztestera: 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 wyników 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 postępu planów testów

Ten wbudowany raport ułatwia śledzenie wykonywania i stanu co najmniej jednego planu testów w projekcie. Odwiedź stronę Plany testów > raport postępu*, aby rozpocząć korzystanie z raportu.

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

1. Podsumowanie: przedstawia skonsolidowany widok dla wybranych planów testowych.
2. Trend wyników: Zapewnia codzienną migawkę, aby przedstawić linię trendu przebiegu i stanu. Dane mogą być wyświetlane przez 14 dni (wartość domyślna), 30 dni lub zakres niestandardowy.
3. Szczegóły: ta sekcja umożliwia przechodzenie do szczegółów poszczególnych planów testów i udostępnia ważne analizy dla każdego zestawu testów.

Artefakty

Notatka

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

Wyrażenia licencji i osadzone licencje

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 doświadczenie jest takie samo w przypadku wyrażeń licencji i licencji osadzonych, więc można zobaczyć szczegóły licencji pakietów przechowywanych w usłudze Azure Artifacts w jednym miejscu (dla pakietów, które określają informacje o licencji i są wspierane przez program Visual Studio).

Uproszczone zadania uwierzytelniania

Teraz możesz uwierzytelniać się za pomocą popularnych menedżerów pakietów w Azure Pipelines, korzystając z lekkich zadań uwierzytelniania. Obejmuje to narzędzia NuGet, npm, PIP, Twine i Maven. Wcześniej można było uwierzytelnić 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. Jednakże wymagało to użycia tych zadań dla wszystkich działań, które współpracowały z menedżerami pakietów. Gdybyś miał własne skrypty do wykonywania zadań, takich jak publikowanie lub pobieranie pakietów, nie mógłbyś ich używać w potoku. Teraz możesz używać skryptów własnego projektu w potoku YAML i wykonywać uwierzytelnianie przy użyciu tych nowych uproszczonych 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ływaniem poleceń i ułatwia użycie wspólnych skryptów w konfiguracji potoku. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją zadania uwierzytelniania dla NuGet, npm, PIP, Twinei Maven.

Ulepszenia czasu ładowania strony kanału informacyjnego

Z przyjemnością informujemy, że poprawiliśmy czas ładowania strony kanału. Średnio 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 (czas ładowania w najwyższym 99% wszystkich kanałów informacyjnych) zmniejszył się o 75%.

Udostępniaj publicznie swoje pakiety przy użyciu publicznych kanałów

Teraz możesz tworzyć i przechowywać swoje pakiety w publicznych kanałach informacyjnych. Pakiety przechowywane w publicznych repozytoriach są dostępne dla wszystkich użytkowników w Internecie bez uwierzytelniania, niezależnie od tego, czy użytkownicy mają je w swojej kolekcji, czy są zalogowani do kolekcji usługi Azure DevOps. Dowiedz się więcej o kanałach informacyjnych w naszej dokumentacji kanałów lub przejdź bezpośrednio do naszego samouczka o publicznym udostępnianiu pakietów .

Konfigurowanie upstreamów w różnych kolekcjach w dzierżawie AAD

Teraz możesz dodać kanał danych w innej kolekcji skojarzonej z dzierżawą usługi Azure Active Directory (AAD) jako źródło nadrzędne dla kanału 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 skonfigurować tę konfigurację wdokumentacji.

Użyj Python Credential Provider do uwierzytelniania pip i twine z kanałami usługi Azure Artifacts.

Możesz teraz zainstalować i użyć Python Credential Provider (artifacts-keyring), aby automatycznie skonfigurować uwierzytelnianie do publikowania lub korzystania z pakietów Python do lub ze źródła danych Azure Artifacts. Przy użyciu dostawcy poświadczeń nie trzeba konfigurować żadnych plików konfiguracji (pip.ini/pip.conf/.pypirc), po prostu przejdziesz przez proces uwierzytelnienia w przeglądarce internetowej podczas wywoływania pip lub twine po raz pierwszy. Więcej informacji znajdziesz w dokumentacji.

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

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

Zaktualizowano doświadczenie połączenia z kanałem informacyjnym

Okno Łączenie z kanałem to wejście do korzystania z Azure Artifacts; zawiera informacje na temat konfigurowania klientów i repozytoriów w celu wysyłania i pobierania pakietów z kanałów w Azure DevOps. Zaktualizowaliśmy okno dialogowe, aby dodać szczegółowe informacje o konfiguracji i rozwinąć narzędzia, dla których udostępniamy instrukcje.

Publiczne kanały informacyjne są teraz ogólnie dostępne dzięki obsłudze nadrzędnej

Publiczna wersja zapoznawcza publicznych kanałów informacyjnych otrzymała świetne przyjęcie 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 źródła danych. Pliki konfiguracyjne można łatwo uprościć, umożliwiając przesyłanie danych zarówno do prywatnych kanałów danych, jak i z kanałów danych dostępnych tylko w ramach projektu.

Utwórz kanały o zakresie projektu z poziomu portalu

Po wypuszczeniu publicznych kanałów, udostępniliśmy również kanały o zakresie projektu. Do tej pory źródła danych o zakresie projektu można było tworzyć za pośrednictwem interfejsów API REST lub tworząc publiczne źródło danych i następnie przekształcając je na prywatne w ramach 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ą projektami 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 źródłach danych usługi Azure Artifacts. Pomogło nam to osiągnąć maksymalnie 10-krotne zmniejszenie opóźnienia dla niektórych z najwyższych używanych interfejsów API dla npm.

Ulepszenia 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:

• Tworzenie doświadczenia kanału
• Globalne doświadczenie ustawień kanału informacyjnego
• Nawiązywanie połączenia ze środowiskiem kanału informacyjnego

Wiki

Rozbudowane edytowanie stron wiki z kodem

Wcześniej, gdy edytowałeś stronę wiki kodu, następowało przekierowanie do centrum Azure Repos. Obecnie centrum Repo nie jest zoptymalizowane pod kątem edycji Markdown.

Teraz możesz edytować stronę wiki kodu w edytorze równoległym wewnątrz witryny wiki. Dzięki temu możesz korzystać z zaawansowanego paska narzędzi markdown, aby tworzyć zawartość, zapewniając doświadczenie edycji identyczne z tym w wiki projektu. Nadal możesz edytować repozytoria, wybierając opcję Edytuj w repozytoriach w menu kontekstowym.

Tworzenie i osadzanie elementów roboczych na stronie typu wiki

Słuchając waszych opinii, usłyszeliśmy, że korzystasz z wiki do przechwytywania dokumentów burzy mózgów, dokumentów planowania, pomysłów na funkcje, dokumentów specyfikacji, protokołów ze spotkań. 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ć. Również zmniejsza zmianę kontekstu, ponieważ nie wychodzisz poza zakres 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 miałeś możliwości interakcji z innymi użytkownikami w obrębie wiki. Sprawiło to, że współpraca nad zawartością i uzyskaniem odpowiedzi na pytania stanowiła wyzwanie, ponieważ rozmowy miały miejsce za pośrednictwem poczty e-mail lub kanałów czatu. Dzięki komentarzom możesz teraz współpracować z innymi osobami bezpośrednio w witrynie typu wiki. Możesz wykorzystać funkcjonalność oznaczania użytkowników @mention w komentarzach, aby przyciągnąć uwagę innych członków zespołu. Ta funkcja została przyznano priorytet na podstawie tego zgłoszenia sugestii. Aby uzyskać więcej informacji na temat komentarzy, zobacz naszą dokumentację tutaj.

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

Do tej pory drzewo wiki pokazywało wszystkie foldery i pliki, zaczynając od kropki (.) w drzewie wiki. W scenariuszach wiki kodu powodowało to, że foldery takie jak .vscode, które powinny być ukryte, pojawiały się w drzewie wiki. Teraz wszystkie pliki i foldery rozpoczynające się od kropki pozostaną ukryte w drzewie wiki, co spowoduje zmniejszenie niepotrzebnego bałaganu.

Ta funkcja została priorytetyzowana na podstawie tego zgłoszenia 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, aby usunąć parametry, 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 — zapraszamy do strony wiki usługi Azure DevOps:

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

Priorytet ten został nadany na podstawie zgłoszenia o propozycji funkcji ze Społeczności Deweloperów.

Synchroniczne przewijanie do edytowania stron typu wiki

Edytowanie stron typu wiki jest teraz łatwiejsze dzięki synchronizowanemu przewijaniu między oknem edycji 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.

Notatka

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

Wizyty na stronach wiki

Teraz możesz uzyskać szczegółowe informacje na temat wizyt 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 przeglądane strony (top-n).

Na każdej stronie będzie również widoczna zagregowana liczba wizyt na stronie z ostatnich 30 dni.

Notatka

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

Raportowanie

Raporty dotyczące awarii 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 niepowodzeń przepływu pracy przedstawia wskaźnik zdanych kompilacji oraz trend awarii. Ponadto pokaże również trend niepowodzeń podzadań, aby uzyskać szczegółowe informacje o tym, które zadanie w potoku przyczynia się do maksymalnej liczby awarii.

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

Poprawa widżetu Wyników zapytania

Widżet wyników zapytania jest jednym z 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 więcej limitu 5 kolumn!
• Widżet obsługuje wszystkie rozmiary, od 1x1 do 10x10.
• Podczas zmiany rozmiaru kolumny szerokość kolumny zostanie zapisana.
• Możesz rozwinąć widżet do widoku pełnoekranowego. Po rozwinięciu zostaną wyświetlone wszystkie kolumny zwrócone przez zapytanie.

Zaawansowane filtrowanie widżetów czasu realizacji i czasu cyklu

Czas rozpoczęcia i czas realizacji są używane przez zespoły do określenia, jak długo trwa przepływ pracy przez ich ścieżki rozwoju, aby ostatecznie dostarczyć wartość klientom.

Do tej pory widżety dotyczące czasu realizacji i cyklu nie obsługiwały zaawansowanych kryteriów filtrowania, aby zadawać pytania takie jak: "jak długo mój zespół potrzebuje, aby zamknąć elementy o wyższym priorytecie?"

Dzięki tej aktualizacji na takie pytania można odpowiedzieć, filtrując po torze pływackim na tablicy.

Uwzględniliśmy również filtry elementów roboczych w celu ograniczenia elementów roboczych wyświetlanych na wykresie.

Przykładowe wypalenie sprintu przy użyciu story points

Twoje wykresy sprintu mogą teraz pokazywać postęp według opowieści użytkownika. Ta odpowiedź dotyczy Twojej opinii z społeczności deweloperów .

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

1. Wybierz backlog Historii
2. Wybierz, aby wykonać analizę wykresu spalania na sumie punktów historii

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

Nowy widżet Postępu przebiegu obsługuje wypalanie według punktów scenariuszy, liczby zadań lub sumowania pól niestandardowych. Możesz nawet utworzyć wykres spalania sprintu dla funkcjonalności lub Epików. Widżet wyświetla średni wykres spalania zadań, ukończone (%) oraz zwiększenie zakresu prac. Możesz skonfigurować zespół, co pozwala na wyświetlanie wykresów spalania sprintu dla wielu zespołów na jednym pulpicie nawigacyjnym. Dzięki tym wszystkim doskonałym informacjom do wyświetlenia możemy zmienić jego rozmiar do 10x10 na pulpicie nawigacyjnym.

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

Notatka

Nowy widżet korzysta z usługi Analytics. Zachowaliśmy starszy wykres Sprint Burndown na wypadek, gdybyś nie miał dostępu do Analityki.

Miniatura przebiegu sprintu wbudowanego

Sprint Burndown powraca! Kilka sprintów temu usunęliśmy wypalenie w kontekście danego sprintu z nagłówków Sprint Burndown i Taskboard. Na podstawie waszych opinii ulepszyliśmy i przywróciliśmy miniaturę przedstawiającą wykres spalania sprintu.

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ć ją tak, aby mogła być wypalona na podstawie scenariuszy, punktów historii lub liczby zadań, a nie tylko ilości pozostałej pracy.

Tworzenie pulpitu nawigacyjnego bez zespołu

Teraz możesz utworzyć pulpit nawigacyjny bez skojarzenia 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 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 ich konfiguracji. Możesz dodać te widżety do pulpitów nawigacyjnych projektu i wybrać odpowiedni zespół.

Notatka

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.

---

informacja zwrotna

Chcielibyśmy usłyszeć od Ciebie! Możesz zgłosić problem lub podać pomysł i śledzić go za pośrednictwem Developer Community i uzyskać porady na temat Stack Overflow.

---

Góra strony