informacje o wersji Azure DevOps Server 2022

---

| | Developer Community Wymagania systemowe i warunkilicencyjne | zgodności | DevOps blog | SHA-256 skróty |

---

W tym artykule znajdziesz informacje dotyczące najnowszej wersji Azure DevOps Server.

Aby dowiedzieć się więcej na temat instalowania lub uaktualniania wdrożenia Azure DevOps Server, zobacz Azure DevOps Server Wymagania.

Aby pobrać produkty Azure DevOps Server, odwiedź stronę Azure DevOps Server Pliki do pobrania.

Bezpośrednie uaktualnienie do wersji Azure DevOps Server 2022 jest obsługiwane z wersji Azure DevOps Server 2019 lub Team Foundation Server 2015 lub nowszej. Jeśli wdrożenie serwera TFS jest w wersji TFS 2013 lub starszej, przed uaktualnieniem do wersji Azure DevOps Server 2022 należy wykonać kilka kroków tymczasowych. Aby uzyskać więcej informacji, zobacz stronę Instalowanie .

---

Azure DevOps Server 2022 Update 0.1 Patch 5 Data wydania: 14 listopada 2023 r.

Uwaga

Azure DevOps Server poprawki są skumulowane, jeśli nie zainstalowano poprawki 3, ta poprawka zawiera aktualizacje agenta usługi Azure Pipelines. Nowa wersja agenta po zainstalowaniu poprawki 5 będzie mieć wartość 3.225.0.

File	Skrót SHA-256
devops2022.0.1patch5.exe	DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

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

• Rozszerzono listę dozwolonych znaków zadań programu PowerShell dla sprawdzania poprawności parametru Włącz argumenty zadań powłoki.
• Rozwiązano problem polegający na tym, że zmiany połączeń usług były trwałe po kliknięciu przycisku anulowania.

Azure DevOps Server 2022 Update 0.1 Patch 4 Data wydania: 10 października 2023 r.

Uwaga

Azure DevOps Server poprawki są skumulowane, jeśli nie zainstalowano poprawki 3, ta poprawka zawiera aktualizacje agenta usługi Azure Pipelines. Nowa wersja agenta po zainstalowaniu poprawki 5 będzie mieć wartość 3.225.0.

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

• Usunięto usterkę powodującą zablokowanie potoków przez uaktualnienie modelu wykonywania potoku.
• Usunięto usterkę polegającą na tym, że tożsamość "Właściciel analizy" została wyświetlona jako Nieaktywna tożsamość na maszynach uaktualnianych poprawek.
• Zadanie oczyszczania kompilacji zawiera wiele zadań, z których każdy usuwa artefakt dla kompilacji. Jeśli którekolwiek z tych zadań nie powiodło się, żadna z kolejnych zadań nie została uruchomiona. Zmieniliśmy to zachowanie, aby zignorować błędy zadań i wyczyścić jak najwięcej artefaktów, jak to możliwe.

Azure DevOps Server 2022 Update 0.1 Patch 3 Data wydania: 12 września 2023 r.

Uwaga

Ta poprawka obejmuje aktualizacje agenta usługi Azure Pipelines. Nowa wersja agenta po zainstalowaniu poprawki 3 będzie mieć wartość 3.225.0.

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

• CVE-2023-33136: luka w zabezpieczeniach dotycząca zdalnego wykonywania kodu Azure DevOps Server.
• CVE-2023-38155: luka w zabezpieczeniach dotycząca podniesienia uprawnień Azure DevOps Server i serwera Team Foundation Server.

Azure DevOps Server 2022 Update 0.1 Patch 2 Data wydania: 8 sierpnia 2023 r.

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

• CVE-2023-36869: Azure DevOps Server Luka w zabezpieczeniach dotycząca fałszowania.
• Usunięto usterkę w wywołaniach protokołu SOAP, w której można zgłaszać wyjątek ArithmeticException dla odpowiedzi XML z dużymi metadanymi.
• Zaimplementowano zmiany w edytorze połączeń usług, dzięki czemu stan punktu końcowego zostanie opróżniony po odrzuceniu składnika.
• Rozwiązano problem polegający na tym, że linki względne nie działały w plikach markdown.
• Rozwiązano problem z wydajnością związany z warstwą aplikacji trwając dłużej niż zwykle podczas uruchamiania, gdy zdefiniowano dużą liczbę tagów.
• Rozwiązano TF400367 błędów na stronie Pule agentów.
• Usunięto usterkę polegającą na tym, że tożsamość właściciela analizy została wyświetlona jako Nieaktywna tożsamość.
• Usunięto usterkę pętli nieskończonej w CronScheduleJobExtension.

Azure DevOps Server 2022 Update 0.1 Patch 1 Data wydania: 13 czerwca 2023 r.

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

• CVE-2023-21565: Azure DevOps Server Luka w zabezpieczeniach dotycząca fałszowania.
• CVE-2023-21569: Azure DevOps Server Luka w zabezpieczeniach dotycząca fałszowania.
• Usunięto usterkę dotyczącą edytora połączeń usług. Teraz w wersji roboczej stan punktu końcowego opróżnia się po odrzuceniu składnika.
• Usunięto usterkę polegającą na tym, że odłączanie lub dołączanie kolekcji nie powiodło się, zgłaszając następujący błąd: "TF246018: Operacja bazy danych przekroczyła limit czasu i została anulowana.

Azure DevOps Server 2022 Update 0.1 Data wydania: 9 maja 2023 r.

Azure DevOps Server 2022.0.1 to zestawienie poprawek błędów. Zawiera wszystkie poprawki w wersji Azure DevOps Server 2022.0.1 RC wcześniej wydane. Możesz bezpośrednio zainstalować Azure DevOps Server 2022.0.1 lub uaktualnić z wersji Azure DevOps Server 2022 lub Team Foundation Server 2015 lub nowszej.

Azure DevOps Server 2022 Update 0.1 RC Data wydania: 11 kwietnia 2023 r.

