Zpráva k vydání verze pro Azure DevOps Server 2022 Update 2

| 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 2022 Update 2 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 .

Datum vydání aktualizace Azure DevOps Server 2022 Update 2 Patch 8: 10. února 2026

File SHA-256 hash
devops2022.2patch8 D44ECE516945569F8B3FD23386B52D085FF83E237B741B1FD3238E59B52AE386

Vydali jsme opravu 8 pro Azure DevOps Server 2022 Update 2, aby zahrnovala následující:

  • CVE-2026-21512: Ohrožení zabezpečení skriptování mezi weby Azure DevOps Serveru
  • 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.

Datum vydání aktualizace Azure DevOps Server 2022 Update 2 Patch 7: 11. listopadu 2025

File SHA-256 hash
devops2022.2patch7 73523C82BA4F910170E812C1B43374146BFD0EA9A29E2B0DA50A096360E1461F

Vydali jsme opravu 7 pro Azure DevOps Server 2022 Update 2, aby zahrnovala následující:

  • Aktualizace proxy serveru TFVC: Algoritmus hash použitý v procesu autorizace byl aktualizován z SHA-1 na SHA-256. Pokud chcete zajistit kompatibilitu a zabránit přerušení, aktualizujte proxy server společně se serverem.
  • Vyřešili jsme problém s nepodepsanými binárními soubory v úlohách MSBuildV1 a VSBuildV1.
  • Optimalizovaný výkon pro výkon kroku DeleteJobDefinitionsByExtensionName.

Datum vydání aktualizace Azure DevOps Server 2022 Update 2 Patch 6: 10. června 2025

Important

Aktualizace 25. července: V současné době prošetřujeme problém s opravou Patch 6 pro Azure DevOps Server 2022.2. Náš tým aktivně pracuje na identifikaci původní příčiny a co nejrychleji implementuje řešení. Až budou dostupné, budeme v tomto blogu dál poskytovat aktualizace a podrobnosti. Děkujeme vám za vaši trpělivost a porozumění.

File SHA-256 hash
devops2022.2patch6 B0B42C0085045C0B8B8B60C1ECB6D157734758AA24D6A3040A9B57770401A55D

Vydali jsme opravu 6 pro Azure DevOps Server 2022 Update 2, aby zahrnovala následující vylepšení testovacích plánů:

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

S touto opravou 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é.

  • Import sady a kopírování testovacích případů s ID plánu a ID sady pouze ve vyhledávání.

Datum vydání aktualizace Azure DevOps Server 2022 Update 2 Patch 5: 8. dubna 2025

File SHA-256 hash
devops2022.2patch5 299AC29F15BC254167C2987450EF722B083594AFA885A8DAB46625C92D982C1C

Vydali jsme opravu 5 pro Azure DevOps Server 2022 Update 2, která zahrnuje:

Important

Změna adresy URL domény CDN pro agenty v blogu Pipelines obsahuje postup před instalací této opravy.

  • Dříve Azure DevOps Agent používal Edgio CDN s koncovým bodem vstsagentpackage.azureedge.net. V rámci vyřazení služby Edgio bude doména *.azureedge.net vyřazena z provozu. Abychom zajistili trvalou dostupnost, přešli jsme na CDN podporovanou společností Akamai s novým koncovým bodem download.agent.dev.azure.com. Tato záplata zahrnuje potřebné změny k získání binárních souborů agenta z nového koncového bodu CDN, čímž se přechází z předchozího koncového bodu CDN.

Datum vydání opravy 4 pro Azure DevOps Server 2022 Update 2: 11. března 2025

File SHA-256 hash
devops2022.2patch4 975B0FC28737C15BA40D6E084663D1A735A66FA821EB40C7A377AE3D58F0C7DA

Vydali jsme opravu 4 pro Azure DevOps Server 2022 Update 2, která zahrnuje:

Datum vydání Azure DevOps Serveru 2022 Update 2 Patch 3: 11. února 2025

