Udostępnij za pośrednictwem

Ograniczanie przejść stanu elementu roboczego

  • Artykuł

Po kilku przebiegach w wersji zapoznawczej ogłaszamy teraz ogólną wersję reguł ograniczeń przejścia stanu dla wszystkich klientów w ramach aktualizacji Sprint 172.

Aby uzyskać więcej informacji, zapoznaj się z listą funkcji poniżej.

Funkcje

Azure Boards

Azure Pipelines

Azure Artifacts

Azure Boards

Reguły ograniczeń przejścia stanu

Po kilku przebiegach prywatnej wersji zapoznawczej reguły ograniczeń przejścia stanu są teraz ogólnie dostępne dla wszystkich klientów. Ta nowa reguła typu elementu roboczego umożliwia ograniczenie przenoszenia elementów roboczych z jednego stanu do innego. Można na przykład ograniczyć przechodzenie błędów z obszaru Nowy do Rozwiązane. Zamiast tego muszą przejść z obszaru New —> Active —> Resolved

W tym przykładzie usterki są ograniczane do przejścia z stanu Nowy na Aktywny, a następnie do opcji Rozwiązane zamiast przechodzenia ze stanu Nowy do Rozwiązane.

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. W tym przebiegu dodaliśmy nową opcję "Dołącz podrzędne elementy robocze" do okna dialogowego kopiowania elementu roboczego. Po wybraniu tej opcji skopiuje element roboczy i skopiuje wszystkie podrzędne elementy robocze (do 100).

Na tej stronie przedstawiono nową opcję w usłudze Azure Boards, aby uwzględnić podrzędne elementy robocze w skopiowanym elemencie roboczym.

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

Do tej pory reguły Aktywowane przez, Aktywowana data, Rozwiązane przez i Rozwiązane daty były tajemnicą. Są one ustawiane tylko dla typów elementów roboczych systemu i są specyficzne dla wartości stanu "Aktywne" i "Rozwiązane". W przebiegu 172 zmieniliśmy logikę, aby te reguły nie były już przeznaczone dla określonego stanu. Zamiast tego są one wyzwalane przez kategorię (kategorię stanu), w której znajduje się stan. Załóżmy na przykład, że masz niestandardowy stan "Wymaga testowania" w kategorii Rozwiązane. Gdy element roboczy zmieni się z "Aktywne" na "Wymaga testowania", zostaną wyzwolone reguły Rozpoznane przez i Rozwiązane daty .

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

Typy elementów roboczych systemu na listach prac i tablicach (prywatna wersja zapoznawcza)

Od momentu utworzenia modelu procesu dziedziczenia kilka typów elementów roboczych zostało wykluczonych z dodawania do tablic i list prac. Te typy elementów roboczych obejmują:

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

Począwszy od tego przebiegu, zezwalamy na prywatną wersję zapoznawczą dla tych klientów, którzy chcą włączyć te typy elementów roboczych, aby były dostępne na dowolnym poziomie listy prac.

Użyj tej strony usługi Azure Boards, aby dodać wcześniej wykluczone typy elementów roboczych do tablic i list prac.

Jeśli chcesz wyświetlić podgląd tej funkcji, wyślij nam wiadomość e-mail z twoją nazwą organizacji i możemy udzielić Ci dostępu.

Azure Pipelines

Zasady blokady wdrożenia na wyłączność

Dzięki tej aktualizacji można zagwarantować, że w danym momencie tylko jeden przebieg zostanie wdrożony w środowisku. Po wybraniu kontroli "Blokada wyłączna" w środowisku będzie kontynuowane tylko jedno uruchomienie. Kolejne uruchomienia, które chcą zostać wdrożone w tym środowisku, zostaną wstrzymane. Po zakończeniu przebiegu z blokadą wyłączną będzie kontynuowany najnowszy przebieg. Wszystkie przebiegi pośrednie zostaną anulowane.

Na stronie Dodawanie sprawdzania wybierz pozycję Blokada wyłączna, aby upewnić się, że tylko jeden przebieg jest wdrażany w środowisku w danym momencie.

Filtry etapów dla wyzwalaczy zasobów potoku

W tym przebiegu dodaliśmy obsługę "etapów" jako filtru dla zasobów potoku w języku YAML. Dzięki temu filtrowi nie trzeba czekać na ukończenie całego potoku ciągłej integracji w celu wyzwolenia potoku ciągłej integracji. Teraz możesz wyzwolić potok ciągłego wdrażania po zakończeniu określonego etapu w potoku ciągłej integracji.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Gdy etapy podane w filtrze wyzwalacza zostaną pomyślnie ukończone w potoku ciągłej integracji, nowy przebieg zostanie automatycznie wyzwolony dla potoku ciągłego wdrażania.

Ogólne wyzwalacze oparte na elementach webhook dla potoków YAML

