Informacje o wersji usługi Azure DevOpsServer 2020 Update 1

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

W tym artykule znajdziesz informacje dotyczące najnowszej wersji Azure DevOps Server.

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

Bezpośrednie uaktualnienie do Azure DevOps Server 2020 r. jest obsługiwane z wersji Azure DevOps Server 2019 lub Team Foundation Server 2015 lub nowszej. Jeśli wdrożenie serwera TFS jest w wersji TFS 2010 lub starszej, przed uaktualnieniem do Azure DevOps Server 2019 r. należy wykonać kilka kroków tymczasowych. Aby dowiedzieć się więcej, zobacz Instalowanie i konfigurowanie lokalnej usługi Azure DevOps.

---

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

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

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

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

Azure DevOps Server 2020 Update 1.2 Patch 13 Data wydania: 12 marca 2024 r.

File	Skrót SHA-256
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6F6

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

• Rozwiązano problem polegający na tym, że serwer proxy przestał działać po zainstalowaniu poprawki 12.

Azure DevOps Server 2020 Update 1.2 Patch 12 Data wydania: 13 lutego 2024 r.

File	Skrót SHA-256
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

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

• Usunięto usterkę polegającą na tym, że miejsce na dysku używane przez folder pamięci podręcznej serwera proxy zostało obliczone niepoprawnie, a folder nie został prawidłowo wyczyszczony.
• CVE-2024-20667: luka w zabezpieczeniach dotycząca zdalnego wykonywania kodu Azure DevOps Server.

Azure DevOps Server 2020 Update 1.2 Patch 11 Data wydania: 12 grudnia 2023 r.

File	Skrót SHA-256
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

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

• Usunięto usterkę polegającą na tym, że dziedziczenie zabezpieczeń zatwierdzania przed wdrożeniem nie działało na etapach potoków.

Azure DevOps Server 2020 Update 1.2 Patch 10 Data wydania: 14 listopada 2023 r.

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

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

Uwaga

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

Instalowanie poprawek

Ważne

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

Konfigurowanie funkcji TFX

1. Wykonaj kroki opisane w dokumentacji przekazywania zadań do kolekcji projektów , aby zainstalować i zalogować się przy użyciu narzędzia tfx-cli.

Aktualizowanie zadań przy użyciu narzędzia TFX

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

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

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

Wymagania dotyczące potoku

Aby korzystać z nowego zachowania, należy ustawić zmienną AZP_75787_ENABLE_NEW_LOGIC = true w potokach, które używają zadań, których dotyczy problem.

• W wersji klasycznej:

  Zdefiniuj zmienną na karcie zmiennej w potoku.

• Przykład YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Ważne

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

Opublikowaliśmy poprawkę. dla Azure DevOps Server 2020 Update 1.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 do uaktualniania poprawek.

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

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

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

Ważne

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

Uwaga

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

Instalowanie poprawek

1. Pobierz i zainstaluj Azure DevOps Server 2020 Update 1.2 patch 8.

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. Wykonaj kroki opisane w dokumentacji własnych agentów systemu Windows , aby wdrożyć agenta.  

Uwaga

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

Konfigurowanie funkcji TFX

1. Wykonaj kroki opisane w dokumentacji przekazywania zadań do kolekcji projektów , aby zainstalować i zalogować się przy użyciu narzędzia tfx-cli.

Aktualizowanie zadań przy użyciu narzędzia TFX

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

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

Wymagania dotyczące potoku

Aby korzystać z nowego zachowania, należy ustawić zmienną AZP_75787_ENABLE_NEW_LOGIC = true w potokach, które używają zadań, których dotyczy problem.

• W wersji klasycznej:

  Zdefiniuj zmienną na karcie zmiennej w potoku.

• Przykład YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 1.2 Patch 7 Data wydania: 8 sierpnia 2023 r.

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

• CVE-2023-36869: luka w zabezpieczeniach dotycząca Azure DevOps Server fałszowania.
• Zaktualizuj usługę SSH w celu obsługi algorytmów SHA2-256 i SHA2-512. Jeśli masz pliki konfiguracji SSH zakodowane w celu używania rsa, należy zaktualizować go do algorytmu SHA2 lub usunąć wpis.
• Rozwiązano problem z linkami względnymi, które nie działają w plikach markdown.
• Usunięto usterkę z nawigacją komentarzy na stronie zatwierdzania.
• Usunięto usterkę polegającą na tym, że tożsamość właściciela analizy została wyświetlona jako nieaktywna tożsamość.
• Usunięto usterkę pętli nieskończonej w CronScheduleJobExtension.

Azure DevOps Server 2020 Update 1.2 Patch 6 Data wydania: 13 czerwca 2023 r.

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

• CVE-2023-21565: luka w zabezpieczeniach dotycząca Azure DevOps Server fałszowania.
• CVE-2023-21569: luka w zabezpieczeniach dotycząca Azure DevOps Server fałszowania.
• Usunięto usterkę, która zakłócała wypychanie pakietów podczas uaktualniania z wersji 2018 lub starszej.
• Usunięto usterkę polegającą na tym, że operacja odłączania lub dołączania kolekcji nie zgłaszała następującego błędu: "TF246018: Operacja bazy danych przekroczyła limit czasu i została anulowana.

Azure DevOps Server 2020 Update 1.2 Patch 5 Data wydania: 14 lutego 2023 r.

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

• CVE-2023-21553: luka w zabezpieczeniach dotycząca zdalnego wykonywania kodu Azure DevOps Server
• Rozwiązano problem z ułatwieniami dostępu zestawów półek za pośrednictwem internetowego interfejsu użytkownika
• Klienci muszą ponownie uruchomić usługę tfsjobagent i pulę aplikacji Azure DevOps Server po zaktualizowaniu ustawienia związanego z protokołem SMTP w konsoli zarządzania Azure DevOps Server.

Azure DevOps Server 2020 Update 1.2 Patch 4 Data wydania: 13 grudnia 2022 r.

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

• Naprawiono wyświetlanie znaków specjalnych w narzędziu IdentityPicker.

• Dane testowe nie zostały usunięte, co spowodowało wzrost bazy danych. Dzięki tej poprawce zaktualizowaliśmy przechowywanie kompilacji, aby zapobiec tworzeniu nowych oddzielonych danych testowych.

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

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

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

Azure DevOps Server 2020 Update 1.2 Patch 2 Data wydania: 9 sierpnia 2022 r.

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

