Udostępnij za pośrednictwem

Informacje o wersji usługi Azure DevOps Server 2022 Update 1

  • Artykuł

| Wymagania systemowe społeczności deweloperów i zgodność | postanowienia licencyjne DevOps | Blog | SHA-256 Skróty SHA-256 | |

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

Aby dowiedzieć się więcej na temat instalowania lub uaktualniania wdrożenia usługi Azure DevOps Server, zobacz Wymagania dotyczące usługi Azure DevOps Server.

Aby pobrać produkty usługi Azure DevOps Server, odwiedź stronę pobierania usługi Azure DevOps Server.

Bezpośrednie uaktualnienie do usługi Azure DevOps Server 2022 Update 1 jest obsługiwane z poziomu programu Azure DevOps Server 2019 lub Team Foundation Server 2015 lub nowszego. Jeśli wdrożenie serwera TFS jest na serwerze TFS 2013 lub starszym, przed uaktualnieniem do usługi Azure DevOps Server 2022 należy wykonać pewne kroki tymczasowe. Aby uzyskać więcej informacji, zobacz stronę Instalowanie.

Azure DevOps Server 2022 Update 1 Patch 4 — data wydania: 11 czerwca 2024 r.

Plik Skrót SHA-256
devops2022.1patch4.exe 29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F

Opublikowaliśmy poprawkę 4 dla usługi Azure DevOps Server 2022 Update 1, która zawiera poprawkę dla następujących elementów.

  • Rozwiązano problem w witrynie typu wiki i elementach roboczych, w którym wyniki wyszukiwania nie były dostępne dla projektów z tureckimi ustawieniami regionalnymi "I".

Azure DevOps Server 2022 Update 1 Patch 3 — data wydania: 12 marca 2024 r.

Plik Skrót SHA-256
devops2022.1patch3.exe E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

Opublikowaliśmy poprawkę 3 dla usługi Azure DevOps Server 2022 Update 1, która zawiera poprawki dla następujących elementów.

  • Rozwiązano problem polegający na tym, że serwer proxy przestał działać po zainstalowaniu poprawki 2.
  • Rozwiązano problem z renderowaniem na stronie szczegółów rozszerzenia wpływający na języki, które nie były angielskie.

Azure DevOps Server 2022 Update 1 Patch 2 — data wydania: 13 lutego 2024 r.

Plik Skrót SHA-256
devops2022.1patch2.exe 59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

Opublikowaliśmy poprawkę 2 dla usługi Azure DevOps Server 2022 Update 1, która zawiera poprawki dla następujących elementów.

  • Rozwiązywanie problemu z renderowaniem strony szczegółów w rozszerzeniu wyszukiwania.
  • Usunięto usterkę polegającą na tym, że miejsce na dysku używane przez folder pamięci podręcznej serwera proxy było obliczane niepoprawnie i folder nie był prawidłowo czyszczony.
  • CVE-2024-20667: Luka w zabezpieczeniach dotycząca zdalnego wykonywania kodu serwera Azure DevOps Server.

Azure DevOps Server 2022 Update 1 Patch 1 — data wydania: 12 grudnia 2023 r.

Plik Skrót SHA-256
devops2022.1patch1.exe 9D0FDCCD1F20461E586689B756E600CC16424018A377042F7DC3A6EEF096FB6

Opublikowaliśmy poprawkę 1 dla usługi Azure DevOps Server 2022 Update 1, która zawiera poprawki dla następujących elementów.

  • Zapobiegaj ustawieniu requested for podczas kolejkowania przebiegu potoku.

Azure DevOps Server 2022 Update 1 — data wydania: 28 listopada 2023 r.

Uwaga

Istnieją dwa znane problemy z tą wersją:

  1. Wersja agenta nie jest aktualizowana po uaktualnieniu do usługi Azure DevOps Server 2022.1 i przy użyciu agenta aktualizacji w konfiguracji puli agentów. Obecnie pracujemy nad poprawką w celu rozwiązania tego problemu i udostępnimy aktualizacje w społeczności deweloperów w miarę postępu. W międzyczasie możesz znaleźć obejście tego problemu w tym bilecie Społeczności deweloperów.
  2. Zgodność programu Maven 3.9.x. Program Maven 3.9.x wprowadził zmiany powodujące niezgodność w usłudze Azure Artifacts, aktualizując domyślny transport narzędzia Rozpoznawanie maven do natywnego protokołu HTTP z wagonu. Powoduje to problemy z uwierzytelnianiem 401 dla klientów korzystających z protokołu HTTP zamiast https. Więcej szczegółów na temat tego problemu można znaleźć tutaj. Aby obejść ten problem, możesz nadal używać programu Maven 3.9.x z właściwością -Dmaven.resolver.transport=wagon. Ta zmiana wymusza, aby narzędzie Maven korzystało z transportu rozwiązania Wagon Resolver. Zapoznaj się z dokumentacją tutaj , aby uzyskać więcej informacji.

Azure DevOps Server 2022.1 to zestawienie poprawek błędów. Obejmuje ona wszystkie funkcje w wcześniej wydanym programie Azure DevOps Server 2022.1 RC2.

Uwaga

Istnieje znany problem ze zgodnością programu Maven 3.9.x. Program Maven 3.9.x wprowadził zmiany powodujące niezgodność w usłudze Azure Artifacts, aktualizując domyślny transport narzędzia Rozpoznawanie maven do natywnego protokołu HTTP z wagonu. Powoduje to problemy z uwierzytelnianiem 401 dla klientów korzystających z protokołu HTTP zamiast https. Więcej szczegółów na temat tego problemu można znaleźć tutaj.

Aby obejść ten problem, możesz nadal używać programu Maven 3.9.x z właściwością -Dmaven.resolver.transport=wagon. Ta zmiana wymusza, aby narzędzie Maven korzystało z transportu rozwiązania Wagon Resolver. Zapoznaj się z dokumentacją tutaj , aby uzyskać więcej informacji.

Azure DevOps Server 2022 Update 1 RC2 Data wydania: 31 października 2023 r.

Azure DevOps Server 2022.1 RC2 to zestawienie poprawek błędów. Obejmuje ona wszystkie funkcje w wcześniej wydanym programie Azure DevOps Server 2022.1 RC1.

Uwaga

Istnieje znany problem ze zgodnością programu Maven 3.9.x. Program Maven 3.9.x wprowadził zmiany powodujące niezgodność w usłudze Azure Artifacts, aktualizując domyślny transport narzędzia Rozpoznawanie maven do natywnego protokołu HTTP z wagonu. Powoduje to problemy z uwierzytelnianiem 401 dla klientów korzystających z protokołu HTTP zamiast https. Więcej szczegółów na temat tego problemu można znaleźć tutaj.

Aby obejść ten problem, możesz nadal używać programu Maven 3.9.x z właściwością -Dmaven.resolver.transport=wagon. Ta zmiana wymusza, aby narzędzie Maven korzystało z transportu rozwiązania Wagon Resolver. Zapoznaj się z dokumentacją tutaj , aby uzyskać więcej informacji.

W tej wersji naprawiono następujące kwestie:

  • Rozwiązano problem z lokalnymi kanałami informacyjnymi, który polegał na tym, że wpisy nadrzędne nie rozpoznawały zmian nazw wyświetlanych.
  • Wystąpił nieoczekiwany błąd podczas przełączania kart z kodu na inną kartę na stronie Wyszukiwanie.
  • Błąd podczas tworzenia nowego typu elementu roboczego z chińskimi, japońskimi i koreańskimi (CJK) Ujednoliconymi ideografami. Podczas zaewidencjonowania projektu zespołowego lub plików dołączonych do zestawu CJK w dzienniku RAW był wyświetlany znacznik zapytania.
  • Rozwiązano problem podczas instalacji funkcji Wyszukiwania, który polegał na tym, że maszyna wirtualna Java (JVM) nie mogła przydzielić wystarczającej ilości pamięci do procesu elastic search. Widżet konfiguracji wyszukiwania będzie teraz używać zestawu Java Development Kit (JDK), który jest powiązany z usługą Elastic Search, a tym samym usuwa zależność od dowolnego środowiska Java Runtime Environment (JRE) wstępnie zainstalowanego na serwerze docelowym.

