Sdílet prostřednictvím

Poznámky k verzi pro Azure DevOps Server

| Komunita | vývojářůPožadavky na systém a kompatibilita | Licenční podmínky | Blog | DevOpsHodnoty hash SHA-256 |

V tomto článku najdete informace týkající se nejnovější verze Pro Azure DevOps Server.

Další informace o instalaci nebo upgradu nasazení Azure DevOps Serveru najdete v tématu Požadavky na Azure DevOps Server.

Pokud chcete stáhnout produkty Azure DevOps Serveru, přejděte na stránku pro stahování Azure DevOps Serveru.

Přímý upgrade na Azure DevOps Server je podporovaný z Azure DevOps Serveru 2019 nebo Team Foundation Serveru 2015 nebo novějšího. Pokud je vaše nasazení TFS na TFS 2013 nebo starší, musíte před upgradem na Azure DevOps Server 2022 provést několik dočasných kroků. Další informace najdete na stránce Instalace .

Důležité

Problém zjištěný v nejnovější verzi Azure DevOps Serveru

Aktualizace 25. února 2026: Zjistili jsme problém ovlivňující Azure DevOps Server, který v určitých scénářích může vést k deaktivaci členství ve skupinách.

Aktivně prošetřujeme původní příčinu a pracujeme na trvalé opravě. Okamžitě jsme odebrali odkazy na stažení Azure DevOps Serveru, abychom zabránili dalšímu dopadu. Pokud jste už upgradovali, doporučujeme při dokončení řešení použít krok pro zmírnění rizika, který zastaví další dopad. Toto zmírnění zahrnuje spuštění prověřeného skriptu SQL pro konfigurační databázi, aby se zabránilo ovlivnění dalších dat.

Jakmile budou dostupné, podělíme se o podrobné pokyny, další kroky a aktualizovanou verzi. Do té doby zůstává podpora plně dostupná, pokud potřebujete pomoc. Budeme pokračovat v aktualizaci příspěvku na blogu o vydání, jakmile budou k dispozici další informace a pokyny.

Děkujeme vám za vaši trpělivost, zatímco pracujeme na řešení tohoto problému.

Datum vydání 1 opravy Azure DevOps Serveru: 10. února 2026

File SHA-256 hash
devopsserverpatch1 5747BE1A88557FA7AF45EDA4CE13E98FA997E8B7264CE6AC38D119D5E03CE05E

Vydali jsme opravu 1 pro Azure DevOps Server, která zahrnuje následující:

  • Zakázáno přesměrování URL, když připojení ke službě určuje prázdný parametr URL Mustache.
  • Byla zakázána možnost použití PAT s rozhraním API EndpointProxy, když je zadáno interní EndpointId.
  • Opravili jsme problém, kdy místní upgrade na Azure DevOps Server 25H2 mohl selhat, pokud v instanci SQL Serveru nebyl nakonfigurovaný certifikát TLS.
  • Opravili jsme problém, který způsoboval přerušení kroků spuštění webového testu po pozastavení a obnovení spuštění.

Datum vydání Azure DevOps Serveru: 9. prosince 2025

Azure DevOps Server RTW představuje opravy chyb a změny podpory SQL Serveru 2025. Zahrnuje všechny funkce v Azure DevOps Serveru RC, které byly vydány dříve.

Azure DevOps Server nebo upgrade můžete přímo nainstalovat z Azure DevOps Serveru 2022, 2020, 2019 nebo Team Foundation Serveru 2015 nebo novějšího.

Shrnutí novinek v Azure DevOps Serveru RTW

  • Sloučené změny lokalizace
  • Změny podpory SQL Serveru 2025
  • Opravili jsme problém, kdy dlouhé názvy úložišť nebo větví překročily ovládací prvek rozevíracího seznamu v konfiguraci widgetu Dlaždice kódu na stránce Řídicí panely.
  • Opravili jsme problém, kdy se při použití webhooků nesprávně uložil stav pull requestu na GitHubu jako Uzavřeno pro sloučené i nesloučené pull requesty. Systém teď spoléhá na sloučený logický příznak v datové části webhooku, aby přesně zaznamenával správný stav v databázi.
  • Opravili jsme problém s rekurzivní vlastností, který způsoboval zablokování sady Visual Studio během scénářů propojení sledování pracovních položek (WIT).
  • Vyřešili jsme problém, kdy se na stránce Fond agentů v nastavení kolekce zobrazila chyba a nepodařilo se načíst, když byla analýza pozastavená nebo zakázaná. Stránka se teď načte správně bez ohledu na stav Analýzy.

