Azure DevOpsServer 2020 Update 1 — informacje o wersji

Developer Community | System RequirementsLicense Terms DevOps Blog SHA-1 Hashes (Postanowienia licencyjne dotyczące wymagań systemowych DevOps bloga dotyczące skrótów | | | SHA-1)

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

Aby dowiedzieć się więcej na temat instalowania lub uaktualniania wdrożenia Azure DevOps Server, zobacz Azure DevOps Server wymagania. Aby pobrać Azure DevOps produktów, odwiedź stronę Azure DevOps Server pliki do pobrania.

Bezpośrednie uaktualnienie do wersji Azure DevOps Server 2020 jest obsługiwane od wersji Azure DevOps Server 2019 lub Team Foundation Server 2015 lub nowszej. Jeśli wdrożenie serwera TFS jest na wersji TFS 2010 lub starszej, przed uaktualnieniem do wersji Azure DevOps Server 2019 należy wykonać pewne kroki pośrednie. Aby dowiedzieć się więcej, zobacz Install and configure Azure DevOps on-premises (Instalowanie ikonfigurowanie aplikacji lokalnych).


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

Azure DevOps Server 2020 r. wprowadzono nowy model przechowywania uruchamiania potoku (kompilacji), który działa w oparciu o ustawienia na poziomie projektu.

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

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

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

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

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

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

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

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

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

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

  • Naprawiono Artifacts pobierania/przekazywania.
  • Rozwiązywanie problemu z niespójnymi Wyniki testów danych.

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

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

Uwaga

Narzędzie do migracji danych będzie dostępne 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 pracy" w wiadomościach e-mail z powiadomieniami nie używa publicznego adresu URL.

Azure Repos

  • Naprawiono ograniczone pola wyboru dziedziczenia typów scalania, aby włączyć modyfikowanie typów scalania limitu po ustawieniu zasad zmiany położenia krzyżowego.

Azure Pipelines

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

Ogólne

  • Poprawiono pisownię w kreatorze konfiguracji serwera.
  • Zwiększony rozmiar pakietu rozszerzenia i umożliwia zmianę 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.

Wydaliśmy poprawkę dla wersji Azure DevOps Server 2020.1, która naprawia następujące problemy.

  • Naprawiono błąd interfejsu użytkownika definicji kompilacji.
  • Zmieniono historię przeglądania w celu wyświetlania plików zamiast repozytorium głównego.

Azure DevOps Server wersji 2020.1 Patch 1: 15 czerwca 2021 r.

Wydaliśmy poprawkę dla wersji Azure DevOps Server 2020.1, która naprawia 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ń korzystające z filtru ścieżki obszaru nie były prawidłowo analizowane.

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

Podsumowanie nowości w programie Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW to zbiorcza aktualizacja poprawek błędów. Zawiera on wszystkie funkcje w wersji Azure DevOps Server 2020.1 RC2 wydanej wcześniej. Azure DevOps Server 2020.1 RTW to zbiorcza aktualizacja poprawek błędów. Możesz bezpośrednio zainstalować program Azure DevOps Server 2020.1 lub uaktualnić z wersji Azure DevOps Server 2020, 2019 lub Team Foundation Server 2015 lub nowszej.

Uwaga

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

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

Podsumowanie nowości w programie Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 to zestaw poprawek błędów. Zawiera on wszystkie funkcje w wersji Azure DevOps Server 2020.1 RC1 wydanej wcześniej.

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

Podsumowanie nowości w programie Azure DevOps Server 2020.1 RC1

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

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


Boards

Reguły ograniczeń przejścia stanu

Nadal zamykamy lukę w parzystości funkcji między hostowanych xml i dziedziczonego modelu procesu. Ta nowa reguła typu elementu roboczego umożliwia ograniczenie możliwości przeniesienia elementów roboczych z jednego stanu do innego. Możesz na przykład ograniczyć możliwość przeniesienia usterek z Nowego na Rozwiązane. Zamiast tego muszą przejść z nowej — > aktywnej — > rozwiązane