Azure DevOps Server 2022 Update 1 RC1 Data wydania: 19 września 2023 r.

Program Azure DevOps Server 2022.1 RC1 zawiera 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:

Ogólne

Wszystkie publiczne interfejsy API REST obsługują szczegółowe zakresy pat

Wcześniej wiele publicznie udokumentowanych interfejsów API REST usługi Azure DevOps nie było skojarzonych z zakresami (np. odczytem elementów roboczych), które doprowadziły klientów do korzystania z pełnych zakresów w celu korzystania z tych interfejsów API za pośrednictwem nieinterakcyjnych mechanizmów uwierzytelniania, takich jak osobiste tokeny dostępu (PAT). Korzystanie z osobistego tokenu dostępu w pełnym zakresie zwiększa ryzyko, gdy może wylądować w rękach złośliwego użytkownika. Jest to jeden z głównych powodów, dla których wielu naszych klientów nie skorzystało w pełni z zasad płaszczyzny sterowania w celu ograniczenia użycia i zachowania pat.

Teraz wszystkie publiczne interfejsy API REST usługi Azure DevOps są teraz skojarzone i obsługują szczegółowy zakres pat. Jeśli obecnie używasz pełnego dostępu warunkowego do uwierzytelniania w jednym z publicznych interfejsów API REST usługi Azure DevOps, rozważ migrację do tokenu dostępu z określonym zakresem akceptowanym przez interfejs API, aby uniknąć niepotrzebnego dostępu. Obsługiwane szczegółowe zakresy pat dla danego interfejsu API REST można znaleźć w sekcji Zabezpieczenia stron dokumentacji. Ponadto w tym miejscu znajduje się tabela zakresów.

Rozszerzenia powinny wyświetlać zakresy

Podczas instalowania rozszerzeń w kolekcji usługi Azure DevOps możesz przejrzeć uprawnienia wymagane przez rozszerzenie w ramach instalacji. Jednak po zainstalowaniu uprawnienia rozszerzenia nie są widoczne w ustawieniach rozszerzenia. Stanowi to wyzwanie dla administratorów wymagających okresowego przeglądu zainstalowanych rozszerzeń. Teraz dodaliśmy uprawnienia rozszerzenia do ustawień rozszerzenia, aby ułatwić przeglądanie i podejmowanie świadomej decyzji o tym, czy je zachować, czy nie.

Tworzenie osobistych tokenów dostępu do wdrożenia w witrynie Marketplace

Boards

Kolumna Ostatni dostęp na stronie Plany dostarczania

Strona katalogu Plany dostarczania zawiera listę planów zdefiniowanych dla projektu. Możesz sortować według: Nazwa, Utworzona przez, Opis, Ostatnia konfiguracja lub Ulubione. Dzięki tej aktualizacji dodaliśmy kolumnę Ostatni dostęp do strony katalogu. Zapewnia to wgląd w czas ostatniego otwarcia planu dostarczania i przyjrzenia się temu. W związku z tym łatwo jest zidentyfikować plany, które nie są już używane i można je usunąć.

Obraz GIF do pokazu Ostatni dostęp do pola na stronie Plany dostarczania.

Wizualizowanie wszystkich zależności w planach dostarczania

Plany dostarczania zawsze zapewniały możliwość wyświetlania zależności między elementami roboczymi. Możesz zwizualizować linie zależności — jeden po drugim. W tej wersji ulepszyliśmy środowisko, umożliwiając wyświetlanie wszystkich wierszy zależności we wszystkich elementach roboczych na ekranie. Wystarczy kliknąć przycisk przełącznika zależności w prawym górnym rogu planu dostawy. Kliknij go ponownie, aby wyłączyć wiersze.

Plik GIF do wizualizacji demonstracyjnej wszystkich zależności na stronie Plany dostarczania.

Limity poprawek nowego elementu roboczego

W ciągu ostatnich kilku lat widzieliśmy kolekcje projektów z zautomatyzowanymi narzędziami generują dziesiątki tysięcy poprawek elementów roboczych. Powoduje to problemy z wydajnością i użytecznością formularza elementu roboczego oraz interfejsami API REST raportowania. Aby rozwiązać ten problem, zaimplementowaliśmy limit poprawki elementu roboczego o wartości 10 000 do usługi Azure DevOps Service. Limit dotyczy tylko aktualizacji przy użyciu interfejsu API REST, a nie formularza elementu roboczego.

Kliknij tutaj , aby dowiedzieć się więcej na temat limitu poprawek i sposobu obsługi go w zautomatyzowanym narzędziu.

Zwiększanie limitu zespołu planów dostarczania z zakresu od 15 do 20

Plany dostarczania umożliwiają wyświetlanie wielu list prac i wielu zespołów w kolekcji projektów. Wcześniej można było wyświetlić 15 list prac zespołu, w tym mieszankę list prac i zespołów z różnych projektów. W tej wersji zwiększyliśmy maksymalny limit z 15 do 20.

Usunęliśmy usterkę w interfejsie API pobierania linków elementów roboczych raportowania, aby zwrócić poprawną wartość remoteUrl dla System.LinkTypes.Remote.Related typów linków. Przed tą poprawką zwracaliśmy nieprawidłową nazwę kolekcji projektów i brakujący identyfikator projektu.

Tworzenie tymczasowego punktu końcowego REST zapytania

Widzieliśmy kilka wystąpień autorów rozszerzeń próbujących uruchamiać niezapisane zapytania, przekazując instrukcję WIQL (Work Item Query Language) za pośrednictwem ciągu zapytania. Działa to dobrze, chyba że masz dużą instrukcję WIQL, która osiąga limity przeglądarki na długości ciągu zapytania. Aby rozwiązać ten problem, utworzyliśmy nowy punkt końcowy REST, aby umożliwić autorom narzędzi generowanie zapytania tymczasowego. Użycie identyfikatora z odpowiedzi w celu przekazania przez element querystring eliminuje ten problem.

Dowiedz się więcej na stronie dokumentacji interfejsu API REST zapytań tymczasowych.

Interfejs API usuwania usługi Batch

Obecnie jedynym sposobem usunięcia elementów roboczych z kosza jest użycie tego interfejsu API REST do jednorazowego usunięcia. Może to być powolny proces i podlega ograniczeniu szybkości podczas próby przeprowadzenia dowolnego rodzaju masowego czyszczenia. W odpowiedzi dodaliśmy nowy punkt końcowy interfejsu API REST do usuwania i/lub niszczenia elementów roboczych w partii.

@CurrentIteration makro w planach dostarczania

Dzięki tej aktualizacji dodaliśmy obsługę makr dla @CurrentIteration stylów w planach dostarczania. To makro umożliwi uzyskanie bieżącej iteracji z kontekstu zespołu każdego wiersza w planie.

Plik GIF do demonstracyjnego makra CurrentIteration w planach dostarczania.

Logika zmiany rozmiaru karty w planach dostarczania

Nie wszyscy używają daty docelowej i/lub daty rozpoczęcia podczas śledzenia funkcji i epików. Niektórzy decydują się na użycie kombinacji dat i ścieżki iteracji. W tej wersji ulepszyliśmy logikę, aby odpowiednio ustawić kombinacje pól i ścieżki iteracji w zależności od sposobu ich użycia.

