Aktualizacje usługi Azure DevOps i ulepszenia integracji

Aby zapewnić bezpieczeństwo środowiska usługi Azure DevOps, wprowadzamy kluczowe aktualizacje usługi. Obejmuje to zakończenie obsługi nowych rejestracji aplikacji OAuth od kwietnia 2025 r., chociaż istniejące aplikacje będą nadal działać do pełnej emerytury w 2026 r. Ponadto, Indykacja Nazwy Serwera (SNI) będzie wymagana dla wszystkich połączeń HTTPS od 23 kwietnia 2025 r., wraz z aktualizacjami zasad zatwierdzania w TFVC w usłudze Azure Repos.

Oprócz tych aktualizacji z przyjemnością ogłaszamy najnowsze ulepszenia integracji Azure Boards i GitHub, ułatwiające łączenie gałęzi, pull requestów i commitów do elementów roboczych. Ponadto usługa Pipelines zapewnia teraz lepszy wgląd w zależności etapu YAML, pomagając zespołom zarządzać bardziej złożonymi przepływami pracy dzięki lepszej wydajności.

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

Ogólne

• Brak nowych aplikacji usługi Azure DevOps OAuth od kwietnia 2025 r.
• Wskazanie nazwy serwera (SNI) jest teraz obowiązkowe dla usług Azure DevOps Services

Azure Boards:

• Integracja z GitHubem: ulepszenia w łączeniu z zatwierdzeniami, gałęziami i pull requestami
• Integracja z usługą GitHub: wyświetlanie stanu kompilacji dla potoków YAML
• Zwiększono limit planów dostarczania

Azure Repos

• Zmiany zasad TFVC
• Ulepszenie interfejsu API GetRepository
• Ulepszenia dla interfejsu API do zapytań Pull Requests

Azure Pipelines

• Ulepszony wgląd w zależności między etapami w potoku YAML
• Nowy agent CDN
• Węzeł 16 zostanie usunięty z pipelines-* Pakietów agentów rurowania

Plany testów platformy Azure:

• Wycofywanie rejestrowania akcji i przełączanie się na nagrywanie ekranu
• Automatyczne wstrzymywanie ręcznego przebiegu testu

Ogólne

Brak nowych aplikacji usługi Azure DevOps OAuth od kwietnia 2025 r.

Od kwietnia 2025 r. nie obsługujemy już nowych rejestracji aplikacji OAuth usługi Azure DevOps. Jest to pierwszy krok w kierunku długoterminowej wizji przejścia na emeryturę platformy Azure DevOps OAuth. Zalecamy, aby wszyscy deweloperzy tworzący aplikacje na podstawie interfejsów API REST usługi Azure DevOps zapoznali się z platformą tożsamości firmy Microsoft i zamiast tego zarejestrowali nową aplikację Entra .

Wszystkie istniejące aplikacje OAuth usługi Azure DevOps będą nadal działać do czasu oficjalnego wycofania platformy w 2026 roku. Dowiedz się więcej w naszym wpisie w blogu tutaj.

Wskazanie nazwy serwera (SNI) jest teraz obowiązkowe dla usług Azure DevOps Services

Od 23 kwietnia 2025 r. będziemy wymagać wskazania nazwy serwera (SNI) na wszystkich przychodzących połączeniach HTTPS z usługami Azure DevOps Services.

SNI to rozszerzenie protokołu TLS, które umożliwia klientom określenie nazwy hosta, z którą nawiązuje połączenie. Wszystkie nowoczesne przeglądarki i oprogramowanie klienckie obsługują sieć SNI i używają jej domyślnie, zapewniając bezproblemowe przejście dla większości użytkowników. W rzeczywistości ponad 99.995% ruchu klientów docierającego do naszych serwerów jest przystosowane do SNI.

Jednak niektóre oprogramowanie klienckie może być niezgodne z siecią SNI ze względu na różne czynniki, takie jak nieaktualne, nieprawidłowo skonfigurowane biblioteki sieciowe, środowiska uruchomieniowe lub systemy operacyjne. Problemy mogą również wynikać z serwerów proxy lub zapór NGFW. Problemy z interfejsem SNI mogą mieć wpływ na następujące narzędzia używane z usługą Azure DevOps:

• Klienci usługi Git
• Wtyczki i rozszerzenia IDE (Team Explorer Everywhere)
• Oprogramowanie działające w starszych wersjach języka Java, które nie obsługują interfejsu SNI (Java 6 i starszych) lub nie ma domyślnie włączonego interfejsu SNI (niektóre wersje języka Java 7 i 8)
• Stare wersje przeglądarki (zobacz https://caniuse.com/sni)

Problemy z siecią SNI zwykle manifestują się przez błędy połączenia, takie jak:

• ERR_SSL_PROTOCOL_ERROR (błąd protokołu SSL), ERR_CERT_COMMON_NAME_INVALID (Nieprawidłowa nazwa wspólna certyfikatu)
• javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLException
• Nie można ustanowić relacji zaufania dla bezpiecznego kanału SSL/TLS

Zweryfikuj zgodność interfejsu SNI systemu, wywołując punkt końcowy stanu usługi Azure DevOps, który skonfigurowaliśmy pod kątem wymagania interfejsu SNI. Jeśli to wywołanie powiedzie się, oznacza to, że host, w tym jego system operacyjny i środowisko sieciowe, jest zgodny ze standardem SNI. Aby uzyskać szczegółowe instrukcje dotyczące testowania, odwiedź nasz wpis w blogu.

Azure Boards

Integracja z GitHub: usprawnienia związane z zatwierdzeniami, gałęziami i pull requestami.

Stale ulepszamy integrację z usługami Boards + GitHub, aby zamknąć luki w użyteczności i dostosować się do doświadczenia, które znasz w usłudze Azure Repos.

W tej aktualizacji wprowadziliśmy kilka ulepszeń, aby usprawnić sposób, w jaki gałęzie, pull requesty i zatwierdzenia są połączone z elementami roboczymi.

• Gdy gałąź usługi GitHub jest połączona z elementem roboczym, wszystkie skojarzone żądania ściągnięcia będą teraz automatycznie połączone. Nie trzeba ręcznie używać AB#.

• Po scaleniu pull requestu, scalony commit zostanie automatycznie powiązany z elementem roboczym.

• Jeśli gałąź zostanie usunięta po połączeniu żądania ściągnięcia, link do gałęzi zostanie automatycznie usunięty z elementu zadania.

Te ulepszenia ułatwiają śledzenie postępu rozwoju i utrzymywanie czystych, aktualnych powiązań elementów roboczych.

Integracja z usługą GitHub: wyświetlanie stanu kompilacji dla potoków YAML

Zobowiązujemy się do osiągnięcia równorzędności funkcji między YAML a klasycznymi potokami. Jedną z kluczowych brakujących funkcji było udostępnienie linku "Zintegrowane w kompilacji", gdy repozytorium jest hostowane w usłudze GitHub. W najnowszej wersji rozwiązaliśmy tę lukę, dodając opcję w ustawieniach potoku YAML do sprawdzenia:

Po zakończeniu kompilacji odpowiedni link zostanie automatycznie wyświetlony na skojarzonych elementach roboczych, co poprawi ogólną historię śledzenia.

Zwiększono limit planów dostawy

Wcześniej ograniczyliśmy plany dostarczania na projekt do 1000. Dzięki tej aktualizacji zwiększyliśmy maksymalną liczbę planów dostarczania na projekt do 1500. Więcej informacji na temat dodawania i edytowania planów dostarczania można znaleźć w dokumentacji tutaj.

Azure Repos

Zmiany zasad zatwierdzania TFVC

Nowa wersja (19.255.0-preview) pakietu NuGet Microsoft.TeamFoundationServer.ExtendedClient

Pakiet NuGet Microsoft.TeamFoundationServer.ExtendedClient został zaktualizowany o nowe klasy i metody polityk TFVC.

Zmiany zasad

Wprowadzamy zmiany w sposobie przechowywania zasad ewidencjonowania TFVC w usłudze Azure DevOps, co oznacza również aktualizacje sposobu komunikowania się NuGet Microsoft.TeamFoundationServer.ExtendedClient z usługą.

Jeśli projekt TFVC używa zasad wprowadzania zmian, przeprowadź migrację tych zasad do nowego formatu. Istnieją dwa sposoby, aby to zrobić:

1. Korzystanie z programu Visual Studio.

Aby administrator projektu programu Visual Studio mógł utworzyć nowe zasady, powinien otworzyć Ustawienia —> Projekt zespołowy —> Kontrola źródła —> Zasady ewidencjonowania, a następnie dodać nową zasadę (bez oznaczenia „Przestarzałe”) z tymi samymi parametrami co stara.

2. Jeśli używasz niestandardowej implementacji Microsoft.TeamFoundationServer.ExtendedClient do komunikacji z serwerem, postępuj zgodnie z przewodnikiem migracji.

Migracja jest wymagana, aby zachować kompatybilność kontroli wersji TFVC z przyszłymi wersjami usługi Azure DevOps. W tym czasie zarówno stare (przestarzałe), jak i nowe zasady pozostają prawidłowe i funkcjonalne. Aby uzyskać informacje na temat przyszłych planów, zobacz nasz wpis w blogu.

Ulepszenia w interfejsie API GetRepository

Dodaliśmy właściwość creationDate do odpowiedzi API Pobierz Repozytorium, która zwraca datę utworzenia repozytorium. Właściwość jest dostępna na wersjach interfejsu API 7.2-preview i nowszych.

Ulepszenia interfejsu API zapytań Pull Requestów

Wprowadziliśmy nową właściwość Label w odpowiedzi na zapytanie o Pull Request — Pobierz interfejs API. Teraz możesz określić, czy mają być uwzględniane etykiety dla powiązanych pull requestów w każdym zapytaniu. Dostępny jest nowy Include atrybut — jeśli ustawiony na Etykiety, odpowiedź zawiera etykiety dla określonych PR. Jeśli pozostawiono wartość null, etykiety nie zostaną uwzględnione. Aby zapobiec niezamierzonym błędom, upewnij się, że NotSet nie został jawnie przypisany — spowoduje to Bad Request.

Przykład treści żądania:

{
    "queries": [
        {
            "type": "lastMergeCommit",
            "include": "Labels",
            "items": [ 
                "0d6c9b2b524113113fced41aecbf8631a4649dec"
            ]
        },
        {
            "type": "lastMergeCommit",
            "items": [
                "b524113113f0dd41aecbf8631a4649dec6c9b2ce"
            ]
        }
    ]
}

Azure Pipelines

Ulepszony wgląd w zależności między etapami potoków YAML

Potoki YAML zapewniają elastyczność zarządzania złożonymi przepływami pracy, ale wizualizacja zależności pomiędzy etapami była wyzwaniem — szczególnie przy wdrożeniach w wielu regionach.

Nie zawsze było jasne, jak etapy są połączone. Na przykład określenie, czy CUS3 zależy od WUS1 oprócz WUS2 i WUS3, wymaga bezpośredniego przeglądu YAML.

Dzięki temu sprintowi zależności pomiędzy etapami są teraz wyświetlane, gdy etap zostanie rozwinięty, zapewniając natychmiastowy wgląd w kolejność wykonywania i wymagania nadrzędne.

Nowy agent CDN

Ponieważ usługa Edgio CDN jest wycofywana, adres URL domeny należący do firmy Edgio https://vstsagentpackage.azureedge.net również zostanie wycofany. Dodajemy nowy adres URL https://download.agent.dev.azure.com domeny obsługiwany przez nową sieć CDN. Pamiętaj, aby dodać ten nowy adres URL domeny do listy dozwolonych w zaporze. Pobieranie pakietów agenta dla agentów hostowanych lokalnie zakończy się niepowodzeniem po usunięciu starego adresu URL domeny. Aby uzyskać więcej informacji, zapoznaj się z wpisem .

Węzeł 16 zostanie usunięty z potoków—* Pakiety agentów potoku

Zadania agenta można zaimplementować w PowerShell lub Node.js. Agent jest dostarczany z wieloma wersjami Node.js, które mogą być używane przez zadania.

W miarę wydawania nowych wersji Node,zadania są aktualizowane w celu korzystania z tych nowych wersji. Środowiska uruchomieniowe są dołączane do agenta.

Gdy wersje Node wychodzą z głównego okresu wsparcia technicznego, niektóre zadania Pipelines nadal na nim polegają. Usługa Azure DevOps aktualizuje obsługiwane zadania do obsługiwanej wersji środowiska Node. Do uruchamiania zadań innych firm mogą być nadal potrzebne starsze wersje Node.

W tym celu mamy dwa typy pakietów agenta potokowego:

Jeśli chcesz uruchomić zadanie wymagające obsługi wykonawczej Node 16 na agencie, który nie ma w pakiecie Node 16, możesz zainstalować rękę wykonawczą, wstawiając zadanie NodeTaskRunnerInstaller@0 w potoku:

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

Azure Test Plans

Wycofywanie rejestrowania akcji i przełączanie się na nagrywanie ekranu

Nasz klasyczny klient modułu uruchamiającego testy platformy Azure opiera się na rejestratorze kroków problemów (PSR), narzędziu wprowadzonego w systemie Windows 7, które jest obecnie przestarzałe w nowszych wersjach systemu Windows. W związku z tym funkcjonalność dziennika akcji w naszym programie do uruchamiania testów na pulpicie może przestać działać w przyszłych aktualizacjach.

Aby zapewnić nieprzerwane śledzenie testów, zalecamy przełączenie na nagrywanie ekranu w naszym internetowym module uruchamiającym testy, rozszerzeniu Test & Feedback, które zapewnia nowoczesny, niezawodny sposób przechwytywania kroków testowych i zarządzania nimi. Jeśli potrzebujesz pomocy w przejściu do rozszerzenia Test & Feedback, skontaktuj się z naszym zespołem pomocy technicznej.

Automatyczne wstrzymywanie ręcznego przebiegu testu

Nigdy nie trać postępu w przebiegach testowych dzięki funkcji automatycznego wstrzymywania testów. Ta nowa funkcja automatycznie wstrzymuje przebieg przypadku testowego, jeśli praca zostanie przerwana, dzięki czemu postęp częściowy zostanie zapisany bez konieczności ręcznego wstrzymania. Niezależnie od tego, czy odejdziesz, czy zamkniesz sesję, możesz łatwo wznowić przypadek testowy w miejscu, w którym została przerwana, zmniejszając ryzyko utraty danych i poprawiając przepływ pracy. Upraszczając proces wstrzymywania i wznawiania, automatyczne wstrzymywanie pomaga skoncentrować się na testowaniu bez obaw o utratę postępu. Spróbuj i daj nam znać za pośrednictwem wiadomości e-mail co myślisz!

Następne kroki

Przejdź do usługi Azure DevOps i przyjrzyj się.

Jak przekazać opinię

Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.

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

Dzięki

Silviu Andrica