Note

24. února 2025 jsme znovu vydali opravu Patch 3 pro Azure DevOps Server 2022.2. Pokud jste dříve nainstalovali starší verzi této opravy, aktualizujte ji pomocí poskytnutého odkazu. Tato opětovná verze řeší problém, který způsobuje selhání kanálů YAML. Další podrobnosti o problému najdete v komunitě vývojářů .

File SHA-256 hash
devops2022.2patch3 F5C2DA846B8A38A1FB55D1EB555FB2FD6B974B0436F573CC01A0FEBAF3D67521

Vydali jsme opravu 3 pro Azure DevOps Server 2022 Update 2, která zahrnuje:

Datum vydání aktualizace Azure DevOps Server 2022 Update 2: 12. listopadu 2024

File SHA-256 hash
devops2022.2patch2.exe 70930BE091607B490890A48C250DAB6C2087F7F610CC695C9C632C679A491D23

Vydali jsme opravu 2 pro Azure DevOps Server 2022 Update 2, která zahrnuje upgrade na ohroženou závislost.

Datum vydání Azure DevOps Serveru 2022.2 RTW: 9. července 2024

Shrnutí novinek v Azure DevOps Serveru 2022.2 RTW

Note

Znovu jsme vydali Azure DevOps Server 2022.2, abychom vyřešili problém s načítáním názvů Teams. Problém byl nahlášen v příspěvku na blogu Azure DevOps Server 2022.2 RTW, který je nyní dostupný. Pokud jste nainstalovali verzi Azure DevOps Serveru 2022.2 vydanou 9. července, můžete nainstalovat opravný balíček 1 pro Azure DevOps Server 2022.2 k vyřešení problému. Oprava 1 se nevyžaduje, pokud instalujete Azure DevOps Server 2022.2 poprvé od aktualizace odkazů ke stažení, aby zahrnovala opravu.

Azure DevOps Server 2022.2 RTW je souhrn oprav chyb. Zahrnuje všechny funkce v Azure DevOps Serveru 2022.2 RC, které byly vydány dříve. Můžete přímo nainstalovat Azure DevOps Server 2022.2 nebo upgradovat z Azure DevOps Serveru 2020, 2019 nebo Team Foundation Serveru 2015 nebo novějšího. V této verzi jsme vyřešili následující problémy a ohrožení zabezpečení:

Datum vydání Azure DevOps Serveru 2022 Update 2 RC: 7. května 2024

Azure DevOps Server 2022.2 RC obsahuje mnoho nových funkcí. Mezi nejzajímavější z nich patří:

Můžete také přejít na jednotlivé části a zobrazit všechny nové funkce pro každou službu:

General

Úloha pro publikování výsledků testu

Úloha Publikovat výsledky testu teď má podporu příloh testovacího spuštění ve formátu reportu JUnit.

Nová verze sady SDK webového rozšíření Azure DevOps

V této aktualizaci vydáváme novou verzi sady SDK webového rozšíření Azure DevOps. Klientská sada SDK umožňuje webovým rozšířením komunikovat s rámcem hostitele. Dá se použít k:

  • Upozorněte hostitele, že je rozšíření načtené nebo obsahuje chyby.
  • Získání základních kontextových informací o aktuální stránce (aktuální uživatel, informace o hostiteli a rozšíření)
  • Získání informací o motivu
  • Získání autorizačního tokenu pro použití v volání REST zpět do Azure DevOps
  • Získání vzdálených služeb nabízených hostitelským rámcem

Úplné referenční informace k rozhraní API najdete v dokumentaci k balíčku azure-devops-extension-sdk. Tato nová verze poskytuje podporu pro následující moduly:

  • Podpora modulů ES: Sada SDK teď kromě existujících modulů AMD (Asynchronní definice modulu) podporuje moduly ES (ECMAScript). Teď můžete importovat sadu SDK pomocí syntaxe modulu ES, která poskytuje vylepšení výkonu a snižuje velikost aplikace.

  • Zpětná kompatibilita modulů AMD: Stávající podpora modulů AMD zůstává nedotčená. Pokud váš projekt používá moduly AMD, můžete je dál používat stejně jako předtím bez jakýchkoli změn.