Azure DevOps Server 2022.0.1 RC to pakiet poprawek błędów. Zawiera wszystkie poprawki w poprzednich poprawkach Azure DevOps Server 2022. Możesz bezpośrednio zainstalować Azure DevOps Server 2022.0.1 lub uaktualnić z wersji Azure DevOps Server 2022 lub Team Foundation Server 2015 lub nowszej.

Ta wersja zawiera poprawki następujących błędów:

• Uaktualniono system plików Git Virtual File System (GVFS) z wersji 2.39.1.1-micorosoft.2, aby rozwiązać problem z luką w zabezpieczeniach.
• Dane testowe nie zostały usunięte, co powoduje wzrost bazy danych. Dzięki tej poprawki zaktualizowaliśmy przechowywanie kompilacji, aby zapobiec tworzeniu nowych oddzielonych danych testowych.
• Aktualizacje do zadania AnalyticCleanupJob stan zadania został zatrzymany, a teraz zgłaszamy powodzenie.
• Naprawiono błąd "publikowanie rozszerzenia tfx" z powodu błędu "Podany klucz nie był obecny w słowniku".
• Zaimplementowano obejście problemu w celu rozwiązania problemu i błędu podczas uzyskiwania dostępu do rozszerzenia Kalendarz zespołu.
• CVE-2023-21564: luka Azure DevOps Server w zabezpieczeniach dotycząca skryptów między witrynami
• CVE-2023-21553: luka w zabezpieczeniach dotycząca zdalnego wykonywania kodu Azure DevOps Server
• Zaktualizowano zadania programu MSBuild i programu VSBuild w celu obsługi programu Visual Studio 2022.
• Metodologia aktualizacji ładowania ponownego uwierzytelniania, aby zapobiec wektorowi ataków XSS.
• Azure DevOps Server serwera proxy 2022 zgłasza następujący błąd: VS800069: Ta usługa jest dostępna tylko w lokalnej usłudze Azure DevOps.
• Rozwiązano problem z ułatwieniami dostępu zestawów półek za pośrednictwem internetowego interfejsu użytkownika.
• Rozwiązano problem polegający na tym, że wymagane ponowne uruchomienie usługi tfsjobagent i Azure DevOps Server puli aplikacji po zaktualizowaniu ustawienia powiązanego z protokołem SMTP w konsoli zarządzania Azure DevOps Server.
• Powiadomienia nie były wysyłane przez pat siedem dni przed datą wygaśnięcia.

Azure DevOps Server 2022 Patch 4 Data wydania: 13 czerwca 2023 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2022 r., która zawiera poprawki dla następujących elementów.

• CVE-2023-21565: Azure DevOps Server Luka w zabezpieczeniach dotycząca fałszowania.
• CVE-2023-21569: Azure DevOps Server Luka w zabezpieczeniach dotycząca fałszowania.
• Usunięto usterkę dotyczącą edytora połączeń usług. Teraz w wersji roboczej stan punktu końcowego opróżnia się po odrzuceniu składnika.
• Usunięto usterkę polegającą na tym, że odłączanie lub dołączanie kolekcji nie powiodło się, zgłaszając następujący błąd: "TF246018: Operacja bazy danych przekroczyła limit czasu i została anulowana.

Azure DevOps Server 2022 Patch 3 Data wydania: 21 marca 2023 r.

Opublikowaliśmy poprawkę (19.205.33506.1) dla Azure DevOps Server 2022 r., która zawiera poprawki dla następujących elementów.

• Rozwiązano problem polegający na tym, że wymagane ponowne uruchomienie usługi tfsjobagent i Azure DevOps Server puli aplikacji po zaktualizowaniu ustawienia powiązanego z protokołem SMTP w konsoli zarządzania Azure DevOps Server.
• Skopiuj stan punktu końcowego do panelu edycji punktu końcowego usługi zamiast przekazywania go przy użyciu odwołania.
• Wcześniej podczas edytowania połączeń usługi zmiany były utrwalane w interfejsie użytkownika po wybraniu przycisku anuluj. Ta poprawka została naprawiona w zestawie SDK powiadomień, gdy zespół ma ustawienie dostarczania powiadomień na Nie dostarczaj. W tym scenariuszu, jeśli subskrypcja powiadomień jest skonfigurowana z opcją dostarczania preferencji Zespołu , członkowie zespołu nie otrzymają powiadomień. Nie ma potrzeby dalszego rozszerzania tożsamości w ramach zespołu w celu sprawdzenia preferencji członków.

Azure DevOps Server 2022 Patch 2 — data wydania: 14 lutego 2023 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2022 r., która zawiera poprawki dla następujących elementów.

• CVE-2023-21564: luka w zabezpieczeniach dotycząca Azure DevOps Server skryptów między witrynami
• Zaktualizowano zadania programu MSBuild i programu VSBuild w celu obsługi programu Visual Studio 2022.
• Metodologia aktualizacji ładowania ponownego uwierzytelniania, aby zapobiec możliwemu wektorowi ataków XSS.
• Azure DevOps Server serwera proxy 2022 zgłasza następujący błąd: VS800069: Ta usługa jest dostępna tylko w lokalnej usłudze Azure DevOps.

Azure DevOps Server 2022 Patch 1 Data wydania: 24 stycznia 2023 r.

Opublikowaliśmy poprawkę dla Azure DevOps Server 2022 r., która zawiera poprawki dla następujących elementów.

• Dane testowe nie zostały usunięte, co spowodowało wzrost bazy danych. Dzięki tej poprawce zaktualizowaliśmy przechowywanie kompilacji, aby zapobiec tworzeniu nowych oddzielonych danych testowych.
• Aktualizacje do zadania AnalyticCleanupJob stan zadania to Zatrzymano, a teraz zgłaszamy powodzenie.
• Rozwiązano problem polegający na tym, że polecenie "tfx extension publish" kończyło się niepowodzeniem z powodu błędu "Podany klucz nie był obecny w słowniku".
• Zaimplementowano obejście w celu rozwiązania problemu i błędu podczas uzyskiwania dostępu do rozszerzenia Kalendarza zespołu.