Jeśli na przykład data docelowa nie jest używana i zmieniasz rozmiar karty, nowa ścieżka iteracji jest ustawiona zamiast aktualizować datę docelową.

Plik GIF do demonstracyjnego linku do kopiowania komentarzy.

Ulepszenia aktualizacji usługi Batch

Wprowadziliśmy kilka zmian w wersji 7.1 interfejsu API aktualizacji wsadowej elementu roboczego. Obejmują one niewielkie ulepszenia wydajności i obsługę częściowych awarii. Oznacza to, że jeśli jedna poprawka nie powiedzie się, ale inne nie, pozostałe zostaną pomyślnie ukończone.

Kliknij tutaj , aby dowiedzieć się więcej na temat interfejsu API REST aktualizacji wsadowej.

Interfejs API usuwania usługi Batch

Ten nowy punkt końcowy interfejsu API REST do usunięcia i/lub zniszczenia elementów roboczych w partii jest teraz publicznie dostępny. Kliknij tutaj, aby dowiedzieć się więcej.

Zapobieganie edytowaniu pól listy wyboru z możliwością udostępniania

Pola niestandardowe są współużytkowane przez procesy. Może to spowodować problem z polami listy wyboru, ponieważ zezwalamy administratorom procesów na dodawanie lub usuwanie wartości z pola. W takim przypadku zmiany wpływają na to pole w każdym procesie, przy użyciu którego jest on używany.

Aby rozwiązać ten problem, dodaliśmy możliwość edytowania pola przez administratora kolekcji. Gdy pole listy wyboru jest zablokowane, administrator lokalnego procesu nie może zmienić wartości tej listy wyboru. Mogą tylko dodawać lub usuwać pole z procesu.

Plik GIF do demonstracyjnego edytowania pól listy wyboru z możliwością udostępniania.

Nowe uprawnienie do zapisywania komentarzy

Możliwość zapisywania tylko komentarzy elementów roboczych była głównym żądaniem w społeczności deweloperów. Z przyjemnością poinformujemy Cię, że zaimplementowaliśmy tę funkcję. Aby rozpocząć, przejrzyjmy najbardziej typowy scenariusz:

"Chcę uniemożliwić niektórym użytkownikom edytowanie pól elementów roboczych, ale umożliwić im współtworzenie dyskusji".

W tym celu należy przejść do ścieżki obszaru konfiguracji > projektu Ustawienia > projektu. Następnie wybierz wybraną ścieżkę obszaru i kliknij pozycję Zabezpieczenia.

Ścieżka obszaru

Zwróć uwagę na nowe uprawnienie "Edytuj komentarze elementów roboczych w tym węźle". Domyślnie uprawnienie jest ustawione na Wartość Nie ustawiono. Oznacza to, że element roboczy będzie zachowywał się dokładnie tak, jak wcześniej. Aby zezwolić grupie lub użytkownikom na zapisywanie komentarzy, wybierz tę grupę/użytkowników i zmień uprawnienie na Zezwalaj.

Nowe uprawnienie

Gdy użytkownik otworzy formularz elementu roboczego w tej ścieżce obszaru, będzie mógł dodawać komentarze, ale nie może zaktualizować żadnego z pozostałych pól.

Pokaz edytowania pól listy wyboru z możliwością udostępniania.

Mamy nadzieję, że pokochasz tę funkcję tak samo, jak my. Jak zawsze, jeśli masz jakiekolwiek opinie lub sugestie, daj nam znać.

Raporty tablic interakcyjnych

Interaktywne raporty znajdujące się w centrum Boards są dostępne od kilku lat w naszej hostowanej wersji produktu. Zastępują one starsze wykresy skumulowanego przepływu, prędkości i przebiegu. W tej wersji udostępniamy je.

Aby wyświetlić te wykresy, kliknij lokalizację karty Analiza na stronach Tablica Kanban, Lista prac i Przebiegi.

Raporty interakcyjne

Repos

Usuwanie uprawnień "Edytuj zasady" do twórcy gałęzi

Wcześniej po utworzeniu nowej gałęzi udzielono Ci uprawnień do edytowania zasad w tej gałęzi. W przypadku tej aktualizacji zmieniamy domyślne zachowanie, aby nie udzielać tego uprawnienia, nawet jeśli ustawienie „Zarządzanie uprawnieniami” jest włączone dla repozytorium.

Obraz zarządzania uprawnieniami.

Będziesz także potrzebować uprawnienia „Edytuj zasady” przyznanego jawnie (ręcznie lub za pośrednictwem interfejsu API REST) poprzez dziedziczenie uprawnień zabezpieczeń lub poprzez członkostwo w grupie.

Pipelines

Bieżący projekt ustawiony jako domyślny zakres tokenu dostępu kompilacji w potokach klasycznych

Usługa Azure Pipelines używa tokenów dostępu do zadań w celu uzyskania dostępu do innych zasobów w usłudze Azure DevOps w czasie wykonywania. Token dostępu do zadania to token zabezpieczający, który jest dynamicznie generowany przez usługę Azure Pipelines dla każdego zadania w czasie wykonywania. Wcześniej podczas tworzenia nowych klasycznych potoków wartość domyślna tokenu dostępu została ustawiona na Project Collection. Dzięki tej aktualizacji ustawiamy zakres autoryzacji zadania na bieżący projekt jako domyślny podczas tworzenia nowego potoku klasycznego.

Więcej szczegółowych informacji na temat tokenów dostępu do zadań można znaleźć w dokumentacji repozytoriów programu Access, artefaktów i innych zasobów.

Zmiana domyślnego zakresu tokenów dostępu w klasycznych potokach kompilacji

Aby zwiększyć bezpieczeństwo klasycznych potoków kompilacji, podczas tworzenia nowego zakresu autoryzacji zadania kompilacji będzie domyślnie projekt. Do tej pory była to kolekcja projektów. Przeczytaj więcej na temat tokenów dostępu do zadań. Ta zmiana nie ma wpływu na żadne z istniejących potoków. Ma to wpływ tylko na nowe klasyczne potoki kompilacji tworzone od tego momentu.

Obsługa usługi Azure Pipelines dla wersji San Diego, Tokio i Utah usługi ServiceNow

Usługa Azure Pipelines ma istniejącą integrację z usługą ServiceNow. Integracja opiera się na aplikacji w usłudze ServiceNow i rozszerzeniu w usłudze Azure DevOps. Teraz zaktualizowaliśmy aplikację do pracy z wersjami Usługi ServiceNow w San Diego, Tokio i Utah. Aby upewnić się, że ta integracja działa, przeprowadź uaktualnienie do nowej wersji aplikacji (4.215.2) ze sklepu ServiceNow.

Aby uzyskać więcej informacji, zobacz dokumentację Integrowanie z usługą ServiceNow Change Management.

Korzystanie z adresów URL serwera proxy na potrzeby integracji z usługą GitHub Enterprise

Usługa Azure Pipelines integruje się z lokalnymi serwerami GitHub Enterprise Server w celu uruchamiania kompilacji ciągłej integracji i żądań ściągnięcia. W niektórych przypadkach serwer GitHub Enterprise Server znajduje się za zaporą i wymaga, aby ruch był kierowany przez serwer proxy. Aby obsłużyć ten scenariusz, połączenia usługi GitHub Enterprise Server w usłudze Azure DevOps umożliwiają skonfigurowanie adresu URL serwera proxy. Wcześniej nie cały ruch z usługi Azure DevOps był kierowany przez ten adres URL serwera proxy. Dzięki tej aktualizacji upewniamy się, że kierujemy następujący ruch z usługi Azure Pipelines, aby przejść przez adres URL serwera proxy:

  • Pobieranie gałęzi
  • Pobieranie informacji o żądaniu ściągnięcia
  • Stan kompilacji raportu

