Udostępnij przez


Usługa GitHub Secret Protection i zabezpieczenia kodu GitHub są dostępne jako produkty autonomiczne w usłudze Azure DevOps

Teraz możesz uzyskać usługę GitHub Secret Protection i GitHub Code Security jako produkty autonomiczne w usłudze Azure DevOps. Ochrona tajemnic zapewnia dostęp do skanowania tajemnic, ochrony przed wypychaniem oraz doświadczenia związanego z przeglądem zabezpieczeń. Zabezpieczenia kodu zapewniają dostęp do wszystkich doświadczeń związanych ze skanowaniem zależności, skanowaniem kodu i przeglądem zabezpieczeń.

W Planach testów publikujemy nowy katalog Planów testów, który pomoże Ci pozostać zorganizowanym i zaoszczędzić czas. Teraz możesz wydajniej zarządzać planami testów, mając większą kontrolę nad obszarem roboczym i zmniejszając powtarzalne zadania.

Sprawdź notatki o wydaniu, aby uzyskać szczegóły.

GitHub Advanced Security dla usługi Azure DevOps

Ogólne

Azure Pipelines

Azure Test Plans

GitHub Advanced Security dla usługi Azure DevOps

Usługa GitHub Advanced Security jest teraz dostępna jako usługa GitHub Secret Protection i zabezpieczenia kodu dla usługi Azure DevOps

GitHub Secret Protection i GitHub Code Security można teraz kupić jako autonomiczne produkty w Azure DevOps dla nowych klientów.

Ochrona tajemnic zapewnia dostęp do skanowania tajemnic, ochrony przed wypychaniem oraz doświadczenia związanego z przeglądem zabezpieczeń. Zabezpieczenia kodu zapewniają dostęp do wszystkich doświadczeń związanych ze skanowaniem zależności, skanowaniem kodu i przeglądem zabezpieczeń.

Wszyscy istniejący klienci usługi Advanced Security mogą nadal korzystać z połączonego środowiska produktu bez zakłóceń. Jeśli jesteś bieżącym klientem usługi Advanced Security i chcesz przełączyć się do produktów autonomicznych, skontaktuj się z pomocą techniczną usługi Azure DevOps za pośrednictwem witryny Azure Portal. Możesz zgłosić zgłoszenie pomocy technicznej dla GitHub Advanced Security dla Azure DevOps i wybrać Billing migration from bundled to standalone products jako typ problemu.

Aby uzyskać więcej informacji na temat tych produktów, zobacz blog deweloperski.

Ogólne

Ograniczenie tworzenia osobistych tokenów dostępu w polityce organizacyjnej, teraz dostępne w publicznej wersji zapoznawczej.

Wprowadziliśmy nowe zasady na poziomie organizacji w usłudze Azure DevOps — Ograniczanie tworzenia osobistego tokenu dostępu (PAT), które są teraz dostępne w publicznej wersji zapoznawczej. Ta długo oczekiwana funkcja umożliwia administratorom kolekcji projektów kontrolowanie, kto może tworzyć lub ponownie wygenerować osobiste tokeny dostępu (PAT), co pomaga zmniejszyć rozrastanie tokenów i zwiększyć bezpieczeństwo. Po włączeniu tej opcji tylko użytkownicy na liście dozwolonych mogą generować elementy PAT z opcjonalną obsługą zakresów tworzenia pakietów. Zasady blokują również globalne użycie PAT, chyba że jest wyraźnie dozwolone. Dowiedz się więcej o tych zasadach i najlepszych rozwiązaniach dotyczących implementowania tej zmiany w naszym wpisie w blogu!

Usuwanie wygasłych aplikacji OAuth usługi Azure DevOps

Przygotowując się do wycofania aplikacji OAuth w Azure DevOps w 2026 roku, zaczniemy regularnie usuwać aplikacje z hasłami, które wygasły ponad sześć miesięcy temu (180 dni temu). pl-PL: Właściciele tych nieaktywnych aplikacji zostaną poinformowani, a jeśli będzie potrzebna rejestracja aplikacji przed końcem Azure DevOps OAuth w 2026 r., zostaniecie poproszeni o wymianę sekretu aplikacji przed 9 czerwca, kiedy zaczniemy usuwać aplikacje. Dowiedz się więcej w naszym wpisie w blogu.