img

Można 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ć wątki użytkownika z nowej — > zatwierdzonej.

Kopiowanie elementu roboczego w celu kopiowania elementów children

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

Na tej stronie przedstawiono nową opcję w Azure Boards do dołączyć podrzędne elementy robocze do skopiowanego elementu roboczego.

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

Do tej pory reguły aktywowane przez , Data aktywowania, Rozwiązane przez i Data rozwiązania były bardzo aktualne. Są one ustawiane tylko dla typów systemowych elementów pracy i są specyficzne dla wartości stanu "Aktywne" i "Rozwiązane". Zmieniliśmy logikę, aby te reguły nie były już dla określonego stanu. Zamiast tego są one wyzwalane przez kategorię (kategorię stanu), w którym znajduje się stan. Załóżmy na przykład, że masz niestandardowy stan "Wymaga testowania" w kategorii Rozwiązane. Gdy element pracy zmieni się z "Aktywny" na "Wymaga testowania", zostaną wyzwolone reguły Rozwiązane według i Data rozwiązania.

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

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

Uczestnicy projektu zawsze mogli zmieniać stan elementów roboczych. Jednak gdy przejdą do tablicy Kanban, nie będą mogli przenieść elementów roboczych z jednej kolumny do innej. Zamiast tego uczestnicy projektu muszą otworzyć każdy element pracy po jednym na raz i zaktualizować wartość stanu. Od dawna jest to dla klientów bardzo pracowitym punktem i z przyjemnością ogłaszamy, że teraz można przenosić elementy robocze między kolumnami tablic.

Systemowe typy elementów pracy na listy prac i tablice

Teraz możesz dodać systemowy typ elementu roboczego do wybranego poziomu listy prac. W przeszłości te typy elementów pracy były dostępne tylko w zapytaniach.

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

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

backlogs

Azure Boards GitHub został podniesiony limit repo aplikacji

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

Dostosowywanie stanu elementu roboczego podczas scalania żądania ściągnnięcia

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

Mamy nową funkcję, która umożliwia ustawianie żądanego stanu elementów roboczych podczas scalania i ukończenia żądania ściągnnięcia. W tym celu przeskanujemy opis żądania ściągnnięcia i poszukamy wartości stanu, a następnie #mention elementów pracy. W tym przykładzie ustawiamy dwa wątki użytkownika na Rozwiązane i zamykamy dwa zadania.

work-item-state

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

łączenie elementów roboczych

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, opisu nie można edytować. Była to różnica między funkcjami hostowanych plików XML i dziedziczonych, która uniemożliwiała niektórym klientom migrowanie do modelu dziedziczonego. Teraz możesz edytować opis w polach systemowych. Edytowana wartość będzie mieć wpływ tylko na to pole w procesie i dla tego typu elementu roboczego. Zapewnia to elastyczność w zakresie różnych opisów dla tego samego pola dla różnych typów elementów pracy.

edytowanie opisu

Dostosowywanie stanu elementu roboczego podczas scalania żądania ściągnnięcia

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

Customize state

Pole nadrzędne na tablicy zadań

Ze względu na popularne żądanie można teraz dodać pole Nadrzędny do karty podrzędnej i nadrzędnej na tablicy zadań.

parent field task board

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

Istnieje kilka ukrytych reguł systemowych dla wszystkich różnych typów elementów pracy w systemach Agile, Scrum i CMMI. Te reguły istniały od ponad dekady i ogólnie działały prawidłowo bez żadnych skarg. Istnieje jednak kilka reguł, dla których zabrakło powitania. Jedna reguła w szczególności spowodowała wiele bólu dla nowych i istniejących klientów i zdecydowaliśmy, że na czas ją usunąć. Ta reguła istnieje dla typu elementu roboczego Usterka w procesie Agile.