Połączenia usługi Container Registry mogą teraz używać tożsamości zarządzanych platformy Azure

Tożsamość zarządzana przypisana przez system można użyć podczas tworzenia połączeń usługi Docker Registry dla usługi Azure Container Registry. Dzięki temu można uzyskać dostęp do usługi Azure Container Registry przy użyciu tożsamości zarządzanej skojarzonej z własnym agentem usługi Azure Pipelines, eliminując konieczność zarządzania poświadczeniami.

Nowe połączenie usługi rejestru platformy Docker w celu wprowadzenia zmian w zatwierdzeniach

Uwaga

Tożsamość zarządzana używana do uzyskiwania dostępu do usługi Azure Container Registry będzie potrzebować odpowiedniego przypisania kontroli dostępu na podstawie ról (RBAC), np. roli AcrPull lub AcrPush.

Automatyczne tokeny utworzone dla połączenia usługi Kubernetes Service

Ponieważ platforma Kubernetes 1.24, tokeny nie były już tworzone automatycznie podczas tworzenia nowego połączenia usługi Kubernetes. Dodaliśmy tę funkcję z powrotem. Zaleca się jednak użycie połączenia z usługą Azure podczas uzyskiwania dostępu do usługi AKS, aby dowiedzieć się więcej na temat wskazówek dotyczących połączenia z usługą dla klientów usługi AKS korzystających z zadań platformy Kubernetes w blogu.

Zadania kubernetes obsługują teraz rozwiązanie kubelogin

Zaktualizowaliśmy zadania KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 i AzureFunctionOnKubernetes@1 w celu obsługi narzędzia kubelogin. Dzięki temu można kierować usługę Azure Kubernetes Service (AKS) skonfigurowaną z integracją usługi Azure Active Directory.

Platforma Kubelogin nie jest wstępnie zainstalowana na hostowanych obrazach. Aby upewnić się, że wymienione powyżej zadania używają narzędzia kubelogin, zainstaluj je, wstawiając zadanie KubeloginInstaller@0 przed zadaniem, które jest od niego zależne:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Ulepszenia środowiska dotyczące uprawnień potoku

Ulepszyliśmy środowisko zarządzania uprawnieniami potoku, aby system uprawnień zapamiętał, czy potok wcześniej używał chronionego zasobu, takiego jak połączenie z usługą.

W przeszłości, jeśli podczas tworzenia chronionego zasobu została zaznaczona opcja "Udziel uprawnień dostępu do wszystkich potoków", ale następnie ograniczono dostęp do zasobu, potok potrzebował nowej autoryzacji do korzystania z zasobu. To zachowanie było niespójne z kolejnym otwarciem i zamknięciem dostępu do zasobu, w którym nie była wymagana nowa autoryzacja. Jest to teraz naprawione.

Nowy zakres pat do zarządzania autoryzacją potoku i zatwierdzeniami i sprawdzaniem

Aby ograniczyć szkody spowodowane wyciekiem tokenu PAT, dodaliśmy nowy zakres pat o nazwie Pipeline Resources. Ten zakres pat można użyć podczas zarządzania autoryzacją potoku przy użyciu chronionego zasobu, takiego jak połączenie z usługą, lub do zarządzania zatwierdzeniami i sprawdzania tego zasobu.

Zrzut ekranu przedstawiający aktualizacje interfejsu API REST potoków.

Następujące wywołania interfejsu API REST obsługują nowy zakres pat w następujący sposób:

Ograniczanie otwierania chronionych zasobów do administratorów zasobów

Aby zwiększyć bezpieczeństwo zasobów, które mają kluczowe znaczenie dla możliwości bezpiecznego kompilowania i wdrażania aplikacji, usługa Azure Pipelines wymaga teraz roli administratora typu zasobu podczas otwierania dostępu do zasobu do wszystkich potoków.

Na przykład do zezwalania na używanie połączenia z usługą jest wymagana ogólna rola administratora połączeń usług. To ograniczenie dotyczy tworzenia chronionego zasobu lub edytowania konfiguracji zabezpieczeń.

Ponadto podczas tworzenia połączenia z usługą i nie masz wystarczających praw, opcja Udziel dostępu do wszystkich potoków jest wyłączona.

Połączenia z usługami Ponadto podczas próby otwarcia dostępu do istniejącego zasobu i nie masz wystarczających praw, otrzymasz komunikat Nie masz uprawnień do otwierania dostępu do tego zasobu .

Uprawnienia potoków

Ulepszenia zabezpieczeń interfejsu API REST potoków

Większość interfejsów API REST w usłudze Azure DevOps używa tokenów pat o określonym zakresie. Jednak niektóre z nich wymagają w pełni zakres tokenów PAT. Innymi słowy, należy utworzyć token pat, wybierając pozycję "Pełny dostęp", aby użyć niektórych z tych interfejsów API. Takie tokeny stanowią zagrożenie bezpieczeństwa, ponieważ mogą być używane do wywoływania dowolnego interfejsu API REST. Wprowadziliśmy ulepszenia w usłudze Azure DevOps, aby usunąć potrzebę w pełni określonych tokenów, włączając każdy interfejs API REST do określonego zakresu. W ramach tego nakładu pracy interfejs API REST do aktualizowania uprawnień potoku dla zasobu wymaga teraz określonego zakresu. Zakres zależy od typu zasobu autoryzowanego do użycia:

  • Code (read, write, and manage) dla zasobów typu repository
  • Agent Pools (read, manage) lub Environment (read, manage) dla zasobów typu queue i agentpool
  • Secure Files (read, create, and manage) dla zasobów typu securefile
  • Variable Groups (read, create and manage) dla zasobów typu variablegroup
  • Service Endpoints (read, query and manage) dla zasobów typu endpoint
  • Environment (read, manage) dla zasobów typu environment

Aby zbiorczo edytować uprawnienia potoków, nadal będziesz potrzebować w pełni ograniczonego tokenu pat. Aby dowiedzieć się więcej na temat aktualizowania uprawnień potoku dla zasobów, zobacz dokumentację Uprawnienia potoku — aktualizowanie uprawnień potoku dla zasobów .

Szczegółowe zarządzanie dostępem dla pul agentów

Pule agentów umożliwiają określanie maszyn, na których działają potoki i zarządzanie nimi.

Wcześniej, jeśli użyto niestandardowej puli agentów, zarządzanie potokami, do których potoków może uzyskiwać dostęp, było gruboziarniste. Możesz zezwolić na korzystanie ze wszystkich potoków lub wymagać, aby każdy potok poprosił o uprawnienie. Niestety po udzieleniu uprawnień dostępu do potoku do puli agentów nie można go odwołać przy użyciu interfejsu użytkownika potoków.

Usługa Azure Pipelines zapewnia teraz szczegółowe zarządzanie dostępem dla pul agentów. Środowisko jest podobne do tego, które służy do zarządzania uprawnieniami potoku dla połączeń usług.

Pula agentów FabrikamFiber dla zmian w zatwierdzeniach

Zapobieganie udzielaniu dostępu do wszystkich potoków chronionym zasobom

Podczas tworzenia chronionego zasobu, takiego jak połączenie z usługą lub środowisko, możesz zaznaczyć pole wyboru Udziel uprawnień dostępu do wszystkich potoków . Do tej pory ta opcja została domyślnie zaznaczona.

Chociaż ułatwia to potokom korzystanie z nowych chronionych zasobów, odwrotnie jest to, że faworyzuje przypadkowe przyznanie zbyt wielu potoków prawa dostępu do zasobu.

