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

---

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

---

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í opravy 4 pro Azure DevOps Server 2022 Update 2: 11. března 2025

Soubor	Hash SHA-256
devops2022.2patch4	975B0FC28737C15BA40D6E084663D1A735A6FA821EB40C7A377AE3D58F0C7DA

Vydali jsme Patch 4 pro Azure DevOps Server 2022 Update 2, aby zahrnoval:

• Aktualizace úkolů kvůli zrušení Edgio CDN. Další podrobnosti najdete v blogovém příspěvku Přepnutí poskytovatelů CDN.
• Závislost Mermaid byla upgradována

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

Poznámka:

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ářů .

Soubor	Hash SHA-256
devops2022.2patch3	F5C2DA846B8A38A1FB55D1EB555FB2FD6B974B0436F573CC01A0FEBAF3D67521

Vydali jsme Patch 3 pro Azure DevOps Server 2022 Update 2, aby zahrnoval:

• Aktualizace v artefaktech pro přidání návrhu vylepšení Pythonu (PEP) 685. Tato aktualizace řeší zpětnou vazbu sdílenou v komunitě vývojářů .

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

Soubor	Hash SHA-256
devops2022.2patch2.exe	70930BE091607B490890A48C250DAB6C2087F7F610CC695C9C632C679A491D23

Vydali jsme Patch 2 pro Azure DevOps Server 2022 Update 2, který zahrnuje upgrade na zranitelnou závislost.

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

Shrnutí novinek v Azure DevOps Serveru 2022.2 RTW

Poznámka:

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 blogovém příspěvku Azure DevOps Server 2022.2 RTW now available. Pokud jste nainstalovali verzi Azure DevOps Serveru 2022.2 vydanou 9. července, můžete problém vyřešit instalací Záplaty 1 pro Azure DevOps Server 2022.2. 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 kompilací 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í:

• CVE-2024-35266: Ohrožení zabezpečení z hlediska falšování identity serveru Azure DevOps
• CVE-2024-35267: Ohrožení zabezpečení z hlediska falšování identity serveru Azure DevOps
• Lístek zpětné vazby komunity vývojářů: Verze agenta se po upgradu na Azure DevOps Server 2022.1 a použití agenta aktualizace v konfiguraci fondu agentů neaktualizuje
• Lístek zpětné vazby komunity vývojářů: Problém s načtením stránky konfigurace týmu
• Lístek zpětné vazby z komunity vývojářů: Oprava nesprávného zpracování data v e-mailových oznámeních o pull requestech pro určité regionální formáty

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ří:

• Omezení pro oblasti a cesty iterací
• Obcházení schválení a kontrol v pipelinech
• Vylepšené ověřování YAML
• Podpora Azure Artifacts pro Cargo Crates
• Nové prostředí adresáře řídicího panelu
• Rychlé kopírování a import pomocí ID testovacího plánu nebo sady testů

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

• Obecné
• Panely
• Repos
• Pipelines
• Artefakty
• Reportování

---

OBECNÉ

Ú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 pro moduly 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
});

Tabule

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 .

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.

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

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

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ě předpokládá schválení prvního potvrzení uživatele A (při vytvoření žádosti o přijetí změn) a nově zavedená zásada 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.

Poznámka:

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

Důležité

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í. Toto jsou: --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 pouze SSH-RSA a požádali jsme uživatele, aby zde povolili SSH-RSA.

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 o ukončení podpory SSH-RSA pro Azure Repos .

Potrubí

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í pro kolekci projektů a úroveň projektových kanálů s názvem Zakázat implicitní YAML spouštěč CI, které umožňuje toto chování změnit. Pokud chybí sekce spuštění, můžete se rozhodnout, že pipeline nespustíte.

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í.

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í.

Obejití kontroly pracovních hodin

Obejít kontrolu funkce Azure Functions. Obejití kontroly pracovních hodin

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

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

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í.

Poznámka:

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 požadované kontrole šablony

Šablony jsou mechanismus zabezpečení, který umožňuje řídit fáze, úlohy a kroky potrubí ve vaší kolekci projektů.

Funkce Vyžadovat kontrolu šablon umožňuje vynutit, aby pipeline vycházel ze sady schválených šablon před přístupem k chráněnému zdroji, 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ů.

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.

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.

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í.

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 soubor prostředků, na které můžete cílit nasazování z kanálu. Prostředí poskytují historii nasazení, sledovatelnost pracovních položek a potvrzení 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.

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

Agent Azure Pipelines teď podporuje Alpine Linux.

Agent Pipeline v3.227 teď 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 Node 16 se posunulo dopředu, začali jsme pracovat na spouštění úkolů 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 odpovídat maximální velikosti šablon ARM 4 MB při řešení omezení velikosti během integrace 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 zakázané základní ověřování, úlohy AzureRmWebAppDeploymentV3/4 používají ověřování Microsoft Entra ID k provádění nasazení do koncového bodu Kudu služby App Service. To vyžaduje nedávnou verzi msdeploy.exe nainstalovanou na agentovi, což je zajištěno u agentů Hostovaných agentů windows-2022/windows-latest (viz referenční informace k úlohám).

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í.

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.

Artefakty

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ů.

Reportování

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.

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.

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ě. Pohled na pokrytí kódu se zobrazí, když je zapnuto tlačítko Režim zobrazení složek. 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.

Testovací plány

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.

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.

---

Názory

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.

---

Na začátek stránky