"Ustaw wartość Przypisano na Utworzono 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 będzie mieć wpływ na każdy projekt przy użyciu dziedziczonego procesu Agile lub dostosowanego dziedziczonego procesu Agile. W przypadku klientów, którzy chcą 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 na stronie Elementy robocze

Strona Elementy robocze to doskonałe miejsce do szybkiego wyszukiwania między innymi utworzonych lub przypisanych do Ciebie elementów. Udostępnia ona kilka spersonalizowanych tabel przestawnych i filtrów. Jedną z najbardziej skarg w przypadku tabeli przestawnej "Przypisane do mnie" jest to, że wyświetlane są w nim pozycje Usunięte elementy robocze (czyli elementy robocze w stanie Usunięte). I zgadzamy się! Usunięte elementy to praca, która nie ma już wartości i dlatego została usunięta z listy prac, więc jej uwzględnienie w tym widoku nie jest przydatne.

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

Repos

Domyślna preferencja nazwy gałęzi

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

 default-branch-name

Uwaga: jeśli ta funkcja nie zostanie włączona, repozytoria zostaną zainicjowane przy użyciu Azure Repos domyślnej nazwy. W tej chwili wartością domyślną jest master. Aby honorować zobowiązanie firmy Microsoft do obsługi języka inkluzywnego i żądania klientów, dołączymy do branżowych współpracowników, zmieniając to ustawienie domyślne na główne. Ta zmiana nastąpi później tego lata. Jeśli chcesz nadal używać wzorca, włącz tę funkcję teraz i ustaw ją na master.

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

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ślisz początkowej nazwy gałęzi w ustawieniach organizacji lub ustawieniach projektu, nowe repozytoria będą używać Azure DevOps domyślnej.

branch setting for org level

Dodawanie nowego zakresu uwierzytelniania na celu współtworzenie komentarzy do ściągnień

W tej wersji dodano nowy zakres uwierzytelniania OAuth do odczytywania/zapisywania komentarzy do żądań ściągnięć. Jeśli masz bota lub automatyzację, która wymaga tylko interakcji z komentarzami, możesz nadać mu pat pat tylko z tym zakresem. Ten proces zmniejsza promień promienia, jeśli automatyzacja ma usterkę lub jeśli token został naruszony.

Ulepszenia obsługi żądań ściągnięć

Ulepszono nowe środowisko żądania ściągniętego dzięki następującym możliwościom:

  • Spraw, aby opcjonalne kontrole były bardziej widoczne

Klienci korzystają z opcjonalnych testów, aby zwrócić uwagę dewelopera na potencjalne problemy. W poprzednim przypadku było oczywiste, że te testy nie powiodą się. Nie jest to jednak przypadek w wersji zapoznawczej. Duży, zielony znacznik wyboru na wymaganych testach maskuje błędy w testach opcjonalnych. Użytkownicy mogli tylko wykryć, że opcjonalne testy nie powiodły się, otwierając panel kontroli. Deweloperzy często nie robią tego, gdy nie ma żadnego wskazania problemu. W tym wdrożeniu stan opcjonalnych testów był bardziej widoczny w podsumowaniu.


show the optional checks


  • Klikanie elementów menu za pomocą klawiszy Ctrl

Menu kart w poleceń ściągnięcie nie obsługuje kliknięcia klawiszem Ctrl. Użytkownicy często otwierają nowe karty przeglądarki podczas przeglądania żądania ściągnnięcia. Ten problem został rozwiązany.

  • Lokalizacja adnotacji [+]

Lista drzewa plików w pniu ściągnięciem zawiera adnotację [+], która pomaga autorom i recenzentom identyfikować nowe pliki. Ponieważ adnotacja była po wielokropka, często nie była widoczna dla dłuższych nazw plików.


show locations of annotations

  • Informacje o czasie odzyskania informacji o chronometrażu są odzyskiwane na liście rozwijanej aktualizacji pr

