Informacje o wersji programu Azure DevOps Server 2022

---

| 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 jest obsługiwane z 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 0.1 Patch 5 Data wydania: 14 listopada 2023 r.

Uwaga

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

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

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

• Rozszerzono listę dozwolonych zadań programu PowerShell dla opcji Włącz sprawdzanie poprawności parametrów argumentów zadań powłoki.
• Rozwiązano problem powodujący, że zmiany połączeń usług były trwałe po kliknięciu przycisku anuluj.

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

Uwaga

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

Opublikowaliśmy poprawkę dla usługi 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ę, żadne z kolejnych zadań nie zostały uruchomione. Zmieniliśmy to zachowanie, aby ignorować błędy zadań i czyścić dowolną liczbę artefaktów.

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 usługi 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 serwera Azure DevOps Server.
• CVE-2023-38155: Luka w zabezpieczeniach dotycząca podniesienia uprawnień na serwerze 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 usługi Azure DevOps Server 2022 Update 0.1, która zawiera poprawki dla następujących elementów.

• CVE-2023-36869: Luka w zabezpieczeniach dotycząca fałszowania serwera Azure DevOps.
• Usunięto usterkę wywołań protokołu SOAP, w której można wywołać wyjątek ArithmeticException w przypadku odpowiedzi XML na duże metadane.
• 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 z linkami względnymi, które nie działają w plikach markdown.
• Rozwiązano problem z wydajnością związany z warstwą aplikacji trwa dłużej niż zwykle podczas uruchamiania, gdy zdefiniowano dużą liczbę tagów.
• Rozwiązano błędy TF400367 na stronie Pule agentów.
• Usunięto usterkę polegającą na tym, że tożsamość właściciela analizy zawierała wartość Nieaktywna tożsamość.
• Usunięto usterkę nieskończonej pętli w CronScheduleJobExtension.

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

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

• CVE-2023-21565: Luka w zabezpieczeniach dotycząca fałszowania serwera Azure DevOps Server.
• CVE-2023-21569: Luka w zabezpieczeniach dotycząca fałszowania serwera Azure DevOps Server.
• Usunięto usterkę edytora połączeń usług. Teraz stan punktu końcowego wersji roboczej jest opróżniany po odrzuceniu składnika.
• Usunięto usterkę polegającą na tym, że niepowodzenie odłączania lub dołączania kolekcji nie zgłaszało następującego błędu: "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 wcześniej wydanym programie Azure DevOps Server 2022.0.1 RC. Możesz bezpośrednio zainstalować program Azure DevOps Server 2022.0.1 lub uaktualnić z programu Azure DevOps Server 2022 lub Team Foundation Server 2015 lub nowszego.

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 wcześniej wydanych poprawkach programu Azure DevOps Server 2022. Możesz bezpośrednio zainstalować program Azure DevOps Server 2022.0.1 lub uaktualnić z programu Azure DevOps Server 2022 lub Team Foundation Server 2015 lub nowszego.

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.
• Nie usunięto danych testowych, co spowodowało wzrost bazy danych. Dzięki tej poprawce zaktualizowaliśmy przechowywanie kompilacji, aby zapobiec tworzeniu nowych danych testowych oddzielonych.
• Aktualizacje zadania AnalyticCleanupJob, stan zadania został zatrzymany, a teraz zgłaszamy powodzenie.
• Naprawiono błąd "publikowanie rozszerzenia tfx" z błędem "Podany klucz nie był obecny w słowniku".
• Zaimplementowano obejście problemu i błędu podczas uzyskiwania dostępu do rozszerzenia Kalendarza zespołu.
• CVE-2023-21564: Luka w zabezpieczeniach dotycząca skryptów między witrynami usługi Azure DevOps Server
• CVE-2023-21553: Luka w zabezpieczeniach dotycząca zdalnego wykonywania kodu w usłudze Azure DevOps Server
• Zaktualizowano zadania programu MSBuild i programu VSBuild w celu obsługi programu Visual Studio 2022.
• Metodologia aktualizacji ponownego uwierzytelniania w celu zapobiegania wektorowi ataków XSS.
• Serwer proxy usługi Azure DevOps Server 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 puli aplikacji usługi Azure DevOps Server po zaktualizowaniu ustawienia związanego z protokołem SMTP w konsoli zarządzania serwera 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 usługi Azure DevOps Server 2022, która zawiera poprawki dla następujących elementów.