Nowe zakresy protokołu OAuth firmy Microsoft Entra

Usługa Azure DevOps wprowadziła dwa nowe zakresy OAuth Microsoft Entra, vso.pats i vso.pats_manage, aby zwiększyć bezpieczeństwo i kontrolę nad zarządzaniem cyklem życia interfejsów API osobistych tokenów dostępu (PAT). Te zakresy są teraz wymagane dla delegowanych przepływów, które obejmują tworzenie i zarządzanie Personal Access Token (PAT), zastępując wcześniejszy szeroki zakres user_impersonation. Ta zmiana umożliwia właścicielom aplikacji zmniejszenie uprawnień wymaganych przez aplikację w celu uzyskania dostępu do interfejsów API pat. Ogranicz aplikacje user_impersonation do minimalnych zakresów potrzebnych na dziś!

Żądanie dostępności adresu URL dostępu

Administratorzy usługi Azure DevOps mogą wyłączyć zasady żądania dostępu i podać adres URL dla użytkowników żądań dostępu do organizacji lub projektu. Ten adres URL, wcześniej dostępny tylko dla nowych użytkowników, jest teraz również wyświetlany dla istniejących użytkowników na stronie 404. Aby zachować poufność, adres URL dostępu do żądania jest wyświetlany niezależnie od istnienia projektu.

Azure Pipelines

Zarządzane pule DevOps — deprecjacja obrazów

Ze względu na wycofanie hostowanego obrazu z systemem Windows Server 2019 i wycofanie systemu Ubuntu 20.04, Zarządzane pule DevOps wycofują obraz „Azure Pipelines – Windows Server 2019” oraz obrazy Ubuntu 20.04. Więcej szczegółów na temat wycofania można znaleźć tutaj. Więcej informacji na temat cyklu życia obrazów oferowanych przez zarządzane pule DevOps można znaleźć tutaj.

Strona Nowe wyzwalacze

Pipeline'y YAML oferują wiele potężnych opcji definiowania, kiedy pipeline powinien zostać uruchomiony. Nie zawsze jest łatwo zrozumieć, czy potok jest skonfigurowany tak, aby uruchamiać się w odpowiedzi na zdarzenie, na przykład gdy zakończono potok zasilający.

W tym sprincie wprowadzamy stronę Wyzwalacze, która pokazuje przegląd wyzwalaczy zdefiniowanych w potoku.

Wyobraź sobie, że masz następujący potok YAML zdefiniowany w main gałęzi repozytorium. Weź pod uwagę również gałąź feature, która zawiera ten sam kod w potoku YAML.

trigger:
- main

schedules:
  - cron: 0 0 * * *
    always: true
    displayName: Nightly build
    branches:
      include:
        - main

resources:
  pipelines:
    - pipeline: FabrikamFiber
      source: FabrikamFiber
      trigger: true

Po przejściu do strony Wyzwalacze zobaczysz następujące informacje

Zwróć uwagę, że domyślna gałąź potoku , mainjest wstępnie wybrana.

Zobaczysz, że istnieje wyzwalacz ciągłej integracji dla tej gałęzi i jest on zdefiniowany w pliku YAML.

Po przejściu do wyzwalaczy harmonogramu widzisz, że zostały zdefiniowane wyzwalacze oraz ich szczegóły.

Po przejściu do sekcji Wyzwalacze zasobów zostaną wyświetlone zdefiniowane wyzwalacze zasobów i ich szczegóły.

Możesz przełączać gałęzie z main do feature, aby zobaczyć, jakie wyzwalacze zostały zdefiniowane dla feature gałęzi.

Na karcie Wyzwalacze zasobów , jeśli nie w gałęzi domyślnej, zostanie wyświetlone ostrzeżenie informujące o tym, że wyzwalacze zdefiniowane dla tej gałęzi są ignorowane.