Jak používat:

Pro moduly ES můžete importovat naše moduly pomocí příkazu import:

import * as SDK from 'azure-devops-extension-sdk';
// Use the module here

Pokud používáte moduly AMD, můžete s importem sady SDK pokračovat pomocí funkce require.

require(['azure-devops-extension-sdk'], function(SDK) {

  // Use the module here
});

Boards

Omezení pro dráhy oblastí a iterací

Omezení hrají důležitou roli při udržování zdraví a efektivity velké globální služby. V této verzi zavádíme striktní limity 10 000 na jeden projekt pro cesty oblastí a iterací. Další informace o různých omezeních služby najdete na stránce sledování práce, procesu a projektu .

Snímky obrazovky oblastních a iterativních cest.

Ovládací prvky vývoje a nasazení

Z pracovní položky teď odebereme ovládací prvky Vývoj a/nebo Nasazení podle toho, jak je váš projekt nakonfigurovaný. Můžete například nakonfigurovat nastavení projektu tak, aby zakázala repozitáře a/nebo Pipelines.

Snímky obrazovky se službami DevOps

Když přejdete na pracovní položku, odpovídající ovládací prvky Vývoj a nasazení budou ve formuláři skryté.

Snímky obrazovky související práce

Pokud se rozhodnete připojit úložiště GitHub k Azure Boards, zobrazí se ovládací prvek Vývoj pro úložiště GitHub.

Snímky obrazovek ovládacího prvku pro vývoj

Repos

Nová "Zásada větve" brání uživatelům ve schválení vlastních změn

Abychom zlepšili kontrolu nad tím, jaké změny uživatel schválí a odpovídají přísnějším zákonným požadavkům nebo požadavkům na dodržování předpisů, poskytujeme možnost zabránit uživateli, aby schválil své vlastní změny, pokud to explicitně nepovolí.

Uživatel s oprávněním spravovat zásady větve nyní může přepnout nově přidanou možnost "Vyžadovat alespoň jedno schválení při každé iteraci" v sekci "Když jsou nové změny vloženy". Pokud je tato možnost vybraná, vyžaduje se aspoň jeden schvalovací hlas pro poslední změnu zdrojové větve. Schválení uživatele se nezapočítává do žádné předchozí neschválené iterace odeslané tímto uživatelem. V důsledku toho je potřeba provést další schválení poslední iterace jiným uživatelem.

Následující obrázek ukazuje žádost o přijetí změn vytvořenou uživatelem A a dalších 4 potvrzení (iterace) provedených pro tuto žádost o přijetí změn uživateli B, C, A a znovu a C. Po dokončení druhé iterace (potvrzení provedené uživatelem B) uživatel C to schválil. V té době to naznačovalo schválení prvního commitu uživatele A (při vytvoření pull requestu) a nově zavedená politika bude úspěšná. Po páté iteraci (poslední potvrzení uživatele C) bylo schválení provedeno uživatelem A. Toto znamenalo schválení pro dřívější potvrzení provedené uživatelem C, ale neznamenalo to schválení pro druhé potvrzení provedené uživatelem A ve čtvrté iteraci. Aby byla nově zavedená zásada úspěšná, musí být neschválená iterace čtyři schválena buď uživatelem B, C, nebo jiným uživatelem, který neprovedl žádnou změnu pull requestu.

Image správy oprávnění

Note

Existuje známý problém, kdy zásady větví berou v úvahu skupinu, která je nakonfigurovaná jako recenzent, jako subjekt schválení. Představme si, že existuje požadované schválení provedené libovolným uživatelem skupiny G. Uživatel A je členem této skupiny G. Jakmile uživatel A poskytne schválení jako na obrázku výše (po páté iteraci), schválení skupiny G schválí změnu provedenou uživatelem A. Toto není očekávané a bude vyřešeno ve verzi RTW.