Lista rozwijana do wybierania aktualizacji i porównywania plików w poleceniu ściągnięciem utraciła ważny element w wersji zapoznawczej. Nie pokazaliśmy, kiedy ta aktualizacja została wykonana. Ten problem został rozwiązany.


PR updates dropdown missing timing information

  • **Udoskonalony układ filtru komentarzy **

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


Improved comment filter layout

  • Nawigacja do zatwierdzeń nadrzędnych

Na stronie Zatwierdzenia możesz porównać zmiany wprowadzone w konkretnym zatwierdzeniu z jego zatwierdzeniem nadrzędnym. Możesz jednak przejść do zatwierdzenia nadrzędnego i lepiej zrozumieć, czym to zatwierdzenie różni się od jego własnego elementu nadrzędnego. Jest to często potrzebne, gdy chcesz zrozumieć wszystkie zmiany w wydaniu. Aby to osiągnąć, dodaliśmy do zatwierdzenia kartę nadrzędną.


Navigation to parent commits

  • Więcej miejsca dla folderów i plików o długich nazwach na karcie Pliki ściągnięć

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 tak, aby było zgodne z węzłem głównym, i ukrywając przycisk wielokropka ze strony z wyjątkiem aktywowania wskaźnika myszy.

Obraz nowego drzewa plików:


More space for folders and files

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


Name display

  • Zachowywanie położenia przewijania podczas zmiany rozmiaru okienka różnic na karcie Pliki ściągnięć

Podczas zmiany rozmiaru okienka różnic obok siebie na karcie Pliki ściągnięć lokalizacja przewijania użytkownika zostanie utracona. Ten problem został rozwiązany. Lokalizacja przewijania użytkownika jest teraz zachowywana w przypadku zmiany rozmiaru okienka różnicowego.

  • Wyszukiwanie zatwierdzenia na urządzeniu przenośnym

Podczas wyświetlania strony Zatwierdzenia na urządzeniu przenośnym w nowym trybie brakuje pola wyszukiwania. W związku z tym trudno jest znaleźć zatwierdzenie według jego skrótu i otworzyć je. Rozwiązano ten problem.


Search for a commit on a mobile device

  • Ulepszone użycie miejsca dla nowego widoku mobilnego różnic plików pr

Zaktualizowaliśmy tę stronę, aby lepiej wykorzystać miejsce, dzięki czemu użytkownicy będą widzieć więcej pliku w widokach dla urządzeń przenośnych, zamiast mieć 40% ekranu zajętego przez nagłówek.


Improved usage of space new PR filename

  • Ulepszone obrazy w widoku podsumowania ściągnięć

Obrazy edytowane w pniu ściągnięcie nie były wyświetlane w widoku podsumowania, ale były wyświetlane poprawnie w widoku plików pr. Ten problem został rozwiązany.

  • Ulepszone środowisko rozgałęzienia podczas tworzenia nowego pr

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


branch experience enhancement

Pipelines

Dodatkowa platforma agentów: ARM64

Dodaliśmy system Linux/ARM64 do listy obsługiwanych platform dla Azure Pipelines agenta. Mimo że zmiany kodu były minimalne, wiele za kulisami pracy musiało zostać ukończonych w pierwszej kolejności i z przyjemnością ogłaszamy jego wydanie.

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

Dodaliśmy teraz "tagi" w potokach YAML. Za pomocą tagów można ustawić uruchamianie potoku ci lub czas jego automatycznego wyzwalania.

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

Powyższy fragment kodu pokazuje, że za pomocą tagów można określić domyślną wersję potoku ciągłej integracji do uruchomienia, gdy uruchomienie potoku ciągłego wdrażania nie zostanie wyzwolone przez inne źródło/zasób lub wyzwalacz zaplanowanego uruchomienia.

Jeśli na przykład masz ustawiony zaplanowany wyzwalacz dla potoku cd, który chcesz uruchomić tylko wtedy, gdy twoja ciasna ci ma tag produkcyjny, tagi w sekcji triggers zapewniają, że potok cd jest wyzwalany tylko wtedy, gdy warunek tagowania zostanie spełniony przez zdarzenie ukończenia ciasnego.