• Napraw błąd wartości tożsamości podczas przypisywania elementu roboczego do tożsamości, która pojawia się w różnych domenach.

Azure DevOps Server 2020 Update 1.2 Patch 1 Data wydania: 12 lipca 2022 r.

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

• W interfejsach API przebiegów testów zwracany token kontynuacji był większy niż określona wartość "maxLastUpdatedDate".

Azure DevOps Server 2020 Update 1.2 Data wydania: 17 maja 2022 r.

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

Uwaga

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

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

• Azure DevOps Server 2020.1.2 wyłącza nowy model przechowywania (wprowadzony w Azure DevOps Server 2020 r.), aby zapobiec utracie przebiegów potoków (kompilacji). Oznacza to, że system będzie:

  • Tworzenie dzierżaw dla najnowszych 3 kompilacji wygenerowanych podczas uruchamiania programu Server 2020
  • W przypadku potoków YAML i potoków klasycznych bez zasad przechowywania potoku kompilacje zostaną zachowane zgodnie z ustawieniami maksymalnego przechowywania na poziomie kolekcji
  • W przypadku klasycznych potoków z niestandardowymi zasadami przechowywania potoków kompilacje będą zachowywane zgodnie z zasadami przechowywania specyficznymi dla potoku
  • Kompilacje z dzierżawami nie są liczone do wartości Minimum, aby zachować ustawienie

• Linki do komentarzy zestawów zmian i zestawów na półce nie były prawidłowo przekierowywane. Gdy komentarze zostały dodane do plików w zestawach zmian lub zestawach na półce, wybranie tych komentarzy nie było przekierowywane do poprawnego miejsca w widoku plikó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.1.1 Patch 4 Data wydania: 26 stycznia 2022 r.

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

• Email powiadomienia nie zostały wysłane podczas korzystania z kontrolki @mention w elemencie roboczym.
• Preferowany adres e-mail nie został zaktualizowany w profilu użytkownika. Spowodowało to wysłanie wiadomości e-mail na poprzedni adres e-mail.
• Nagłówek nie został wyświetlony na stronie Podsumowanie projektu. Nagłówek został wyświetlony przez kilka milisekund, a następnie zniknął.
• 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 4.
2. Sprawdź wartość rejestru pod adresem HKLM:\Software\Elasticsearch\Version. Jeśli wartość rejestru nie istnieje, dodaj wartość ciągu i ustaw wartość Version na 5.4.1 (Name = Version, Value = 5.4.1).
3. Uruchom polecenie PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update aktualizacji zgodnie z opisem w pliku readme. Może zostać zwrócone ostrzeżenie, takie jak: Nie można nawiązać połączenia z serwerem zdalnym. Nie zamykaj okna, ponieważ aktualizacja jest ponawiana do momentu jej ukończenia.

Uwaga

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

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

SKRÓT SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 Patch 3 Data wydania: 15 grudnia 2021 r.

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

• Poprawiono makro elementu roboczego dla zapytań z wyrazami "Contains Words". Wcześniej zapytania zwracały nieprawidłowe wyniki dla wartości, które zawierały podział wiersza.
• Zwiększ limity długości znaków wersji pakietu Maven.
• Problem z lokalizacją dla niestandardowych stanów układu elementów roboczych.
• Problem z lokalizacją w szablonie powiadomień e-mail.
• Problem z oceną reguł NOTSAMEAS, gdy dla pola zdefiniowano wiele reguł NOTSAMEAS.

Azure DevOps Server 2020.1.1 Patch 2 Data wydania: 26 października 2021 r.

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

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

Azure DevOps Server 2020.1.1 Patch 1 Data wydania: 14 września 2021 r.

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

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

Azure DevOps Server 2020 Update 1.1 Data wydania: 17 sierpnia 2021 r.

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

Uwaga

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

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

Azure Boards

• Hiperlink "Wyświetl element roboczy" w wiadomościach e-mail z powiadomieniami nie korzysta z publicznego adresu URL.

Azure Repos

• Naprawiono pola wyboru dziedziczenia ograniczone typy scalania, aby włączyć modyfikowanie typów scalania limitów po ustawieniu zasad współposilności krzyżowych.

Azure Pipelines

• Podczas zmiany ustawienia aktualizacji agenta ustawienia nie były propagowane do innych warstw aplikacji w środowisku.

Ogólne

• Naprawiono pisownię w kreatorze konfiguracji serwera.
• Zwiększony rozmiar pakietu rozszerzenia i umożliwia zmianę rozmiaru rejestru.

Azure Test Plans

• Nie można przejść z powrotem do wyników testów po powrocie z historii do strony podsumowania.

---

Azure DevOps Server 2020.1 Poprawka 2 Data wydania: 10 sierpnia 2021 r.

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

• Naprawiono błąd interfejsu użytkownika definicji kompilacji.
• Zmieniono historię przeglądania, aby wyświetlać pliki zamiast repozytorium głównego.

Azure DevOps Server 2020.1 Poprawka 1 Data wydania: 15 czerwca 2021 r.

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

• Zabezpieczanie plików cookie używanych w przepływach autoryzacji, które potwierdzają SameSite=None.

• Rozwiąż problem z zestawem SDK powiadomień. Wcześniej subskrypcje powiadomień przy użyciu filtru Ścieżka obszaru nie były prawidłowo analizowane.

data wydania Azure DevOps Server 2020.1 RTW: 25 maja 2021 r.

Podsumowanie nowości w Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW to pakiet poprawek błędów. Obejmuje ona wszystkie funkcje wydane wcześniej w wersji Azure DevOps Server 2020.1 RC2. Azure DevOps Server 2020.1 RTW to zestawienie poprawek błędów. Możesz bezpośrednio zainstalować program Azure DevOps Server 2020.1 lub uaktualnić go z wersji Azure DevOps Server 2020, 2019 lub Team Foundation Server 2015 lub nowszej.

Uwaga

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

Azure DevOps Server 2020.1 RC2 Data wydania: 13 kwietnia 2021 r.

Podsumowanie nowości w programie Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 to zbiorcze poprawki błędów. Zawiera wszystkie funkcje wydane wcześniej w wersji Azure DevOps Server 2020.1 RC1.

Azure DevOps Server 2020.1 RC1 Data wydania: 23 marca 2021 r.

Podsumowanie nowości w programie Azure DevOps Server 2020.1 RC1

Azure DevOps Server 2020.1 RC1 wprowadza wiele nowych funkcji. Niektóre najważniejsze funkcje to:

• Reguły ograniczeń przejścia stanu w tablicach
• Osoby biorące udział w projekcie mogą teraz przenosić elementy robocze między kolumnami
• Zwiększanie zabezpieczeń wydania przez ograniczenie zakresu tokenów dostępu
• Ulepszone środowisko żądania ściągnięcia
• Wyzwalacze z wieloma repozytoriami w potokach

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

• Boards
• Repos
• Pipelines
• Artifacts

---

Boards

Reguły ograniczeń przejścia stanu

Nadal zamykamy lukę parzystości funkcji między hostowanym kodem XML a dziedziczonym modelem procesu. Ta nowa reguła typu elementu roboczego umożliwia ograniczenie przenoszenia elementów roboczych z jednego stanu do innego. Na przykład możesz ograniczyć możliwość przechodzenia z obszaru Usterki z obszaru Nowe na Rozwiązane. Zamiast tego muszą przejść z obszaru Nowy —> Aktywny —> rozwiązany

Regułę można również utworzyć, aby ograniczyć przejścia stanu według członkostwa w grupie. Na przykład tylko użytkownicy w grupie "Osoby zatwierdzające" mogą przenosić historie użytkowników z obszaru Nowy —> Zatwierdzone.

Kopiowanie elementu roboczego do kopiowania elementów podrzędnych

Jedną z najbardziej żądanych funkcji Azure Boards jest możliwość kopiowania elementu roboczego, który kopiuje również podrzędne elementy robocze. Dodaliśmy nową opcję "Dołącz podrzędne elementy robocze" do okna dialogowego kopiowania elementu roboczego. Po wybraniu tej opcji skopiuje element roboczy i skopiuje wszystkie podrzędne elementy robocze (do 100).

Ulepszone reguły aktywowanych i rozwiązanych pól

Do tej pory reguły aktywowane przez, Aktywowana data, Rozwiązane według i Rozwiązane daty były tajemnicą. Są one ustawione tylko dla systemowych typów elementów roboczych i są specyficzne dla wartości stanu "Aktywne" i "Rozwiązane". Zmieniliśmy logikę, aby te reguły nie były już przeznaczone dla określonego stanu. Zamiast tego są wyzwalane przez kategorię (kategorię stanu), w której znajduje się stan. Załóżmy na przykład, że masz niestandardowy stan "Wymaga testowania" w kategorii Rozwiązane. Gdy element roboczy zmieni się z "Aktywny" na "Wymaga testowania", zostaną wyzwolone reguły Rozwiązane według i Rozwiązane daty .

Dzięki temu klienci mogą tworzyć dowolne niestandardowe wartości stanu i nadal generować pola Aktywowane według, Aktywowana data, Rozwiązane według i Rozwiązane daty bez konieczności używania reguł niestandardowych.

Osoby biorące udział w projekcie mogą przenosić elementy robocze między kolumnami

Uczestnicy projektu zawsze byli w stanie zmienić stan elementów roboczych. Ale kiedy idą do tablicy Kanban, nie mogą przenieść elementów roboczych z jednej kolumny do innej. Zamiast tego uczestnicy projektu musieliby otworzyć każdy element roboczy, jeden naraz i zaktualizować wartość stanu. Od dawna jest to punkt bólu dla klientów i z przyjemnością ogłaszamy, że teraz możesz przenosić elementy robocze między kolumnami.

Systemowe typy elementów roboczych na listach prac i tablicach

Teraz możesz dodać typ elementu roboczego systemu do wybranego poziomu listy prac. Historycznie te typy elementów roboczych były dostępne tylko z zapytań.

Proces	Typ elementu roboczego
Zwinność	Problem
Scrum	Przeszkody
CMMI	Żądanie zmiany
	Problem
	Przegląd
	Ryzyko

Dodawanie typu elementu roboczego systemu do poziomu listy prac jest proste. Po prostu przejdź do procesu niestandardowego i kliknij kartę Poziomy listy prac. Wybierz wybrany poziom listy prac (na przykład: Listy prac wymagań) i wybierz opcję edycji. Następnie dodaj typ elementu roboczego.

Azure Boards podniesiono limit repozytorium aplikacji GitHub

Limit repozytorium dla aplikacji Azure Boards w witrynie GitHub Marketplace został zwiększony z 100 do 250.

Dostosowywanie stanu elementu roboczego po scaleniu żądania ściągnięcia

Nie wszystkie przepływy pracy są takie same. Niektórzy klienci chcą zamknąć powiązane elementy robocze po zakończeniu żądania ściągnięcia. Inne osoby chcą ustawić elementy robocze na inny stan, który ma zostać zweryfikowany przed zamknięciem. Powinniśmy pozwolić na oba te elementy.

Mamy nową funkcję, która umożliwia ustawienie elementów roboczych na żądany stan po scaleniu i zakończeniu żądania ściągnięcia. W tym celu przeskanujemy opis żądania ściągnięcia i wyszukamy wartość stanu, po której następuje #mention elementów roboczych. W tym przykładzie ustawiamy dwa scenariusze użytkownika na Rozwiązane i zamykamy dwa zadania.

Łączenie elementu roboczego z kompilacjami w innym projekcie

Teraz można łatwo śledzić zależności kompilacji w projekcie, łącząc element roboczy z kompilacją, znalezioną w kompilacji lub zintegrowaną w kompilacji.

Edytowanie opisu (tekstu pomocy) w polach systemowych

Zawsze można było edytować opis pól niestandardowych. Jednak w przypadku pól systemowych, takich jak priorytet, ważność i aktywność, opis nie był edytowalny. Była to luka funkcji między hostowanym plikiem XML i dziedziczona, która uniemożliwiła niektórym klientom migrację do modelu dziedziczonego. Teraz możesz edytować opis w polach systemowych. Edytowana wartość będzie mieć wpływ tylko na to pole w procesie i dla tego typu elementu roboczego. Zapewnia to elastyczność, aby mieć różne opisy dla tego samego pola w różnych typach elementów roboczych.

Dostosowywanie stanu elementu roboczego po scaleniu żądania ściągnięcia

Żądania ściągnięcia często odwołują się do wielu elementów roboczych. Podczas tworzenia lub aktualizowania żądania ściągnięcia możesz chcieć zamknąć niektóre z nich, rozwiązać niektóre z nich i zachować resztę otwartą. Teraz możesz użyć komentarzy, takich jak te pokazane na poniższej ilustracji, aby to osiągnąć. Aby uzyskać więcej informacji, zobacz dokumentację.