data wydania Azure DevOps Server 2022 r.: 6 grudnia 2022 r.

Azure DevOps Server 2022 r. to pakiet poprawek błędów. Zawiera wszystkie funkcje w wcześniej wydanych Azure DevOps Server 2022 RC2 i RC1.

Azure DevOps Server 2022 RC2 Data wydania: 25 października 2022 r.

Azure DevOps Server 2022 RC2 to pakiet poprawek błędów. Zawiera wszystkie funkcje w wersji Azure DevOps Server 2022 RC1, która została wcześniej wydana.

Uwaga

Włączone nowe algorytmy SSH RSA

Obsługa kluczy publicznych RSA została ulepszona w celu obsługi typów kluczy publicznych SHA2 oprócz wcześniej obsługiwanego algorytmu SHA1 SSH-RSA.

Teraz obsługiwane typy kluczy publicznych obejmują:

• SSH-RSA
• RSA-SHA2-256
• RSA-SHA2-512

Wymagana akcja

Jeśli zaimplementowano obejście w celu włączenia protokołu SSH-RSA przez jawne określenie go w .ssh/config1 pliku, należy usunąć element lub zmodyfikować go tak, aby używał algorytmu PubkeyAcceptedTypesRSA-SHA2-256 lub RSA-SHA2-512 lub obu tych typów. Szczegółowe informacje o tym, co zrobić, jeśli nadal jest wyświetlany monit o podanie hasła i GIT_SSH_COMMAND="ssh -v" git fetch nie są wyświetlane żadne algorytmy wzajemnego podpisu w dokumentacji tutaj.

Obsługa klucza wielokropkowego nie została jeszcze dodana i pozostaje wysoce żądaną funkcją na naszej liście prac.

Azure DevOps Server 2022 RC1 Data wydania: 9 sierpnia 2022 r.

Podsumowanie nowości w Azure DevOps Server 2022 r.

Ważne

Usługa Warehouse and Analysis Service została uznana za przestarzałą w poprzedniej wersji Azure DevOps Server (2020). W Azure DevOps Server 2022 r. usługa Warehouse and Analysis Service została usunięta z produktu. Analiza udostępnia teraz środowisko raportowania w produkcie.

Azure DevOps Server 2022 r. wprowadzono wiele nowych funkcji. Niektóre najważniejsze funkcje to:

• Plany dostarczania
• Wyświetl poprawną osobę w linkach zatwierdzania
• Nowe kontrolki zmiennych środowiskowych w potokach
• Generowanie nieograniczonego tokenu dla kompilacji rozwidlenia
• Nowe strony kontroli wersji serwera Team Foundation
• Grupuj według tagów dostępnych w widżetach wykresu

Możesz również przejść do poszczególnych sekcji, aby zobaczyć wszystkie nowe funkcje dla każdej usługi:

• Boards
• Repos
• Pipelines
• Raportowanie

---

Boards

Plany dostarczania

Z przyjemnością ogłaszamy, że plany dostarczania są teraz uwzględnione w Azure DevOps Server. Plany dostarczania zapewniają 3 kluczowe scenariusze:

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

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

Istnieją dwa główne widoki: skondensowany i rozszerzony

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 rozpoczęcie & dat docelowych, a następnie iteracja. Umożliwia to dodawanie elementów roboczych na poziomie portfela, takich jakEpic, które często nie są zdefiniowane w iteracji.

Istnieją dwa główne widoki widoku skondensowanego i widoku rozwiniętego. Możesz również powiększyć i wyjąć plan, klikając lupę w zręczną stronę planu.

Istnieją dwa główne widoki widoku skondensowanego i widoku rozwiniętego. Możesz również powiększyć i wyjść 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 rozwiniętym widokiem.

  

• Widok rozwinięty

  Rozwinięty widok pokazuje postęp elementu roboczego przez zliczanie liczby elementów podrzędnych i połączonych oraz wyświetlanie procentu ukończenia. Obecnie postęp jest określany przez liczbę elementów roboczych.

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

  

Śledzenie zależności

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

• 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, wystarczy kliknąć ikonę linku zależności w prawym górnym rogu karty. Oto przykłady zależności.

  

  

• Linie zależności

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

  Oto kilka przykładów.

  

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

  

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

  Oto przykład:

  

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.

• Stary adres

• Po

Aby dowiedzieć się więcej na temat planów dostarczania, zapoznaj się z dokumentacją tutaj.

Usunięte elementy w centrum elementów roboczych

Centrum elementów roboczych to miejsce, w którym zostanie wyświetlona lista utworzonych elementów lub przypisanych do Ciebie. Udostępnia ona kilka spersonalizowanych funkcji przestawnych i filtrów, aby usprawnić wyświetlanie elementów roboczych. Jedną z najważniejszych skarg elementu przestawnego Przypisane do mnie jest wyświetlenie usuniętych elementów roboczych. Zgadzamy się, że usunięte elementy robocze nie są już wartością i nie powinny znajdować się na liście prac. W tym przebiegu ukrywamy wszystkie usunięte elementy z widoków Przypisane do mnie w Centrum elementów roboczych.

Wyświetlanie poprawnej osoby w linkach zatwierdzania

Sekcja programowania w elemencie roboczym zawiera listę odpowiednich zatwierdzeń i żądań ściągnięcia. Możesz wyświetlić autora zatwierdzenia lub żądania ściągnięcia wraz ze skojarzonym czasem. Dzięki tej aktualizacji rozwiązaliśmy problem z niepoprawnym wyświetlaniem awatara autora w widoku.

Usuwanie możliwości pobierania usuniętego załącznika z historii elementów roboczych

Rozwiązaliśmy niewielki problem polegający na tym, że użytkownicy mogli pobierać załączniki z historii elementów roboczych, nawet po usunięciu załącznika z formularza. Teraz po usunięciu załącznika nie można pobrać go z historii ani adresu URL pobierania będzie dostępny z odpowiedzi interfejsu API REST.

Dodano wartość "Nie naprawi" do pola Przyczyna błędu