• CVE-2023-21565: Luka w zabezpieczeniach dotycząca fałszowania serwera Azure DevOps Server.
• CVE-2023-21569: Luka w zabezpieczeniach dotycząca fałszowania serwera Azure DevOps Server.
• Usunięto usterkę edytora połączeń usług. Teraz stan punktu końcowego wersji roboczej jest opróżniany po odrzuceniu składnika.
• Usunięto usterkę polegającą na tym, że niepowodzenie odłączania lub dołączania kolekcji nie zgłaszało następującego błędu: "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 usługi Azure DevOps Server 2022, 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 puli aplikacji usługi Azure DevOps Server po zaktualizowaniu ustawienia związanego z protokołem SMTP w konsoli zarządzania serwera Azure DevOps Server.
• Skopiuj stan punktu końcowego do panelu edycji punktu końcowego usługi zamiast przekazywać go za pomocą odwołania.
• Wcześniej podczas edytowania połączeń usługi zmiany były utrwalane w interfejsie użytkownika po wybraniu przycisku anuluj. W przypadku tej poprawki usunęliśmy w zestawie SDK powiadomień, gdy zespół ma ustawioną wartość Nie dostarczaj. W tym scenariuszu, jeśli subskrypcja powiadomień jest skonfigurowana z opcją dostarczania preferencji Zespół, członkowie zespołu nie będą otrzymywać 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 usługi Azure DevOps Server 2022, która zawiera poprawki dla następujących elementów.

• CVE-2023-21564: Luka w zabezpieczeniach dotycząca skryptów między witrynami usługi Azure DevOps Server
• Zaktualizowano zadania programu MSBuild i programu VSBuild w celu obsługi programu Visual Studio 2022.
• Metodologia aktualizacji ponownego uwierzytelniania w celu zapobiegania możliwemu wektorowi ataków XSS.
• Serwer proxy usługi Azure DevOps Server 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 usługi Azure DevOps Server 2022, która zawiera poprawki dla następujących elementów.

• Nie usunięto danych testowych, co spowodowało wzrost bazy danych. Dzięki tej poprawce zaktualizowaliśmy przechowywanie kompilacji, aby zapobiec tworzeniu nowych danych testowych oddzielonych.
• Aktualizacje zadania AnalyticCleanupJob, stan zadania został zatrzymany, a teraz zgłaszamy powodzenie.
• Naprawiono błąd "publikowanie rozszerzenia tfx" z błędem "Podany klucz nie był obecny w słowniku".
• Zaimplementowano obejście problemu i błędu podczas uzyskiwania dostępu do rozszerzenia Kalendarza zespołu.

Data wydania usługi Azure DevOps Server 2022: 6 grudnia 2022 r.

Azure DevOps Server 2022 to zestawienie poprawek błędów. Obejmuje ona wszystkie funkcje w wcześniej wydanych usługach 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 zestawienie poprawek błędów. Obejmuje ona wszystkie funkcje w wcześniej wydanym programie Azure DevOps Server 2022 RC1.

Uwaga

Włączone nowe algorytmy RSA protokołu SSH

Obsługa klucza publicznego 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 pracę w celu włączenia protokołu SSH-RSA przez jawne określenie go w .ssh/config1 pliku, należy usunąć PubkeyAcceptedTypeselement lub zmodyfikować go tak, aby używał rsA-SHA2-256 lub RSA-SHA2-512 lub obu tych elementów. Szczegółowe informacje na temat tego, co należy zrobić, jeśli nadal jest wyświetlany monit o podanie hasła i GIT_SSH_COMMAND="ssh -v" git fetch nie zawiera algorytmu 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 usłudze Azure DevOps Server 2022

Ważne

Usługa Warehouse and Analysis Service została uznana za przestarzałą w poprzedniej wersji usługi Azure DevOps Server (2020). W usłudze Azure DevOps Server 2022 magazyn i usługa Analysis Service zostały usunięte z produktu. Analiza udostępnia teraz środowisko raportowania w produktach.

Usługa Azure DevOps Server 2022 wprowadza wiele nowych funkcji. Niektóre najważniejsze funkcje to:

• Plany dostarczania
• Wyświetlanie poprawnej osoby w linkach zatwierdzenia
• 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 wyświetlić wszystkie nowe funkcje dla każdej usługi:

• Tablice
• Repos
• Pipelines
• Raportowanie

---

Boards

Plany dostarczania

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

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

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

Istnieją dwa główne widoki: skondensowane i rozwinięte

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 daty początkowe i docelowe, 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 rozszerzonego. Możesz również powiększyć i z planu, klikając lupę po stronie ight-hand planu.

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

  

