Azure DevOpsServer 2020 Update 1 — informacje o wersji

Skróty SHA-1 bloga | DevOps dotyczące wymagań systemowych | dla | społeczności | deweloperów

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 Usługi Azure DevOps, odwiedź stronę pobierania usługi 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 przebiegu potoku (kompilacji), 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 zasad 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 1.2 Patch 13 Data wydania: 12 marca 2024 r.

Plik	Skrót SHA-256
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

Opublikowaliśmy poprawkę 13 dla usługi 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.

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

Opublikowaliśmy poprawkę 12 dla usługi 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 było obliczane niepoprawnie i folder nie był prawidłowo czyszczony.
• CVE-2024-20667: Luka w zabezpieczeniach dotycząca zdalnego wykonywania kodu serwera Azure DevOps Server.

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

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

Opublikowaliśmy poprawkę 11 dla usługi 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 usługi Azure DevOps Server 2020 Update 1.2, która zawiera poprawki dla następujących elementów.

• Rozszerzono listę dozwolonych zadań programu PowerShell dla opcji Włącz sprawdzanie poprawności parametrów argumentów zadań powłoki.

Uwaga

Aby zaimplementować poprawki dla tej poprawki, należy wykonać kilka kroków w celu rę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 rozwiązania TFX

1. Wykonaj kroki opisane w dokumentacji przekazywania zadań do kolekcji projektów, aby zainstalować i zalogować się za pomocą interfejsu wiersza polecenia 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 wyodrębnione pliki.
3. Wykonaj następujące polecenia, aby przekazać zadania:

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

Wymagania dotyczące potoku

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

• W wersji klasycznej:

  Zdefiniuj zmienną na karcie zmiennej w potoku.

• Przykład YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 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 usługi 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 uaktualnień poprawek.

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

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

Aktualizowanie agenta usługi Azure Pipelines

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

Uwaga

AZP_AGENT_DOWNGRADE_DISABLED musi być ustawiona na wartość "true", aby zapobiec obniżeniu poziomu agenta. W systemie Windows następujące polecenie może być używane w wierszu polecenia administracyjnego, a następnie ponowne uruchomienie. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Konfigurowanie rozwiązania TFX

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

Aktualizowanie zadań przy użyciu narzędzia TFX

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

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

Wymagania dotyczące potoku

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

• W wersji klasycznej:

  Zdefiniuj zmienną na karcie zmiennej w potoku.

• Przykład YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Opublikowaliśmy poprawkę dla usługi 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 fałszowania serwera Azure DevOps.
• Zaktualizuj usługę SSH, aby obsługiwać algorytm 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 zatwierdzenia.
• Usunięto usterkę polegającą na tym, że tożsamość właściciela analizy zawierała wartość Nieaktywna tożsamość.
• Usunięto usterkę nieskończonej pętli w CronScheduleJobExtension.

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

Opublikowaliśmy poprawkę dla usługi 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 fałszowania serwera Azure DevOps Server.
• CVE-2023-21569: Luka w zabezpieczeniach dotycząca fałszowania serwera Azure DevOps Server.
• Usunięto usterkę zakłócającą wypychanie pakietów podczas uaktualniania z wersji 2018 lub starszej.
• Usunięto usterkę polegającą na tym, że niepowodzenie odłączania lub dołączania kolekcji nie zgłaszało 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 usługi 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 w usłudze 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 usługi Azure DevOps Server po zaktualizowaniu ustawienia związanego z protokołem SMTP w konsoli zarządzania serwera Azure DevOps Server.

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

Opublikowaliśmy poprawkę dla usługi 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.

• Nie usunięto danych testowych, co spowodowało wzrost bazy danych. Dzięki tej poprawce zaktualizowaliśmy przechowywanie kompilacji, aby zapobiec tworzeniu nowych danych testowych oddzielonych.

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

Opublikowaliśmy poprawkę dla usługi 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 żądanym przez członka filtru 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 uwierzytelnionymi serwerami proxy.

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