Aby podwyższyć poziom bezpieczeństwa domyślnie, usługa Azure DevOps pozostawia pole wyboru niezakluczone.

Przyznawanie uprawnień dostępu do wszystkich potoków jest domyślnie wyłączone

Możliwość wyłączenia maskowania krótkich wpisów tajnych

Usługa Azure Pipelines maskuje wpisy tajne w dziennikach. Wpisy tajne mogą być zmiennymi oznaczonymi jako wpis tajny, zmiennymi z grup zmiennych połączonych z usługą Azure Key Vault lub elementami połączenia usługi oznaczonymi jako wpis tajny przez dostawcę połączenia z usługą.

Wszystkie wystąpienia wartości wpisu tajnego są maskowane. Maskowanie krótkich wpisów tajnych, np. "1", "2Dev", ułatwia odgadnięcie ich wartości, np. w dacie: "Jan 3, 202***"
Teraz jest jasne, "3" jest tajemnicą. W takich przypadkach możesz całkowicie nie maskować wpisu tajnego. Jeśli nie można oznaczyć wartości jako wpisu tajnego (np. wartość jest pobierana z usługi Key Vault), możesz ustawić AZP_IGNORE_SECRETS_SHORTER_THAN pokrętło na wartość maksymalnie 4.

Zadanie pobierania modułu uruchamiającego węzły

W przypadku wdrażania wydań agenta, które wykluczają moduł uruchamiający zadania node 6, może być okazjonalnie konieczne uruchamianie zadań, które nie zostały zaktualizowane w celu korzystania z nowszego modułu uruchamiającego węzeł. W tym scenariuszu udostępniamy metodę, aby nadal używać zadań zależnych od modułów uruchamiaczy end-of-life węzłów, zobacz wpis w blogu dotyczący wskazówek dotyczących modułu uruchamiającego węzły.

Poniższe zadanie to metoda instalowania modułu uruchamiającego oprogramowanie Node 6 just-in-time, więc stare zadanie może nadal być wykonywane:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

Zaktualizowano walidację modułu uruchamiającego węzły TFX

Autorzy zadań używają narzędzia do tworzenia pakietów rozszerzeń (TFX) do publikowania rozszerzeń. Funkcja TFX została zaktualizowana w celu przeprowadzenia walidacji w wersjach modułu uruchamiającego węzeł. Zobacz wpis w blogu wskazówki dotyczące modułu uruchamiającego węzły.

Rozszerzenia zawierające zadania korzystające z modułu uruchamiającego węzeł 6 będą widzieć następujące ostrzeżenie:

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

Instrukcje dotyczące ręcznej wstępnej instalacji węzła 6 na agentach potoku

Jeśli używasz kanału informacyjnego pipeline-agenta, nie masz węzła 6 dołączonego do agenta. W niektórych przypadkach, gdy zadanie platformy Marketplace jest nadal zależne od węzła Node 6, a agent nie jest w stanie użyć zadania NodeTaskRunnerInstaller (np. z powodu ograniczeń łączności), konieczne będzie wstępne zainstalowanie węzła Node 6 niezależnie. Aby to zrobić, zapoznaj się z instrukcjami dotyczącymi ręcznego instalowania modułu uruchamiającego węzeł Node 6.

Dziennik zmian zadań potoku

Teraz publikujemy zmiany w zadaniach potoku w tym dzienniku zmian. Zawiera pełną listę zmian wprowadzonych we wbudowanych zadaniach potoku. Opublikowaliśmy wcześniejsze zmiany z mocą wsteczną, więc dziennik zmian zawiera historyczny rekord aktualizacji zadań.

Zadania wydania korzystają z interfejsu API programu Microsoft Graph

Zaktualizowaliśmy nasze zadania wydania w celu korzystania z interfejsu API programu Microsoft Graph. Spowoduje to usunięcie użycia interfejsu API programu Graph usługi AAD z naszych zadań.

Poprawa wydajności zadań programu Windows PowerShell

Zadania można używać do definiowania automatyzacji w potoku. Jednym z tych zadań jest PowerShell@2 zadanie narzędzia, które umożliwia wykonywanie skryptów programu PowerShell w potoku. Aby użyć skryptu programu PowerShell do kierowania środowiska platformy Azure, możesz użyć AzurePowerShell@5 zadania . Niektóre polecenia programu PowerShell, które mogą drukować aktualizacje postępu, na przykład Invoke-WebRequest, są teraz wykonywane szybciej. Poprawa jest bardziej znacząca, jeśli masz wiele z tych poleceń w skrypsie lub gdy są długotrwałe. Dzięki tej aktualizacji progressPreference właściwość PowerShell@2 zadań i AzurePowerShell@5 jest teraz domyślnie ustawiona na SilentlyContinue wartość .

Agent potoków w wersji 3 na platformie .NET 6

Agent potoku został uaktualniony do używania platformy .NET 3.1 Core do platformy .NET 6 jako środowiska uruchomieniowego. Wprowadza to natywną obsługę systemu Apple Silicon, a także Windows Arm64.

Korzystanie z platformy .NET 6 ma wpływ na wymagania systemowe agenta. W szczególności spadek obsługi następujących systemów operacyjnych: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Zobacz dokumentację oprogramowania agenta w wersji 3.

Ten skrypt może służyć do identyfikowania potoków korzystających z agentów z nieobsługiwanymi systemami operacyjnymi.

Ważne

Należy pamiętać, że agenci działający w dowolnym z powyższych systemów operacyjnych nie będą już aktualizować ani nie działać po wdrożeniu agenta opartego na platformie .NET 6.

Określanie wersji agenta w rozszerzeniu maszyny wirtualnej agenta

Maszyny wirtualne platformy Azure można uwzględnić w grupach wdrożeń przy użyciu rozszerzenia maszyny wirtualnej. Rozszerzenie maszyny wirtualnej zostało zaktualizowane w celu opcjonalnego określenia żądanej wersji agenta do zainstalowania:

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

Nowe przełączanie w celu kontrolowania tworzenia klasycznych potoków

Usługa Azure DevOps umożliwia teraz zapewnienie, że kolekcja projektów używa tylko potoków YAML, wyłączając tworzenie klasycznych potoków kompilacji, klasycznych potoków wydania, grup zadań i grup wdrożeń. Istniejące potoki klasyczne będą nadal działać i będzie można je edytować, ale nie będzie można tworzyć nowych.

Usługa Azure DevOps umożliwia teraz zapewnienie, że organizacja korzysta tylko z potoków YAML, wyłączając tworzenie klasycznych potoków kompilacji, klasycznych potoków wydania, grup zadań i grup wdrożeń. Istniejące potoki klasyczne będą nadal działać i będzie można je edytować, ale nie będzie można tworzyć nowych.

Możesz wyłączyć tworzenie klasycznych potoków na poziomie kolekcji projektów lub na poziomie projektu, włączając odpowiednie przełączanie. Przełączanie można znaleźć w obszarze Project/Project Settings — Pipelines - Settings (Ustawienia projektu/ projektu —> potoki —> ustawienia). Istnieją dwa przełączniki: jeden dla klasycznych potoków kompilacji i jeden dla klasycznych potoków wydania, grup wdrożeń i grup zadań.

Wyłączanie tworzenia potoków klasycznych

Stan przełączania jest domyślnie wyłączony i musisz mieć uprawnienia administratora, aby zmienić stan. Jeśli przełącznik jest włączony na poziomie organizacji, wyłączenie jest wymuszane dla wszystkich projektów. W przeciwnym razie każdy projekt jest bezpłatny, aby wybrać, czy wymuszać, czy nie wyłączyć.