Kontrolowanie dozwolonych zadań w potokach

Teraz możesz wyłączyć zadania witryny Marketplace. Niektórzy z Nich mogą zezwalać na rozszerzenia witryny Marketplace, ale nie na Pipelines zadań, które są przez nie wykonywane. Aby uzyskać jeszcze większą kontrolę, umożliwiamy również niezależne wyłączenie wszystkich zadań w ramach usługi (z wyjątkiem wyewidencjonowania, co jest specjalną akcją). Po włączeniu obu tych ustawień jedynymi zadaniami, które mogą być uruchamiane w potoku, będą zadania przekazane przy użyciu tfx. Odwiedź https://dev.azure.com/<your_org>/_settings/pipelinessettings stronę 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 środowisku jednocześnie będzie wdrażany tylko jeden przebieg. Wybranie kontroli "Blokada wyłączna" w środowisku spowoduje kontynuowanie tylko jednego uruchomienia. Kolejne przebiegi, które mają zostać wdrożone w tym środowisku, zostaną wstrzymane. Po zakończeniu uruchamiania z blokadą na wyłączność będzie kontynuowane najnowsze uruchomienie. Wszystkie przebiegi pośrednie zostaną anulowane.

Na stronie Dodawanie kontroli wybierz pozycję Blokada na wyłączność, aby upewnić się, że w środowisku jednocześnie jest wdrażany tylko jeden przebieg.

Filtry etapów dla wyzwalaczy zasobów potoku

Dodaliśmy obsługę "etapów" jako filtru dla zasobów potoku w pliku YAML. Dzięki temu filtrowi nie musisz czekać na ukończenie całego potoku cicha, aby wyzwolić potok cd. Teraz możesz wyzwolić potok cd po ukończeniu określonego etapu w potoku 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

Po pomyślnym ukończeniu etapów w filtrze wyzwalacza w potoku ciasnym zostanie automatycznie wyzwolony nowy przebieg dla potoku cd.

Wyzwalacze ogólne oparte na 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ć wyzwalacze automatyczne. Do tej pory nie można było jednak zautomatyzować procesu wdrażania na podstawie innych zdarzeń lub usług zewnętrznych. W tej wersji wprowadzamy obsługę wyzwalacza 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 jego webhook (Github, Github Enterprise, Nexus, Aritfactory itp.) i wyzwalać potoki.

Poniżej podano kroki konfigurowania wyzwalaczy webhook:

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

    • Adres URL żądania — " https://dev.azure.com/ <ADO collection> /_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
    • Klucz tajny — jest to opcjonalne. Jeśli musisz zabezpieczyć ładunek JSON, podaj wartość Klucz tajny
  2. Utwórz nowe połączenie usługi "Przychodzący webhook". Jest to nowo wprowadzony typ połączenia usługi, który umożliwia zdefiniowanie trzech ważnych informacji:

    • Nazwa urządzenia webhook: nazwa tego webhook powinna być dopasowana do webhook utworzonego w usłudze zewnętrznej.
    • Nagłówek HTTP — nazwa nagłówka HTTP w żądaniu, który zawiera wartość skrótu ładunku dla weryfikacji żądania. Na przykład w przypadku żądania GitHub nagłówkiem żądania będzie "X-Hub-Signature"
    • Klucz 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 element webhook został użyty klucz tajny, musisz podać ten sam klucz tajny

    Na stronie Edytowanie połączenia z usługą skonfiguruj wyzwalacze webhook.

  3. W potokach YAML zostanie wprowadzony nowy typ zasobu o webhooks nazwie . Aby subskrybować zdarzenie webhook, należy zdefiniować zasób webhook w potoku i wskazać połączenie z usługą przychodzącego urządzenia webhook. Można również zdefiniować dodatkowe filtry dla zasobu element webhook na podstawie danych ładunku JSON, aby dodatkowo dostosować wyzwalacze dla każdego potoku. Dane ładunku można również używać w formie 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}}
  1. Za każdym razem, gdy zdarzenie webhook zostanie odebrane przez przychodzące połączenie usługi webhook, zostanie wyzwolone nowe uruchomienie dla wszystkich potoków zasubskrybowanych do zdarzenia tegohook.