Datum vydání Verze RC Azure DevOps Serveru: 7. října 2025

Shrnutí novinek v Azure DevOps Serveru RC

Azure DevOps Server zavádí funkce, které jsme dříve vydali v naší hostované verzi produktu. Můžete přejít na jednotlivé části a zobrazit všechny nové funkce pro každou službu:

General

Zkopírujte blok kódu do schránky

V reakci na vaši zpětnou vazbu v komunitě vývojářů jsme představili tlačítko Kopírovat do schránky pro všechny bloky kódu v vykreslované markdownu. Toto vylepšení je k dispozici na stránkách wikiwebu, náhledech souborů Markdown v repos, diskuzích o žádostech o přijetí změn a popisech a diskuzích pracovních položek.

Kopírovat do schránky

Bylo přidáno oprávnění Delivery Plans

V rámci našich průběžných vylepšení zabezpečení jsme zavedli nové oprávnění na úrovni projektu Spravovat plány doručení. Tato změna byla implementována, aby se zabránilo neúmyslnému přístupu pro čtení a zápis pro uživatele ve skupině Čtenáři.

Správa plánů doručení

Boards

V rámci našich průběžných vylepšení integrace Azure Boards + GitHubu s radostí představujeme novou funkci, která zjednodušuje zobrazování odkazů AB#. Díky této aktualizaci se odkazy AB# teď zobrazují přímo v části Vývoj žádostí o přijetí změn GitHubu, což usnadňuje přístup k propojeným pracovním položkám bez hledání popisů nebo komentářů.

Odkazy AB ve vývoji

Tyto odkazy se zobrazí jenom v případech, kdy je v popisu pull requestu zahrnutý AB#. Pokud propojíte přímo z pracovní položky, nezobrazí se v části Vývoj. Odebráním odkazu AB# z popisu ho navíc odeberete z ovládacího prvku Vývoj.

Připojit se k vylepšení vyhledávání v úložišti GitHub

Vylepšili jsme proces připojení projektu Azure DevOps k organizaci GitHubu, zejména pro ty, kteří mají tisíce úložišť. Dříve jste mohli čelit výzvám, jako jsou chyby časového limitu a dlouhé doby čekání. Tato aktualizace optimalizuje možnosti vyhledávání a výběru, eliminuje riziko chyb časového limitu a usnadňuje a zefektivňuje proces připojení.

Přidání úložišť GitHubu

Integrace GitHubu: Zobrazení stavu sestavení pro kanály YAML

Zavázali jsme se dosáhnout parity funkcí mezi YAML a klasickými kanály. Jednou z klíčových chybějících funkcí byla možnost poskytnout odkaz "Integrovaný v sestavení", když je úložiště hostované na GitHubu. V naší nejnovější verzi jsme tuto mezeru vyřešili přidáním možnosti v nastavení kanálu YAML, abyste mohli zkontrolovat:

Obrázek konfigurace pipeliny s automatickým propojením pracovních položek

Po dokončení sestavení se odpovídající odkaz automaticky zobrazí na přidružených pracovních položkách, čímž se zlepší celkový scénář sledovatelnosti.

Podpora rozhraní REST API pro připojení úložišť GitHub

Zavádíme nové koncové body rozhraní REST API, které umožňují automatizovat přidávání a odebírání úložišť GitHubu ve vašich projektech Azure DevOps. Kromě toho jsme při používání těchto koncových bodů zvýšili limit úložiště na připojení z 500 na 2 000.

Mezi tyto koncové body patří:

Také jsme vám poskytli ukázkový kód , který vám pomůže začít.

Změna pro odstraňování oblastí a iteračních cest

Odstranění oblasti nebo iterační cesty může být rušivé. Může přesunout pracovní položky na novou cestu a může způsobit, že týmy ztratí přístup ke svým panelům a backlogům. I přes upozornění a výzvy se cesty někdy odstraní, aniž by byl plně pochopen jejich důsledek. Abychom to vyřešili, změnili jsme chování: Cesty oblasti a iterace se teď dají odstranit jenom v případě, že už nejsou používány žádnými pracovními položkami.

Obrázek nastavení pipeline s propojením na pracovní položky

Vylepšená správa tagů na formuláři pracovního úkolu

Správa značek ve službě Azure Boards byla vylepšena tak, aby poskytovala efektivnější prostředí. Odstraněné značky se už nezobrazují v navrhovaném seznamu ve formulářích pracovních položek a zajišťují, aby se zobrazovaly jenom aktivní značky.

Vylepšená podpora obrázků v komentářích pracovních položek

Vylepšili jsme podporu vkládání obrázků do komentářů pracovních položek. Do oddílu diskuze pracovní položky teď můžete vložit obrázky přímo ze zdrojů, jako jsou Microsoft Teams, e-maily a wordové dokumenty.

Omezení rozhraní REST API pro komentáře pracovních položek

Pro zvýšení zabezpečení byl nový limit nastaven na počet komentářů, které je možné přidat do pracovních položek prostřednictvím rozhraní REST API. Každá pracovní položka teď prostřednictvím rozhraní API podporuje maximálně 1 000 komentářů. Toto omezení platí výhradně pro rozhraní REST API a uživatelé můžou komentáře přidávat prostřednictvím webového rozhraní ručně i za prahovou hodnotu 1 000 komentářů.

Zvýšení limitu plánů doručení

Zvýšili jsme maximální počet plánů doručení na jeden projekt z 1 000 na 1 500.

Repos

Nové nastavení pro zakázání vytváření úložišť TFVC

V posledních letech nebyly do správy verzí Team Foundation (TFVC) přidány žádné nové funkce, protože Git se stal upřednostňovaným systémem správy verzí v Azure Repos. Všechna nedávná vylepšení zabezpečení, výkonu a přístupnosti byla provedena výhradně v úložištích Git, což vede k průběžnému poklesu využití TFVC. I když někteří stále spoléhají na TFVC a my tuto sadu funkcí nechceme odebrat, plánujeme TFVC postupně postupně vyřadit pro nové projekty a kolekce projektů a také pro projekty, které aktuálně nepoužívají TFVC.

V rámci tohoto přechodu zavádíme nové nastavení "Zakázat vytváření úložišť TFVC", které ovlivní jenom vytváření nových úložišť TFVC a nebude mít vliv na stávající úložiště.

Gif pro ukázku nového nastavení pro zakázání vytváření úložišť TFVC

Podpora uživatelského rozhraní dílčích modulů Gitu

Mnoho týmů aktivně využívá dílčímoduly Gitu k uspořádání základu kódu. S radostí sdílíme, že jsme přidali podporu submodulů Git v Centru souborů. Teď můžete okamžitě přejít do úložiště dílčího modulu jediným kliknutím přesně na konkrétní potvrzení, na které odkazuje váš superprojekt. Pokud se používá jako dílčí modul, podporují se následující služby Git: Azure Repos, GitHub, GitLab a Bitbucket. Podporuje se také více formátů adres URL zadaných v souboru .gitmodules, včetně absolutních HTTPS, SSH a relativních adres URL.

Gif pro demonstraci podpory uživatelského rozhraní dílčích modulů Gitu

Nový panel Stav a využití v centru souborů úložiště

S růstem úložišť Git se shromažďují potvrzení, objekty blob a další data, což může zvýšit zatížení infrastruktury Azure DevOps, což má vliv na výkon a uživatelské prostředí. Udržování úložiště, které je v pořádku, je klíčem k zajištění konzistentního výkonu a spolehlivosti.

