Udostępnij za pośrednictwem


Plany dostarczania 2.0 — ogólna dostępność

Z przyjemnością ogłaszamy, że plany dostarczania 2.0 są ogólnie dostępne! Plany dostarczania 2.0 zapewniają 3 kluczowe scenariusze: widok osi czasu planu, postęp pracy i śledzenie zależności.

Zapoznaj się z poniższymi opisami funkcji, aby uzyskać szczegóły.

Azure Boards

Azure Pipelines

Azure Boards

Plany dostarczania 2.0 są ogólnie dostępne

Z przyjemnością ogłaszamy, że plany dostarczania 2.0 są ogólnie dostępne! Zapewnia on 3 kluczowe scenariusze:

  • Widok osi czasu planu
  • Postęp pracy
  • Śledzenie zależności

Te scenariusze działają w zespołach i projektach. Plany dostarczania 2.0 są teraz natywne dla produktu, więc rozszerzenie nie jest już wymagane. Plany utworzone przy użyciu oryginalnego rozszerzenia Plany będą nadal działać w planach dostarczania.

Poniżej przedstawiono krótkie porównanie różnic między planami i planami dostarczania

Funkcja Plany 1.0 (rozszerzenie) Plany dostarczania 2.0
Liczba zespołów Limit to 10 Limit to 15
Przedział czasu elementu roboczego Tylko iteracji Data początkowa/docelowa i iteracja
Wizualizacja Widok pełnej karty Skrócone i rozwinięte widoki
Zbiorcze informacje Brak % wykonanych elementów podrzędnych i połączonych
Śledzenie zależności Brak Tak
Wizualizacja godzina rozpoczęcia Nie, tylko wtedy, gdy kończy się element roboczy Tak, zarówno daty rozpoczęcia, jak i daty docelowe
Styl karty Nie. Tak

Funkcje planów dostarczania

Poniżej przedstawiono główne funkcje. Filtrowanie, znaczniki i kryteria pól są również częścią planów dostarczania.

Istnieją dwa główne widoki: skondensowane i rozwinięte

Plany dostarczania 2.0 umożliwiają wyświetlanie wszystkich elementów roboczych w planie na osi czasu przy użyciu dat rozpoczęcia i celu lub dat iteracji. Kolejność pierwszeństwa to daty początkowe i docelowe, a następnie iteracja. Dzięki temu można dodawać elementy robocze na poziomie portfela, takie jak Epika, które często nie są zdefiniowane w iteracji.

Istnieją dwa główne widoki widoku skondensowanego i widoku rozszerzonego. Możesz również powiększyć i z planu, klikając lupę po prawej stronie planu.

  • Widok skondensowany

    Widok skondensowany pokazuje wszystkie karty elementów roboczych zwinięte , co oznacza, że nie są wyświetlane wszystkie informacje o karcie. Ten widok jest przydatny w przypadku ogólnego widoku pracy w planie. Aby zwinąć pola karty, kliknij ikonę karty obok ikon powiększania w prawej części planu.

    Oto przykład przełączania planu między skondensowanym i rozszerzonym widokiem.

    Gif to demo condensed view.

  • Widok rozwinięty

    Widok rozwinięty pokazuje postęp elementu roboczego, zliczając liczbę elementów podrzędnych i połączonych oraz pokazując procent ukończenia. Obecnie postęp jest określany przez liczbę elementów roboczych.

    Oto przykład planu korzystającego z widoku rozszerzonego. Zwróć uwagę na ukończone paski postępu i procent.

    Example of a plan using an expanded view

Śledzenie zależności

Śledzenie zależności jest oparte na łączach poprzedników i następców zdefiniowanych w elementach roboczych. Jeśli te linki nie są zdefiniowane, nie będą wyświetlane żadne wiersze zależności. Jeśli występuje problem z zależnością elementu roboczego, ikona linku zależności jest kolorem czerwonym.

Dependency tracking with dependency icon in red to show dependencies

  • Wyświetlanie zależności

    Określone zależności są wyświetlane za pośrednictwem panelu zależności, który pokazuje wszystkie zależności dla tego elementu roboczego, w tym kierunek. Czerwony wykrzyknik wskazuje problem z zależnością. Aby wyświetlić panel, po prostu kliknij ikonę linku zależności w prawym górnym rogu karty. Oto przykłady zależności.

    Example of viewing dependencies

    Another example of viewing dependencies

  • Linie zależności

    Zależności między elementami roboczymi są wizualizowane z liniami strzałek kierunkowych między odpowiednimi elementami roboczymi. Wiele zależności będzie wyświetlanych jako wiele wierszy. Czerwona linia kolorowa wskazuje problem.

    Oto kilka przykładów.

    Dependencies work items visualized with directional arrow lines between the respective work items

    Oto przykład elementu roboczego z wieloma zależnościami i działa również przy użyciu widoku skondensowanego.

    Example of a work item with multiple dependencies in condensed view

    Gdy występuje problem, kolor linii jest czerwony, a więc jest ikoną zależności.

    Oto przykład.

    Example of a work item with multiple dependencies

