Nowe ulepszenia planów dostarczania 2.0

W tym przebiegu ulepszamy plany dostarczania 2.0 z nowymi skróconymi widokami i informacjami zbiorczymi. Wprowadzamy również ręczną walidację i nową uses instrukcję na potrzeby wstępnego deklarowania zasobów w potokach YAML.

Aby uzyskać szczegółowe informacje, zapoznaj się z listą funkcji poniżej.

Azure Boards

• Plany dostarczania: informacje o zestawień
• Plany dostarczania: widoki skondensowane

Azure Pipelines

• Instrukcja "uses" dla wstępnie deklarujących zasoby
• Ręczna walidacja potoków YAML

Azure Boards

Plany dostarczania: informacje o zestawień

W ramach planów dostarczania 2.0 w publicznej wersji zapoznawczej są teraz dostępne informacje zbiorcze. W przypadku pracy z elementami roboczymi wyższego poziomu, takimi jak epiki lub funkcje, możesz zobaczyć więcej szczegółów. Rzutowanie pokazuje postęp podstawowych podrzędnych elementów roboczych, ujawniając pełną historię. Aby włączyć tę funkcję, przejdź do ustawień planu, a następnie wybierz pozycję Pola i wybierz pozycję Pokaż podrzędne dane zestawienia.

Plany dostarczania: widoki skondensowane

W ramach programu Delivery Plans 2.0 w publicznej wersji zapoznawczej klienci mogą teraz przełączać się między widokami normalnymi i skondensowanym. Karty z dodatkowymi polami mogą zająć dużo miejsca w pionie. To sprawia, że trudno jest zobaczyć więcej niż kilka kart na ekranie naraz, nawet gdy w pełni pomniejszony. Utworzyliśmy zwinięty widok karty, który ukrywa wszystkie pola z kart i wyświetla tylko ikonę i tytuł typu elementu roboczego. Ukrywanie i pokazywanie wszystkich pól jest teraz tylko kliknięciem.

Azure Pipelines

Instrukcja "uses" dla wstępnie deklarujących zasoby

Gdy potok uruchamia zadanie na agencie, agent otrzymuje token dostępu do wywołania z powrotem do interfejsów API REST usługi Azure Pipelines i pobierania zasobów, takich jak repozytoria. W przypadku potoków YAML niedawno dodaliśmy ustawienie ograniczające token tylko do repozytoriów rzeczywiście używanych w zadaniu. Niektórzy klienci używali jednak repozytoriów bez jawnego użycia checkout kroku, na przykład jeśli użyto kroku skryptu w celu bezpośredniego wywołania usługi Git. Ci klienci nie mogli włączyć funkcji ograniczania tokenów, ponieważ usługa Azure Pipelines nie mogła dokładnie określić, które repozytoria były potrzebne do wykonania zadania.

Dzięki tej aktualizacji dodaliśmy alternatywny sposób informowania usługi Azure Pipelines o tym, że zadanie chce używać repozytorium bez użycia checkout kroku. Zamiast tego możesz użyć nowego uses słowa kluczowego w następujący sposób:

resources:
  repositories:
  - repository: myrepo
    type: git
    name: MyProject/MyRepo

jobs:
- job: myjob
  uses:
    repositories:
    - myrepo
  steps:
  # without the preceding "uses" statement, if you have the
  # new limit-repositories feature turned on, then Azure Pipelines
  # won't include this repo in the access token and you'll
  # get an access error at runtime (also, in a real pipeline
  # you must include the auth token header as an argument to Git)
  - script: git clone https://dev.azure.com/MyOrg/MyProject/_git/MyRepo

Ta funkcja rozwiązuje również związany (choć mniej powszechny) problem. Jeśli używasz słowa kluczowego matrix do generowania wielu zadań, a te zadania używają pul określonych w kroku macierzy, mogą wystąpić problemy z autoryzacją tych pul dla potoku. Główna przyczyna jest taka sama: ponieważ macierze są obliczane w czasie wykonywania, system autoryzacji zasobów z góry nie może dokładnie określić, które pule są używane. Za pomocą programu usesmożna zadeklarować, które pule będą używane przez zadania, aby mogły być autoryzowane z góry.

jobs:
- job: mtrx
  strategy:
    matrix:
      windows:
        mypoolname: Private-Windows
      mac:
        mypoolname: Private-Mac
  pool: $(mypoolname)
  # without the following "uses" statement, "pool" won't see
  # the pool names until it's too late, and you'll get an error
  # at runtime
  uses:
    pools:
    - Private-Windows
    - Private-Mac

Ręczna walidacja potoków YAML

Nowo wydane zadanie ręcznej weryfikacji umożliwia wstrzymywanie potoku YAML w połowie etapu. Dzięki temu można wykonywać działania ręczne lub offline, a następnie wznawiać (lub odrzucać) przebieg. Jest to szczególnie przydatne w scenariuszach, w których chcesz wstrzymać potok i umożliwić elementowi równorzędnym weryfikowanie ustawień konfiguracji, pakietu kompilacji itp. przed przejściem do długotrwałego zadania wymagającego dużej mocy obliczeniowej. Dowiedz się więcej.

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 spójrz.

Przejdź do usługi Azure DevOps

Jak przekazać opinię

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

Możesz również uzyskać porady i pytania, na które odpowiada społeczność w witrynie Stack Overflow.

Dzięki,

Matt Cooper