Problemy z obsługą i możliwością śledzenia wyzwalacza zasobu YAML

Może to być mylące, gdy nie można wykonać wyzwalaczy potoku 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ą dostępne informacje dotyczące przyczyn, dla których wyzwalacze nie są wykonywane.

Wykonanie wyzwalaczy zasobów może się nie powieść 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 dostępne jako błędy.

  2. Jeśli warunki wyzwalacza nie zostaną dopasowane, wyzwalacz nie zostanie wykonany. W takim przypadku zostanie wyświetlane ostrzeżenie, aby można było zrozumieć, dlaczego warunki nie zostały dopasowane.

    Ta strona definicji potoku o nazwie Problemy z wyzwalaczem zawiera informacje dotyczące tego, dlaczego wyzwalacze nie są uruchomione.

Wyzwalacze z wieloma repo

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. Testy aplikacji mają być uruchamiane przy każdej aktualizacji narzędzia lub biblioteki.
  • Plik YAML należy przechowywać w oddzielnym repozytorium niż kod aplikacji. Chcesz wyzwolić potok za każdym razem, gdy aktualizacja jest wypychana do repozytorium aplikacji.

Dzięki tej aktualizacji wyzwalacze wielu repozytoriów będą działać tylko w przypadku repozytoriów Git w Azure Repos. Nie działają one w przypadku GitHub repozytorium BitBucket.

Oto przykład, który pokazuje, jak zdefiniować wiele zasobów repozytorium w potoku i jak skonfigurować wyzwalacze dla 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 w przypadku aktualizacji:

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

Aby uzyskać więcej informacji, zobacz Multiple repositories in your pipeline (Wiele repozytoriów w potoku).

Ulepszono przekazywanie dzienników agentów

Gdy agent przestaje komunikować się z serwerem Azure Pipelines, uruchomione zadanie zostaje porzucone. Jeśli używasz dzienników konsoli przesyłania strumieniowego, być może masz pewne wskazówki dotyczące tego, co agent był odpowiedni, zanim przestał odpowiadać. Jeśli jednak nie jesteś lub odświeżysz stronę, te dzienniki konsoli zostały zniknęły. W tej wersji, jeśli agent przestanie odpowiadać przed wysłaniem pełnych dzienników, zachowajemy dzienniki konsoli jako najlepsze rozwiązanie. Dzienniki konsoli są ograniczone do 1000 znaków w wierszu i czasami mogą być niekompletne, ale są znacznie bardziej przydatne niż wyświetlanie 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 podczas rozwiązywania problemów.

Opcjonalnie zainstaluj woluminy kontenera tylko do odczytu

Po uruchomieniu zadania kontenera w Azure Pipelines woluminy zawierające obszar roboczy, zadania i inne materiały są mapowane jako woluminy. Te woluminy domyślnie mają dostęp do odczytu/zapisu. Aby zwiększyć bezpieczeństwo, można zainstalować woluminy tylko do odczytu, zmieniając specyfikację kontenera w yaml. Dla każdego klucza w obszarze można ustawić mountReadOnly wartość tylko do odczytu true (wartość domyślna to false ).

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

Ujednolicona kontrola nad uruchamianiem/zatrzymywaniem kontenera

Ogólnie rzecz biorąc, zalecamy, aby zezwolić Azure Pipelines na zarządzanie cyklem życia kontenerów zadań i usług. Jednak w niektórych nietypowych scenariuszach możesz chcieć je uruchomić i zatrzymać samodzielnie. W tej wersji wbudowaliśmy tę możliwość do zadania 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 dołączymy listę kontenerów do zmiennej Agent.ContainerMapping potoku . Możesz użyć tej funkcji, jeśli chcesz na przykład sprawdzić listę kontenerów w skrypcie. Zawiera on obiekt JSON z ciągami mapujący nazwę zasobu ("konstruktor" z powyższego przykładu) na identyfikator kontenera, który zarządza agent.