Styl karty

Karty można teraz stylować przy użyciu reguł, takich jak tablice Kanban. Otwórz ustawienia planu i kliknij pozycję Style. W okienku Style kliknij pozycję + Dodaj regułę stylów, aby dodać regułę, a następnie kliknij przycisk Zapisz. Może istnieć maksymalnie 10 reguł, a każda reguła może mieć maksymalnie 5 klauzul.

Styling settings

  • Przed

Card styling before

  • Po

Card styling after

Kopiowanie pulpitu nawigacyjnego jest teraz dostępne w publicznej wersji zapoznawczej

W tej wersji można teraz skopiować pulpit nawigacyjny zespołu lub projektu do tego samego lub nowego projektu. Widżety i układ pulpitu nawigacyjnego zostaną skopiowane, ale widżety będą nadal musiały być skonfigurowane przy użyciu nowych zapytań i ustawień.

Aby wyświetlić podgląd tej funkcji, po prostu włącz flagę funkcji o nazwie Kopiuj środowisko pulpitu nawigacyjnego (w obszarze funkcje w wersji zapoznawczej).

Enable copy dashboard experience

Poniżej przedstawiono kroki kopiowania pulpitu nawigacyjnego:

  1. Przejdź do pulpitu nawigacyjnego, który chcesz skopiować. W tym miejscu kliknij menu, aby wyświetlić kopiuj pulpit nawigacyjny , a następnie kliknij go.

Copy dashboard

  1. Wprowadź nazwę i opis nowego pulpitu nawigacyjnego, a następnie wybierz typ pulpitu nawigacyjnego, Zespół lub Projekt. Podczas wybierania pulpitu nawigacyjnego zespołu nowy projekt i zespół są wybierane odpowiednio z listy rozwijanej projektu i zespołu. W przypadku pulpitu nawigacyjnego projektu wymagany jest tylko projekt.

New dashboard options menu

Nowy interfejs API REST pojemności iteracji

Teraz możesz uzyskać łączną pojemność dla wszystkich zespołów w iteracji przy użyciu nowego interfejsu API REST iteracji . iterationId Podaj wartości i interfejs API zwróci łączną pojemność dla każdego zespołu skojarzonego z iterację, a także łączną sumę. Ta funkcja ułatwi planowanie pojemności dla przyrostu. Aby dowiedzieć się więcej na temat iteracji, zobacz dokumentację tutaj.

Azure Pipelines

Zmiana zasad preinstalacji zestawu .NET SDK na agentach systemu Ubuntu hostowanych przez firmę Microsoft

Zmieniamy wersje zestawu .NET SDK, które są wstępnie zainstalowane na agentach systemu Ubuntu hostowanych przez firmę Microsoft. Obecnie instalujemy wszystkie dostępne i obsługiwane wersje zestawu .NET SDK (2.1.x, 3.1.x, 5.0.x). Takie podejście zostanie zmienione na rzecz zainstalowania najnowszej wersji poprawki dla każdej wersji funkcji. Ta zmiana jest wprowadzana w celu zapewnienia większej ilości wolnego miejsca i nowych żądań narzędzi.

Co to oznacza?

Wersja zestawu SDK składa się z następujących części: x.y.znn. z jest wersją funkcji i nn jest wersją poprawki. Na przykład w wersji 2.1.302 wersja funkcji to 3, a 02 to wersja poprawki. Zgodnie z nowym podejściem zainstalujemy tylko najnowszą wersję poprawki dla każdej wersji funkcji, tj. tylko 2.1.302 zostaną zainstalowane dla wersji 2.1.3x, tylko 2.1.403 dla wersji 2.1.4x itd. Wszystkie wersje zestawu .NET SDK, które nie są najnowszymi wersjami poprawek, zostaną usunięte z obrazów systemu Ubuntu 14 czerwca. Ta zmiana ma wpływ na wszystkie wersje systemu Ubuntu na agentach hostowanych przez firmę Microsoft.

Data docelowa

Wdrożenie zaktualizowanych obrazów rozpocznie się 14 czerwca i potrwa od 3 do 4 dni.

Możliwy wpływ

Jeśli używasz pliku global.json, kompilacja będzie miała wpływ w następujących przypadkach:

Kompilacja zakończy się niepowodzeniem, jeśli plik global.json zawiera rollForward: disable właściwość i wersję zestawu SDK, która nie jest najnowszą wersją poprawki. Na przykład:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "disable"
  }
}

Wersja zestawu .NET SDK zostanie automatycznie zmieniona na najnowszą poprawkę, jeśli plik global.json zawiera rollForward: patch właściwość . Na przykład:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "patch"
  }
}

rollForward Jeśli pole nie zostanie określone w pliku global.json, nie będzie żadnych zmian. Używany jest najnowszy zainstalowany poziom poprawek.

Jeśli musisz użyć dokładnej wersji zestawu .NET SDK, która nie jest najnowszą poprawką, użyj UseDotNet zadania , aby zainstalować ją w ramach kompilacji:

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    version: <dotnet version>