Gdy definicje wyzwalacza nie zostały prawidłowo przetworzone przez system, otrzymasz ostrzeżenie i wskazówki dotyczące sposobu rozwiązywania problemu.

Typ parametru StringList

Jedną z najbardziej żądanych funkcji potoków YAML w społeczności deweloperów jest zdefiniowanie parametrów zawierających listę elementów.

Począwszy od tego sprintu, dodaliśmy nowy typ parametru o nazwie StringList, który to umożliwia.

Załóżmy, że chcesz zezwolić osobom, które umieszczają przebieg potoku w kolejce, na wybór regionów, w których mają zostać wdrożone ładunki. Teraz możesz to zrobić, jak pokazano w poniższym przykładzie.

parameters:
- name: regions
  type: stringList
  displayName: Regions
  values:
    - WUS
    - CUS
    - EUS
  default: 
    - WUS
    - CUS
    - EUS 

stages:
- ${{ each stage in parameters.regions}}:
  - stage: ${{stage}}
    displayName: Deploy to ${{stage}}
    jobs:
    - job:
      steps:
      - script: ./deploy ${{stage}}

Podczas kolejkowania tego potoku masz możliwość wybrania kilku regionów do wdrożenia, jako pokazano na poniższym zrzucie ekranu.

Uwaga / Notatka

Typ stringList danych nie jest dostępny w szablonach. object Zamiast tego użyj typu danych w szablonach.

Zobacz pełny kod YAML przebiegu potoku

Potoki YAML są komponowalne. Możesz rozszerzyć szablon, aby upewnić się, że pipeline'y uruchamiają niezbędne narzędzia do analizy statycznej oraz aby zawierały szablony do uruchamiania typowych etapów, zadań lub prac.

Debugowanie takich potoków nie było łatwe, ponieważ nie można było zobaczyć pełnego kodu YAML, który był uruchomiony.

Załóżmy, że masz następujący pipeline:

parameters:
- name: PoolName
  type: string
  default: Azure Pipelines
- name: VmImage
  type: string
  default: ubuntu latest

extends:
  template: security-enforcing-template.yml
  parameters:
    jobs:
    - template: job.monitoring.yml
    - template: job.build.yml
      parameters:
        PoolName: ${{parameters.PoolName}}
        VmImage: ${{parameters.VmImage}}

W tym miejscu są używane trzy szablony. Każdy szablon może używać wyrażeń warunkowych na podstawie parametrów i wartości zmiennych w celu określenia rzeczywistych zadań lub kroków do uruchomienia.

Ponadto podczas analizowania starych przebiegów potoku nie wiadomo, czy kod wykorzystywany przez potok jest teraz taki sam, jak gdy przebieg był uruchamiany.

W tym przebiegu dodajemy nową funkcję, która umożliwia łatwe wyświetlanie pełnego kodu YAML przebiegu potoku.

Azure Test Plans

Wprowadzanie nowego katalogu planów testowych

Bądź zorganizowany i oszczędzaj czas dzięki katalogowi Nowe plany testów. Wprowadzamy kilka ulepszeń, które ułatwiają wydajniejsze zarządzanie planami testów, zapewniając większą kontrolę nad obszarem roboczym i zmniejszenie powtarzalnych zadań.

gif do katalogu Plany testów.

Oto co nowego:

  • Czystszy projekt interfejsu użytkownika: łatwo nawiguj po planach testów przy użyciu nowoczesnego interfejsu, który zwiększa czytelność i zmniejsza bałagan, co pozwala skupić się na zadaniach bez rozpraszania uwagi.

  • Sortowanie kolumn: znajdowanie potrzebnych elementów szybciej przez sortowanie kolumn na podstawie nazwy, stanu lub innych atrybutów klucza. Ta funkcja ułatwia szybkie organizowanie i określanie priorytetów planów testowych w celu uzyskania lepszej wydajności.

  • Filtr zespołu na karcie Wszystkie: skup się na tym, co ma znaczenie, filtrując plany testów według zespołu, zapewniając, że widzisz tylko odpowiednie plany zgodne z twoimi zadaniami i celami.

  • Filtry trwałe: oszczędzaj czas dzięki trwałym filtrom, które zapamiętują ustawienia. Po powrocie do strony zastosowane wcześniej filtry pozostaną nienaruszone, zapewniając zorganizowany widok bez konieczności ponownego stosowania filtrów za każdym razem.