Obecnie mamy różne zasoby (takie jak potoki, kontenery, kompilacje i pakiety), za pomocą których można korzystać z artefaktów i włączać automatyczne wyzwalacze. Do tej pory nie można było jednak zautomatyzować procesu wdrażania na podstawie innych zdarzeń zewnętrznych lub usług. W tej wersji wprowadzamy obsługę wyzwalacza elementu webhook w potokach YAML, aby umożliwić integrację automatyzacji potoku z dowolną usługą zewnętrzną. Możesz subskrybować dowolne zdarzenia zewnętrzne za pośrednictwem elementów webhook (GitHub, GitHub Enterprise, Nexus, Artifactory itp.) i wyzwalać potoki.

Poniżej przedstawiono kroki konfigurowania wyzwalaczy elementu webhook:

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

    • Adres URL żądania — "https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
    • Wpis tajny — jest to opcjonalne. Jeśli musisz zabezpieczyć ładunek JSON, podaj wartość wpisu tajnego

  2. Utwórz nowe połączenie usługi "Przychodzący element webhook". Jest to nowo wprowadzony typ połączenia usługi, który umożliwia zdefiniowanie trzech ważnych informacji:

    • Nazwa elementu webhook: nazwa elementu webhook powinna być zgodna z elementem webhook utworzonym w usłudze zewnętrznej.
    • Nagłówek HTTP — nazwa nagłówka HTTP w żądaniu, który zawiera wartość skrótu ładunku na potrzeby weryfikacji żądania. Na przykład w przypadku usługi GitHub nagłówek żądania będzie mieć wartość "X-Hub-Signature"
    • Wpis tajny — klucz tajny służy do analizowania skrótu ładunku używanego do weryfikacji żądania przychodzącego (jest to opcjonalne). Jeśli podczas tworzenia elementu webhook użyto wpisu tajnego, musisz podać ten sam klucz tajny

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

  3. Nowy typ zasobu o nazwie webhooks jest wprowadzany w potokach YAML. Aby subskrybować zdarzenie elementu webhook, należy zdefiniować zasób elementu webhook w potoku i wskazać je na przychodzące połączenie usługi elementu webhook. Możesz również zdefiniować dodatkowe filtry dla zasobu elementu webhook na podstawie danych ładunku JSON, aby dodatkowo dostosować wyzwalacze dla każdego potoku, a dane ładunku można używać w postaci zmiennych w zadaniach.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
  1. Za każdym razem, gdy zdarzenie elementu webhook zostanie odebrane przez przychodzące połączenie usługi elementu webhook, zostanie wyzwolone nowe uruchomienie dla wszystkich potoków subskrybowanych do zdarzenia elementu webhook.

Problemy z wyzwalaczem zasobów YAML — obsługa i możliwość śledzenia

Może to być mylące, gdy wyzwalacze potoku nie będą wykonywane zgodnie z oczekiwaniami. Aby lepiej zrozumieć ten problem, dodaliśmy nowy element menu na stronie definicji potoku o nazwie "Problemy z wyzwalaczem", w którym są wyświetlane informacje dotyczące przyczyn braku wykonywania wyzwalaczy.

Wyzwalacze zasobów mogą nie działać z dwóch powodów.

  1. Jeśli źródło podanego połączenia z usługą jest nieprawidłowe lub w wyzwalaczu występują błędy składniowe, wyzwalacz nie zostanie w ogóle skonfigurowany. Są one wyświetlane jako błędy.

  2. Jeśli warunki wyzwalacza nie są zgodne, wyzwalacz nie zostanie wykonany. Zawsze, gdy tak się stanie, zostanie wyświetlone ostrzeżenie, aby zrozumieć, dlaczego warunki nie zostały dopasowane.

    Na tej stronie definicji potoku o nazwie Problemy z wyzwalaczem są wyświetlane informacje dotyczące tego, dlaczego wyzwalacze nie są uruchomione.

Dodaliśmy baner ostrzegawczy do strony potoków, aby otrzymywać alerty o bieżących zdarzeniach w Twoim regionie, co może mieć wpływ na potoki.

Azure Artifacts

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

Przywracamy klientom możliwość tworzenia kanałów informacyjnych w zakresie organizacji i zarządzania nimi za pośrednictwem internetowego interfejsu użytkownika zarówno dla usług lokalnych, jak i hostowanych.

Teraz możesz tworzyć źródła danych o zakresie organizacji za pośrednictwem interfejsu użytkownika, przechodząc do sekcji Artifacts — Create Feed (Artefakty —> tworzenie kanału informacyjnego) i wybierając typ źródła danych w obszarze Zakres.

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

Chociaż zalecamy użycie źródeł danych o zakresie projektu zgodnie z resztą ofert usługi Azure DevOps, można ponownie tworzyć źródła danych o zakresie organizacji i zarządzać nimi za pośrednictwem interfejsu użytkownika i różnych interfejsów API REST. Aby uzyskać więcej informacji, zobacz dokumentację kanałów informacyjnych.

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ę.

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ę.

Utwórz sugestię

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

Dzięki,

Aaron Hallberg