Abychom to mohli podporovat, nyní monitorujeme několik faktorů, jako je velikost úložiště, frekvence potvrzení, obsah a struktura. Pokud vaše úložiště začne zatěžovat infrastrukturu, můžete obdržet oznámení s doporučeními pro nápravnou akci. Správou stavu úložiště můžete zabránit přerušení a zajistit hladké operace.

Pokud chcete zkontrolovat stav úložiště, přejděte do Azure Repos, > Files a v nabídce se třemi tečky zvolte Stav a využití, abyste se dostali k panelu Stav a využití úložiště.

Obrázek demonstrující podporu UI submodulů Git

Konfigurace cílových větví pro pull requesty

Správa více větví v úložišti může být náročná, zejména při vytváření nových pull requestů. Díky nové funkci Konfigurovat cílové větve pro žádosti o přijetí změn teď můžete zadat seznam upřednostňovaných cílových větví, abyste zajistili přesnější a relevantnější návrhy žádostí o přijetí změn. To vám pomůže zjednodušit pracovní postup a snížit riziko cílení na nesprávnou větev. Pokud chcete tuto funkci použít, vytvořte ve výchozí větvi úložiště soubor .azuredevops/pull_request_targets.yml. Tento soubor YAML by měl obsahovat seznam s názvem pull_request_targets s názvy větví nebo předponami, které odpovídají kandidátským větvím. Například:

pull_request_targets:
  - main
  - release/*
  - feature/*

V této konfiguraci má hlavní větev prioritu, ale větve začínající s "release/" nebo "feature/" budou také zohledněny, když to bude vhodné. Konfigurace se použije v následujících scénářích:

  • Návrhy Pull Requestů: Po odeslání větve do Azure DevOps může stránka Repos navrhnout vytvoření pull requestu z této větve a automaticky vybrat cílovou větev.
  • Adresa URL žádosti o přijetí změn: Když přejdete přímo na stránku pro vytvoření žádosti o přijetí změn pomocí parametru sourceRef, ale vynecháte parametr targetRef, Azure DevOps vybere cílovou větev na základě této dynamické volby.

Doporučuje se zahrnout pouze větve chráněné zásadami žádostí o přijetí změn, aby se zajistila konzistence v první nadřazené historii potvrzení tipu.

Podporovat diagramy Mermaid v souboru Markdown

Soubory Markdown obsahující syntaxi mermaid se teď vykreslují jako diagramy v náhledech souborů v prohlížeči souborů repos a v žádostech o přijetí změn. To vám může pomoct přidat do úložišť bohatší dokumentaci.

Obrázek pro ukázání podpory diagramu

Hledat pull requesty podle názvu na stránce seznamu PR

Stránka se seznamem žádostí o přijetí změn teď obsahuje filtr podle názvu žádosti o přijetí změn, což usnadňuje vyhledání konkrétních žádostí o přijetí změn.

Obrázek pro zobrazení hledání 'pull request' podle názvu

Řídký výběr pro Azure Repos

Příkaz gitrse-checkout je nyní podporován v úloze rezervace YAML spolu s částečným klonovacím filtrem za účelem zlepšení výkonu rezervace úložiště. Můžete použít vlastnosti sparseCheckoutDirectories a sparseCheckoutPatterns.

Nastavení sparseCheckoutDirectories povoluje cone mode, ve kterém proces kontroly verzí používá porovnávání adresářů. Alternativně můžete nastavit řídkéSekeckoutPatterny, které aktivují jiný než kuželový režim, což umožňuje složitější porovnávání vzorů.

Pokud jsou nastaveny obě vlastnosti, agent inicializuje režim kužele s odpovídajícími adresáři. Pokud není v úloze checkout zadána žádná vlastnost, je proces řídkého checkoutu zakázán. Jakékoliv problémy během provádění příkazu způsobí selhání úlohy výběru. Příklad YAML pro režim řídkého kuželového výběru:

    checkout: repo
    sparseCheckoutDirectories: src
YAML example for sparse checkout non-cone mode:
YAMLCopy

   checkout: repo
   sparseCheckoutPatterns: /* !/img

Důležité

Funkce řídkého výběru vyžaduje agenta verze 3.248.0 (v4.248.0 pro .NET 8) nebo pozdější.

Agenta najdete na stránce vydání.

Učinit zásady napříč úložišti citlivé na velikost písmen

Dříve náhled kandidátské větve pro zásady křížového repozitáře zobrazoval výsledky bez rozlišení malých a velkých písmen, přestože porovnávání větví rozlišuje malá a velká písmena. Tato nekonzistence mohla vést k potenciálnímu nesouladu, protože se mohlo zdát, že určité pobočky byly chráněny, když nebyly. Abychom tento problém vyřešili, aktualizovali jsme náhled vzoru větve tak, aby odpovídal chování politiky s rozlišením velikosti písmen.

Dříve:

Obrázek znázorňuje přidání ochrany větví

After:

Obrázek znázorňující přidání ochrany větví s rozlišením velikosti písmen

Změny zásad potvrzování změn TFVC

Nová verze (19.254) balíčku NuGet Microsoft.TeamFoundationServer.ExtendedClient

Balíček NuGet Microsoft.TeamFoundationServer.ExtendedClient byl aktualizován novými třídami a metodami zásad TFVC.

Změny zásad

Provádíme změny ve způsobu, jakým jsou zásady vracení změn TFVC uloženy v Azure DevOps, což také obnáší aktualizaci způsobu, jakým NuGet Microsoft.TeamFoundationServer.ExtendedClient komunikuje se službou. Pokud váš projekt TFVC používá zásady připojení změn, migrujte tyto zásady do nového formátu. Můžete to udělat dvěma způsoby:

  1. Pomocí sady Visual Studio.

Výstraha

Nebezpečné určité důsledky akce.: Před pokračováním se ujistěte, že jste sadu Visual Studio aktualizovali na nejnovější verzi (VS 2022, VS 2019 a VS 2017 s minimálními verzemi 17.14 Preview 3, 17.13.6, 17.12.7, 17.10.13, 17.8.20, 16.11.46, 15.9.72 podporují nové zásady).

Pokud chcete vytvořit nové zásady pomocí správce projektu sady Visual Studio, měli byste otevřít Nastavení –> Týmový projekt –> Zdrojová kontrola –> Zásady přihlašování a přidat nové zásady (bez značky Zastaralé) se stejnými parametry jako staré:

Obrázek s nastavením správy zdrojového kódu

  1. Pokud ke komunikaci se serverem používáte vlastní implementaci Microsoft.TeamFoundationServer.ExtendedClient, postupujte podle průvodce migrací. Migrace je nutná, aby vkládání změn TFVC zůstalo kompatibilní s budoucími verzemi Azure DevOps. Za tu dobu zůstanou staré (zastaralé) i nové zásady platné a funkční. Informace o budoucích plánech najdete v našem blogovém příspěvku.

Vylepšení rozhraní GetRepository API

Do odpovědi úložiště jsme přidali vlastnost creationDate – Get Repository API vracející datum vytvoření úložiště. Vlastnost je k dispozici ve verzích rozhraní API 7.2-Preview a vyšší.

Vylepšení API pro dotazy na pull requesty

V odpovědi na API dotaz „Get“ pro pull request jsme zavedli novou vlastnost Popisek. Teď můžete určit, jestli chcete do každého dotazu zahrnout popisky (značky) pro související žádosti o přijetí změn. K dispozici je nová vlastnost "Include" – pokud je nastavená na "Labels", odpověď obsahuje popisky pro zadané žádosti o přijetí změn. Pokud bude hodnota nastavena na null, popisky nebudou zahrnuty. Pokud chcete zabránit nezamýšleným chybám, ujistěte se, že 'NotSet' není explicitně přiřazen – výsledkem bude špatný požadavek.

Poznámka:

Využití prostředků rozšiřování popisků závisí na počtu přiřazených popisků a jejich délce. Žádosti o štítky mohou ovlivnit omezení a zvýšit zatížení sítě. Pokud chcete optimalizovat výkon, doporučujeme vyhnout se zbytečným požadavkům na popisky.

Příklad obsahu požadavku:

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

Pipelines

TFX ověřuje, zda úloha používá běžce Node.js, který dosáhl konce životnosti.

Autoři úloh používají TFX k publikování rozšíření. TFX byl aktualizován tak, aby prováděl ověřování v jiných verzích Node Runneru.

Rozšíření obsahující úlohy používající verzi Node runneru, která dosáhla konce životnosti (EOL) (až do 16. uzlu), uvidí toto upozornění.

Task < TaskName > je závislý na spouštěči úkolů, který je na konci životnosti a bude v budoucnu odebrán. Autoři by měli zkontrolovat pokyny k upgradu uzlu: https://aka.ms/node-runner-guidance

Přístup ke službě Azure Service Bus z Pipelines pomocí ověřování Microsoft Entra ID

Teď můžete použít ověřování Microsoft Entra ID pro přístup ke službě Azure Service Bus z Azure Pipelines. Díky tomu můžete využít Azure RBAC k jemně odstupňovanému řízení přístupu.

Identitám, které přistupují ke službě Azure Service Bus, je potřeba udělit jednu z předdefinovaných rolí Azure pro Službu Azure Service Bus v přístupné službě Service Bus.

PublishToAzureServiceBus@2 úloha

Nové úlohy PublishToAzureServiceBus@2 je možné nakonfigurovat pomocí připojení služby Azure. Vytvořte připojení ke službě Azure a nastavte vlastnosti serviceBusQueueName a serviceBusNamespace pro nový úkol:

- task: PublishToAzureServiceBus@2
  inputs:
    azureSubscription: my-azure-service-connection
    serviceBusQueueName: my-service-bus-queue
    serviceBusNamespace: my-service-bus-namespace
    useDataContractSerializer: false
    messageBody: |
      {
        "foo": "bar"
      }

Úlohy serveru

Vlastní úlohy serveru (bez agenta), které používají spouštění ServiceBus, můžou zadat připojení ke službě Azure jako EndpointId a vynechat connectionString. Viz Vytváření úloh serveru.

TFX ověřuje, zda úloha používá běžce Node.js, který dosáhl konce životnosti.

Autoři úloh používají TFX k publikování rozšíření. TFX byl aktualizován tak, aby prováděl ověřování v jiných verzích Node Runneru.

Rozšíření obsahující úlohy používající verzi Node runneru, která dosáhla konce životnosti (EOL) (až do 16. uzlu), uvidí toto upozornění.

Task < TaskName > je závislý na spouštěči úkolů, který je na konci životnosti a bude v budoucnu odebrán. Autoři by měli zkontrolovat pokyny k upgradu uzlu: https://aka.ms/node-runner-guidance

Úlohy, které ke spuštění používají verzi Node runneru s ukončenou podporou, generují varování.

Úlohy kanálu, které závisí na verzi uzlu (10), která již není udržována, obdrží upozornění: Verze úlohy TaskName závisí na Node.js verzi (10), která je ukončena životností. Požádejte vlastníka rozšíření o aktualizovanou verzi úlohy. Správci úloh by měli zkontrolovat pokyny k upgradu uzlu: https://aka.ms/node-runner-guidance Pokud chcete tato upozornění potlačit, můžete nastavit prostředí nebo proměnnou kanálu na úrovni kanálu (úlohy) nebo úlohy. Například:

variables:
  AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false

DockerCompose@0 používá Docker Compose v2 v režimu kompatibility v1.

Docker Compose v1 dosáhne konce životnosti a bude odebrán z hostovaných agentů 24. července 2024. Aktualizovali jsme úlohu DockerCompose@0 tak, aby používala Docker Compose v2 v režimu kompatibility v1, pokud na agentu není k dispozici Docker Compose v1.

Režim kompatibility ale neřeší všechny problémy s kompatibilitou. Viz Přejít na Compose V2. Někteří uživatelé budou potřebovat více času na aktualizaci svých projektů Docker Compose pro kompatibilitu Docker Compose v2. V těchto případech postupujte podle těchto pokynů a použijte úlohu DockerComposeV0 s docker-compose v1. POZNÁMKA: Tato příručka je založena na dokumentaci k samostatné instalaci Compose. Použijte docker-compose v1 na Windows. Přidejte krok PowerShellu do vašeho kanálu pro stažení docker-compose v1.29.2 a použijte ho s úlohou DockerComposeV0 ve Windows.

variables:
    dockerComposePath: C:\docker-compose

steps:
- powershell: |
    mkdir -f $(dockerComposePath)
    # GitHub now requires TLS1.2. In PowerShell, run the following
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: '**/docker-compose.yml'
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)\docker-compose.exe
Use docker-compose v1 on Linux
Add the bash step to your pipeline to download Docker-Compose v1.29.2 and use it with the DockerComposeV0 task on Linux:
YAMLCopy
variables:
    dockerComposePath: /tmp/docker-compose