Opublikowaliśmy poprawkę dla usługi 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 jest wyświetlana w różnych domenach.

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

Opublikowaliśmy poprawkę dla usługi 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 zestawienie poprawek błędów. Możesz bezpośrednio zainstalować usługę Azure DevOps Server 2020 Update 1.2 lub uaktualnić z programu Azure DevOps Server 2020 lub Team Foundation Server 2013 lub nowszego.

Uwaga

Narzędzie do migracji danych będzie dostępne dla usługi 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:

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

  • Tworzenie dzierżaw dla najnowszych 3 kompilacji wygenerowanych podczas działania programu Server 2020
  • W przypadku potoków YAML i potoków klasycznych bez zasad przechowywania potoku kompilacje będą zachowywane 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 w kierunku minimum, aby zachować ustawienie

• Linki komentarzy do zestawu 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 półek, wybranie tych komentarzy nie było przekierowywane do właściwego miejsca w widoku pliku.

• 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 usługi Azure DevOps Server 2020.1.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.
• 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, jak podano 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.

Uwaga

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 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 C:\Program Files\{TFS Version Folder}\Search\zip folderze zdalnym elasticsearch.
4. Uruchom polecenie Configure-TFSSearch.ps1 -Operation update na maszynie serwera Elasticsearch.

SKRÓT SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F65F29D6

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

Poprawka 3 dla usługi 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 zawierających 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 usługi Azure DevOps Server 2020.1.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 usługi 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.1.1 Patch 1 Data wydania: 14 września 2021 r.

Poprawka 1 dla usługi 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 zestawienie poprawek błędów. Możesz bezpośrednio zainstalować usługę Azure DevOps Server 2020 Update 1.1 lub uaktualnić z programu Azure DevOps Server 2020 lub Team Foundation Server 2013 lub nowszego.

Uwaga

Narzędzie do migracji danych będzie dostępne dla usługi 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 ograniczone pola wyboru dziedziczenia typów scalania, aby włączyć modyfikowanie typów scalania limitów po ustawieniu zasad repozytorium krzyżowego.

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 wrócić do wyników testów po powrocie z historii do strony podsumowania.

---

Azure DevOps Server 2020.1 Patch 2 — data wydania: 10 sierpnia 2021 r.

Opublikowaliśmy poprawkę dla usługi 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 Patch 1 — data wydania: 15 czerwca 2021 r.

Opublikowaliśmy poprawkę dla usługi 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 poprawnie analizowane.

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

Podsumowanie nowości w usłudze Azure DevOps Server 2020.1 RTW

Usługa Azure DevOps Server 2020.1 RTW to zestawienie poprawek błędów. Obejmuje ona wszystkie funkcje wcześniej wydanego serwera Azure DevOps Server 2020.1 RC2. Usługa 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ć z programu Azure DevOps Server 2020, 2019 lub Team Foundation Server 2015 lub nowszego.

Uwaga

Narzędzie do migracji danych będzie dostępne dla usługi 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 usłudze Azure DevOps Server 2020.1 RC2

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

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

Podsumowanie nowości w usłudze Azure DevOps Server 2020.1 RC1

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

• Reguły ograniczeń przejścia stanu w tablicach
• Uczestnicy projektu mogą teraz przenosić elementy robocze między kolumnami
• Ulepszenie zabezpieczeń wersji dzięki ograniczeniu 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:

• Tablice
• Repos
• Pipelines
• Artefakty

---

Boards

Reguły ograniczeń przejścia stanu

Nadal zamykamy lukę parzystości funkcji między hostowanymi plikami XML i odziedziczonym modelem procesu. Ta nowa reguła typu elementu roboczego umożliwia ograniczenie przenoszenia elementów roboczych z jednego stanu do innego. Można na przykład ograniczyć przechodzenie błędów z obszaru Nowy do Rozwiązane. Zamiast tego muszą przejść z obszaru New —> Active —> Resolved