Rozpakuj pakiety zadań dla każdego kroku

Gdy agent uruchamia zadanie, najpierw pobiera wszystkie pakiety zadań wymagane przez kroki zadania. Zwykle w celu wydajności rozpakowywuje zadania raz dla każdego zadania, nawet jeśli zadanie jest używane w wielu krokach. Jeśli masz obawy dotyczące niezaufanego kodu zmieniającego rozpakowana zawartość, możesz odejść od nieco wydajności, rozpakując zadanie przy każdym użyciu. Aby włączyć ten tryb, --alwaysextracttask należy przekazać podczas konfigurowania agenta.

Ulepszanie zabezpieczeń wydania przez ograniczenie zakresu tokenów dostępu

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

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

Dzięki tej aktualizacji ulepszamy zabezpieczenia potoku, ograniczając zakres tokenów dostępu i rozszerzając je tak samo do wersji klasycznych.

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

Ulepszenia interfejsu API w wersji zapoznawczej YAML

Teraz możesz wyświetlić podgląd pełnego pliku YAML potoku bez jego uruchamiania. Ponadto utworzono dedykowany nowy adres URL dla funkcji w wersji zapoznawczej. Teraz możesz wysłać do pliku https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview POST, aby pobrać sfinacyjną treść YAML. Ten nowy interfejs API przyjmuje te same parametry co kolejkowanie uruchomienia, ale nie wymaga już uprawnienia " kompilacji " kolejki.

Uruchom to zadanie w następnej

Czy kiedykolwiek masz poprawkę usterek, którą trzeba było wdrożyć w tej minucie, ale trzeba było czekać za zadaniami ciasnych i prysłowy? W tej wersji umożliwiamy teraz podniesienie priorytet zadania w kolejce. Użytkownicy z uprawnieniem "Zarządzaj" w puli — zazwyczaj administratorzy puli — zobaczą nowy przycisk "Uruchom dalej" na stronie szczegółów zadania. Kliknięcie przycisku spowoduje ustawienie zadania do uruchomienia tak szybko, jak to możliwe. (Oczywiście nadal będziesz potrzebować dostępnej równoległości i odpowiedniego agenta).

Wyrażenia szablonów dozwolone w bloku resources YAML

Wcześniej wyrażenia czasu kompilacji ( ) były niedozwolone w sekcji pliku ${{ }} resources YAML Azure Pipelines pliku YAML. W tej wersji zdjęliśmy to ograniczenie dotyczące kontenerów. Dzięki temu można używać zawartości parametrów środowiska uruchomieniowego wewnątrz zasobów, na przykład w celu wyboru kontenera w czasie kolejki. Planujemy rozszerzyć tę obsługę na inne zasoby w czasie.

Kontrola nad automatycznymi aktualizacjami zadań z witryny Marketplace

Podczas pisania potoku YAML zwykle określa się tylko główny numer wersji dołączonych zadań. Dzięki temu potoki mogą automatycznie pobierać najnowsze dodatki do funkcji i poprawki błędów. Czasami może być konieczne cofniesz się do poprzedniej wersji punktu zadania, a dzięki tej aktualizacji dodaliśmy możliwość wykonania tego zadania. Możesz teraz określić pełną wersję zadania główna.pomocnicza.poprawka w potokach YAML.

Nie zalecamy regularnego stosowania tego rozwiązania i używania go tylko jako tymczasowego obejścia, gdy okazuje się, że nowsze zadanie przerywa potoki. Ponadto nie spowoduje to zainstalowania starszej wersji zadania z witryny Marketplace. Musi już istnieć w kolekcji, ponieważ potok nie powiedzie się.

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 Node 10 w agentach i zadaniach