steps:
- bash: |
    sudo mkdir $(dockerComposePath)
    sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
    sudo chmod 755 $(dockerComposePath)/docker-compose
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)/docker-compose

Test Plans

Rozšíření Testování a Zpětná vazba v manifestu V3

S radostí oznamujeme novou aktualizaci rozšíření Azure DevOps Test a Feedback pro Chrome i Edge. Tato aktualizace přechází naši implementaci z Manifestu V2 na Manifest V3 v souladu s plánem společnosti Google na zrušení podpory pro Manifest V2. I když základní funkce rozšíření zůstávají beze změny, aktualizace vylepšuje zabezpečení i výkon.

Další podrobnosti najdete v našem nedávném blogovém příspěvku o této aktualizaci. Testovací a zpětnovazební rozšíření manifestu V3

Azure Test Runner verze 1.2.2

Azure Test Plans vydaly ve verzi 1.2.2 opravu pro nedávný problém v testovacích plánech, kdy Spouštěč testů Azure (ATR) zažil selhání spuštění v prohlížeči Chrome verze 130. K tomuto problému došlo kvůli přidání podpory pro nespeciální adresy URL dle schématu, což ovlivnilo průběh uživatelského toku ATR. Při této aktualizaci se vyřeší chyba regrese a obnoví se funkce ATR. Další podrobnosti o této regresní chybě naleznete v tomto systému sledování problémů v Chromium.