Pole nadrzędne na tablicy zadań

Ze względu na popularne żądanie można teraz dodać pole Nadrzędne zarówno do kart podrzędnych, jak i nadrzędnych na tablicy zadań.

Usuwanie reguły "Przypisano do" dla typu elementu roboczego usterki

Istnieje kilka ukrytych reguł systemowych we wszystkich różnych typach elementów roboczych w systemach Agile, Scrum i CMMI. Przepisy te istniały od ponad dekady i ogólnie działały dobrze bez żadnych skarg. Jednak istnieje kilka zasad, które zabrakło ich powitanie. Jedna z reguł w szczególności spowodowała wiele bólu dla nowych i istniejących klientów i zdecydowaliśmy, że nadszedł czas, aby go usunąć. Ta reguła istnieje w typie elementu roboczego Usterki w procesie Agile.

"Ustaw wartość Przypisana na Wartość utworzona przez, gdy stan zostanie zmieniony na Rozwiązane"

Otrzymaliśmy wiele opinii na temat tej reguły. W odpowiedzi usunęliśmy tę regułę z typu element roboczy Bug w procesie Agile. Ta zmiana wpłynie na każdy projekt przy użyciu dziedziczonego procesu Agile lub niestandardowego dziedziczonego procesu Agile. W przypadku tych klientów, którzy lubią tę bieżącą regułę i od nich zależą, zapoznaj się z naszym wpisem w blogu dotyczącym kroków, które można wykonać, aby ponownie dodać regułę przy użyciu reguł niestandardowych.

Usunięte elementy na stronie Elementy robocze

Strona Elementy robocze to doskonałe miejsce do szybkiego znajdowania utworzonych lub przypisanych do Ciebie elementów. Udostępnia on kilka spersonalizowanych elementów przestawnych i filtrów. Jedną z najważniejszych skarg dotyczących elementu przestawnego "Przypisano do mnie" jest to, że jest wyświetlana pozycja Usunięte elementy robocze (czyli elementy robocze w stanie Usunięte). I zgadzamy się! Usunięte elementy to praca, która nie jest już wartością, dlatego została usunięta z listy prac, dlatego dołączenie ich w tym widoku nie jest przydatne.

Teraz możesz ukryć wszystkie usunięte elementy z obszaru przestawnego Przypisane do mnie na stronie Elementy robocze.

Repos

Domyślna preferencja nazwy gałęzi

Azure Repos teraz oferuje dostosowywalną domyślną nazwę gałęzi dla usługi Git. W ustawieniach repozytorium można wybrać dowolną nazwę gałęzi prawnej do użycia podczas inicjowania repozytorium. Azure Repos zawsze obsługiwała zmianę domyślnej nazwy gałęzi dla istniejącego repozytorium. Aby uzyskać więcej informacji, odwiedź stronę Zarządzanie gałęziami .

 

Uwaga: jeśli ta funkcja nie zostanie włączona, repozytoria zostaną zainicjowane przy użyciu nazwy domyślnej Azure Repos. W tej chwili wartość domyślna to master. Aby uczcić zaangażowanie firmy Microsoft i żądania klientów dotyczące języka inkluzywnego, dołączymy do partnerów branżowych , zmieniając to ustawienie domyślne na główne. Ta zmiana nastąpi jeszcze tego lata. Jeśli chcesz nadal korzystać z wzorca, należy teraz włączyć tę funkcję i ustawić ją na master.

Ustawienie na poziomie organizacji dla gałęzi domyślnej

Teraz istnieje ustawienie na poziomie kolekcji dla preferowanej początkowej nazwy gałęzi dla nowych repozytoriów. Jeśli projekt nie wybrał nazwy początkowej gałęzi, zostanie użyte to ustawienie na poziomie organizacji. Jeśli nie określisz początkowej nazwy gałęzi w ustawieniach organizacji lub ustawieniach projektu, nowe repozytoria będą używać zdefiniowanej wartości domyślnej usługi Azure DevOps.

Dodawanie nowego zakresu uwierzytelniania na potrzeby współtworzenia komentarzy do żądania ściągnięcia

W tej wersji dodano nowy zakres OAuth na potrzeby odczytywania/zapisywania komentarzy żądania ściągnięcia. Jeśli masz bota lub automatyzację, która wymaga tylko interakcji z komentarzami, możesz nadać mu token dostępu tylko w tym zakresie. Ten proces zmniejsza promień wybuchu, jeśli automatyzacja ma usterkę lub jeśli token został naruszony.

Ulepszenia środowiska żądania ściągnięcia

Ulepszono nowe środowisko żądania ściągnięcia, wykonując następujące czynności:

• Uwidocznij opcjonalne kontrole

Klienci korzystają z opcjonalnych kontroli, aby zwrócić uwagę dewelopera na potencjalne problemy. W poprzednim środowisku było to oczywiste, gdy te testy kończą się niepowodzeniem. Nie dotyczy to jednak środowiska w wersji zapoznawczej. Duży, zielony znacznik wyboru dla wymaganych kontroli maskuje błędy w opcjonalnych kontrolach. Użytkownicy mogli tylko wykryć, że opcjonalne kontrole nie powiodły się, otwierając panel sprawdzania. Deweloperzy nie często to robią, gdy nie ma żadnych oznak problemu. W tym wdrożeniu stan opcjonalnych testów stał się bardziej widoczny w podsumowaniu.

• Naciśnięcie klawiszy Ctrl w elementach menu

Menu tabulacji w żądaniom ściągnięcia nie obsługiwały naciśnięcia klawiszy Ctrl. Użytkownicy często otwierają nowe karty przeglądarki podczas przeglądania żądania ściągnięcia. Ten problem został rozwiązany.

• Lokalizacja adnotacji [+]

Lista drzewa plików w żądaniu ściągnięcia zawiera adnotację [+], aby ułatwić autorom i recenzentom identyfikowanie nowych plików. Ponieważ adnotacja była po wielokropku, często nie była widoczna dla dłuższych nazw plików.

• Lista rozwijana Aktualizacje żądania ściągnięcia odzyska informacje o chronometrażu

Lista rozwijana do wybierania aktualizacji i porównywania plików w żądaniu ściągnięcia straciła ważny element w środowisku podglądu. Nie było ono wyświetlane po wprowadzeniu tej aktualizacji. Ten problem został rozwiązany.