Podpora filtrů bez blobů a stromových struktur

Important

Funkce je ve výchozím nastavení vypnutá. Pokud chcete tuto funkci povolit, spusťte v konfigurační databázi následující dotaz:

exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1

Azure DevOps teď podporuje dva další filtrování při klonování a načítání. Jedná se o: --filter=blob:none a --filter=tree:0 První možnost (klon bez objektů blob) je nejvhodnější pro běžný vývoj, zatímco druhá možnost (klon bez stromové struktury) se hodí lépe pro ty případy, kdy klon zahodíte, například po provedení sestavení.

ukončení podpory SSH-RSA

Azure Repos poskytuje uživatelům dva způsoby přístupu k úložišti Git v Azure Repos – HTTPS a SSH. Pokud chcete použít SSH, musíte vytvořit pár klíčů pomocí jedné z podporovaných metod šifrování. V minulosti jsme podporovali jenom SSH-RSA a požádali jsme uživatele, aby povolili SSH-RSA tady.

V této aktualizaci oznamujeme vyřazení SSH-RSA jako podporované metody šifrování pro připojení k Azure Repos pomocí SSH. Další podrobnosti najdete v blogovém příspěvku Na konci SSH-RSA podpory pro Azure Repos .

Pipelines

Zabránění nechtěným spuštěním potrubí

V současné době, pokud potrubí YAML neurčí trigger oddíl, spustí se pro všechny změny, které se odeslaly do úložiště. To může vést k nejasnostem, proč potrubí běželo a způsobit mnoho nechtěných spuštění.

Přidali jsme nastavení na úrovni kolekce projektů a pipeline na úrovni projektu s názvem Zakázat implicitní YAML CI trigger, které vám umožní toto chování změnit. Pokud chybí sekce spuštění, můžete se rozhodnout, že pipeline nespustíte.

Snímek obrazovky s triggerem YAML CI

Opakujte fázi, když vyprší časový limit pro schválení a kontroly.

Když vyprší časový limit schválení a kontroly, fáze, ke které patří, se přeskočí. Fáze, které mají závislost na přeskočené fázi, se také přeskočí.

Nyní můžete opakovat fázi, když vyprší časový limit schválení a kontroly. Dříve to bylo možné pouze v případě, že vypršel časový limit schválení.

Snímek obrazovky opakování fáze

Obejití schválení a kontrol

Schválení a kontroly pomáhají chránit přístup k důležitým prostředkům, jako jsou připojení služeb, úložiště nebo fondy agentů. Běžným případem použití je použití schválení a kontroly při nasazování do produkčního prostředí a chcete chránit připojení služby ARM.

Řekněme, že jste do připojení služby přidali následující kontroly: schválení, kontrola pracovní doby a kontrola vyvolání funkce Azure (pro vynucení zpoždění mezi různými oblastmi).

Teď si představte, že musíte provést nasazení hotfixu. Spustíte pipeline, ale nepokračuje; čeká na dokončení většiny kontrol. Nemůžete si dovolit čekat na dokončení schválení a kontrol.

Ve této verzi jsme umožnili obejít probíhající schvalování a kontroly, abyste mohli dokončit rychlou opravu.

Můžete obejít spouštění schvalování, pracovní doby, vyvolání funkce Azure Functions a volání kontrol rozhraní REST API.

Obejít schválení.

Snímek obrazovky obcházení schválení

Obejití kontroly pracovních hodin

Snímek obrazovky s kontrolou Vynechat pracovní dobu

Obejít kontrolu spuštění funkce Azure Function. Obejití kontroly pracovních hodin

Snímek obrazovky kontroly obejití vyvolání funkce Azure