Podobnie jak w przypadku wszystkich innych typów elementów roboczych, typ elementu roboczego usterki ma dobrze zdefiniowany przepływ pracy. Każdy przepływ pracy składa się z co najmniej trzech stanów i przyczyny. Powody określają, dlaczego element został przeniesiony z jednego stanu do innego. W ramach tej aktualizacji dodaliśmy wartość Nie naprawi przyczyny typów elementów roboczych usterek w procesie Agile. Wartość będzie dostępna jako przyczyna przenoszenia usterek z nowej lub aktywnej do rozwiązanej. Więcej informacji na temat definiowania, przechwytywania, klasyfikacji i zarządzania usterkami oprogramowania można dowiedzieć się w dokumentacji Azure Boards.

Pipelines

Usuwanie zasad przechowywania dla potoku w kompilacjach klasycznych

Teraz można skonfigurować zasady przechowywania zarówno dla klasycznych kompilacji, jak i potoków YAML w ustawieniach projektu usługi Azure DevOps. Reguły przechowywania potoku dla klasycznych potoków kompilacji nie są już obsługiwane. Chociaż jest to jedyny sposób konfigurowania przechowywania potoków YAML, można również skonfigurować przechowywanie dla klasycznych potoków kompilacji na podstawie potoku. Usunęliśmy wszystkie reguły przechowywania potoków dla klasycznych potoków kompilacji w nadchodzącym wydaniu.

Co to oznacza dla Ciebie: każdy klasyczny potok kompilacji, który był używany do obsługi reguł przechowywania potoku, będzie podlegać regułom przechowywania na poziomie projektu.

Aby upewnić się, że nie utracisz żadnych kompilacji podczas uaktualniania, utworzymy dzierżawę dla wszystkich kompilacji istniejących w momencie uaktualniania, które nie mają dzierżawy.

Zalecamy sprawdzenie ustawień przechowywania na poziomie projektu po uaktualnieniu. Jeśli potok wymaga specjalnie niestandardowych reguł, możesz użyć niestandardowego zadania w potoku. Aby uzyskać informacje na temat dodawania dzierżaw przechowywania za pomocą zadania, zobacz dokumentację ustawiania zasad przechowywania kompilacji, wydań i testów.

Nowe kontrolki zmiennych środowiskowych w potokach

Agent usługi Azure Pipelines skanuje standardowe dane wyjściowe pod kątem specjalnych poleceń rejestrowania i wykonuje je. Polecenie setVariablemoże służyć do ustawiania zmiennej lub modyfikowania wcześniej zdefiniowanej zmiennej. Może to być potencjalnie wykorzystane przez aktora poza systemem. Jeśli na przykład potok ma krok, który wyświetla listę plików na serwerze FTP, osoba mająca dostęp do serwera FTP może dodać nowy plik, którego nazwa zawiera setVariable polecenie i spowodować zmianę zachowania potoku.

Mamy wielu użytkowników, którzy polegają na ustawianiu zmiennych przy użyciu polecenia rejestrowania w potoku. W tej wersji wprowadzamy następujące zmiany, aby zmniejszyć ryzyko niepożądanych zastosowań setVariable polecenia.

• Dodaliśmy nową konstrukcję dla autorów zadań. Dołączając fragment kodu, taki jak poniższy w pliku task.json, autor zadania może kontrolować, czy jakiekolwiek zmienne są ustawiane przez ich zadanie.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 

• Ponadto aktualizujemy szereg wbudowanych zadań, takich jak ssh, aby nie można było ich wykorzystać.

• Na koniec możesz teraz użyć konstrukcji YAML do kontrolowania, czy krok może ustawić zmienne.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Generowanie nieograniczonego tokenu dla kompilacji rozwidlenia

Użytkownicy usługi GitHub Enterprise często używają rozwidlenia do współtworzenia nadrzędnego repozytorium. Gdy usługa Azure Pipelines tworzy wkład z rozwidlenia repozytorium GitHub Enterprise, ogranicza uprawnienia przyznane tokenowi dostępu do zadania i nie zezwala na dostęp do wpisów tajnych potoku przez takie zadania. Więcej informacji na temat zabezpieczeń rozwidlenia budynku można znaleźć w naszej dokumentacji.

Może to być bardziej restrykcyjne niż pożądane w takich zamkniętych środowiskach, w których użytkownicy mogą nadal korzystać z modelu współpracy wewnętrznej źródła. Ustawienie w potoku można skonfigurować tak, aby wpisy tajne były dostępne dla rozwidlenia, ale nie ma ustawienia umożliwiającego kontrolowanie zakresu tokenu dostępu do zadania. W tej wersji dajemy ci kontrolę nad generowaniem regularnego tokenu dostępu do zadania nawet w przypadku kompilacji rozwidlenia.

To ustawienie można zmienić z wyzwalaczy w edytorze potoków . Przed zmianą tego ustawienia upewnij się, że w pełni rozumiesz implikacje dotyczące zabezpieczeń włączania tej konfiguracji.

Repozytoria jako chroniony zasób w potokach YAML

Możesz zorganizować projekt usługi Azure DevOps w celu hostowania wielu podprojektów — każdy z własnym repozytorium Git Usługi Azure DevOps i co najmniej jednym potokiem. W tej strukturze możesz chcieć kontrolować, które potoki mogą uzyskiwać dostęp do tych repozytoriów. Załóżmy na przykład, że masz dwa repozytoria A i B w tym samym projekcie oraz dwa potoki X i Y, które zwykle tworzą te repozytoria. Możesz uniemożliwić potokowi Y uzyskiwanie dostępu do repozytorium A. Ogólnie rzecz biorąc, chcesz, aby współautorzy A kontrolowali, do których potoków chcą zapewnić dostęp.

Chociaż było to częściowo możliwe w przypadku repozytoriów i potoków usługi Azure Git, nie było doświadczenia w zarządzaniu nim. Ta funkcja rozwiązuje tę lukę. Repozytoria Git platformy Azure mogą być teraz traktowane jako chronione zasoby w potokach YAML, podobnie jak połączenia usług i pule agentów.