Wyłączenie tworzenia klasycznych potoków jest wymuszane, interfejsy API REST związane z tworzeniem klasycznych potoków, grup zadań i grup wdrożeń zakończy się niepowodzeniem. Interfejsy API REST, które tworzą potoki YAML, będą działać.

Aktualizacje zdarzenia "Zmiana stanu etapu uruchamiania" elementu service hook

Punkty zaczepienia usługi umożliwiają uruchamianie zadań w innych usługach, gdy zdarzenia występują w projekcie w usłudze Azure DevOps. Stan etapu uruchamiania zmienia się w jednym z tych zdarzeń. Zdarzenie Zmiany stanu etapu uruchamiania musi zawierać informacje o przebiegu, w tym nazwę potoku. Wcześniej zawierał tylko informacje o identyfikatorze i nazwie przebiegu. Dzięki tej aktualizacji wprowadziliśmy zmiany w zdarzeniu, aby uwzględnić brakujące informacje.

Wyłącz wyświetlanie ostatniego komunikatu zatwierdzenia dla uruchomienia potoku

Wcześniej interfejs użytkownika potoków używany do wyświetlania ostatniego komunikatu zatwierdzenia podczas wyświetlania uruchomienia potoku.

Przykład ostatniego komunikatu zatwierdzenia

Ten komunikat może być mylący, na przykład wtedy, gdy kod potoku YAML znajduje się w repozytorium innym niż ten, który przechowuje kod, który jest kompilujący. Wysłuchaliśmy opinii społeczności deweloperów z prośbą o włączenie/wyłączenie dołączania najnowszego komunikatu zatwierdzenia do tytułu każdego uruchomienia potoku.

Dzięki tej aktualizacji dodaliśmy nową właściwość YAML o nazwie appendCommitMessageToRunName, która umożliwia wykonanie dokładnie tej czynności. Domyślnie właściwość jest ustawiona na truewartość . Po ustawieniu go na falsewartość , uruchomienie potoku BuildNumberbędzie wyświetlać tylko element .

Przykład uruchomienia potoku z numerem kompilacji

Przykład uruchomienia potoku z komunikatem ostatniego zatwierdzenia

Zwiększono limity usługi Azure Pipeline w celu dostosowania do maksymalnego rozmiaru szablonu usługi Azure Resource Manager (ARM) 4 MB.

Aby utworzyć infrastrukturę platformy Azure, możesz użyć zadania wdrażania szablonu usługi Azure Resource Manager. W odpowiedzi na Twoją opinię zwiększyliśmy limit integracji usługi Azure Pipelines wynoszący od 2 MB do 4 MB. Będzie to zgodne z szablonami usługi ARM o maksymalnym rozmiarze 4 MB rozpoznawania ograniczeń rozmiaru podczas integracji dużych szablonów.

Ikona przeglądu stanu uruchomienia potoku

W tej wersji ułatwiamy poznanie ogólnego stanu uruchomienia potoku.

W przypadku potoków YAML, które mają wiele etapów, trudno było poznać stan uruchomienia potoku, czyli jest to, że jest on nadal uruchomiony lub został ukończony. A jeśli to się skończy, jaki jest ogólny stan: powodzenie, niepowodzenie lub anulowanie. Rozwiązaliśmy ten problem, dodając ikonę przeglądu stanu przebiegu.

Ikona przeglądu stanu uruchomienia potoku

Panel boczny etapów potoku

Potoki YAML mogą mieć dziesiątki etapów, a nie wszystkie z nich będą pasować na ekranie. Chociaż ikona przeglądu przebiegu potoku informuje o ogólnym stanie przebiegu, nadal trudno jest wiedzieć, który etap zakończył się niepowodzeniem lub który etap jest nadal uruchomiony, na przykład.

W tej wersji dodaliśmy panel boczny etapów potoku, który pozwala szybko zobaczyć stan wszystkich etapów. Następnie możesz kliknąć etap i przejść bezpośrednio do jego dzienników.

Potoki aktualizacji

Aktualizacje interfejsu użytkownika potoków

Wyszukiwanie etapów w panelu bocznym

Ułatwiliśmy znajdowanie etapów, których szukasz w panelu bocznym etapów. Teraz możesz szybko filtrować etapy na podstawie ich stanu, na przykład etapów uruchamiania lub tych, które wymagają interwencji ręcznej. Możesz również wyszukać etapy według ich nazwy.

Aktualizowanie potoków AZ

Szybkie akcje etapu

Ekran Uruchomienia potoku zapewnia szybki dostęp do wszystkich etapów uruchamiania. W tej wersji dodaliśmy panel etapów, z którego można wykonywać akcje dla każdego etapu. Można na przykład łatwo ponownie uruchomić zadania, które zakończyły się niepowodzeniem, lub ponownie uruchomić cały etap. Panel jest dostępny, gdy nie wszystkie etapy mieszczą się w interfejsie użytkownika, jak widać na poniższym zrzucie ekranu.

Zrzut ekranu przedstawiający potok z zbyt wieloma etapami. Po kliknięciu znaku "+" w kolumnie etapy zostanie wyświetlony panel etapów, a następnie można wykonać akcje etapu.

Zrzut ekranu przedstawiający panel etapów.

Sprawdzanie ulepszeń środowiska użytkownika

Ułatwiamy odczytywanie dzienników sprawdzania. Sprawdzanie dzienników zapewnia informacje krytyczne dla powodzenia wdrożenia. Mogą powiedzieć, czy nie pamiętasz o zamknięciu biletu elementu roboczego lub że musisz zaktualizować bilet w usłudze ServiceNow. Wcześniej, wiedząc, że sprawdzenie pod warunkiem, że takie krytyczne informacje były trudne.

Teraz na stronie szczegółów przebiegu potoku jest wyświetlany najnowszy dziennik sprawdzania. Dotyczy to tylko kontroli, które są zgodne z naszym zalecanym użyciem.

Obraz przedstawiający najnowszy dziennik sprawdzania. Aby zapobiec błędnemu zatwierdzeniu zatwierdzeń, usługa Azure DevOps wyświetla instrukcje zatwierdzania w panelu bocznym Zatwierdzenia i sprawdzania na stronie szczegółów przebiegu potoku.

Oczekiwanie na obraz przeglądu potoku.

Wyłączanie sprawdzania

Wprowadziliśmy testy debugowania mniej żmudne. Czasami sprawdzanie wywołania funkcji platformy Azure lub wywołania interfejsu API REST nie działa poprawnie i należy go naprawić. Wcześniej trzeba było usunąć takie kontrole, aby uniemożliwić im błędne blokowanie wdrożenia. Po naprawieniu sprawdzania trzeba było go ponownie dodać i skonfigurować poprawnie, upewniając się, że wszystkie wymagane nagłówki są ustawione lub parametry zapytania są poprawne. To jest żmudne.

Teraz możesz po prostu wyłączyć sprawdzanie. Wyłączone sprawdzanie nie zostanie uruchomione w kolejnych ocenach pakietu sprawdzania.

Wyłącz obraz sprawdzania. Po naprawieniu błędnego sprawdzania można go tylko włączyć.

Włącz obraz sprawdzania.

Zużyte zasoby i parametry szablonu w interfejsie API REST przebiegów potoków

Rozszerzony interfejs API REST przebiegów potoków zwraca teraz więcej typów artefaktów używanych przez uruchomienie potoku i parametry używane do wyzwalania tego uruchomienia. Ulepszyliśmy interfejs API w celu zwrócenia container zasobów i oraz pipeline parametrów szablonu używanych w przebiegu potoku. Teraz możesz na przykład pisać testy zgodności, które oceniają repozytoria, kontenery i inne uruchomienia potoków używane przez potok.