Když se kontrola vynechá, zobrazí se na kontrolním panelu.

Snímek obrazovky s obejitím kontroly.

Kontrolu můžete obejít jenom v případě, že jste správcem prostředku, na kterém byly kontroly definovány.

Snímek obrazovky s požadovanou šablonou YAML

Znovu spustit kontroly funkcí Azure

Představte si, že systém nasadíte ve více fázích. Před nasazením druhé fáze probíhá základní kontrola, která zahrnuje schválení a vyvolání funkce Azure, na již nasazené části systému.

Při kontrole žádosti o schválení si všimnete, že kontrola správnosti byla spuštěna před dvěma dny. V tomto scénáři možná víte o jiném nasazení, které ovlivnilo výsledek základní kontroly.

V této aktualizaci můžete znovu spustit volání funkce Azure Functions a vyvolat kontroly rozhraní REST API. Tato funkce je dostupná jenom pro kontroly, které proběhly úspěšně a nemají žádné opakování.

Snímek obrazovky s dynamickou kontrolou

Note

Kontrolu můžete spustit znovu jenom v případě, že jste správcem prostředku, na kterém byly kontroly definovány.

Podpora podnikového serveru GitHubu v povinné kontrole šablon.

Šablony jsou bezpečnostní mechanismus, který vám umožní řídit fáze, úlohy a kroky pipeline v kolekci vašich projektů.

Kontrola Vyžadovat šablonu umožňuje vynutit, aby kanál vycházel ze sady schválených šablon dříve, než přistoupí k chráněnému prostředku, jako je například fond agentů nebo připojení služby.

Teď můžete zadat šablony umístěné v úložištích GitHub Enterprise Serveru.

Role správce pro všechna prostředí

Prostředí v kanálech YAML představují výpočetní prostředek, do kterého nasadíte aplikaci, například cluster AKS nebo sadu virtuálních počítačů. Poskytují vám bezpečnostní prvky a sledovatelnost vašich nasazení.

Správa prostředí může být poměrně náročná. Je to proto, že při vytvoření prostředí se osoba, která ho vytváří, automaticky stane jediným správcem. Pokud například chcete spravovat schvalování a kontroly všech prostředí centralizovaným způsobem, museli jste požádat každého správce prostředí, aby přidal konkrétního uživatele nebo skupinu jako správce a pak pomocí rozhraní REST API nakonfiguroval kontroly. Tento přístup je zdlouhavý, náchylný k chybám a neškáluje se efektivně, když se přidávají nová prostředí.

V této verzi jsme přidali roli správce na úrovni centra prostředí. Tím se prostředí dostanou na úroveň připojení ke službě nebo fondů agentů. Pokud chcete přiřadit roli Správce uživateli nebo skupině, musíte už být správcem centra prostředí nebo vlastníkem kolekce projektů.

Snímek obrazovky s rolí Správce

Uživatel s touto rolí správce může spravovat oprávnění, spravovat, zobrazovat a používat libovolné prostředí. To zahrnuje otevření prostředí pro všechny potrubí.

Když udělíte roli správce uživatele na úrovni centra prostředí, stanou se správci pro všechna stávající prostředí a pro všechna budoucí prostředí.

Vylepšené ověřování YAML

Pokud chcete ověřit správnost syntaxe YAML, můžete použít funkci Ověření webového editoru Azure Pipelines. Proto je důležité, aby tato funkce zachytila co nejvíce problémů YAML.

Snímek obrazovky s ověřováním YAML

Ověřování YAML je teď důkladnější, pokud jde o výrazy.

Při psaní kanálů YAML můžete pomocí funkcí definovat hodnoty proměnných.

Představte si, že definujete následující proměnné:

variables:
  Major: '1'
  Minor: '0'
  Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]

Proměnná Patch je definována pomocí funkce counter a dalších dvou proměnných. Ve výše uvedeném kódu YAML je slovo format chybně napsané. Tato chyba se dříve nezjištěla. Funkce Ověřit tuto funkci rozpozná a zobrazí chybovou zprávu.