• Widok rozwinięty

  Widok rozwinięty pokazuje postęp elementu roboczego, zliczając liczbę elementów podrzędnych i połączonych oraz pokazując procent ukończenia. Obecnie postęp jest określany przez liczbę elementów roboczych.

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

  

Śledzenie zależności

Śledzenie zależności jest oparte na łączach poprzedników i następców zdefiniowanych w elementach roboczych. Jeśli te linki nie są zdefiniowane, nie będą wyświetlane żadne wiersze 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, po prostu kliknij 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 z liniami strzałek kierunkowych między odpowiednimi elementami roboczymi. Wiele zależności będzie wyświetlanych jako wiele wierszy. Czerwona linia kolorowa 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 widoku skondensowanego.

  

  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.

• Przed

• 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 do wyświetlenia listy utworzonych elementów lub przypisanych do Ciebie. Udostępnia ona kilka spersonalizowanych funkcji przestawnych i filtrujących, aby usprawnić wyświetlanie elementów roboczych. Jedną z najważniejszych skarg elementu przestawnego Przypisano do mnie jest to, że wyświetla usunięte elementy robocze. 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 zatwierdzenia

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ązano 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 go pobrać z historii ani adres URL pobierania będzie dostępny z odpowiedzi interfejsu API REST.

Dodano wartość "Will not Fix" 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 przeszedł z jednego stanu na inny. W przypadku tej aktualizacji dodaliśmy wartość Nie naprawi wartości przyczyny dla typów elementów roboczych usterki w procesie Agile. Wartość będzie dostępna jako powód podczas 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 usługi 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 dla potoków YAML, można również skonfigurować przechowywanie dla klasycznych potoków kompilacji na podstawie potoku. Usunęliśmy wszystkie reguły przechowywania dla potoków dla klasycznych potoków kompilacji w nadchodzącej wersji.

Co to oznacza: każdy klasyczny potok kompilacji, który używał reguł przechowywania dla 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 czasie 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 dla 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 setVariable moż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 zawiera 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 setVariable zastosowań polecenia.

• Dodaliśmy nową konstrukcję dla autorów zadań. Dołączając fragment kodu, taki jak poniższy w task.jsonpliku , 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żywać konstrukcji YAML do kontrolowania, czy krok może ustawiać 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 kompiluje współtworzenie 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 źródła wewnętrznego. 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 zwykłego tokenu dostępu do zadań 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 zabezpieczeń dotyczące 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 dostęp 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.

Jako współautor repozytorium A możesz dodawać kontrole i uprawnienia potoku do repozytorium. W tym celu przejdź do ustawień projektu, wybierz pozycję Repozytoria, a następnie repozytorium. Zostanie wyświetlone nowe menu o nazwie "Kontrole", w którym można skonfigurować dowolne kontrole w polu lub niestandardowe 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 kontrole 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 były dostępne na połączeniach usług, środowiskach i pulach agentów przez pewien czas. Ostatnio dodano je do repozytoriów. W tej wersji dodajemy te same zabezpieczenia do grup zmiennych i bezpiecznych plików.

Aby ograniczyć dostęp do grupy zmiennych lub bezpiecznego pliku do małego zestawu potoków, użyj funkcji uprawnienia Potoki.

Aby skonfigurować kontrole lub zatwierdzenia, które powinny być oceniane przy każdym uruchomieniu potoku, użyj funkcji Zatwierdzenia i sprawdza, czy biblioteka jest funkcją.

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 informacje o użytkowniku wykonującym 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 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 potoków jest nadal dostępna, aby uzyskać potrzebne szczegółowe informacje.

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

W potokach YAML kontrole są używane do kontrolowania wykonywania etapów w chronionych zasobach. Jedną z typowych kontroli, których można użyć, jest wyłączna kontrola blokady. Ta kontrola umożliwia kontynuowanie tylko jednego uruchomienia z potoku. Gdy wiele uruchomień próbuje wdrożyć w środowisku w tym samym czasie, sprawdzanie anuluje wszystkie stare uruchomienia 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żesz 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łącznej kontroli blokady sequential we wdrożeniach lub runLatest, wykonaj następujące kroki:

1. Włącz wyłączne sprawdzanie blokady 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 etapie:

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 elementu lockBehavior, przyjmuje się, że jest runLatestto .

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ą usługi ServiceNow w Quebecu. Potoki klasyczne i YAML działają teraz z Quebec. 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 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 jako niedogodności dla kilku klientów. 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

