Azure DevOps Server 2020 Update 1: informacje o wersji
Społeczność deweloperów | Wymagania systemowe | Warunki licencji | Blog DevOps | Skróty SHA-1
Ten artykuł zawiera informacje dotyczące najnowszej wersji usługi Azure DevOps Server.
Aby dowiedzieć się więcej na temat instalowania lub uaktualniania wdrożenia usługi Azure DevOps Server, zobacz Wymagania dotyczące usługi Azure DevOps Server. Aby pobrać produkty 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 powodują usunięcie przebiegów potoku po aktualizacji. Przebiegi potoków, które zostały ręcznie zachowane lub są zachowywane przez proces wydania, nie zostaną usunięte po aktualizacji.
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 15 Data wydania: 11 marca 2025 r.
Plik | Skrót SHA-256 |
---|---|
devops2020.1.2patch15.exe | 66B6FDE4949C0B7A87B20F3BC8E0673774401929D8B75E37F599DFF8BA74ABE5 |
Opublikowaliśmy Patch 15 dla usługi Azure DevOps Server 2020 Update 1.2, aby uwzględnić następujące elementy:
- Zaktualizuj zadania z powodu wycofania usługi Edgio CDN. Aby uzyskać więcej informacji, zapoznaj się z wpisem w blogu Przełączanie dostawców usługi CDN.
Azure DevOps Server 2020 Update 1.2 Patch 14 Data wydania: 12 listopada 2024 r.
Plik | Skrót SHA-256 |
---|---|
devops2020.1.2patch14.exe | 89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420 |
Opublikowaliśmy poprawkę 14 dla usługi Azure DevOps Server 2020 Update 1.2, aby uwzględnić uaktualnienie do zależności podatnej na zagrożenia.
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 haszujący 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ń zatwierdzeń przed wdrożeniem nie działało na etapach pipeline'ó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 znaków dla zadań programu PowerShell w 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
- Wykonaj kroki w instrukcjach przekazywania zadań do kolekcji projektów, aby zainstalować i zalogować się za pomocą tfx-cli.
Aktualizowanie zadań przy użyciu narzędzia TFX
Plik | Skrót SHA-256 |
---|---|
Tasks20231103.zip | 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9EFCED5034D2E5 |
- Pobierz i wyodrębnij Tasks20231103.zip.
- Zmień katalog na wyodrębnione pliki.
- Wykonaj następujące polecenia, aby załadować zadania:
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip
Wymagania dotyczące rurociągu
Aby 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ą w zakładce zmiennych 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 pokazywana jako nieaktywna na maszynach podczas aktualizacji 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
- Pobierz i zainstaluj poprawkę 8 usługi Azure DevOps Server 2020 Update 1.2.
Aktualizowanie agenta usługi Azure Pipelines
- Pobierz agenta z: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
- Aby wdrożyć agenta, wykonaj kroki opisane w dokumentacji własnych agentów systemu Windows.
Uwaga
AZP_AGENT_DOWNGRADE_DISABLED musi być ustawiony na wartość "true", aby zapobiec degradacji agenta. W systemie Windows następujące polecenie może być używane w wierszu polecenia administracyjnego, po czym należy zrestartować system. setx AZP_AGENT_DOWNGRADE_DISABLED true /M
Konfigurowanie rozwiązania TFX
- Postępuj zgodnie z krokami w dokumentacji przekazywania zadań do kolekcji projektów, aby zainstalować i zalogować się za pomocą tfx-cli.
Aktualizowanie zadań przy użyciu narzędzia TFX
- Pobierz i wyodrębnij Tasks_20230825.zip.
- Zmień katalog na wyodrębnione pliki.
- Wykonaj następujące polecenia, aby przesłać zadania.
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip
Wymagania dotyczące rurociągu
Aby 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ą w zakładce zmiennych 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ę, w wyniku której tożsamość właściciela analizy pokazywała się jako "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 związana z fałszowaniem w Azure DevOps Server.
- CVE-2023-21569: Luka związana z fałszowaniem w Azure DevOps Server.
- Usunięto usterkę zakłócającą wypychanie pakietów podczas uaktualniania z wersji 2018 lub starszej.
- Usunięto usterkę powodującą, że odłączanie lub dołączanie kolekcji kończyło się niepowodzeniem, zgłaszając następujący błąd: "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 buildów, aby zapobiegać tworzeniu nowych osieroconych danych testowych.
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 AD, które nie pojawiają się w oknach dialogowych wyboru tożsamości dla zabezpieczeń.
- Rozwiązano problem z filtrem "Żądane przez członka grupy" w ustawieniach webhooków.
- Naprawiono błąd kompilacji gated check-in, gdy ustawienia organizacji dla potoku miały zakres autoryzacji zadania skonfigurowany jako Ogranicz zakres autoryzacji zadania do bieżącego projektu dla potoków innych niż wydawnicze.
- Naprawiono pobieranie tokenu dostępu z Azure przy ustanawianiu połączenia usługi za autoryzowanym serwerem 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 dla przebiegów testów token kontynuacji, który był zwracany, był większy niż wartość określona jako "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 klasycznych bez indywidualnych zasad przechowywania dla potoków kompilacje będą przechowywane zgodnie z ustawieniami maksymalnego przechowywania na poziomie kolekcji.
- W przypadku klasycznych rurociągów z niestandardowymi zasadami przechowywania, buildy będą zachowywane zgodnie z zasadami specyficznymi dla danego rurociągu.
- Kompilacje z dzierżawami nie są uwzględniane przy ustalaniu minimum, aby zachować ustawienia.
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ółkowych, wybranie tych komentarzy nie przekierowywało do odpowiedniego 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
- Uaktualnij serwer przy użyciu poprawki 4.
- 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). - 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.
- Uaktualnij serwer przy użyciu poprawki 4.
- 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). - Skopiuj zawartość folderu o nazwie zip zlokalizowanego w
C:\Program Files\{TFS Version Folder}\Search\zip
do zdalnego folderu plików Elasticsearch. - 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 usługi Azure DevOps Server 2020.1.1 zawiera poprawki dla następujących elementów.
- Napraw makro elementu roboczego dla zapytań z użyciem "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 z wykonania testu pokazywał niewłaściwego 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 awarię 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 wyświetlanie ograniczonych pól wyboru dla dziedziczenia typów scalania, aby umożliwić modyfikowanie ograniczeń typów scalania po ustawieniu zasad międzyrepozytoryjnych.
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ększono rozmiar pakietu rozszerzenia i umożliwiono zmianę tego rozmiaru w rejestrze.
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 Azure DevOps Server 2020.1, która naprawia następujące problemy.
- 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 Azure DevOps Server 2020.1, która rozwiązuje następujące problemy.
Bezpieczne pliki cookie używane 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
Azure DevOps Server 2020.1 RTW to zbiór poprawek błędów. Obejmuje ona wszystkie funkcje wcześniej wydanego serwera Azure DevOps Server 2020.1 RC2. Azure DevOps Server 2020.1 RTW to zestaw 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ń zmiany stanu na tablicach
- Uczestnicy projektu mogą teraz przenosić elementy robocze między kolumnami
- Ulepszenie zabezpieczeń wersji dzięki ograniczeniu zakresu tokenów dostępu
- Ulepszone doświadczenie obsługi pull requestów
- 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:
Deski
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ć zmianę statusu błędów z Nowe do Rozwiązane. Zamiast tego muszą przejść z 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 okna dialogowego kopiowania elementu roboczego: "Dołącz podrzędne elementy robocze". Po wybraniu tej opcji zostanie skopiowany zarówno element roboczy, jak i 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, Data aktywacji, Rozwiązane przez i Data rozwiązania 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ą uruchomione reguły Rozwiązane przez i Data rozwiązania.
Dzięki temu klienci mogą tworzyć dowolne niestandardowe wartości stanu i nadal generować pola Aktywowane przez, Data aktywacji, Rozwiązane przez i Data rozwiązania 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 pracy systemu do wybranego poziomu backlogu. Historycznie te typy elementów roboczych były dostępne tylko z zapytań.
Proces | Typ elementu roboczego |
---|---|
Metodyka Agile | Kwestia |
Scrum | Przeszkoda |
CMMI | Żądanie zmiany |
Problem | |
Wykonaj przegląd | |
Ryzyko |
Dodawanie typu elementu roboczego systemu do poziomu backlogu jest proste. Wystarczy przejść do swojego procesu niestandardowego i kliknąć kartę Poziomy backlogu. Wybierz swój poziom backlogu (na przykład: Backlog 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.
Dostosuj stan 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 pull requestu. 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 podczas scalania i kończenia żądania pull. Aby to zrobić, skanujemy opis żądania ściągnięcia i wyszukujemy wartość stanu, po której następuje oznaczenie 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 w projekcie, łącząc element roboczy z kompilacją, w której został znaleziony lub zintegrowany.
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 XML a Inheritowanym, która uniemożliwiła niektórym klientom migrację do modelu Inheritowanego. 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 pull request często odwołują się do wielu zadań. 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 pracy 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 przestały być mile widziane. 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 Utworzone przez, gdy Stan zostanie zmieniony na Rozwiązane
Otrzymaliśmy wiele opinii na temat tej reguły. W związku z tym usunęliśmy tę regułę z elementu roboczego typu Usterka w procesie Agile. Ta zmiana wpłynie na każdy projekt korzystający z odziedziczonego lub niestandardowego dziedziczonego procesu Agile. Dla tych klientów, którzy cenią sobie i polegają na tej bieżącej regule, zapoznaj się z naszym wpisem na blogu o krokach, które można podjąć, 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 elementów, które utworzyłeś lub które zostały Ci przypisane, między innymi. Udostępnia kilka spersonalizowanych przegubów 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
Teraz istnieje ustawienie na poziomie całej kolekcji dla preferowanej nazwy początkowej 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 pull requestów. 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 skutki wybuchu, gdy automatyzacja ma usterkę lub gdy token zostanie skompromitowany.
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 doświadczeniu było oczywiste, gdy te testy kończyły się niepowodzeniem. Nie jest to jednak prawdą w przypadku 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 bardziej uwidoczniliśmy stan opcjonalnych testów w podsumowaniu.
- Naciśnięcie Ctrl w elementach menu
Menu tabów w PR nie obsługiwało Ctrl+kliku. Użytkownicy często otwierają nowe karty przeglądarki podczas przeglądania pull requesta. 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.
- Aktualizacje PR w rozwijanym menu odzyskują informacje o czasie
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 był wcięty 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ę rodzica/rodziców 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 PR
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, dokonując modyfikacji wcięcia drzewa, aby dopasować do węzła głównego, oraz ukrywając przycisk z wielokropkiem na stronie, pojawiający się dopiero przy wskazaniu myszą.
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 rozmiaru panelu porównawczego na karcie plików w żądaniu ściągnięcia
W przypadku zmiany rozmiaru sąsiadujących okienek różnic w zakładce Pliki PR pozycja przewijania użytkownika zostanie utracona. Ten błąd został rozwiązany; lokalizacja przewijania użytkownika jest teraz zachowywana przy zmianie rozmiaru panelu różnic.
- Wyszukiwanie zatwierdzenia na urządzeniu mobilnym
Podczas wyświetlania strony Commits na telefonie komórkowym w nowej wersji brakuje pola wyszukiwania. W związku z tym trudno jest znaleźć commit za pomocą jego skrótu i go otworzyć. To zostało naprawione teraz.
- Ulepszone wykorzystanie przestrzeni dla widoku różnic plików PR 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 podsumowaniu PR
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 doświadczenie nie było idealne, ponieważ porównywano zmiany z domyślną gałęzią repozytorium zamiast z gałęzią porównania.
Rurociągi
Dodatkowa platforma agenta: ARM64
Dodaliśmy system Linux/ARM64 do listy obsługiwanych platform dla agenta usługi Azure Pipelines. Mimo że zmiany w kodzie były minimalne, najpierw musieliśmy wykonać dużo pracy w tle, i z radością ogłaszamy jego 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ć, kiedy uruchomić potok ciągłej integracji lub kiedy ma się 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) do uruchomienia, gdy uruchomienie potoku ciągłego wdrażania (CD) nie jest wyzwalane przez inne źródło/zasób lub zaplanowany wyzwalacz uruchamiania.
Jeśli na przykład masz ustawiony wyzwalacz dla potoku CD, który chcesz uruchomić tylko wtedy, gdy CI ma tag produkcyjny, tagi w sekcji wyzwalaczy zapewniają, że potok CD jest uruchamiany tylko wtedy, gdy warunek tagowania zostanie spełniony przez zdarzenie ukończenia CI.
Kontrola nad tym, które zadania są dozwolone w potokach
Teraz można wyłączyć zadania witryny Marketplace. Niektórzy z was mogą zezwalać na rozszerzenia Marketplace, ale nie na zadania dla potoków, które one przynoszą. 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 załadowane przy użyciu tfx. Odwiedź stronę https://dev.azure.com/<your_org>/_settings/pipelinessettings
i poszukaj sekcji o nazwie "Ograniczenia zadań", aby rozpocząć pracę.
Zasady wyłącznej blokady wdrożenia
Dzięki tej aktualizacji możesz zapewnić, że w danym momencie tylko jeden proces zostanie wdrożony w środowisku. Po wybraniu opcji "Blokada wyłączna" w środowisku zostanie uruchomione tylko jedno uruchomienie. Kolejne uruchomienia, które chcą zostać wdrożone w tym środowisku, zostaną wstrzymane. Po zakończeniu przebiegu z blokadą wyłączną, zostanie uruchomiony 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 YAML. Dzięki temu filtrowi nie trzeba czekać na ukończenie całego potoku ciągłej integracji, aby wyzwolić potok ciągłego dostarczania. Możesz teraz zdecydować, aby uruchomić pipeline CD po zakończeniu określonego etapu w pipeline CI.
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ę wyzwalaczy webhook w potokach YAML, umożliwiając integrację automatyzacji potoków z dowolną usługą zewnętrzną. Możesz subskrybować dowolne zdarzenia zewnętrzne za pośrednictwem mechanizmów webhook (Github, Github Enterprise, Nexus, Artifactory itp.) i uruchamiać swoje potoki pracy.
Oto kroki, jak skonfigurować wyzwalacze webhook:
Skonfiguruj webhook w swojej 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 Webhook>?api-version=6.0-preview"
- Wpis tajny — jest to opcjonalne. Jeśli musisz zabezpieczyć ładunek JSON, podaj wartość tajną Secret
Utwórz nowe połączenie do usługi "Incoming Webhook". Jest to nowo wprowadzony typ połączenia usługi, który umożliwia zdefiniowanie trzech ważnych informacji:
- Nazwa webhooka: Nazwa webhooka powinna być zgodna z webhookiem utworzonym w zewnętrznej usłudze.
- 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"
- Sekret — Sekret służy do parsowania skrótu ładunku używanego do weryfikacji żądania przychodzącego (jest to opcjonalne). Jeśli podczas tworzenia webhooka użyto sekretu, musisz podać ten sam klucz tajny.
Nowy typ zasobu o nazwie
webhooks
jest wprowadzany w potokach YAML. Aby subskrybować zdarzenie webhook, należy zdefiniować zasób webhook w potoku i wskazać go na przychodzące połączenie usługi webhook. Możesz również zdefiniować dodatkowe filtry dla zasobu webhook na podstawie ładunku JSON, aby jeszcze bardziej dostosować wyzwalacze dla każdego potoku, a ładunek możesz 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}}
- Za każdym razem, gdy zdarzenie webhook zostanie odebrane przez połączenie usługi webhook, zostanie uruchomione nowe zadanie dla wszystkich potoków subskrybowanych do tego zdarzenia.
Kwestie z wyzwalaczem zasobów YAML — wsparcie i możliwość śledzenia
Może to być mylące, gdy wyzwalacze potoku nie działają 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.
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.
Jeśli warunki wyzwalania nie są spełnione, wyzwalacz nie zostanie uruchomiony. Za każdym razem, gdy do tego dochodzi, zostanie wyświetlone ostrzeżenie, dzięki któremu można zrozumieć, dlaczego warunki nie zostały spełnione.
Wyzwalacze wielorepozytoryjne
Można określić wiele repozytoriów w jednym pliku YAML i uruchomić potok przez aktualizacje dowolnego z repozytoriów. 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 uruchomić potok za każdym razem, gdy aktualizacja zostanie wgrana do repozytorium aplikacji.
W ramach tej aktualizacji wyzwalacze z wieloma repozytoriami będą działać tylko dla repozytoriów Git w 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
Pipeline w tym przykładzie zostanie wyzwolony, jeśli zostaną wprowadzone jakiekolwiek aktualizacje:
-
main
gałąź w repozytoriumself
, które zawiera plik YAML-a -
main
lubrelease
gałęzie w repozytoriumtools
Aby uzyskać więcej informacji, zobacz Wiele repozytoriów w ciągu produkcyjnym.
Ulepszone przesyłanie logów 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 transmisji strumieniowej, mogłeś zdobyć pewne wskazówki na temat tego, co robił agent tuż zanim przestał odpowiadać. Ale jeśli cię nie było lub odświeżyłeś stronę, te dzienniki konsoli zniknęły. W tej wersji, jeśli agent przestanie odpowiadać przed wysłaniem pełnych dzienników, zachowamy dzienniki konsoli jako najlepszą alternatywę. 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. Każdy klucz pod mountReadOnly
można ustawić jako true
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 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 pipeline korzystający z nowej funkcjonalnoś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 przechowującej potok Agent.ContainerMapping
. Możesz tego użyć, jeśli chcesz sprawdzić listę kontenerów w skrypcie, na przykład. Zawiera on zserializowany obiekt JSON mapujący nazwę zasobu ("builder" z powyższego przykładu) na identyfikator kontenera, którym zarządza agent.
Rozpakuj pakiety zadań dla każdego kroku.
Gdy agent uruchamia zadanie, najpierw pobiera wszystkie pakiety zadań wymagane przez kroki zadania. Zwykle dla poprawy wydajności rozpakowuje się zadania oddzielnie dla każdego zadania, nawet jeśli zadanie jest używane w wielu krokach. Jeśli masz obawy dotyczące niezaufanego kodu zmieniającego rozpakowaną zawartość, możesz poświęcić trochę wydajności, pozwalając agentowi rozpakowywać zadanie przy każdym użyciu. Aby włączyć ten tryb, należy przekazać --alwaysextracttask
podczas konfigurowania agenta.
Ulepszenie zabezpieczeń wersji dzięki ograniczeniu zakresu tokenów dostępu
Opierając się na naszej inicjatywie mającej na celu ulepszenie ustawień zabezpieczeń dla usługi Azure Pipelines, obsługujemy teraz ograniczenie zakresu tokenów dostępu dla wydań.
Każde zadanie uruchamiane w wersjach pobiera token dostępu. Token dostępu jest używany przez zadania i skrypty do odwołania się 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 kontynuujemy poprawę bezpieczeństwa potoku, ograniczając zakres tokenów dostępu i rozszerzając te zasady na wersje klasyczne.
Ta funkcja będzie domyślnie włączona dla nowych projektów i kolekcji. W przypadku istniejących kolekcji musisz włączyć to w ustawieniach kolekcji Ustawienia > Potoków > Ustawienia. > Ogranicz zakres autoryzacji zadań do bieżącego projektu dla potoków wydania. Dowiedz się więcej tutaj.
Ulepszenia interfejsu API podglądu 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 wysłać POST do https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview
, aby pobrać sfinalizowaną treść YAML. Ten nowy interfejs API przyjmuje te same parametry co kolejkowanie uruchomienia, ale nie wymaga już uprawnień do "Kolejkowanie kompilacji".
Uruchom to zadanie jako następne
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 pull requestami? 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ępnej 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ć parametrów środowiska uruchomieniowego wewnątrz zasobów, na przykład do wyboru 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, zazwyczaj podaje się jedynie numer główny wersji zadań uwzględnionych. Dzięki temu potoki danych mogą automatycznie korzystać z najnowszych dodatków funkcji i poprawek błędów. Czasami może być konieczne wycofanie do poprzedniej wersji punktowej zadania, a wraz z tą aktualizacją dodaliśmy możliwość wykonania tego. Teraz możesz określić pełną wersję zadania major.minor.patch w potokach YAML.
Nie zalecamy regularnego wykonywania tej czynności; zalecamy używać jej tylko jako tymczasowego rozwiązania, gdy okaże się, że nowsze zadanie przerywa potoki. Ponadto nie spowoduje to zainstalowania starszej wersji zadania z witryny Marketplace. Musi już istnieć w twojej kolekcji, inaczej proces 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
Wsparcie dla Node 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ń wewnętrznych do Node 10. Agent może teraz uruchamiać zadania node 6 i Node 10. W przyszłej aktualizacji całkowicie usuniemy Node 6 z agenta. Aby przygotować się do usunięcia Node 6 z agenta, prosimy o zaktualizowanie wewnętrznych rozszerzeń i zadań niestandardowych, aby wkrótce używać Node 10. Aby użyć Node.js 10 dla swojego zadania, w obszarze task.json
, pod execution
, zaktualizuj z Node
do Node10
.
Ulepszono konwersję YAML w klasycznym projektancie kompilacji
W tej wersji wprowadzamy nową funkcję "eksportuj do YAML" dla potoków tworzenia projektów. Zapisz definicję potoku danych, 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, jak dokładnie potok będzie przetwarzany i generuje kod YAML z wiernym odwzorowaniem potoku projektanta.
Nowa konwersja platformy internetowej — ustawienia repozytorium
Zamieniliśmy dwie strony ustawień repozytorium na jedno zintegrowane doświadczenie użytkownika, które zostało uaktualnione do nowej platformy sieciowej. 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 polityki można wyświetlić listę wszystkich gałęzi, na których ustawiono politykę. 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ż zaktualizowana do nowej platformy internetowej z sekcjami do rozkładania! Aby ulepszyć doświadczenie związane z wyszukiwaniem określonych zasad weryfikacji kompilacji, kontroli statusu lub automatycznego recenzenta, dodaliśmy filtry wyszukiwania dla każdej z tych 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 kontynuujemy naszą podróż, aby uczynić Azure Pipelines świadomymi procesu zarządzania zmianami zarządzanego w usłudze ServiceNow, co teraz rozciąga się na potoki YAML.
Konfigurując kontrolę "Zarządzanie zmianami w ServiceNow" dla zasobu, można teraz wstrzymać się i poczekać na zatwierdzenie zmiany przed wdrożeniem wersji na ten zasób. Możesz automatycznie utworzyć nową zmianę dla etapu lub zaczekać na istniejące żądanie zmiany.
Możesz również dodać zadanie UpdateServiceNowChangeRequest
do zadania serwera, aby zaktualizować żądanie zmiany z aktualnym stanem wdrożenia, uwagami itp.
Artefakty
Możliwość tworzenia źródeł danych o zakresie organizacji na podstawie interfejsu użytkownika
Przywracamy możliwość tworzenia i zarządzania kanałami informacyjnymi powiązanymi z kolekcjami za pośrednictwem internetowego interfejsu użytkownika zarówno dla usług lokalnie instalowanych, 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.
Interfejs API REST do aktualizacji wersji pakietów jest teraz dostępny dla pakietów 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 | Rodzaj | Opis |
---|---|---|---|---|
artifactId | ścieżka | PRAWIDŁOWE | string | Identyfikator artefaktu pakietu |
źródło | ścieżka | PRAWDA | string | Nazwa lub identyfikator kanału informacyjnego |
identyfikatorGrupy | ścieżka | PRAWDA | string | Identyfikator grupy pakietu |
kolekcja | ścieżka | PRAWDA | ciąg znaków | Nazwa kolekcji usługi Azure DevOps |
wersja | ścieżka | PRAWDA | ciąg znaków | Wersja pakietu |
projekt | ścieżka | 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, ponieważ jest ona aktualizowana.
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.