Współautor repozytorium A umożliwia dodawanie kontroli i uprawnień potoku do repozytorium. W tym celu przejdź do ustawień projektu, wybierz pozycję Repozytoria, a następnie repozytorium. Zostanie wyświetlone nowe menu o nazwie "Sprawdza", w którym można skonfigurować dowolne z kontrolek w polu lub niestandardowym w postaci funkcji platformy Azure.

Na karcie "Zabezpieczenia" możesz zarządzać listą potoków, które mogą uzyskiwać dostęp do repozytorium.

Za każdym razem, gdy potok YAML używa repozytorium, infrastruktura usługi Azure Pipelines weryfikuje i zapewnia, że wszystkie kontrole i uprawnienia są spełnione.

Uwaga

Te uprawnienia i kontrole mają zastosowanie tylko do potoków YAML. Potoki klasyczne nie rozpoznają tych nowych funkcji.

Uprawnienia i sprawdzanie 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 są dostępne na połączeniach usług, środowiskach i pulach agentów przez pewien czas. Zostały one ostatnio dodane 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 uprawnień Potoki .

Aby skonfigurować kontrole lub zatwierdzenia, które powinny być oceniane za każdym razem, gdy potok jest uruchamiany, użyj opcji Zatwierdzenia i sprawdź funkcję Biblioteka .

Zmiany w automatycznym tworzeniu środowisk

Podczas tworzenia potoku YAML i odwoływania się do środowiska, które nie istnieje, usługa Azure Pipelines automatycznie tworzy środowisko. To automatyczne tworzenie może wystąpić w kontekście użytkownika lub w kontekście systemu. W następujących przepływach usługa Azure Pipelines wie o użytkowniku wykonującym operację:

• Używasz kreatora tworzenia potoku YAML w środowisku internetowym usługi Azure Pipelines i odwołujesz się do środowiska, które nie zostało jeszcze utworzone.
• Aktualizujesz plik YAML w edytorze internetowym usługi Azure Pipelines i zapisujesz potok po dodaniu odwołania do nieistniejącego środowiska. W każdym z powyższych przypadków usługa Azure Pipelines ma jasne zrozumienie użytkownika wykonującego operację. W związku z tym tworzy środowisko i dodaje użytkownika do roli administratora środowiska. Ten użytkownik ma wszystkie uprawnienia do zarządzania środowiskiem i/lub dołączania innych użytkowników do różnych ról do zarządzania środowiskiem.

W następujących przepływach usługa Azure Pipelines nie zawiera informacji o użytkowniku tworzącym środowisko: aktualizujesz plik YAML przy użyciu innego zewnętrznego edytora kodu, dodaj odwołanie do środowiska, które nie istnieje, a następnie powoduje wyzwolenie potoku ciągłej integracji. W takim przypadku usługa Azure Pipelines nie ma informacji o użytkowniku. Wcześniej radziliśmy sobie z tym przypadkiem tak, że dodawaliśmy wszystkich współautorów projektu do roli administratora środowiska. Każdy członek projektu mógł wtedy zmieniać te uprawnienia i uniemożliwiać innym dostęp do środowiska.

Otrzymaliśmy Twoją opinię na temat udzielania uprawnień administratora w środowisku wszystkim członkom projektu. Podczas nasłuchiwania opinii słyszeliśmy, że nie powinniśmy automatycznie tworzyć środowiska, jeśli nie jest jasne, kim jest użytkownik wykonujący operację. W tej wersji wprowadziliśmy zmiany w sposobie automatycznego tworzenia środowisk:

• W przyszłości przebiegi potoków nie będą automatycznie tworzyć środowiska, jeśli nie istnieje i jeśli kontekst użytkownika nie jest znany. W takich przypadkach potok zakończy się niepowodzeniem z powodu błędu Nie znaleziono środowiska. Przed użyciem środowiska w potoku należy wstępnie utworzyć środowiska z odpowiednimi zabezpieczeniami i sprawdzić konfigurację.
• Potoki ze znanym kontekstem użytkownika będą nadal automatycznie tworzyć środowiska tak samo jak w przeszłości.
• Na koniec należy zauważyć, że funkcja automatycznego tworzenia środowiska została dodana tylko w celu uproszczenia procesu rozpoczynania pracy z usługą Azure Pipelines. Była przeznaczona dla scenariuszy testowych, a nie dla scenariuszy produkcyjnych. Zawsze należy wstępnie tworzyć środowiska produkcyjne z odpowiednimi uprawnieniami i sprawdzaniem, a następnie używać ich w potokach.

Okno dialogowe Usuwanie szczegółowych informacji z potoku kompilacji

Na podstawie opinii okno dialogowe Analiza zadania/potoku wyświetlane podczas nawigowania po potoku kompilacji zostało usunięte w celu ulepszenia przepływu pracy. Analiza potoku jest nadal dostępna, aby uzyskać potrzebne szczegółowe informacje.

Obsługa wdrożeń sekwencyjnych, a nie najnowszych tylko w przypadku używania kontroli blokady na wyłączność

W potokach YAML kontrole służą do kontrolowania wykonywania etapów w chronionych zasobach. Jedną z typowych kontroli, których można użyć, jest wyłączna kontrola blokady. To sprawdzenie umożliwia kontynuowanie tylko jednego uruchomienia z potoku. Gdy wiele przebiegów próbuje wdrożyć w środowisku w tym samym czasie, kontrola anuluje wszystkie stare przebiegi i zezwala na wdrożenie najnowszego uruchomienia.

Anulowanie starych przebiegów jest dobrym rozwiązaniem, gdy wydania są zbiorcze i zawierają wszystkie zmiany kodu z poprzednich przebiegów. Istnieją jednak potoki, w których zmiany kodu nie są skumulowane. Dzięki tej nowej funkcji można zezwolić wszystkim przebiegom na kontynuowanie i wdrażanie sekwencyjnie w środowisku lub zachować poprzednie zachowanie anulowania starych przebiegów i zezwalania tylko na najnowsze. To zachowanie można określić przy użyciu nowej właściwości o nazwie lockBehavior w pliku YAML potoku. Wartość sequential oznacza, że wszystkie uruchomienia uzyskują blokadę sekwencyjnie do chronionego zasobu. Wartość runLatest oznacza, że tylko najnowszy przebieg uzyskuje blokadę zasobu.