• **Ulepszony układ filtru komentarzy **

Podczas filtrowania komentarzy na stronie podsumowania żądania ściągnięcia lista rozwijana znajdowała się po prawej stronie, ale tekst był wyrównany do lewej. Ten problem został rozwiązany.

• Nawigacja do zatwierdzeń nadrzędnych

Na stronie Zatwierdzenia można porównać zmiany wprowadzone w określonym zatwierdzeniu z jego zatwierdzeniem nadrzędnym. Możesz jednak przejść do zatwierdzenia nadrzędnego i lepiej zrozumieć, jak to zatwierdzenie różni się od własnego elementu nadrzędnego. Jest to często potrzebne, gdy chcesz zrozumieć wszystkie zmiany w wersji. Dodaliśmy kartę elementów nadrzędnych do zatwierdzenia, aby ułatwić osiągnięcie tego celu.

• Więcej miejsca dla folderów i plików z długimi nazwami na karcie Pliki żądania ściągnięcia

Foldery i pliki o długich nazwach zostały odcięte z powodu braku odstępów w poziomie w drzewie plików. Odzyskaliśmy dodatkowe miejsce w drzewie, modyfikując wcięcie drzewa w celu dopasowania go do węzła głównego i ukrywając przycisk wielokropka na stronie z wyjątkiem aktywowania.

Obraz przedstawiający nowe drzewo plików:

Obraz drzewa plików po umieszczeniu wskaźnika myszy na katalogu:

• Zachowaj położenie przewijania podczas zmiany rozmiaru okienka różnic na karcie Pliki żądania ściągnięcia

W przypadku zmiany rozmiaru okienka różnic side-by-side na karcie Pliki żądania ściągnięcia lokalizacja przewijania użytkownika zostanie utracona. Ten problem został rozwiązany; lokalizacja przewijania użytkownika jest teraz zachowywana przy zmianie rozmiaru okienka różnicy.

• Wyszukiwanie zatwierdzenia na urządzeniu przenośnym

Podczas wyświetlania strony Zatwierdzenia na urządzeniu przenośnym w nowym środowisku brakuje pola wyszukiwania. W rezultacie trudno jest znaleźć zatwierdzenie przez jego skrót i otworzyć je. To zostało naprawione teraz.

• Ulepszone użycie miejsca dla nowego widoku plików żądania ściągnięcia dla urządzeń przenośnych

Zaktualizowaliśmy tę stronę, aby lepiej wykorzystać miejsce, aby użytkownicy mogli zobaczyć więcej plików w widokach mobilnych zamiast 40% ekranu zajętego przez nagłówek.

• Ulepszone obrazy w widoku podsumowania żądania ściągnięcia

Obrazy edytowane w żądaniu ściągnięcia nie były wyświetlane w widoku podsumowania żądania ściągnięcia, ale były wyświetlane poprawnie w widoku plików żądania ściągnięcia. Ten problem został rozwiązany.

• Ulepszone środowisko gałęzi podczas tworzenia nowego żądania ściągnięcia

Przed tą aktualizacją to środowisko nie było idealne, ponieważ porównuje zmiany z domyślną gałęzią repozytorium zamiast gałęzi porównawczej.

Pipelines

Dodatkowa platforma agenta: ARM64

Dodaliśmy system Linux/ARM64 do listy obsługiwanych platform dla agenta usługi Azure Pipelines. Chociaż zmiany w kodzie były minimalne, wiele prac zakulisowych musiało zostać ukończonych jako pierwsze i z przyjemnością ogłaszamy jej wydanie!

Obsługa filtru tagów dla zasobów potoku

Dodaliśmy teraz tagi w potokach YAML. Możesz użyć tagów, aby ustawić potok ciągłej integracji do uruchomienia lub czas automatycznego wyzwalania.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

Powyższy fragment kodu pokazuje, że tagi mogą służyć do określenia domyślnej wersji potoku ciągłej integracji (ciągłej integracji) do uruchomienia, gdy uruchomienie potoku ciągłego wdrażania (ciągłe wdrażanie) nie jest wyzwalane przez inne źródło/zasób lub zaplanowany wyzwalacz uruchamiania.

Jeśli na przykład masz ustawiony zaplanowany wyzwalacz dla potoku ciągłego wdrażania, który chcesz uruchomić tylko wtedy, gdy ciągła integracja ma tag produkcyjny, tagi w sekcji wyzwalaczy zapewniają, że potok ciągłego wdrażania jest wyzwalany tylko wtedy, gdy warunek tagowania jest spełniony przez zdarzenie ukończenia ciągłej integracji.

Kontrolowanie, które zadania są dozwolone w potokach

Teraz możesz wyłączyć zadania witryny Marketplace. Niektóre z nich mogą zezwalać na rozszerzenia witryny Marketplace, ale nie zadania Potoki, które są przez nie wykonywane. Aby uzyskać jeszcze większą kontrolę, możemy również niezależnie wyłączyć wszystkie zadania w pudełku (z wyjątkiem wyewidencjonowania, co jest akcją specjalną). Po włączeniu obu tych ustawień jedynymi zadaniami, które mogą być uruchamiane w potoku, będą te przekazywane przy użyciu narzędzia tfx. Odwiedź stronę https://dev.azure.com/<your_org>/_settings/pipelinessettings i poszukaj sekcji o nazwie "Ograniczenia zadań", aby rozpocząć pracę.

Zasady blokady wdrożenia wyłącznego

Dzięki tej aktualizacji można zagwarantować, że w danym momencie tylko jeden przebieg zostanie wdrożony w środowisku. Po wybraniu opcji "Blokada wyłączna" w środowisku będzie kontynuowane tylko jedno uruchomienie. Kolejne przebiegi, które mają zostać wdrożone w tym środowisku, zostaną wstrzymane. Po zakończeniu przebiegu z blokadą wyłączną będzie kontynuowany najnowszy przebieg. Wszystkie przebiegi pośrednie zostaną anulowane.

Filtry etapów dla wyzwalaczy zasobów potoku

Dodaliśmy obsługę "etapów" jako filtru dla zasobów potoku w języku YAML. Dzięki temu filtrowi nie trzeba czekać na ukończenie całego potoku ciągłej integracji w celu wyzwolenia potoku ciągłego wdrażania. Teraz możesz wyzwolić potok ciągłego wdrażania po zakończeniu określonego etapu w potoku ciągłej integracji.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Gdy etapy podane w filtrze wyzwalacza zostaną pomyślnie ukończone w potoku ciągłej integracji, nowy przebieg zostanie automatycznie wyzwolony dla potoku ciągłego wdrażania.