windows-2022 Obraz 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 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ź stronę problemu z usługą GitHub. Aby uzyskać pełną listę oprogramowania zainstalowanego na obrazie, sprawdź tutaj.

Zmiana nazwy folderu potoku weryfikuje uprawnienia

Można zmienić nazwy folderów zawierających potoki. 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, które działa na hoście potoku w celu wykonywania zadań potoku. Działa on na agentach hostowanych przez firmę Microsoft, agentach zestawu skalowania i własnych agentach. W drugim przypadku zainstalujesz go samodzielnie. Agent potoku składa się z odbiornika i procesu roboczego (zaimplementowanego na platformie .NET), proces roboczy uruchamia zadania implementowane w środowisku Node lub PowerShell i w związku z tym hostuje te środowiska uruchomieniowe.

Nadchodzące uaktualnienie do wycofania oprogramowania .NET 6 i Red Hat 6

Wraz z wersją platformy .NET 6 możemy skorzystać z jej nowych możliwości międzyplatformowych. W szczególności będziemy mogli zapewnić natywną zgodność urządzeń Apple Silicon i Windows Arm64. Dlatego planujemy przejść do platformy .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 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 są często 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 czyszczenia obiektu docelowego, 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 wersji głównej dla tego zadania. Aby korzystać z nowej wersji, należy jawnie zaktualizować potoki. Dokonaliśmy wyboru aktualizacji 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 niestandardowego menu 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 usług Azure DevOps Services

Podczas importowania z usługi Azure DevOps Server do usługi Azure DevOps Services należy wziąć pod uwagę, że usługa Azure DevOps nie obsługuje już reguł przechowywania potoku. Dzięki tej aktualizacji usunęliśmy te zasady podczas migracji do usług Azure DevOps Services z lokalnego serwera Azure DevOps Server. 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 interfejsu API REST przebiegów potoków

Wcześniej interfejs API REST uruchomień potoków zwrócił tylko self repozytorium. Dzięki tej aktualizacji interfejs API REST potoków uruchamia 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życia programu templateContext:

• Szablony służą do zmniejszenia duplikacji kodu lub zwiększenia 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 każde zadanie jest uruchamiane lub dodaje dodatkowe kroki w celu wymuszania 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 uruchamiać kompleksowe testy, 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ą miały 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 }} w celu zwrócenia ${{ 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, a 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ługi zarządzane przez grupę na własnych agentach w systemie Windows.

Konta usługi 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, więc hasło nie jest 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, aby sprawdzić, czy istnieją zmiany kodu i rozpocząć zaplanowane uruchomienie, czy nie. Gdy ten krok zakończy się niepowodzeniem, system utworzy przebieg informacyjny. Te uruchomienia 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 BuildDefinition API 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 tfVC zostały zaktualizowane w celu korzystania z nowej platformy internetowej. W tej wersji udostępniamy nowe strony tfVC.

Wyłączanie repozytorium

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

• W repozytorium znaleziono wpis tajny.
• Narzędzie do skanowania innej firmy stwierdziło, że repozytorium jest niezgodne.

W takich przypadkach możesz tymczasowo wyłączyć repozytorium podczas pracy w celu rozwiązania problemu. Dzięki tej aktualizacji możesz wyłączyć repozytorium, jeśli masz uprawnienia do usuwania repozytorium . Wyłączając repozytorium:

• 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, że repozytorium zostało wyłączone podczas próby uzyskania dostępu do repozytorium w interfejsie użytkownika usługi 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 ustawienia określającego, że twórcy gałęzi nie mają dostępu do polecenia „Zarządzaj uprawnieniami” w swoich gałęziach

Podczas tworzenia nowej gałęzi otrzymujesz pozycję "Zarządzaj uprawnieniami" w tej gałęzi. 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 umożliwić innemu użytkownikowi zewnętrznemu 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 rozwidleń głosowania na ich żądania ściągnięcia w repozytorium nadrzędnym

Dzięki usłudze Azure Repos użytkownicy z uprawnieniami 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ędnym strumieniu. 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 można utworzyć sytuację, w której 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 wewnętrzny źródła, rozwidlenie i współtworzenie jest typowym wzorcem. Aby dodatkowo zabezpieczyć i promować ten wzorzec, zmieniamy uprawnienia do głosowania nad żądaniem ś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 usłudze 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 dostępna jest teraz opcja 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 burn down i sumowane lub zliczane 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ć 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