Uprawnienia i kontrole grup zmiennych i bezpiecznych plików

W potokach YAML można używać różnych typów zasobów udostępnionych. Przykłady obejmują połączenia usług, grupy zmiennych, bezpieczne pliki, pule agentów, środowiska lub repozytoria. Aby chronić potok przed uzyskaniem dostępu do zasobu, właściciel zasobu może skonfigurować uprawnienia i sprawdzić ten zasób. Za każdym razem, gdy potok próbuje uzyskać dostęp do zasobu, są oceniane wszystkie skonfigurowane uprawnienia i kontrole. Te zabezpieczenia były dostępne na połączeniach usług, środowiskach i pulach agentów przez pewien czas. Ostatnio dodano je do repozytoriów. W tej wersji dodajemy te same zabezpieczenia do grup zmiennych i zabezpieczanych plików.

Aby ograniczyć dostęp do grupy zmiennych lub bezpiecznego pliku do małego zestawu potoków, użyj funkcji uprawnienia Potoki.

My secret variables

Aby skonfigurować kontrole lub zatwierdzenia, które powinny być oceniane przy każdym uruchomieniu potoku, użyj Zatwierdzenia i sprawdź funkcję Biblioteka.

Add checks approval

Podgląd obsługi szablonów w edytorze YAML

Szablony są często używaną funkcją w potokach YAML. Są one łatwym sposobem udostępniania fragmentów potoku. Są one również zaawansowanym mechanizmem weryfikacji lub wymuszania zabezpieczeń i ładu za pośrednictwem potoku.

Usługa Azure Pipelines obsługuje edytor YAML, który może być przydatny podczas edytowania potoku. Wcześniej edytor nie obsługiwał szablonów. Autorzy potoków YAML nie mogą uzyskać pomocy funkcji IntelliSense podczas korzystania z szablonu. W tej wersji zapoznamy się z obsługą szablonów w edytorze YAML. Aby włączyć tę wersję zapoznawcza, przejdź do funkcji w wersji zapoznawczej w organizacji usługi Azure DevOps i włącz edytor szablonów YAML.

Enable YAML templates editor in preview features

Podczas edytowania głównego pliku YAML usługi Azure Pipelines możesz dołączyć lub rozszerzyć szablon. Po wpiseniu nazwy szablonu zostanie wyświetlony monit o zweryfikowanie szablonu. Po zweryfikowaniu edytor YAML rozumie schemat szablonu, w tym parametry wejściowe.

YAML template

Po weryfikacji możesz przejść do szablonu. Będzie można wprowadzać zmiany w szablonie przy użyciu wszystkich funkcji edytora YAML.

Pamiętaj, że ta funkcja jest dostępna w wersji zapoznawczej. Istnieją znane ograniczenia, z których część pracujemy nad rozwiązaniem problemu. Jeśli szablon ma wymagane parametry, które nie są podane jako dane wejściowe w głównym pliku YAML, walidacja zakończy się niepowodzeniem i wyświetli monit o podanie tych danych wejściowych. W idealnym środowisku sprawdzanie poprawności nie powinno być blokowane i powinno być możliwe wypełnienie parametrów wejściowych przy użyciu funkcji IntelliSense. Ponadto nie można utworzyć nowego szablonu z poziomu edytora. Można używać lub edytować tylko istniejące szablony.

Ubuntu-16.04 zostanie usunięty z pul hostowanych przez firmę Microsoft we wrześniu 2021 r.

Tradycyjne 5-letnie wsparcie systemu Ubuntu 16.04 przez Canonical kończy się w kwietniu 2021 roku. Aby zapewnić aktualność i bezpieczeństwo środowiska, usuniemy system Ubuntu 16.04 20 września 2021 r.

Należy przeprowadzić migrację przepływów pracy ubuntu-16.04 do systemu ubuntu-18.04 lub ubuntu-latest, które będą działać w systemie Ubuntu 20.04 LTS.

Aby upewnić się, że wszyscy wiedzą o tej zmianie, zaplanowaliśmy dwa krótkie brownouts. Każda kompilacja systemu Ubuntu 16.04 zakończy się niepowodzeniem w okresie brownout. W związku z tym zaleca się przeprowadzenie migracji potoków przed 6 września 2021 r.

Brownouts są wstępnie zaplanowane na następujące daty i godziny. Będziemy aktualizować te czasy, gdy zbliżamy się do tego okresu.

6 września 2021 r. 17:00 UTC – 10:00 UTC

14 września 2021 r. 15:00 UTC – 10:00 UTC

Następne kroki

Uwaga

Te funkcje będą wdrażane w ciągu najbliższych dwóch do trzech tygodni.

Przejdź do usługi Azure DevOps i przyjrzyj się.

Jak przekazać opinię

Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.

Make a suggestion

Możesz również uzyskać porady i odpowiedzi na pytania społeczności w witrynie Stack Overflow.

Dzięki,

Aaron Hallberg