Aby użyć wyłącznego sprawdzania blokady sequential we wdrożeniach lub runLatest, wykonaj następujące kroki:

1. Włącz kontrolę wyłącznych blokad w środowisku (lub inny chroniony zasób).
2. W pliku YAML potoku określ nową właściwość o nazwie lockBehavior. Można to określić dla całego potoku lub dla danego etapu:

Ustaw na scenie:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Ustaw w potoku:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Jeśli nie określisz lockBehaviorelementu , przyjmuje się, że ma wartość runLatest.

Obsługa wersji Quebec 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 wersją Quebec usługi ServiceNow. Potoki klasyczne i YAML działają teraz z Quebecem. Aby upewnić się, że ta integracja działa, przeprowadź uaktualnienie do nowej wersji aplikacji (4.188.0) ze sklepu Service Now Store. Aby uzyskać więcej informacji, zobacz Integracja z usługą ServiceNow Change Management.

Nowe wyrażenia warunkowe YAML

Pisanie wyrażeń warunkowych w plikach YAML stało się łatwiejsze dzięki użyciu ${{ else }} wyrażeń i ${{ elseif }} . Poniżej przedstawiono przykłady używania tych wyrażeń w plikach potoków YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Obsługa symboli wieloznacznych w filtrach ścieżek

Symbole wieloznaczne mogą być używane podczas określania gałęzi dołączania i wykluczania dla wyzwalaczy ciągłej integracji lub żądania ściągnięcia w pliku YAML potoku. Nie można ich jednak używać podczas określania filtrów ścieżek. Na przykład nie można uwzględnić wszystkich ścieżek pasujących do src/app/**/myapp*elementu . Zostało to wskazane przez kilku klientów jako niedogodności. Ta aktualizacja wypełnia tę lukę. Teraz możesz użyć symboli wieloznacznych (**, *lub ?) podczas określania filtrów ścieżek.

Domyślna specyfikacja agenta dla potoków to Windows-2022

Obraz windows-2022 jest gotowy do użycia jako domyślna wersja windows-latest etykiety w agentach hostowanych przez firmę Microsoft w usłudze Azure Pipelines. Do tej pory ta etykieta wskazywała na agentów systemu Windows-2019. Ta zmiana zostanie wdrożona w ciągu kilku tygodni, począwszy od 17 stycznia. Planujemy ukończenie migracji do marca.

Usługa Azure Pipelines jest obsługiwana windows-2022 od września 2021 r. Monitorowaliśmy Twoją opinię, windows-2022 aby poprawić stabilność obrazu, a teraz jesteśmy gotowi ustawić ją jako najnowszą.

Obraz windows-2022 zawiera program Visual Studio 2022. Aby uzyskać pełną listę różnic między elementami windows-2022 i windows-2019, odwiedź witrynę GitHub problemu. Aby uzyskać pełną listę oprogramowania zainstalowanego na obrazie, sprawdź tutaj.

Zmiana nazwy folderu potoku weryfikuje uprawnienia

Nazwy folderów zawierających potoki można zmienić. Zmiana nazwy folderu zakończy się teraz powodzeniem tylko wtedy, gdy użytkownik ma uprawnienia do edycji co najmniej jednego potoku zawartego w folderze.

Planowanie uaktualniania środowiska uruchomieniowego agenta potoków

Co to jest agent potoku?

Agent potoku usługi Azure DevOps to oprogramowanie uruchamiane na hoście potoku w celu wykonywania zadań potoku. Działa on na agentach hostowanych przez firmę Microsoft, agentach zestawu skalowania i agentach hostowanych samodzielnie. W tym ostatnim przypadku zainstalujesz go samodzielnie. Agent potoku składa się z odbiornika i procesu roboczego (zaimplementowanego na platformie .NET), proces roboczy uruchamia zadania implementowane w węźle lub programie PowerShell, a w związku z tym hostuje te środowiska uruchomieniowe.

Nadchodzące uaktualnienie do platformy .NET 6 & wycofanie oprogramowania Red Hat 6

Wraz z wydaniem platformy .NET 6 możemy skorzystać z nowych możliwości międzyplatformowych. W szczególności będziemy mogli zapewnić natywną zgodność z urządzeniami Apple Silicon i Windows Arm64. W związku z tym planujemy przejście na platformę .NET 6 dla agenta potoku (odbiornika i procesu roboczego) w nadchodzących miesiącach.

Ze względu na szereg ograniczeń, które nakłada, usuwamy wsparcie systemu Red Hat Enterprise Linux 6 od naszego agenta 30 kwietnia 2022 r.

Aktualizacje do zadania kopiowania plików platformy Azure

Wprowadzamy nową wersję zadania kopiowania plików platformy Azure. To zadanie służy do kopiowania plików do obiektów blob usługi Microsoft Azure Storage lub maszyn wirtualnych. Nowa wersja zawiera kilka aktualizacji, które często są wymagane przez społeczność:

• Wersja narzędzia AzCopy została zaktualizowana do wersji 10.12.2, która obsługuje typy zawartości plików. W związku z tym podczas kopiowania plików PDF, Excel, PPT lub jednego z obsługiwanych typów mime typ zawartości pliku jest poprawnie ustawiony.

• Przy użyciu nowej wersji narzędzia AzCopy można również skonfigurować ustawienie, aby wyczyścić obiekt docelowy, gdy typ docelowy to Azure Blob. Ustawienie tej opcji spowoduje usunięcie wszystkich folderów/plików w tym kontenerze. Lub jeśli zostanie podany prefiks obiektu blob, wszystkie foldery/pliki w tym prefiksie zostaną usunięte.