Te aktualizacje zostały zaprojektowane tak, aby usprawnić przepływ pracy, ograniczyć powtarzające się zadania i ułatwić śledzenie planów testów i zarządzanie nimi. Spróbuj i daj nam znać za pośrednictwem wiadomości e-mail co myślisz!

Zaawansowana historia wyników przypadku testowego

Łatwe śledzenie kluczowych szczegółów przebiegu testu dzięki nowym ulepszeniom strony wyników przypadku testowego. Na stronie zobaczysz kluczowe informacje, takie jak Identyfikator przebiegu, Identyfikator potoku, Właściciel, Ścieżka iteracji i Ścieżka obszaru, co umożliwia uzyskanie pełnego obrazu każdego przebiegu testu na pierwszy rzut oka.

Dodaliśmy przewijanie w poziomie dla dłuższych wartości i dostosowywalnych kolumn, co pozwala na personalizowanie układu i zachowywanie preferencji zapisanych na poziomie użytkownika. Aby przyspieszyć działanie, identyfikatory uruchomień i wiersze są klikalne, umożliwiając szybki dostęp do widoku Przebiegu testu w celu uzyskania szczegółowych informacji. Te aktualizacje mają na celu poprawę widoczności, oszczędność czasu i usprawnienie przepływu pracy, co ułatwia efektywne śledzenie przebiegów testów i zarządzanie nimi. Daj mu spróbować i daj nam znać za pośrednictwem poczty e-mail , jeśli masz jakiekolwiek opinie. Chcemy poznać Twoje zdanie!

Wyświetl stan przypadku testowego na karcie Wykonywanie

Teraz możesz dodać kolumnę "Test Case State" (Stan przypadku testowego) do karty Wykonywanie , aby szybko zobaczyć stan każdego przypadku testowego. Niezależnie od tego, czy jest to Zatwierdzony, W trakcie realizacji, czy jakikolwiek inny stan, ta aktualizacja zapewnia lepszy wgląd w przygotowanie do testów bez przełączania kart przeglądarki lub uruchamiania złożonych zapytań.

Kolumna jest opcjonalna i może być włączona za pośrednictwem selektora kolumn. Jest on również zgodny z istniejącym filtrem Stan, co umożliwia filtrowanie i wyświetlanie stanów przypadków testowych obok siebie— wszystko w jednym miejscu.

To ulepszenie pomaga zapewnić, że testerzy rozpoczynają wykonywanie z przypadkami testowymi, które są naprawdę gotowe lub zatwierdzone, zmniejszając ryzyko uruchamiania niekompletnych lub roboczych elementów i czyniąc przebiegi testów bardziej efektywnymi od samego początku.

Domyślne wznowienie dla wstrzymanego przypadku testowego

Szybko wznawiaj wstrzymane przypadki testowe jednym kliknięciem. Ustawiliśmy "Wznów" jako domyślną akcję dla wstrzymanych przypadków testowych, co pozwala łatwo kontynuować od miejsca, w którym przerwano, bez potrzeby dodatkowej nawigacji. Ta aktualizacja przyspiesza i ułatwia kontynuowanie pracy bez przerw.

Aby dodatkowo chronić Twoje postępy, wprowadzamy monit o potwierdzenie, aby zapobiec przypadkowemu nadpisaniu wstrzymanego postępu testu. To zabezpieczenie gwarantuje, że częściowo zapisana praca pozostanie nienaruszona, zapewniając spokój podczas zarządzania próbami testowymi. Spróbuj i daj nam znać za pośrednictwem wiadomości e-mail co myślisz!

Dalsze kroki

Uwaga / Notatka

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

Utwórz sugestię

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