Możesz również utworzyć regułę, 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 Nowe —> zatwierdzone.

Kopiowanie elementu roboczego w celu skopiowania elementów podrzędnych

Jedną z najbardziej żądanych funkcji usługi Azure Boards jest możliwość kopiowania elementu roboczego, który również kopiuje 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 dotyczące aktywowanych i rozwiązanych pól

Do tej pory reguły Aktywowane przez, Aktywowana data, Rozwiązane przez i Rozwiązane daty były tajemnicą. Są one ustawiane tylko dla typów elementów roboczych systemu 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ą one 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 "Aktywne" na "Wymaga testowania", zostaną wyzwolone reguły Rozpoznane przez i Rozwiązane daty .

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

Uczestnicy projektu mogą przenosić elementy robocze między kolumnami

Uczestnicy projektu zawsze byli w stanie zmienić stan elementów roboczych. Jednak po przejściu do tablicy Kanban nie mogą przenieść elementów roboczych z jednej kolumny do innej. Zamiast tego uczestnicy projektu musieliby otworzyć każdy element roboczy, pojedynczo 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.

Typy elementów roboczych systemu w ramach listy prac i na 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ń.

Przetwarzaj	Typ elementu roboczego
Zwinność	Problem
Scrum	Przeszkoda
CMMI	Żądanie zmiany
	Problem
	Wykonaj przegląd
	Ryzyko

Dodawanie typu elementu roboczego systemu do poziomu listy prac jest proste. Wystarczy przejść do procesu niestandardowego i kliknąć kartę Poziomy listy prac. Wybierz wybrany poziom listy prac (na przykład: Listę prac wymagań) i wybierz opcję edycji. Następnie dodaj typ elementu roboczego.

Podniesiono limit repozytorium aplikacji GitHub w usłudze Azure Boards

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

Dostosowywanie stanu elementu roboczego podczas scalania żą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żesz łatwo śledzić zależności kompilacji między projektem, łą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 działanie, 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 pól 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 podczas scalania żą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 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" w typie 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 powitania. Jedna zasada 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 Usterka w procesie Agile.

"Ustaw wartość Przypisano 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 elementu roboczego Usterka w procesie Agile. Ta zmiana wpłynie na każdy projekt przy użyciu odziedziczonego procesu Agile lub niestandardowego dziedziczonego procesu Agile. Dla tych klientów, którzy lubią i zależą od tej bieżącej reguły, zobacz nasz wpis w blogu na temat kroków, które można wykonać, aby ponownie dodać regułę przy użyciu reguł niestandardowych.

Usunięto elementy ze strony Elementy robocze

Strona Elementy robocze to doskonałe miejsce do szybkiego znajdowania utworzonych elementów lub przypisanych do Ciebie. 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 wyświetla on 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ą i dlatego została usunięta z listy prac, więc dołączenie ich w tym widoku nie jest pomocne.

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

Usługa Azure Repos oferuje teraz 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. Usługa Azure Repos zawsze obsługiwała zmianę domyślnej nazwy gałęzi dla istniejącego repozytorium.

Aby uzyskać więcej informacji, zobacz Zarządzanie gałęziami i Zmienianie gałęzi domyślnej.

Ustawienie gałęzi domyślnej na poziomie organizacji

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

Dodanie nowego zakresu uwierzytelniania na potrzeby dodawania komentarzy do żądań ściągnięcia

W tej wersji dodano nowy zakres protokołu OAuth do odczytywania/zapisywania komentarzy do żą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 czy token został naruszony.

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

Nowe środowisko żądania ściągnięcia zostało ulepszone o następujące elementy:

• Uwidocznij opcjonalne kontrole

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

• Naciśnięcie Ctrl w elementach menu

Menu tabulatorów w żądań ściągnięcia nie obsługiwało naciśnięcia 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 pokazano, kiedy ta aktualizacja została wykonana. 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 został 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 o długich nazwach na karcie plików żą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 trochę dodatkowego miejsca w drzewie, modyfikując wcięcie drzewa w celu dopasowania do węzła głównego i ukrywając przycisk wielokropka ze strony z wyjątkiem wskaźnika myszy.