Doporučujeme používat webovou aplikaci pro vylepšené funkce. Pokud ve webové aplikaci najdete nějaké chybějící funkce, rádi bychom vás slyšeli. Podělte se s námi o svůj názor!

Bezproblémová integrace sestavovacího řetězce pro provádění testovacích případů

Zjednodušili jsme proces provádění testovacího případu bezproblémovou integrací konfigurací kanálu buildu. Definice a ID buildů nastavené na úrovni testovacího plánu se nyní automaticky přenáší do Web Runneru, což eliminuje nutnost ruční konfigurace při každém použití. Toto vylepšení šetří čas a zvyšuje efektivitu, takže se můžete soustředit na důležitější úlohy.

Gif pro ukázku bezproblémové integrace kanálu buildu pro testovací případy

Obnovení odstraněných testovacích plánů a sad testů pomocí rozhraní REST API

Snadné obnovení odstraněných testovacích plánů a testovacích sad pomocí nových samoobslužných rozhraní API Představujeme rozhraní GET a PATCH API, která umožňují vyhledat odstraněné testovací plány nebo sady a obnovit je společně s podřízenými položkami – to vše bez nutnosti zákaznické podpory. Pomocí těchto rozhraní API můžete rychle obnovit náhodně odstraněné testovací pracovní položky, snížit výpadky a zvýšit produktivitu. I když se artefakty z běhu neobnoví, všechny související testovací plány, sady a testovací případy lze snadno přenést do pracovního prostoru. Tato samoobslužná funkce poskytuje větší kontrolu nad správou testů a zjednodušuje proces obnovení, což usnadňuje a zefektivňuje obnovení kritických testovacích prostředků.