Snímek obrazovky s zjištěnými nesprávnými definicemi proměnných

Azure Pipelines rozpozná nesprávné definice proměnných na úrovni kanálu nebo fáze nebo úlohy.

V kanálech YAML můžete přeskočit provádění fáze pomocí podmínek. Překlepy se můžou zobrazit i tady, například v následujícím příkladu.

steps:
- task: NuGetCommand@2
  condition: eq(variable.Patch, 0)
  inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

Úloha NuGetCommand se provede pouze v případě, že hodnota Patch proměnné je 0. V podmínce je opět překlep a funkce Ověřit ji zobrazí.

Snímek obrazovky s proměnnou Patch

Azure Pipelines rozpozná nesprávné podmínky YAML definované na úrovni kanálu nebo fáze nebo úlohy.

Rozhraní REST API pro prostředí

Prostředí je kolekce prostředků, na které můžete cílit pomocí nasazení z pipeline. Prostředí poskytují historii nasazení, sledovatelnost pracovních položek a commitů a mechanismy řízení přístupu.

Víme, že chcete prostředí vytvářet prostřednictvím kódu programu, takže jsme publikovali dokumentaci pro jejich rozhraní REST API.

Vylepšení REST API pro schválení

Vylepšili jsme vyhledání schválení přiřazených uživateli zahrnutím skupin, do nichž uživatel patří do výsledků hledání.

Schválení teď obsahují informace o spuštění linky, ke kterému patří.

Například následující volání GET REST API https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending vrátí

{
    "count": 1,
    "value":
    [
        {
            "id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
            "steps":
            [],
            "status": "pending",
            "createdOn": "2023-11-09T10:54:37.977Z",
            "lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers":
            [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
                }
            },
            "pipeline":
            {
                "owner":
                {
                    "_links":
                    {
                        "web":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
                        },
                        "self":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
                        }
                    },
                    "id": 73222930,
                    "name": "20231109.1"
                },
                "id": "4597",
                "name": "FabrikamFiber"
            }
        }
    ]
}

Protokoly pipeline nyní obsahují využití prostředků.

Protokoly kanálu Azure nyní mohou zaznamenávat metriky využití prostředků, jako je paměť, využití CPU a dostupné místo na disku. Protokoly také zahrnují prostředky používané agentem vytěžování a podřízenými procesy, včetně úloh spuštěných v rámci pracovního procesu.

Snímek obrazovky se záznamy, včetně prostředků používaných datovým kanálem

Pokud máte podezření, že vaše úloha kanálu může narazit na omezení prostředků, povolte podrobné protokoly , aby do protokolů kanálu byly vloženy informace o využití prostředků. Funguje to u jakéhokoli agenta nezávisle na modelu hostování.

Agent Azure Pipelines teď podporuje Alpine Linux.

Agent Pipeline v3.227 nyní podporuje Alpine Linux verze 3.13 a vyšší. Alpine Linux je oblíbeným základem pro kontejnery (base image). Agenta najdete na stránce releases. Alpine Linux verze agenta mají předponu vsts-agent-linux-musl , například vsts-agent-linux-musl-x64-3.227.1.tar.gz.

Úlohy Azure Pipelines používají Node 16

Úlohy ve zpracování se spouštějí pomocí spouštěcího modulu, přičemž ve většině případů se používá Node.js. Úlohy Azure Pipelines, které využívají Node jako spouštěč, teď všechny používají Node 16. Vzhledem k tomu, že Node 16 je první verzí Node, která nativně podporuje Apple Silicon, dokončí se také úplná podpora úloh pro macOS na čipu Apple. Agenti běžící na čipu Apple nepotřebují ke spuštění Rosetta.

Vzhledem k tomu, že datum konce životnosti uzlu 16 se přesunulo dopředu, začali jsme spouštět úkoly s Node 20.