Obraz przedstawiający nowe drzewo plików:

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

• Zachowanie położenia przewijania podczas zmiany rozmiarów okienka różnic na karcie plików żądania ściągnięcia

W przypadku zmiany rozmiaru okienka różnic obok siebie 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óżnic.

• Wyszukiwanie zatwierdzania na urządzeniu przenośnym

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

• Ulepszone wykorzystanie przestrzeni na potrzeby nowego widoku różnic plików żądania ściągnięcia wyświetlanego na urządzeniach mobilnych

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.

• Rozszerzone 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 rozgałęzienia 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ównania.

Pipelines

Dodatkowa platforma agenta: ARM64

Dodaliśmy system Linux/ARM64 do listy obsługiwanych platform dla agenta usługi Azure Pipelines. Chociaż zmiany kodu były minimalne, wiele prac zakulisowych musiało zostać ukończonych jako pierwsze i cieszymy się, że ogłosimy jej wydanie!

Obsługa filtrów 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 kiedy automatycznie wyzwalać.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    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łego wdrażania) ciągłego wdrażania 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.

Kontrola nad tym, które zadania są dozwolone w potokach

Teraz można wyłączyć zadania witryny Marketplace. Niektóre z nich mogą zezwalać na rozszerzenia witryny Marketplace, ale nie zadania potoków, które wykonują. 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 funkcji 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 na wyłączność

Dzięki tej aktualizacji można zagwarantować, że w danym momencie tylko jeden przebieg zostanie wdrożony w środowisku. Po wybraniu kontroli "Blokada wyłączna" w środowisku będzie kontynuowane tylko jedno uruchomienie. Kolejne uruchomienia, które chcą 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łej integracji. 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, kompilacje 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 potoku 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/<kolekcja> ADO/_apis/public/distributedtask/webhooks/<nazwa> elementu webhook?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 usługi, 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, który zawiera 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 — klucz 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 wyzwolone nowe uruchomienie dla wszystkich potoków subskrybowanych do 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 braku wykonywania wyzwalaczy.

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 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. Zawsze, gdy tak się stanie, zostanie wyświetlone ostrzeżenie, aby zrozumieć, dlaczego warunki nie zostały dopasowane.

   

Wyzwalacze z wieloma repozytoriami

Można 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 za każdym razem, gdy narzędzie lub biblioteka zostanie zaktualizowana.
• Plik YAML należy przechowywać w osobnym repozytorium od kodu aplikacji. Chcesz wyzwolić potok za każdym razem, gdy aktualizacja zostanie wypchnięta do repozytorium aplikacji.

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

Oto przykład pokazujący, jak zdefiniować wiele zasobów repozytorium w potoku i jak skonfigurować wyzwalacze 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.

Ulepszone przekazywanie dziennika agenta

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 znikną. 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.

Opcjonalne instalowanie woluminów 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. W celu zwiększenia bezpieczeństwa można zainstalować woluminy tylko do odczytu, zmieniając specyfikację kontenera w języku YAML. Dla każdego klucza w obszarze mountReadOnly można ustawić wartość tylko do true 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 procesem uruchamiania/zatrzymywania kontenera

Ogólnie rzecz biorąc, zalecamy umożliwienie usłudze Azure Pipelines zarządzania cyklem życia zadań i kontenerów 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żesz to użyć, jeśli chcesz sprawdzić listę kontenerów w skry skrycie, na przykład. Zawiera on ciągyfikowany obiekt JSON mapowania nazwy zasobu ("builder" z powyższego przykładu) na identyfikator kontenera, którym zarządza agent.

Rozpakowywanie pakietów zadań dla poszczególnych kroków

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 wymienić trochę wydajności, rozpakowując zadanie przy każdym użyciu. Aby włączyć ten tryb, należy przekazać --alwaysextracttask go podczas konfigurowania agenta.