Oto przykład nowej treści odpowiedzi.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Ogólna obsługa szablonu dostępności 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. Jednak edytor nie obsługiwał szablonów do tej pory. Autorzy potoków YAML nie mogą uzyskać pomocy za pośrednictwem funkcji IntelliSense podczas korzystania z szablonu. Autorzy szablonów nie mogli korzystać z edytora YAML. W tej wersji dodajemy obsługę szablonów w edytorze YAML.

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.

Aktualizacje interfejsu API REST potoków

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

Istnieją znane ograniczenia:

  • 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.
  • Nie można utworzyć nowego szablonu z poziomu edytora. Można używać lub edytować tylko istniejące szablony.

Nowa wstępnie zdefiniowana zmienna systemowa

Wprowadziliśmy nową wstępnie zdefiniowaną zmienną systemową o nazwie Build.DefinitionFolderPath, której wartością jest ścieżka folderu definicji potoku kompilacji. Zmienna jest dostępna zarówno w potokach YAML, jak i w klasycznych potokach kompilacji.

Jeśli na przykład potok znajduje się w FabrikamFiber\Chat folderze w usłudze Azure Pipelines, wartość to Build.DefinitionFolderPath FabrikamFiber\Chat.

Dodano obsługę funkcji dzielenia ciągów w wyrażeniach szablonu YAML

Potoki YAML zapewniają wygodne sposoby zmniejszania duplikowania kodu, takich jak pętla przez each wartość listy lub właściwości obiektu.

Czasami zestaw elementów do iterowania jest reprezentowany jako ciąg. Na przykład gdy lista środowisk do wdrożenia w programie jest definiowana przez ciąg integration1, integration2.

Gdy wysłuchaliśmy opinii społeczności deweloperów, słyszeliśmy, że potrzebujesz funkcji ciągu split w wyrażeniach szablonów YAML.

Teraz możesz utworzyć ciąg i wykonać split iterację each po jego podciągach.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Wyrażenia szablonów w definicji zasobu repozytorium

Dodaliśmy obsługę wyrażeń szablonu podczas definiowania ref właściwości repository zasobu w potoku YAML. Była to bardzo żądana funkcja przez naszą społeczność deweloperów.

Istnieją przypadki użycia, gdy potok ma wyewidencjonować różne gałęzie tego samego zasobu repozytorium.

Załóżmy na przykład, że masz potok, który kompiluje własne repozytorium, a w tym celu musi wyewidencjonować bibliotekę z repozytorium zasobów. Ponadto załóżmy, że chcesz, aby potok wyewidencjonowył tę samą gałąź biblioteki, której używa sam. Jeśli na przykład potok jest uruchamiany w main gałęzi, należy wyewidencjonować main gałąź repozytorium biblioteki. Jeśli potoki działają w dev gałęzi, należy wyewidencjonować dev gałąź biblioteki.

Do dziś trzeba było jawnie określić gałąź do wyewidencjonowania i zmienić kod potoku za każdym razem, gdy gałąź ulegnie zmianie.

Teraz możesz użyć wyrażeń szablonu, aby wybrać gałąź zasobu repozytorium. Zapoznaj się z poniższym przykładem kodu YAML, który ma być używany dla gałęzi innych niż główne potoku:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

Po uruchomieniu potoku możesz określić gałąź do wyewidencjonowania library repozytorium.

Określanie wersji szablonu do rozszerzenia w czasie kolejki kompilacji

Szablony stanowią doskonały sposób na zmniejszenie duplikowania kodu i zwiększenie bezpieczeństwa potoków.

Jednym z popularnych przypadków użycia jest domowy szablony we własnym repozytorium. Zmniejsza to sprzężenie między szablonem a potokami, które go rozszerzają, i ułatwia niezależne rozwijanie szablonu i potoków.

Rozważmy poniższy przykład, w którym szablon jest używany do monitorowania wykonywania listy kroków. Kod szablonu Templates znajduje się w repozytorium.

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

Załóżmy, że masz potok YAML, który rozszerza ten szablon znajdujący się w repozytorium FabrikamFiber. Do dziś nie można było dynamicznie określić ref właściwości templates zasobu repozytorium w przypadku używania repozytorium jako źródła szablonu. Oznaczało to, że trzeba zmienić kod potoku, jeśli chcesz, aby potok był następujący: rozszerzenie szablonu z innej gałęzi rozszerza szablon z tej samej nazwy gałęzi co potok, niezależnie od gałęzi, w której uruchomiono potok

Wprowadzenie wyrażeń szablonu w definicji zasobu repozytorium umożliwia napisanie potoku w następujący sposób:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

W ten sposób potok rozszerzy szablon w tej samej gałęzi co gałąź, w której działa potok, aby upewnić się, że gałęzie potoku i szablonu są zawsze zgodne. Oznacza to, że uruchomienie potoku w gałęzi devspowoduje rozszerzenie szablonu określonego przez template.yml plik w dev gałęzi templates repozytorium.

Możesz też wybrać w czasie kompilacji kolejki, która gałąź repozytorium szablonów ma być używana, pisząc następujący kod YAML.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

Teraz możesz mieć potok w gałęzi main rozszerzać szablon z gałęzi dev w jednym przebiegu i rozszerzać szablon z gałęzi main w innym przebiegu bez zmiany kodu potoku.

Podczas określania wyrażenia szablonu dla ref właściwości zasobu repozytorium można użyć parameters i wstępnie zdefiniowanych zmiennych systemowych, ale nie można użyć zmiennych zdefiniowanych przez interfejs użytkownika yaML ani pipelines.

Wyrażenia szablonu w definicji zasobu kontenera

Dodaliśmy obsługę wyrażeń szablonu podczas definiowania endpointwłaściwości container , volumesi portsoptions zasobu w potoku YAML. Była to bardzo żądana funkcja przez naszą społeczność deweloperów.

Teraz możesz pisać potoki YAML, takie jak poniżej.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

Możesz użyć parameters. wyrażeń szablonu i variables. . W przypadku zmiennych można używać tylko tych zdefiniowanych w pliku YAML, ale nie zdefiniowanych w interfejsie użytkownika potoków. Jeśli na przykład ponownie zdefiniowasz zmienną przy użyciu poleceń dziennika agenta, nie będzie to miało żadnego wpływu.

Ulepszenia zaplanowanych kompilacji

Rozwiązano problem powodujący uszkodzenie informacji o harmonogramie potoku, a potok nie był ładowany. Było to spowodowane na przykład tym, że nazwa gałęzi przekroczyła określoną liczbę znaków.

Ulepszony komunikat o błędzie podczas niepowodzenia ładowania potoków

Usługa Azure Pipelines udostępnia kilka typów wyzwalaczy w celu skonfigurowania sposobu uruchamiania potoku. Jednym ze sposobów uruchamiania potoku jest użycie zaplanowanych wyzwalaczy. Czasami informacje o zaplanowanym uruchomieniu potoku są uszkodzone i mogą powodować niepowodzenie ładowania. Wcześniej wyświetlaliśmy wprowadzający w błąd komunikat o błędzie, twierdząc, że potok nie został znaleziony. W przypadku tej aktualizacji rozwiązaliśmy ten problem i zwracamy komunikat o błędzie informacyjny. W przyszłości otrzymasz komunikat podobny do: Dane harmonogramu kompilacji są uszkodzone , jeśli nie można załadować potoku.

Nie synchronizuj tagów podczas pobierania repozytorium Git