Zvýšení limitů služby Azure Pipeline tak, aby odpovídalo maximální velikosti šablony Azure Resource Manageru (ARM) o 4 MB.

K vytvoření infrastruktury Azure můžete použít úlohu nasazení šablony Azure Resource Manageru . V reakci na vaši zpětnou vazbu jsme zvýšili limit integrace služby Azure Pipelines o 2 MB na 4 MB. To bude v souladu s maximální velikostí šablon ARM 4 MB, čímž se vyřeší omezení velikosti při integraci velkých šablon.

Úloha AzureRmWebAppDeployment podporuje ověřování ID Microsoft Entra

Úlohy AzureRmWebAppDeploymentV3 a AzureRmWebAppDeployment@4 byly aktualizovány tak, aby podporovaly službu App Service se zakázaným základním ověřováním. Pokud je ve službě App Service deaktivované základní ověřování, úlohy AzureRmWebAppDeploymentV3/4 používají ověřování Microsoft Entra ID pro nasazení na koncový bod Kudu ve službě App Service. To vyžaduje, aby byla v agentu nainstalovaná nedávná verze msdeploy.exe, což je případ agentů hostovaných ve Windows-2022/windows-latest (viz referenční informace k úloze).

Zakázáno změnit stav zásad pokrytí kódu na "selhání", pokud sestavení selhává.

Předchozí stav zásad pokrytí kódu byl přepsán na „Selhání“, pokud vaše sestavení v pull requestu nebylo úspěšné. To byla překážka pro některé z vás, kteří měli sestavení jako volitelnou kontrolu a zásady pokrytí kódu jako povinnou kontrolu pro žádosti o přijetí změn, což vedlo k jejich zablokování.

Snímek obrazovky blokovaných pull requestů

Nyní se zásada pokrytí kódu nepřepíše jako selhaná, pokud sestavení selže. Tato funkce bude povolená pro všechny zákazníky.

Snímek obrazovky s výsledky po změně

Artifacts

Představení podpory Azure Artifacts pro Cargo Crates

S radostí oznamujeme, že Azure Artifacts teď nabízí nativní podporu pro nákladové bedny. Tato podpora zahrnuje paritu funkcí vzhledem k našim stávajícím protokolům, navíc je crates.io k dispozici jako nadřazený zdroj. Vývojáři a týmy Rustu nyní mohou bez problémů využívat, publikovat, spravovat a sdílet své Cargo balíčky, přičemž využívají robustní infrastrukturu Azure a zůstávají ve známém prostředí Azure DevOps.

Oznámení o ukončení podpory úloh v kanálu NuGet Restore v1 a NuGet Installer v0

Pokud používáte úlohy kanálu NuGet Restore v1 a NuGet Installer v0, okamžitě přejděte na úlohu kanálu NuGetCommand@2. Pokud k přechodu nedošlo, začnete ve svých potrubích brzy dostávat upozornění. Pokud se neprovede žádná akce, od 27. listopadu 2023 dojde k selhání sestavení.

Podpora Azure Artifacts pro audit npm

Azure Artifacts teď podporuje npm audit a npm audit fix příkazy. Tato funkce umožňuje uživatelům analyzovat a opravit ohrožení zabezpečení projektu automatickou aktualizací nezabezpečených verzí balíčků. Další informace najdete v nástroji Npm Audit k detekci a opravě ohrožení zabezpečení balíčků.

Reporting

Nové rozhraní adresáře řídicího panelu

Naslouchali jsme vašim názorům a s nadšením vám představujeme novou zážitkovou verzi adresáře Řídicího panelu. Nabízí nejen moderní návrh uživatelského rozhraní, ale také umožňuje řadit podle jednotlivých sloupců s přidáním sloupce Poslední konfigurace . Tento sloupec vám poskytne lepší přehled o celkovém využití řídicího panelu v rámci kolekce projektů. Kromě toho teď můžete filtrovat podle řídicích panelů na úrovni týmu nebo projektu, abyste měli přístup jenom k seznamu toho, co potřebujete vidět, a přitom skrýt řídicí panely, které nechcete zobrazit.