Ogólne wyzwalacze oparte na elementach webhook dla potoków YAML

Obecnie mamy różne zasoby (takie jak potoki, kontenery, kompilacja i pakiety), za pomocą których można korzystać z artefaktów i włączać automatyczne wyzwalacze. Do tej pory nie można było jednak zautomatyzować procesu wdrażania na podstawie innych zdarzeń zewnętrznych lub usług. W tej wersji wprowadzamy obsługę wyzwalacza elementu webhook w potokach YAML, aby umożliwić integrację automatyzacji potoków z dowolną usługą zewnętrzną. Możesz subskrybować dowolne zdarzenia zewnętrzne za pośrednictwem elementów webhook (Github, Github Enterprise, Nexus, Aritfactory itp.) i wyzwalać potoki.

Poniżej przedstawiono kroki konfigurowania wyzwalaczy elementu webhook:

1. Skonfiguruj element webhook w usłudze zewnętrznej. Podczas tworzenia elementu webhook należy podać następujące informacje:

   • Adres URL żądania — "https://dev.azure.com/<ADO collection>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
   • Wpis tajny — jest to opcjonalne. Jeśli musisz zabezpieczyć ładunek JSON, podaj wartość Wpisu tajnego

2. Utwórz nowe połączenie usługi "Przychodzący element webhook". Jest to nowo wprowadzony typ połączenia z usługą, który umożliwia zdefiniowanie trzech ważnych informacji:

   • Nazwa elementu webhook: nazwa elementu webhook powinna być zgodna z elementem webhook utworzonym w usłudze zewnętrznej.
   • Nagłówek HTTP — nazwa nagłówka HTTP w żądaniu zawierającym wartość skrótu ładunku na potrzeby weryfikacji żądania. Na przykład w przypadku usługi GitHub nagłówek żądania będzie mieć wartość "X-Hub-Signature"
   • Wpis tajny — wpis tajny służy do analizowania skrótu ładunku używanego do weryfikacji żądania przychodzącego (jest to opcjonalne). Jeśli podczas tworzenia elementu webhook użyto wpisu tajnego, musisz podać ten sam klucz tajny

   

3. Nowy typ zasobu o nazwie webhooks jest wprowadzany w potokach YAML. Aby subskrybować zdarzenie elementu webhook, należy zdefiniować zasób elementu webhook w potoku i wskazać je na przychodzące połączenie usługi elementu webhook. Możesz również zdefiniować dodatkowe filtry dla zasobu elementu webhook na podstawie danych ładunku JSON, aby dodatkowo dostosować wyzwalacze dla każdego potoku, a dane ładunku można używać w postaci zmiennych w zadaniach.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. Za każdym razem, gdy zdarzenie elementu webhook zostanie odebrane przez przychodzące połączenie usługi elementu webhook, zostanie wyzwolony nowy przebieg dla wszystkich potoków subskrybowanych zdarzenia elementu webhook.

Problemy z wyzwalaczem zasobów YAML — obsługa i możliwość śledzenia

Może to być mylące, gdy wyzwalacze potoku nie będą wykonywane zgodnie z oczekiwaniami. Aby lepiej zrozumieć ten problem, dodaliśmy nowy element menu na stronie definicji potoku o nazwie "Problemy z wyzwalaczem", w którym są wyświetlane informacje dotyczące przyczyn, dla których wyzwalacze nie są wykonywane.

Wyzwalacze zasobów mogą nie działać z dwóch powodów.

1. Jeśli źródło podanego połączenia z usługą jest nieprawidłowe lub jeśli w wyzwalaczu występują błędy składniowe, wyzwalacz nie zostanie w ogóle skonfigurowany. Są one wyświetlane jako błędy.

2. Jeśli warunki wyzwalacza nie są zgodne, wyzwalacz nie zostanie wykonany. Za każdym razem, gdy wystąpi taka sytuacja, zostanie wyświetlone ostrzeżenie, aby zrozumieć, dlaczego warunki nie zostały dopasowane.

   

Wyzwalacze z wieloma repozytoriami

Możesz określić wiele repozytoriów w jednym pliku YAML i spowodować wyzwolenie potoku przez aktualizacje dowolnego repozytorium. Ta funkcja jest przydatna na przykład w następujących scenariuszach:

• Używasz narzędzia lub biblioteki z innego repozytorium. Chcesz uruchamiać testy dla aplikacji przy każdej aktualizacji narzędzia lub biblioteki.
• Plik YAML należy przechowywać w osobnym repozytorium od kodu aplikacji. Chcesz wyzwolić potok za każdym razem, gdy aktualizacja jest wypychana do repozytorium aplikacji.

W przypadku tej aktualizacji wyzwalacze z wieloma repozytoriami będą działać tylko w przypadku repozytoriów Git w Azure Repos. Nie działają one w przypadku zasobów repozytorium GitHub ani BitBucket.

Oto przykład pokazujący sposób definiowania wielu zasobów repozytorium w potoku i konfigurowania wyzwalaczy na wszystkich z nich.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

Potok w tym przykładzie zostanie wyzwolony, jeśli istnieją jakiekolwiek aktualizacje:

• main gałąź w self repozytorium zawierającym plik YAML
• main lub release gałęzie w tools repozytorium

Aby uzyskać więcej informacji, zobacz Wiele repozytoriów w potoku.

Ulepszono przekazywanie dzienników agentów

Gdy agent przestanie komunikować się z serwerem usługi Azure Pipelines, zadanie, które zostało uruchomione, zostanie porzucone. Jeśli zdarzyło Ci się przeglądać dzienniki konsoli przesyłania strumieniowego, być może masz pewne wskazówki dotyczące tego, co agent był aż do prawej, zanim przestał odpowiadać. Ale jeśli nie, lub jeśli odświeżyłeś stronę, te dzienniki konsoli nie zostały wyświetlone. W tej wersji, jeśli agent przestanie odpowiadać przed wysłaniem pełnych dzienników, zachowamy dzienniki konsoli jako następną najlepszą rzecz. Dzienniki konsoli są ograniczone do 1000 znaków na wiersz i czasami mogą być niekompletne, ale są one o wiele bardziej przydatne niż pokazywanie niczego! Badanie tych dzienników może pomóc w rozwiązywaniu problemów z własnymi potokami i z pewnością pomoże naszym inżynierom pomocy technicznej w rozwiązywaniu problemów.