Zadanie wyewidencjonowania używa --tags opcji pobierania zawartości repozytorium Git. Powoduje to pobranie wszystkich tagów przez serwer oraz wszystkich obiektów wskazywanych przez te tagi. Zwiększa to czas uruchamiania zadania w potoku — szczególnie jeśli masz duże repozytorium z wieloma tagami. Ponadto zadanie wyewidencjonowania synchronizuje tagi nawet wtedy, gdy włączysz opcję płytkiego pobierania, co może pokonać jego cel. Aby zmniejszyć ilość danych pobranych lub ściągniętych z repozytorium Git, dodaliśmy teraz nową opcję do zadania w celu kontrolowania zachowania synchronizacji tagów. Ta opcja jest dostępna zarówno w potokach klasycznych, jak i YAML.

To zachowanie może być kontrolowane z pliku YAML lub z interfejsu użytkownika.

Aby zrezygnować z synchronizacji tagów za pośrednictwem pliku YAML, dodaj element fetchTags: false do kroku wyewidencjonowania. fetchTags Jeśli opcja nie jest określona, jest taka sama jak w przypadku fetchTags: true użycia.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Jeśli chcesz zmienić zachowanie istniejących potoków YAML, może być wygodniejsze ustawienie tej opcji w interfejsie użytkownika zamiast aktualizowania pliku YAML. Aby przejść do interfejsu użytkownika, otwórz edytor YAML dla potoku, wybierz pozycję Wyzwalacze, a następnie pozycję Przetwarzanie, a następnie krok Wyewidencjonuj.

Jeśli określisz to ustawienie zarówno w pliku YAML, jak i w interfejsie użytkownika, pierwszeństwo ma wartość określona w pliku YAML.

W przypadku wszystkich nowych potoków tworzonych (YAML lub Klasyczny) tagi są domyślnie synchronizowane. Ta opcja nie zmienia zachowania istniejących potoków. Tagi będą nadal synchronizowane w tych potokach, chyba że jawnie zmienisz opcję zgodnie z powyższym opisem.

Artifacts

Zaktualizowano domyślne uprawnienia kanału informacyjnego

Konta usługi Project Collection Build Service będą domyślnie mieć rolę Współpracownik, gdy zostanie utworzony nowy kanał informacyjny usługi Azure Artifacts o zakresie kolekcji projektów zamiast bieżącej roli Współautor .

Wcześniej można było zobaczyć pakiety nadrzędne, jeśli masz kopię kanału informacyjnego. Ból był taki, że nie można wyszukać pakietów, które są dostępne w górę i które nie zostały jeszcze zapisane w kanale informacyjnym. Teraz możesz wyszukać dostępne pakiety nadrzędne przy użyciu nowego interfejsu użytkownika kanału informacyjnego.

Usługa Azure Artifacts udostępnia teraz interfejs użytkownika, który umożliwia wyszukiwanie pakietów w źródłach nadrzędnych i zapisywanie wersji pakietów w kanale informacyjnym. Jest to zgodne z celem firmy Microsoft w celu poprawy naszych produktów i usług.

Raportowanie

Pokaż element nadrzędny w widżecie wyników zapytania

Widżet Wyniki zapytania obsługuje teraz nazwę elementu nadrzędnego i bezpośredni link do tego elementu nadrzędnego.

Tworzenie osobistych tokenów dostępu w celu wdrożenia w witrynie Marketplace

Kopiowanie pulpitu nawigacyjnego

W tej wersji dołączamy kopiowanie pulpitu nawigacyjnego.

Obraz z kopią pulpitu nawigacyjnego

Data ostatniego dostępu do pulpitów nawigacyjnych i zmodyfikowana przez

Jednym z wyzwań związanych z umożliwieniem zespołom tworzenia kilku pulpitów nawigacyjnych jest zarządzanie przestarzałymi i nieużywanym czyszczeniem ich. Wiedza, kiedy pulpit nawigacyjny został ostatnio odwiedzony lub zmodyfikowany, jest ważną częścią zrozumienia, które z nich można usunąć. W tej wersji dołączyliśmy dwie nowe kolumny do strony katalogu Pulpity nawigacyjne. Data ostatniego dostępu będzie śledzić, kiedy pulpit nawigacyjny został ostatnio odwiedzony. Zmodyfikowany przez śledzi, kiedy pulpit nawigacyjny był ostatnio edytowany i przez kogo.

Informacje zmodyfikowane przez będą również wyświetlane na samej stronie pulpitu nawigacyjnego.

Podgląd pulpitu nawigacyjnego

Mamy nadzieję, że te nowe pola pomogą administratorom projektu zrozumieć poziom aktywności dla pulpitów nawigacyjnych, aby podejmować wykształconą decyzję, jeśli powinny zostać usunięte.

Widoki analizy są teraz dostępne

Funkcja Widoki analizy jest w stanie wersji zapoznawczej przez dłuższy czas w naszej hostowanej wersji produktu. W tej wersji z przyjemnością ogłaszamy, że ta funkcja jest teraz dostępna dla wszystkich kolekcji projektów.

W nawigacji widoki analizy zostały przeniesione z karty Przegląd do karty Tablice .

Widok analizy w nawigacji tablic.

Widok Analiza zapewnia uproszczony sposób określania kryteriów filtrowania raportu usługi Power BI na podstawie danych analizy. Jeśli nie znasz widoków analitycznych, zapoznaj się z dokumentacją, aby dogonić Cię:

Widżet żądania ściągnięcia dla wielu repozytoriów jest teraz dostępny

Z radością ogłaszamy, że widżet żądania ściągnięcia dla wielu repozytoriów jest dostępny w usłudze Azure DevOps Server 2022.1. Dzięki temu nowemu widżetowi można bez wysiłku wyświetlać żądania ściągnięcia z maksymalnie 10 różnych repozytoriów w jednej, usprawnionej liście, co ułatwia niż kiedykolwiek pozostawanie na bieżąco z żądaniami ściągnięcia.

Widżet wielu repozytoriów do ogólnie dostępnej wersji

Bilet sugestii społeczności

Wprowadzenie rozwiązane jako ukończone w wykresach burndown i burnup

Rozumiemy znaczenie dokładnego odzwierciedlenia postępu zespołu, w tym rozwiązanych elementów, które zostały ukończone na wykresach. Po wybraniu prostej opcji przełączania można teraz wyświetlać rozwiązane elementy jako ukończone, co zapewnia prawdziwe odbicie stanu postępu zespołu. To ulepszenie umożliwia dokładniejsze śledzenie i planowanie, umożliwiając zespołom podejmowanie świadomych decyzji w oparciu o rzeczywisty postęp. Korzystaj z ulepszonej przejrzystości i lepszej analizy dzięki zaktualizowanym wykresom postępu i wypalania w raportowaniu.

Plik Gif do pokazu został rozwiązany jako ukończony na wykresach burn-down i burn-up.

Witryna Wiki

Obsługa dodatkowych typów diagramów na stronach typu wiki

Uaktualniliśmy wersję wykresów syreny używanych na stronach wiki do wersji 8.13.9. Dzięki temu uaktualnieniu możesz teraz uwzględnić następujące diagramy i wizualizacje na stronach wiki usługi Azure DevOps:

  • Schemat blokowy
  • Diagramy sekwencji
  • Wykresy Gantta
  • Wykresy kołowe
  • Diagramy wymagań
  • Diagramy stanu
  • Podróż użytkownika

Diagramy, które są w trybie eksperymentalnym, takie jak Relacja jednostki i Git Graph, nie są uwzględniane. Aby uzyskać więcej informacji na temat nowych funkcji, zobacz syreny informacje o wersji.

Opinia

Chcemy poznać Twoje zdanie! Możesz zgłosić problem lub podać pomysł i śledzić go za pośrednictwem społeczności deweloperów i uzyskać porady na temat stack Overflow.

Początek strony