• Nowa wersja zadania opiera się na modułach Az zainstalowanych na agencie zamiast modułów AzureRM. Spowoduje to usunięcie niepotrzebnego ostrzeżenia w niektórych przypadkach podczas korzystania z zadania.

Zmiany są częścią aktualizacji głównej wersji dla tego zadania. Należy jawnie zaktualizować potoki, aby korzystały z nowej wersji. Dokonaliśmy tego wyboru podczas aktualizowania wersji głównej, aby upewnić się, że nie przerywamy żadnych potoków, które nadal są zależne od modułów azureRM.

Nowe punkty rozszerzenia dla widoku szczegółów potoków

Dodaliśmy dwa nowe punkty rozszerzalności, których można kierować w swoich rozszerzeniach. Te punkty rozszerzalności umożliwiają dodanie przycisku niestandardowego w nagłówku potoku i menu niestandardowego w folderze potoku:

• Przycisk niestandardowy w nagłówku potoku: ms.vss-build-web.pipelines-header-menu
• Menu niestandardowe w folderze potoku: ms.vss-build-web.pipelines-folder-menu

Aby użyć tych nowych punktów rozszerzalności, wystarczy dodać nowy wkład przeznaczony dla nich w pliku manifestu vss-extension.json rozszerzenia Usługi Azure DevOps.

Na przykład:

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

Wynik będzie:

• Przycisk niestandardowy w nagłówku potoku

  

• Menu niestandardowe w folderze potoku

  

Ulepszona migracja do Azure DevOps Services

Podczas importowania z Azure DevOps Server do Azure DevOps Services należy wziąć pod uwagę, że usługa Azure DevOps nie obsługuje już reguł przechowywania potoku. Dzięki tej aktualizacji te zasady zostały usunięte podczas migracji do Azure DevOps Services z Azure DevOps Server lokalnej. Aby dowiedzieć się więcej na temat konfigurowania zasad przechowywania, zobacz naszą dokumentację dotyczącą ustawiania zasad przechowywania dla kompilacji, wydań i testów.

Ulepszenie potoków uruchamia interfejs API REST

Wcześniej interfejs API REST uruchomienia potoków zwrócił tylko self repozytorium. Dzięki tej aktualizacji interfejs API REST pipelines runs zwraca wszystkie zasoby repozytorium kompilacji.

Rozszerzone szablony potoków YAML można teraz przekazywać informacje kontekstowe dla etapów, zadań i wdrożeń

Dzięki tej aktualizacji dodajemy nową templateContext właściwość dla jobskładników potoku , deploymenti stage YAML, które mają być używane w połączeniu z szablonami.

Oto scenariusz używania programu templateContext:

• Szablony służą do zmniejszania duplikowania kodu lub zwiększania bezpieczeństwa potoków

• Szablon przyjmuje jako parametr listę stages, jobslub deployments

• Szablon przetwarza listę danych wejściowych i wykonuje pewne przekształcenia na każdym z etapów, zadań lub wdrożeń. Na przykład ustawia środowisko, w którym jest uruchamiane każde zadanie, lub dodaje dodatkowe kroki w celu wymuszenia zgodności

• Przetwarzanie wymaga przekazania przez autora potoku dodatkowych informacji do szablonu dla każdego etapu, zadania lub wdrożenia na liście

Spójrzmy na przykład. Załóżmy, że tworzysz potok, który uruchamia kompleksowe testy na potrzeby weryfikacji żądania ściągnięcia. Twoim celem jest przetestowanie tylko jednego składnika systemu, ale dlatego, że planujesz uruchamianie testów end-to-end, potrzebujesz środowiska, w którym dostępnych jest więcej składników systemu i musisz określić ich zachowanie.

Zdajesz sobie sprawę, że inne zespoły będą mieć podobne potrzeby, dlatego decydujesz się wyodrębnić kroki konfigurowania środowiska do szablonu. Jego kod wygląda następująco:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

To, co robi szablon, dla każdego zadania w parametrze testSet ustawia odpowiedź składników systemu określonych przez ${{ testJob.templateContext.requiredComponents }}, aby zwrócić ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Następnie możesz utworzyć własny potok, który rozszerza testing-template.yml się tak jak w poniższym przykładzie.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Ten potok uruchamia dwa testy, dodatni i ujemny. Oba testy wymagają dimensionsapi , aby składnik był dostępny. Zadanie positive_test oczekuje zwracanego dimensionsapi kodu HTTP 200, podczas gdy negative_test oczekuje, że zwraca kod HTTP 500.

Obsługa kont usług zarządzanych przez grupę jako konta usługi agenta

Agent usługi Azure Pipelines obsługuje teraz konta usług zarządzanych przez grupę na własnych agentach w systemie Windows.

Konta usług zarządzane przez grupę zapewniają scentralizowane zarządzanie hasłami dla kont domeny, które działają jako konta usług. Agent usługi Azure Pipelines może rozpoznać tego typu konto, aby hasło nie było wymagane podczas konfiguracji:

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Uruchomienia informacyjne

Uruchomienie informacyjne informuje, że usługa Azure DevOps nie może pobrać kodu źródłowego potoku YAML. Taki przebieg wygląda następująco.

Usługa Azure DevOps pobiera kod źródłowy potoku YAML w odpowiedzi na zdarzenia zewnętrzne, na przykład wypychane zatwierdzenie lub w odpowiedzi na wyzwalacze wewnętrzne, na przykład w celu sprawdzenia, czy istnieją zmiany kodu, i uruchom zaplanowane uruchomienie, czy nie. Gdy ten krok zakończy się niepowodzeniem, system utworzy przebieg informacyjny. Te przebiegi są tworzone tylko wtedy, gdy kod potoku znajduje się w repozytorium GitHub lub BitBucket.

Pobieranie kodu YAML potoku może zakończyć się niepowodzeniem z powodu:

• Dostawca repozytorium, u którego wystąpiła awaria
• Ograniczanie żądań
• Problemy z uwierzytelnianiem
• Nie można pobrać zawartości pliku yml potoku

Przeczytaj więcej na temat przebiegów informacyjnych.

Właściwość interfejsu API retentionRules REST definicji kompilacji jest przestarzała

