Zpráva k vydání verze pro Azure DevOps Server 2022 Update 2
| Požadavky komunity | vývojářů na systém a licenční podmínky | kompatibility | DevOps Blog | SHA-256 hash |
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í 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 k Azure DevOps Serveru 2022.2 RTW. Pokud jste nainstalovali verzi Azure DevOps Serveru 2022.2 vydané 9. července, můžete problém vyřešit instalací 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 představuje opravy 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 komunity vývojářů: Oprava nesprávného zpracování dat v e-mailových oznámeních o přijetí změn 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 cesty oblastí a iterací
- Obcházení schválení a kontrol v kanálech
- 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 s ID testovacího plánu nebo sady
Můžete také přejít na jednotlivé části a zobrazit všechny nové funkce pro každou službu:
OBECNÉ
Publikování úlohy výsledky testu
Úloha Publikovat výsledky testu teď podporuje přílohy testovacího spuštění pro formát sestavy 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 rámcem hostitele
Ú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 pokračovat v importu require sady SDK pomocí funkce:
require(['azure-devops-extension-sdk'], function(SDK) {
// Use the module here
});
Boards
Omezení pro cesty 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 pevné limity 10 000 na jeden projekt pro cesty oblastí i iterace. 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 vypnula úložiště a kanály.
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ásady větve, které uživatelům brání 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 možností spravovat zásady větve teď může přepnout nově přidanou možnost Vyžadovat alespoň jedno schválení při každé iteraci v části Při vložení nových změn. 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 předpokládané schválení pro dřívější potvrzení provedené uživatelem C, ale nebylo to znamenat 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áleny buď schválením uživatele B, C, nebo jiným uživatelem, který neproveděl žádnou změnu žádosti o přijetí změn.
Poznámka:
Existuje známý problém, kdy zásady větví převedou skupinu, která je nakonfigurovaná jako kontrolor, jako schvalovací entita. 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 objektů blob a bez stromové struktury
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 spuštění sestavení.
Vyřazení 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 .
Pipelines
Zabránění nechtěným spuštěním kanálu
V současné době platí, že pokud kanál YAML neurčí trigger oddíl, spustí se pro všechny změny, které se nasdílely do svého úložiště. To může vést k nejasnostem, proč kanál běžel a vést k mnoha nechtěným spuštěním.
Přidali jsme nastavení shromažďování projektů a kanálů na úrovni projektu s názvem Zakázat implicitní trigger CIML, který umožňuje toto chování změnit. Pokud oddíl triggeru chybí, můžete se rozhodnout neaktivovat kanály.
Opakování fáze při vypršení časového limitu schválení a kontroly
Když vyprší časový limit schválení a kontroly, fáze, do které patří, se přeskočí. Fáze, které mají závislost na přeskočené fázi, se také přeskočí.
Teď můžete zkusit fázi zopakovat, když schválení a časový limit kontroly vyprší. 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í oprav hotfix. Spustíte spuštění kanálu, ale nepokračuje, čeká na dokončení většiny kontrol. Nemůžete si dovolit čekat na dokončení schválení a kontrol.
V této verzi jsme umožnili obejít spouštění schválení a kontroly, abyste mohli dokončit opravu hotfix.
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 vyvolání kontrol funkce Azure
Představte si, že systém nasadíte ve více fázích. Před nasazením druhé fáze existuje kontrola schválení a vyvolání funkce Azure Functions, která spustí kontrolu sanity u již nasazené části systému.
Při kontrole žádosti o schválení si všimnete, že kontrola sanity se spustila před dvěma dny. V tomto scénáři možná znáte jiné nasazení, které ovlivnilo výsledek kontroly sanity.
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 kanálů v kolekci projektů.
Kontrola Vyžadovat šablonu umožňuje vynutit, aby se kanál rozšířil ze sady schválených šablon před přístupem 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 při přidání nových prostředí se škáluje.
V této verzi jsme přidali roli správce na úrovni centra prostředí. Tím se prostředí parsuje s připojeními služeb nebo fondy 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írání prostředí pro všechny kanály.
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 counter pomocí funkce 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 kolekce prostředků, na které můžete cílit s nasazeními 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í rozhraní REST API 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í kanálu, do které patří.
Například následující volání https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending rozhraní GET REST API 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 kanálu teď obsahují využití prostředků.
Protokoly kanálu Azure teď můžou zaznamenávat metriky využití prostředků, jako je paměť, využití procesoru a dostupné místo na disku. Protokoly také zahrnují prostředky používané agentem kanálu a podřízenými procesy, včetně úloh spuštěných v úloze.
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 kanálu v3.227 teď podporuje Alpine Linux verze 3.13 a vyšší. Alpine Linux je oblíbenou imagí kontejneru (base). Agenta najdete na stránce vydaných verzí . 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 v kanálu se spouštějí pomocí spouštěče s Node.js ve většině případů. Ú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 o velikosti 4 MB 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 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 v agentu, což je případ agentů windows-2022/windows-latest hostovaných agentů (viz referenční informace k úloze).
Zakázané přepsání stavu zásad pokrytí kódu na selhání při selhání sestavení
Dříve se stav zásad pokrytí kódu přepsal na Selhání, pokud se vaše sestavení v žádosti o přijetí změn nezdařilo. To byl blokovač pro některé z vás, kteří měli sestavení jako volitelnou kontrolu a zásady pokrytí kódu jako povinná kontrola žádostí o přijetí změn, což vede k zablokování žádostí o přijetí změn.
Teď se zásada pokrytí kódu nepřepíše na selhání, pokud sestavení selže. Tato funkce bude povolená pro všechny zákazníky.
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í s ohledem na naše stávající protokoly, kromě toho, že crates.io k dispozici jako nadřazený zdroj. Vývojáři a týmy Rustu teď můžou bez problémů využívat, publikovat, spravovat a sdílet své nákladové bedny a využívat robustní infrastrukturu Azure a zůstat ve známém prostředí Azure DevOps.
Oznámení o vyřazení pro úlohy 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 v kanálech 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ů.
Sestavy
Nové prostředí adresáře řídicího panelu
Naslouchali jsme vašim názorům a rádi vám představíme nové prostředí 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ě. Zobrazení pokrytí kódu se zobrazí, když je přepínač režimu zobrazení složky. 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.
Test Plans
Rychlé kopírování a import s ID testovacího plánu nebo sady
V azure Test Plans teď můžete snadno zpracovat více testovacích plánů. Když rozpoznáme problémy, se kterými jste se dříve setkávali s dlouhými rozevíracími nabídkami pro import, kopírování nebo klonování testovacích případů , zejména u rozsáhlých plánů nebo sad, provedli jsme kroky ke zjednodušení pracovního postupu.
S radostí oznamujeme funkci Vyhledávání 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í prostředí pro správu testů, což zvyšuje intuitivnější a méně časově náročné prostředí.
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.