Ponieważ węzeł 6 nie jest już obsługiwany, migrowanie zadań do pracy z węzłem Node 10. W tej aktualizacji zmigrowanie niemal 50% zadań do węzła Node 10. Agent może teraz uruchamiać zadania w węzłach Node 6 i Node 10. W przyszłej aktualizacji całkowicie usuniemy węzeł 6 z agenta. Aby przygotować się do usunięcia węzła 6 z agenta, żądamy zaktualizowania rozszerzeń i zadań niestandardowych, aby wkrótce również korzystać z węzła Node 10. Aby użyć węzła 10 do wykonania zadania, w programie task.json w obszarze zaktualizuj z do execution Node Node10 .

Ulepszanie konwersji YAML w klasycznym projektancie kompilacji

W tej wersji wprowadzamy nową funkcję "eksportuj do 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ę "Wyświetl jako YAML" znalezioną wcześniej w klasycznym projektancie kompilacji. Ta funkcja była niekompletna, ponieważ mogła tylko sprawdzić, co internetowy interfejs użytkownika wiedział o kompilacji, co czasami prowadziło do wygenerowania nieprawidłowego pliku YAML. Nowa funkcja eksportu dokładnie uwzględnia sposób przetwarzania potoku i generuje kod YAML z pełną dokładnością do 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 także zapewnia pojedynczy punkt wejścia dla wszystkich zasad od poziomu projektu do poziomu gałęzi.

Nowa konwersja platformy internetowej.

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

Wyświetlanie zasad między repo na karcie Zasady.

Po kliknięciu repozytorium możesz wyświetlić zasady i uprawnienia ustawione na poziomie repozytorium. Na karcie zasady można wyświetlić listę wszystkich gałęzi, dla których ustawiono zasady. Teraz kliknij gałąź , aby wyświetlić wszystkie zasady bez opuszczania strony Ustawienia repozytorium.

Wybierz gałąź, aby wyświetlić zasady.

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.

Pokaż, skąd zasady były dziedziczone.

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

Wyszukaj filtry dla każdej sekcji.

Integracja zarządzania zmianami w usłudze 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 chcemy, aby Azure Pipelines procesu zarządzania zmianami zarządzanego w usłudze ServiceNow w dalszej części potoków YAML.

Konfigurując sprawdzanie zarządzania zmianami w usłudze 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 poczekać na istniejące żądanie zmiany.


ServiceNow Change Management Integration

Możesz również dodać zadanie w zadaniu serwera, aby zaktualizować żądanie zmiany przy użyciu stanu UpdateServiceNowChangeRequest wdrożenia, uwag itp.

Artifacts

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

Wrócimy do możliwości tworzenia kanałów informacyjnych w zakresie kolekcji i zarządzania nimi za pośrednictwem internetowego interfejsu użytkownika zarówno dla usług hostowanych, jak i hostowanych.

Teraz możesz tworzyć kanały informacyjne w zakresie organizacji za pośrednictwem interfejsu użytkownika, przechodząc do Artifacts -> Utwórz źródło danych i wybierając typ kanału informacyjnego w obszarze Zakres.

Utwórz kanały informacyjne w zakresie kolekcji, wybierając pozycję Artifacts, a następnie pozycję Utwórz źródło danych i wybierając typ kanału informacyjnego w obszarze Zakres.

Mimo że zalecamy użycie źródeł danych w zakresie projektu zgodnie z resztą ofert Azure DevOps, możesz ponownie tworzyć i używać źródeł danych o zakresie kolekcji oraz zarządzać nimi za pomocą 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 Maven

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

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

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

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

Parametry identyfikatora URI

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

Treść żądania

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

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

Opinia

Chcemy poznać Twoją opinię! Możesz zgłosić problem lub przekazać pomysł i śledzić go za pośrednictwem usługi Developer Community uzyskać porady dotyczące Stack Overflow.


Początek strony