Opcjonalnie zainstaluj woluminy kontenerów tylko do odczytu

Po uruchomieniu zadania kontenera w usłudze Azure Pipelines kilka woluminów zawierających obszar roboczy, zadania i inne materiały są mapowane jako woluminy. Te woluminy domyślnie mają dostęp do odczytu/zapisu. Aby zwiększyć bezpieczeństwo, można zainstalować woluminy tylko do odczytu, zmieniając specyfikację kontenera w języku YAML. Każdy klucz w obszarze mountReadOnly można ustawić na true dla tylko do odczytu (wartość domyślna to false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Szczegółowa kontrola nad uruchamianiem/zatrzymywaniem kontenera

Ogólnie rzecz biorąc, zalecamy zezwolenie usłudze Azure Pipelines na zarządzanie cyklem życia kontenerów zadań i usług. Jednak w niektórych nietypowych scenariuszach możesz zacząć i zatrzymać je samodzielnie. W tej wersji utworzyliśmy tę funkcję w zadaniu platformy Docker.

Oto przykładowy potok korzystający z nowej możliwości:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Ponadto uwzględniamy listę kontenerów w zmiennej potoku , Agent.ContainerMapping. Można go użyć, jeśli chcesz sprawdzić listę kontenerów w skrycie, na przykład. Zawiera on ciągowany obiekt JSON mapowania nazwy zasobu ("builder" z powyższego przykładu) na identyfikator kontenera zarządzany przez agenta.

Rozpakuj pakiety zadań dla każdego kroku

Gdy agent uruchamia zadanie, najpierw pobiera wszystkie pakiety zadań wymagane przez kroki zadania. Zwykle w przypadku wydajności rozpakowuje zadania raz na zadanie, nawet jeśli zadanie jest używane w wielu krokach. Jeśli masz obawy dotyczące niezaufanego kodu zmieniającego rozpakowaną zawartość, możesz zmniejszyć wydajność, rozpakowując zadanie przy każdym użyciu. Aby włączyć ten tryb, należy przekazać go --alwaysextracttask podczas konfigurowania agenta.

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

Bazując na naszej inicjatywie w celu ulepszenia ustawień zabezpieczeń dla usługi Azure Pipelines, obsługujemy teraz ograniczanie zakresu tokenów dostępu dla wydań.

Każde zadanie uruchamiane w wersjach otrzymuje token dostępu. Token dostępu jest używany przez zadania i skrypty do wywołania z powrotem do usługi Azure DevOps. Na przykład używamy tokenu dostępu do pobierania kodu źródłowego, pobierania artefaktów, przekazywania dzienników, wyników testów lub nawiązywania wywołań REST do usługi Azure DevOps. Nowy token dostępu jest generowany dla każdego zadania i wygasa po zakończeniu zadania.

Dzięki tej aktualizacji zwiększamy bezpieczeństwo potoków, ograniczając zakres tokenów dostępu i rozszerzając je do wersji klasycznych.

Ta funkcja będzie domyślnie włączona dla nowych projektów i kolekcji. W przypadku istniejących kolekcji należy ją włączyć w ustawieniach potoków > kolekcji>. > Ogranicz zakres autoryzacji zadań do bieżącego projektu dla potoków wydania. Więcej informacji można znaleźć tutaj.

Ulepszenia interfejsu API w wersji zapoznawczej YAML

Teraz możesz wyświetlić podgląd kompletnego kodu YAML potoku bez jego uruchamiania. Ponadto utworzyliśmy dedykowany nowy adres URL dla funkcji w wersji zapoznawczej. Teraz możesz wykonać post, aby https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview pobrać sfinalizowaną treść YAML. Ten nowy interfejs API przyjmuje te same parametry co kolejkowanie przebiegu, ale nie wymaga już uprawnień "Kompilacje kolejki".

Uruchom to zadanie dalej

Czy kiedykolwiek miałeś poprawkę usterek, którą trzeba było wdrożyć w tej chwili , ale trzeba było czekać za zadaniami ciągłej integracji i żądania ściągnięcia? Dzięki tej wersji możemy teraz podnieść priorytet zadania w kolejce. Użytkownicy z uprawnieniem "Zarządzaj" w puli — zazwyczaj administratorzy puli — zobaczą nowy przycisk "Uruchom dalej" na stronie szczegółów zadania. Kliknięcie przycisku spowoduje, że zadanie zostanie uruchomione tak szybko, jak to możliwe. (Nadal będziesz potrzebować dostępnego równoległości i odpowiedniego agenta, oczywiście).

Wyrażenia szablonów dozwolone w bloku YAML resources

Wcześniej wyrażenia czasu kompilacji (${{ }}) nie były dozwolone w resources sekcji pliku YAML usługi Azure Pipelines. W tej wersji zniesiono to ograniczenie dla kontenerów. Umożliwia to użycie zawartości parametrów środowiska uruchomieniowego wewnątrz zasobów, na przykład w celu wybrania kontenera w czasie kolejki. Planujemy rozszerzyć tę obsługę na inne zasoby w czasie.

Kontrola nad automatycznymi aktualizacjami zadań z witryny Marketplace

Podczas pisania potoku YAML zwykle określa się tylko numer wersji głównej uwzględnionych zadań. Dzięki temu potoki mogą automatycznie korzystać z najnowszych dodatków funkcji i poprawek błędów. Czasami może być konieczne wycofanie do poprzedniej wersji zadania w punkcie, a wraz z tą aktualizacją dodaliśmy możliwość wykonania tej czynności. Teraz możesz określić pełną wersję zadania major.minor.patch w potokach YAML.

Nie zalecamy regularnego wykonywania tej czynności i używania jej tylko jako tymczasowego obejścia, gdy okaże się, że nowsze zadanie przerywa potoki. Ponadto nie spowoduje to zainstalowania starszej wersji zadania z witryny Marketplace. Musi już istnieć w kolekcji lub potok zakończy się niepowodzeniem.

Przykład:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Obsługa węzła 10 w agentach i zadaniach

Ponieważ węzeł 6 nie jest już obsługiwany, migrujemy zadania do pracy z węzłem Node 10. W przypadku tej aktualizacji przeprowadziliśmy migrację prawie 50% zadań wbudowanych do węzła 10. Agent może teraz uruchamiać zadania węzła 6 i węzła 10. W przyszłej aktualizacji całkowicie usuniemy węzeł Node 6 z agenta. Aby przygotować się do usunięcia węzła Node 6 z agenta, prosimy o zaktualizowanie wewnętrznych rozszerzeń i zadań niestandardowych w celu korzystania z węzła 10 wkrótce. Aby użyć węzła 10 dla zadania, w obszarze task.jsonw obszarze executionzaktualizuj element z Node do Node10.

Ulepszanie konwersji YAML w klasycznym projektancie kompilacji

W tej wersji wprowadzimy nową funkcję "eksportu do języka YAML" dla potoków kompilacji projektanta. Zapisz definicję potoku, a następnie znajdź pozycję "Eksportuj do YAML" w ... menu.

Nowa funkcja eksportu zastępuje funkcję "View as YAML" wcześniej znalezioną w klasycznym projektancie kompilacji. Ta funkcja była niekompletna, ponieważ mogła sprawdzić tylko to, co internetowy interfejs użytkownika wiedział o kompilacji, co czasami doprowadziło do wygenerowania nieprawidłowego kodu YAML. Nowa funkcja eksportu uwzględnia dokładnie sposób przetwarzania potoku i generuje kod YAML z pełną wiernością potoku projektanta.

Nowa konwersja platformy internetowej — ustawienia repozytorium

Przekonwertowaliśmy dwie strony ustawień repozytorium na jedno środowisko, które zostało uaktualnione do nowej platformy internetowej. To uaktualnienie nie tylko sprawia, że środowisko jest szybsze i bardziej nowoczesne, ale te strony zapewniają również pojedynczy punkt wejścia dla wszystkich zasad z poziomu projektu do poziomu gałęzi.

Dzięki temu nowe środowisko nawigacji dla projektów z dużą liczbą repozytoriów stało się łatwiejsze z powodu szybszego ładowania i dodanego filtru wyszukiwania. Możesz również wyświetlić zasady na poziomie projektu i listę zasad między repozytoriami na karcie Zasady.

Jeśli klikniesz do repozytorium, możesz wyświetlić zasady i uprawnienia ustawione na poziomie repozytorium. Na karcie Zasady można wyświetlić listę każdej gałęzi, na której ustawiono zasady. Teraz kliknij gałąź, aby wyświetlić zasady, nie opuszczając strony Ustawienia repozytorium.

Teraz, gdy zasady są dziedziczone z wyższego zakresu niż to, z czym pracujesz, pokazujemy, gdzie zasady zostały odziedziczone obok poszczególnych zasad. Możesz również przejść do strony, na której ustawiono zasady wyższego poziomu, klikając nazwę zakresu.

Sama strona zasad została również uaktualniona do nowej platformy internetowej z zwijanymi sekcjami! Aby ulepszyć środowisko wyszukiwania dla określonych zasad weryfikacji kompilacji, sprawdzania stanu lub automatycznego recenzenta, dodaliśmy filtry wyszukiwania dla każdej sekcji.

Integracja zarządzania zmianami usługi ServiceNow z potokami YAML

Aplikacja Azure Pipelines dla usługi ServiceNow ułatwia integrację usług Azure Pipelines i ServiceNow Change Management. Dzięki tej aktualizacji zapoznamy się z procesem zarządzania zmianami zarządzanym w usłudze ServiceNow w potokach YAML przez usługę Azure Pipelines.

Konfigurując sprawdzanie zasobu "Zarządzanie zmianami usługi ServiceNow", można teraz wstrzymać zatwierdzenie zmiany przed wdrożeniem kompilacji w tym zasobie. Możesz automatycznie utworzyć nową zmianę dla etapu lub poczekać na istniejące żądanie zmiany.

Możesz również dodać UpdateServiceNowChangeRequest zadanie w zadaniu serwera, aby zaktualizować żądanie zmiany o stan wdrożenia, notatki itp.

Artifacts

Możliwość tworzenia kanałów informacyjnych o zakresie organizacji na podstawie interfejsu użytkownika

Przywracamy klientom możliwość tworzenia kanałów informacyjnych o zakresie kolekcji i zarządzania nimi za pośrednictwem internetowego interfejsu użytkownika zarówno dla usług lokalnych, jak i hostowanych.

Teraz możesz tworzyć źródła danych o zakresie organizacji za pośrednictwem interfejsu użytkownika, przechodząc do sekcji Artifacts — Create Feed (Artefakty —> tworzenie kanału informacyjnego) i wybierając typ kanału informacyjnego w obszarze Zakres.

Chociaż zalecamy użycie źródeł danych o zakresie projektu zgodnie z pozostałymi ofertami usługi Azure DevOps, możesz ponownie tworzyć źródła danych o zakresie kolekcji i zarządzać nimi za pośrednictwem interfejsu użytkownika i różnych interfejsów API REST. Aby uzyskać więcej informacji, zobacz naszą dokumentację kanałów informacyjnych.

Aktualizowanie interfejsu API REST wersji pakietu jest teraz dostępne dla pakietów Maven

Teraz możesz użyć interfejsu API REST "Update Package Version" usługi Azure Artifacts, aby zaktualizować wersje pakietu Maven. Wcześniej można było użyć interfejsu API REST do aktualizowania wersji pakietów dla pakietów NuGet, Maven, npm i Universal Packages, ale nie pakietów Maven.

Aby zaktualizować pakiety Maven, użyj polecenia HTTP PATCH w następujący sposób.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Można ustawić następujące elementy:

Parametry identyfikatora URI

Nazwa	W	Wymagane	Typ	Opis
artifactId	path	TRUE	ciąg	Identyfikator artefaktu pakietu
Paszy	path	TRUE	ciąg	Nazwa lub identyfikator kanału informacyjnego
groupId	path	TRUE	ciąg	Identyfikator grupy pakietu
— kolekcja	path	TRUE	ciąg	Nazwa kolekcji Usługi Azure DevOps
Wersja	path	TRUE	ciąg	Wersja pakietu
projekt	path		ciąg	Identyfikator projektu lub nazwa projektu
api-version	query	TRUE	ciąg	Wersja interfejsu API do użycia. Ta wartość powinna być ustawiona na wartość "5.1-preview.1", aby używać tej wersji interfejsu API

Treść żądania

Nazwa	Typ	Opis
widoki	JsonPatchOperation	Widok, do którego zostanie dodana wersja pakietu

Aby uzyskać więcej informacji, zapoznaj się z dokumentacją interfejsu API REST podczas aktualizowania.

Opinia

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

---

Górna część strony