W typie retentionRules odpowiedzi interfejsu BuildDefinitionAPI REST definicji kompilacji właściwość jest teraz oznaczona jako przestarzała, ponieważ ta właściwość zawsze zwraca pusty zestaw.

Repos

Nowe strony kontroli wersji serwera Team Foundation

Zaktualizowaliśmy różne strony w usłudze Azure DevOps, aby użyć nowej platformy internetowej, aby zapewnić spójność i dostępność środowiska w różnych usługach. Strony kontroli wersji serwera Team Foundation zostały zaktualizowane w celu korzystania z nowej platformy internetowej. W tej wersji udostępniamy nowe strony kontroli wersji serwera Team Foundation.

Wyłączanie repozytorium

Klienci często prosili o wyłączenie repozytorium i uniemożliwienie użytkownikom uzyskiwania dostępu do jego zawartości. Na przykład możesz chcieć to zrobić, gdy:

• Wpis tajny został znaleziony w repozytorium.
• Narzędzie do skanowania innej firmy wykryło, że repozytorium jest niezgodne.

W takich przypadkach możesz tymczasowo wyłączyć repozytorium podczas pracy nad rozwiązaniem problemu. Dzięki tej aktualizacji możesz wyłączyć repozytorium, jeśli masz uprawnienia do usuwania repozytorium . Wyłączenie repozytorium umożliwia:

• Może wyświetlić listę repozytoriów na liście repozytoriów
• Nie można odczytać zawartości repozytorium
• Nie można zaktualizować zawartości repozytorium
• Zobacz komunikat informujący, że repozytorium zostało wyłączone podczas próby uzyskania dostępu do repozytorium w interfejsie użytkownika Azure Repos

Po podjęciu niezbędnych kroków zaradczych użytkownicy z uprawnieniem Usuwanie repozytorium mogą ponownie włączyć repozytorium. Aby wyłączyć lub włączyć repozytorium, przejdź do pozycji Ustawienia projektu, wybierz pozycję Repozytoria, a następnie określone repozytorium.

Konfigurowanie twórców gałęzi tak, aby nie uzyskiwali uprawnień do zarządzania w swoich gałęziach

Podczas tworzenia nowej gałęzi uzyskujesz w tej gałęzi pozycję "Zarządzanie uprawnieniami". To uprawnienie umożliwia zmianę uprawnień innych użytkowników lub przyznanie dodatkowych użytkowników do współtworzenia tej gałęzi. Na przykład twórca gałęzi może użyć tego uprawnienia, aby zezwolić innemu użytkownikowi zewnętrznemu na wprowadzanie zmian w kodzie. Mogą też zezwolić potokowi (tożsamości usługi kompilacji) na zmianę kodu w tej gałęzi. W niektórych projektach z wyższymi wymaganiami dotyczącymi zgodności użytkownicy nie powinni mieć możliwości wprowadzania takich zmian.

Dzięki tej aktualizacji można skonfigurować wszystkie repozytoria w projekcie zespołowym i ograniczyć twórcom gałęzi uzyskanie uprawnień "Zarządzanie uprawnieniami". W tym celu przejdź do ustawień projektu, wybierz pozycję Repozytoria, a następnie pozycję Ustawienia dla wszystkich repozytoriów lub określonego repozytorium.

To ustawienie jest domyślnie włączone, aby naśladować istniejące zachowanie. Możesz jednak wyłączyć tę funkcję, jeśli chcesz korzystać z tej nowej funkcji zabezpieczeń.

Uniemożliwianie użytkownikom głosowania nad nadrzędnymi żądaniami ściągnięcia

Dzięki Azure Repos użytkownicy z uprawnieniem do odczytu w repozytorium mogą rozwidlić repozytorium i wprowadzać zmiany w rozwidleniu. Aby przesłać żądanie ściągnięcia ze zmianami do nadrzędnego strumienia, użytkownicy muszą mieć uprawnienie "współtworzenie żądań ściągnięcia" w nadrzędnej sieci. Jednak to uprawnienie określa również, kto może głosować na żądania ściągnięcia w repozytorium nadrzędnym. W związku z tym w sytuacjach, w których użytkownik, który nie jest współautorem repozytorium, może przesłać żądanie ściągnięcia i spowodować scalenie go w zależności od sposobu konfigurowania zasad gałęzi.

W projektach, które promują model źródła wewnętrznego, rozwidlenie i współtworzenie jest typowym wzorcem. Aby dodatkowo zabezpieczyć i promować ten wzorzec, zmieniamy uprawnienia do głosowania na żądanie ściągnięcia z "współtworzenia żądań ściągnięcia" na "współtworzenie". Jednak ta zmiana nie jest domyślnie wprowadzana we wszystkich projektach. Musisz wyrazić zgodę i wybrać nowe zasady w repozytorium o nazwie "Tryb ścisłego głosowania", aby przełączyć to uprawnienie. Zalecamy, aby to zrobić, jeśli korzystasz z rozwidlenia w Azure Repos.

Raportowanie

Grupuj według tagów dostępnych w widżetach wykresu

Widżet wykresu Grupuj według tagów jest teraz domyślnie dostępny dla wszystkich klientów. W przypadku korzystania z widżetu wykresu jest teraz dostępna opcja dla tagów. Użytkownicy mogą wizualizować swoje informacje, wybierając wszystkie tagi lub zestaw tagów w widżecie.

Wyświetlanie niestandardowych typów elementów roboczych w widżecie postępu

Wcześniej nie można było wyświetlić niestandardowych typów elementów roboczych skonfigurowanych w widżecie postępu i zsumowanych lub zliczanych przez pole niestandardowe. Dzięki tej aktualizacji rozwiązaliśmy ten problem, a teraz można zobaczyć niestandardowe typy elementów roboczych w widżecie postępu.

---

Opinia

Chcemy poznać Twoją opinię! Możesz zgłosić problem lub przekazać pomysł i śledzić go przez Developer Community i uzyskać porady w witrynie Stack Overflow.

---

Góra strony