Export testovacích případů s vlastními sloupci v XLSX

Teď můžete exportovat testovací případy s vlastními sloupci v XLSX. Na základě zpětné vazby testovací plány podporují export testovacích případů s vlastními sloupci a poskytují větší flexibilitu a kontrolu nad daty, která sdílíte a analyzujete. Toto vylepšení vám pomůže přizpůsobit exporty vašim potřebám a zajistit, aby informace, které exportujete, byly relevantní a použitelné.

Nové možnosti řazení v adresáři Testovací plány

Adresář Testovací plány teď nabízí vylepšené možnosti řazení. Díky této aktualizaci můžete rychle uspořádat každý sloupec alfanumericky, což usnadňuje hledání a přístup k datům.

Gif pro ukázku řazení v adresáři testovacích plánů

Vrácení testovacího kroku ve webovém a desktopovém spouštěči

Převezměte kontrolu nad spuštěním testovacího případu pomocí nové funkce "Zpět". Stav testovacích kroků můžete snadno vrátit jednoduchým poklikáním, což vám umožní větší flexibilitu a kontrolu během testovacích běhů. Žádné další restartování testovacích případů kvůli opravě náhodných kliknutí—jednoduše akci zrušte a pokračujte ve workflowu bez přerušení.

Zavádíme také vylepšení přístupnosti a navigace pomocí klávesnice, která zajistí, aby tato funkce bez problémů fungovala pro všechny uživatele, včetně těch, kteří spoléhají na technologie usnadnění. Toto vylepšení vám pomůže ušetřit čas, snížit frustraci a soustředit se na efektivní spouštění testů.

Gif pro ukázku testovacího kroku vrácení zpět ve webovém a desktopovém spouštěči

Vylepšení úlohy publikování výsledků pokrytí kódu v2

V této verzi zahrnujeme několik vylepšení úlohy v2:

  • Rozšířená podpora různých formátů pokrytí kódu, včetně: .coverage,.covx,.covb,.cjson,.xml,.lcov a pycov1.

  • Generování úplného souboru cjson (a zprávy o pokrytí zdrojového kódu), který obsahuje podrobné informace o pokrytí zdrojového kódu, jako jsou názvy souborů, řádky pokryté nebo nepokryté atd.

Snímek obrazovky s pokrytím kódu

Podpora rozdílového pokrytí (pokrytí žádostí o přijetí změn): V2 může vygenerovat rozdílové komentáře k žádosti o přijetí změn pro více jazyků v rámci stejného kanálu.

Úloha v2 teď podporuje úlohu kontroly kvality sestavení, která nebyla podporována v úloze v1.

Podpora kanálů YAML v testovacích plánech

Kromě klasických kanálů teď můžete kanály YAML používat při konfiguraci testovacích plánů nebo spouštění automatizovaných testů z testovacích plánů.

Tato žádost byla upřednostněna na základě následujících návrhových lístků vývojářské komunity.

Reportování

Agregovaná data sloupců dostupná v backlogu

Aktualizovali jsme souhrnné sloupce tak, aby zobrazovaly nejnovější dostupná data. Dříve se tyto sloupce mohly zobrazovat jako prázdné pro často aktualizované pracovní položky, což způsobuje nejasnosti. Zobrazí se také časové razítko označující, kdy byla data naposledy aktualizována. I když je určité zpoždění zpracování analýzy běžné, cílem těchto vylepšení je zajistit transparentnost a plynulejší prostředí při práci s souhrnnými sloupci.

Obrázek pro demonstraci dat souhrnných sloupců dostupných v backlogu  

Wiki

Vylepšení vkládání obsahu založeného na HTML do wikiwebů

Usnadnili jsme vkládání obsahu založeného na HTML do wikiwebů. Teď se prvky HTML, jako jsou odkazy, seznamy, tabulky, obrázky, excelové listy, zprávy, e-maily a dotazy Azure Data Exploreru, automaticky převedou na syntaxi Markdownu pro plynulejší úpravy.

  • Last updated on