Gif pro ukázku nového adresáře řídicího panelu

Vyzkoušejte to teď a dejte nám vědět, co si myslíte v naší komunitě Azure DevOps

Filtrování pracovních položek

S radostí oznamujeme filtrování grafu pracovních položek. Tato funkce vám umožní najet myší na graf pracovních položek pro rychlý přehled a přejít k podrobnostem o konkrétních segmentech grafu pro podrobné přehledy. Už nemusíte vytvářet vlastní dotazy pro přístup k přesné části dat, která potřebujete. V grafech pracovních položek se teď můžete několika kliknutími ponořit do pracovních položek.

Gif pro ukázkové filtrování pracovních položek

Vaše zpětná vazba je neocenitelná při formování budoucnosti této funkce. Vyzkoušejte to teď a dejte nám vědět, co si myslíte v naší komunitě Azure DevOps.

Výsledky pokrytí kódu pro složky

Výsledky pokrytí kódu jsou nyní k dispozici pro každý jednotlivý soubor a složku, nikoli pouze jako číslo nejvyšší úrovně. Zobrazení pokrytí kódu se objeví, když je přepínač režimu zobrazení složky aktivován. V tomto režimu můžete přejít k podrobnostem a zobrazit pokrytí kódu pro vybraný podstrom. Pomocí přepínače můžete přepínat mezi novými a starými zobrazeními.

Widget s více úložišti pro obecnou dostupnost

Test Plans

Rychlé kopírování a import pomocí ID testovacího plánu nebo sady

V azure Test Plans teď můžete snadno zpracovat více testovacích plánů. Rozpoznali jsme problémy, se kterými jste se dříve setkávali s dlouhými rozevíracími nabídkami pro tyto operace jako je import, kopírování nebo klonování testovacích případů, zejména u rozsáhlých plánů nebo sad, a proto jsme provedli kroky ke zjednodušení vašeho pracovního postupu.

S radostí oznamujeme funkci vyhledávání podle ID testovacího plánu a sady. Zadejte ID testovacího plánu nebo sady pro rychlý import nebo kopírování testovacích případů bez jakýchkoli zpoždění. Tato aktualizace je součástí našeho průběžného závazku ke zlepšení vašeho zážitku ze správy testů, čímž ho činí intuitivnějším a méně časově náročným.

Gif pro ukázku testovacího plánu, podrobnosti hledání ID sady

Aktualizace pro Azure Test Runner

S radostí oznamujeme, že Azure Test Runner byl aktualizován na novější verzi. Tato aktualizace zlepšuje stabilitu a výkon a umožňuje spouštět testy bez přerušení nebo zpoždění. Starší verze Azure Test Runneru se už nepodporuje. Pokud chcete dosáhnout co nejlepšího výkonu a spolehlivosti testovacích operací, doporučujeme, abyste co nejdříve aktualizovali nejnovější verzi.

Co je nového?

  • Vylepšená stabilita a výkon: Výrazně jsme vylepšili Test Runner a řešili problémy, ke kterým došlo u některých uživatelů. Tento upgrade zajišťuje spolehlivější proces testování, který minimalizuje přerušení vaší práce.
  • Výzva k upgradu: Pokud chcete přechod na novou verzi bezproblémově provést, zobrazí se výzva k upgradu. Tím zajistíte, že všichni budou moct snadno přejít na vylepšenou verzi a zvýšit tak kompatibilitu a výkon.

Snímky obrazovky s výzvou k upgradu

Feedback

Rádi uslyšíme váš názor! Můžete nahlásit problém nebo poskytnout nápad a sledovat ho prostřednictvím komunity vývojářů a získat rady o Stack Overflow.

Začátek stránky
  • Last updated on