Ulepszenie zabezpieczeń wersji dzięki ograniczeniu zakresu tokenów dostępu

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

Każde zadanie uruchamiane w wersjach pobiera 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, pobrać artefakty, przekazać dzienniki, wyniki testów 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 zwiększamy bezpieczeństwo potoku, ograniczając zakres tokenów dostępu i rozszerzając je na wersje klasyczne.

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 > ustawień kolekcji. > > Ogranicz zakres autoryzacji zadań do bieżącego projektu dla potoków wydania. Dowiedz się więcej tutaj.

Ulepszenia interfejsu API podglądu języka 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 utworzyć 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ż uprawnienia "Kompilacje kolejki".

Uruchomienie tego zadania jako następne

Czy kiedykolwiek masz 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? W tej wersji umożliwiamy teraz podbicie priorytetu 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 zniosliśmy to ograniczenie dla kontenerów. Dzięki temu można używać zawartości parametrów środowiska uruchomieniowego wewnątrz zasobów, na przykład do wybierania kontenera w czasie kolejki. Planujemy rozszerzyć tę pomoc techniczną na inne zasoby w czasie.

Kontrola nad automatycznymi aktualizacjami zadań z poziomu 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 punktu, 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ł Node 6 nie jest już obsługiwany, migrujemy zadania do pracy z węzłem Node 10. W przypadku tej aktualizacji zmigrowaliśmy prawie 50% zadań wbudowanych do węzła 10. Agent może teraz uruchamiać zadania node 6 i Node 10. W przyszłej aktualizacji całkowicie usuniemy węzeł Node 6 z agenta. Aby przygotować się do usunięcia węzła 6 z agenta, prosimy o zaktualizowanie rozszerzeń w firmie i zadań niestandardowych w celu korzystania z węzła 10 wkrótce. Aby użyć węzła 10 dla zadania, w obszarze , executionzaktualizuj task.jsonelement z Node do Node10.

Ulepszono konwersję YAML w klasycznym projektancie kompilacji

W tej wersji wprowadzimy nową funkcję "eksportuj 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 tylko sprawdzić, 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 ze znaczną 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 bez opuszczania 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 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.

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

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

Artifacts

Możliwość tworzenia źródeł danych o zakresie organizacji na podstawie interfejsu użytkownika

Przywracamy możliwość tworzenia kanałów informacyjnych w 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 źródła danych w obszarze Zakres.

Chociaż zalecamy użycie źródeł danych o zakresie projektu zgodnie z pozostałymi ofertami usługi Azure DevOps, można 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 dokumentację kanałów informacyjnych.

Interfejs API REST aktualizacji wersji pakietu jest teraz dostępny dla pakietów narzędzia Maven

Teraz możesz użyć interfejsu API REST "Aktualizuj wersję pakietu" w usłudze Azure Artifacts, aby zaktualizować wersje pakietu Maven. Wcześniej można było użyć interfejsu API REST do aktualizowania wersji 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 ustawienia:

Parametry identyfikatora URI

Nazwa/nazwisko	In	Wymagane	Type	Opis
artifactId	path	PRAWDA	string	Identyfikator artefaktu pakietu
źródło	path	PRAWDA	string	Nazwa lub identyfikator kanału informacyjnego
groupId	path	PRAWDA	string	Identyfikator grupy pakietu
— kolekcja	path	PRAWDA	string	Nazwa kolekcji usługi Azure DevOps
version	path	PRAWDA	string	Wersja pakietu
projekt	path		string	Identyfikator projektu lub nazwa projektu
api-version	zapytanie	PRAWDA	string	Wersja interfejsu API do użycia. Należy ustawić wartość "5.1-preview.1", aby użyć tej wersji interfejsu API

Treść żądania

Nazwa/nazwisko	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ć Twoje zdanie! Możesz zgłosić problem lub podać pomysł i śledzić go za pośrednictwem społeczności deweloperów i uzyskać porady na temat stack Overflow.

---

Początek strony