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

---

| 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 1 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í 1 opravy 4 pro Azure DevOps Server 2022 Update 4: 11. června 2024

Soubor	Hodnota hash SHA-256
devops2022.1patch4.exe	29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F

Vydali jsme opravu 4 pro Azure DevOps Server 2022 Update 1, která obsahuje opravu pro následující:

• Opravili jsme problém ve wikiwebu a pracovních položkách, kdy výsledky hledání nebyly k dispozici pro projekty s turečtinou "I" v názvu tureckého národního prostředí.

Datum vydání 1 opravy 3 pro Azure DevOps Server 2022 Update 3: 12. března 2024

Soubor	Hodnota hash SHA-256
devops2022.1patch3.exe	E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

Vydali jsme opravu 3 pro Azure DevOps Server 2022 Update 1, která obsahuje opravy pro následující:

• Vyřešili jsme problém, kdy po instalaci opravy 2 přestal fungovat proxy server.
• Opravili jsme problém s vykreslováním na stránce podrobností o rozšíření, které ovlivnily jazyky, které nebyly angličtinou.

Datum vydání aktualizace 1 opravy 2 Pro Azure DevOps Server 2022: 13. února 2024

Soubor	Hodnota hash SHA-256
devops2022.1patch2.exe	59B3191E86DB787F91FD196654DE580CA97F06BA9CCB1D747D41A2317A5441

Vydali jsme opravu 2 pro Azure DevOps Server 2022 Update 1, která obsahuje opravy pro následující:

• Oprava problému s vykreslováním stránky podrobností u rozšíření vyhledávání
• Opravili jsme chybu, kdy se nesprávně vypočítalo místo na disku používané složkou mezipaměti proxy serveru a složka nebyla správně vyčištěna.
• CVE-2024-20667: Ohrožení zabezpečení spočívající ve vzdáleném spuštění kódu v Azure DevOps Serveru

Datum vydání Aktualizace 1 1 opravy 1 Azure DevOps Serveru 2022: 12. prosince 2023

Soubor	Hodnota hash SHA-256
devops2022.1patch1.exe	9D0FDCCD1F20461E586689B756E60CC16424018A3377042F7DC3A6EEF096FB6

Vydali jsme opravu 1 pro Azure DevOps Server 2022 Update 1, která obsahuje opravy pro následující:

• Zabránit nastavení při zatěžování requested for spuštění kanálu.

Datum vydání Azure DevOps Serveru 2022 Update 1: 28. listopadu 2023

Poznámka:

V této verzi jsou dva známé problémy:

1. Verze agenta se po upgradu na Azure DevOps Server 2022.1 a pomocí agenta update agenta v konfiguraci fondu agentů neaktualizuje. V současné době pracujeme na opravě pro vyřešení tohoto problému a budeme sdílet aktualizace v komunitě vývojářů, jak budeme postupovat. Mezitím najdete alternativní řešení pro tento problém v tomto lístku komunity vývojářů.
2. Kompatibilita Maven 3.9.x Maven 3.9.x zavedl zásadní změny se službou Azure Artifacts aktualizací výchozího přenosu Překladače Mavenu do nativního http z vozu. To způsobuje problémy s ověřováním 401 pro zákazníky, kteří používají protokol HTTP místo https. Další podrobnosti o tomto problému najdete tady. Jako alternativní řešení můžete i nadále používat Maven 3.9.x s vlastností -Dmaven.resolver.transport=wagon. Tato změna vynutí Maven používat transport vagónu Resolver. Další podrobnosti najdete v dokumentaci.

Azure DevOps Server 2022.1 je součástí oprav chyb. Zahrnuje všechny funkce v Azure DevOps Serveru 2022.1 RC2, které byly vydány dříve.

Poznámka:

Existuje známý problém s kompatibilitou Maven 3.9.x. Maven 3.9.x zavedl zásadní změny se službou Azure Artifacts aktualizací výchozího přenosu Překladače Mavenu do nativního http z vozu. To způsobuje problémy s ověřováním 401 pro zákazníky, kteří používají protokol HTTP místo https. Další podrobnosti o tomto problému najdete tady.

Jako alternativní řešení můžete i nadále používat Maven 3.9.x s vlastností -Dmaven.resolver.transport=wagon. Tato změna vynutí Maven používat transport vagónu Resolver. Další podrobnosti najdete v dokumentaci.

Datum vydání Azure DevOps Serveru 2022 Update 1 RC2: 31. října 2023

Azure DevOps Server 2022.1 RC2 představuje opravy chyb. Zahrnuje všechny funkce v Azure DevOps Serveru 2022.1 RC1 dříve vydaném.

Poznámka:

Existuje známý problém s kompatibilitou Maven 3.9.x. Maven 3.9.x zavedl zásadní změny se službou Azure Artifacts aktualizací výchozího přenosu Překladače Mavenu do nativního http z vozu. To způsobuje problémy s ověřováním 401 pro zákazníky, kteří používají protokol HTTP místo https. Další podrobnosti o tomto problému najdete tady.

Jako alternativní řešení můžete i nadále používat Maven 3.9.x s vlastností -Dmaven.resolver.transport=wagon. Tato změna vynutí Maven používat transport vagónu Resolver. Další podrobnosti najdete v dokumentaci.

V této verzi jsme opravili následující:

• Opravili jsme problém v místních informačních kanálech, kdy upstreamové položky nepřeložily změny zobrazovaného názvu.
• Při přepínání karet z kódu na jinou kartu na stránce Hledání došlo k neočekávané chybě.
• Při vytváření nového typu pracovní položky s jednotnými ideografii v čínštině, japonštině a korejštině (CJK) došlo k chybě. Při vráteném vrácení se změnami se zobrazila otazník, když název projektu týmu nebo soubory zahrnovaly CJK.
• Opravili jsme problém při instalaci vyhledávání, kdy virtuální počítač Java Virtual Machine (JVM) nemohl přidělit dostatek paměti procesu elastického vyhledávání. Widget konfigurace vyhledávání teď bude používat sadu Java Development Kit (JDK), která je součástí elastického vyhledávání, a proto odebere závislost na jakémkoli prostředí Java Runtime Environment (JRE) předinstalovaném na cílovém serveru.

Datum vydání Azure DevOps Serveru 2022 Update 1 RC1: 19. září 2023

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

• Všechna veřejná rozhraní REST API podporují podrobné obory PAT.
• Poslední přístupný sloupec na stránce Delivery Plans (Plány doručení)
• Vizualizace všech závislostí ve službě Delivery Plans
• @CurrentIteration makro v Plánech doručení
• Aktuální projekt nastavený jako výchozí obor pro přístupový token sestavení v klasických kanálech
• Zobrazit nadřazený prvek ve widgetu výsledků dotazu
• Kopírovat řídicí panel
• Podpora dalších typů diagramů na stránkách wikiwebu
• Připojení služby Container Registry teď můžou používat spravované identity Azure.

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
• Sestavy
• Wiki

---

OBECNÉ

Všechna veřejná rozhraní REST API podporují podrobné obory PAT.

V minulosti nebylo k rozsahům (např. čtení pracovní položky) přidruženo několik veřejně zdokumentovaných rozhraní REST API Azure DevOps, která vedla k využívání těchto rozhraní API prostřednictvím neinteraktivních ověřovacích mechanismů, jako jsou tokeny PAT (Personal Access Token). Použití tokenu pat pat s úplným rozsahem zvyšuje riziko, když se dostanou do rukou škodlivého uživatele. To je jeden z hlavních důvodů, proč mnoho našich zákazníků nevyužilo plné výhody zásad řídicí roviny k omezení používání a chování PAT.

Teď jsou všechna veřejná rozhraní REST API Azure DevOps přidružená a podporují podrobný obor PAT. Pokud aktuálně používáte plně vymezený token PAT k ověření u některého z veřejných rozhraní REST API Azure DevOps, zvažte migraci na pat s konkrétním oborem, který rozhraní API přijalo, abyste se vyhnuli zbytečnému přístupu. Podporované podrobné obory PAT pro dané rozhraní REST API najdete v části Zabezpečení na stránkách dokumentace. Kromě toho zde existuje tabulka oborů.

Rozšíření by měla zobrazit jejich obory.

Při instalaci rozšíření kolekce Azure DevOps můžete zkontrolovat oprávnění, která rozšíření potřebuje v rámci instalace. Po instalaci se ale oprávnění rozšíření v nastavení rozšíření nezobrazují. To představuje výzvu pro správce, kteří potřebují provádět pravidelnou kontrolu nainstalovaných rozšíření. Teď jsme do nastavení rozšíření přidali oprávnění rozšíření, která vám pomůžou zkontrolovat a přijmout informované rozhodnutí o tom, jestli je chcete zachovat nebo ne.

Boards

Poslední přístupný sloupec na stránce Delivery Plans (Plány doručení)

Na stránce adresáře Delivery Plans najdete seznam plánů definovaných pro váš projekt. Můžete řadit podle názvu, vytvořeného uživatelem, popisem, naposledy nakonfigurovanými nebo oblíbenými položkami. V této aktualizaci jsme na stránku adresáře přidali sloupec Poslední přístup. To poskytuje přehled o tom, kdy byl plán doručení naposledy otevřen a podíval se na ně. V důsledku toho je snadné identifikovat plány, které se už nepoužívají, a je možné je odstranit.

Vizualizace všech závislostí ve službě Delivery Plans

Plány doručení vždy poskytují možnost zobrazit závislosti napříč pracovními položkami. Můžete vizualizovat čáry závislostí, jednu po druhé. V této verzi jsme vylepšili prostředí tím, že vám umožní zobrazit všechny závislosti napříč všemi pracovními položkami na obrazovce. Jednoduše klikněte na přepínač závislostí v pravém horním rohu vašeho plánu doručení. Dalším kliknutím řádky vypnete.

Omezení revizí nových pracovních položek

V posledních několika letech jsme viděli kolekce projektů s automatizovanými nástroji, které generují desítky tisíc revizí pracovních položek. To vytváří problémy s výkonem a použitelností ve formuláři pracovní položky a rozhraních REST API pro vytváření sestav. Abychom tento problém zmírnit, implementovali jsme do služby Azure DevOps limit revize pracovních položek 10 000. Limit má vliv jenom na aktualizace pomocí rozhraní REST API, nikoli formuláře pracovní položky.

Kliknutím sem získáte další informace o limitu revize a o tom, jak ho zpracovat v automatizovaných nástrojích.

Zvýšení limitu týmu pro doručování z 15 na 20

Plány doručení umožňují zobrazit více backlogů a více týmů v kolekci projektů. Dříve jste mohli zobrazit 15 týmových backlogů, včetně kombinace backlogů a týmů z různých projektů. V této verzi jsme zvýšili maximální limit z 15 na 20.

Oprava chyby při vytváření sestav odkazů na pracovní položky – Získání rozhraní API

Opravili jsme chybu v rozhraní API pro získání odkazů pracovních položek pro generování sestav, která vrátila správnou hodnotu remoteUrl pro System.LinkTypes.Remote.Related typy propojení. Před touto opravou jsme vrátili nesprávný název kolekce projektů a chybějící ID projektu.

Vytvoření dočasného koncového bodu REST dotazu

Viděli jsme několik instancí autorů rozšíření, kteří se pokoušejí spustit neuložené dotazy předáním příkazu WIQL (Work Item Query Language) prostřednictvím řetězce dotazu. To funguje správně, pokud nemáte velký příkaz WIQL, který dosáhne limitů prohlížeče na délku řetězce dotazu. Abychom to vyřešili, vytvořili jsme nový koncový bod REST, který autorům nástrojů umožní vygenerovat dočasný dotaz. Použití ID z odpovědi k předání prostřednictvím řetězce dotazu eliminuje tento problém.

Další informace najdete na stránce dokumentace k rozhraní REST API pro dočasné dotazy.

Rozhraní API pro dávkové odstranění

V současné době je jediným způsobem, jak odebrat pracovní položky z koše, pomocí tohoto rozhraní REST API odstranit po jednom. Může to být pomalý proces a při pokusu o vyčištění hmoty se může omezit rychlost. V reakci jsme přidali nový koncový bod rozhraní REST API pro odstranění a/nebo zničení pracovních položek v dávce.

@CurrentIteration makro v Plánech doručení

V této aktualizaci jsme přidali podporu @CurrentIteration makra pro styly v Plánech doručení. Toto makro vám umožní získat aktuální iteraci z týmového kontextu každého řádku v plánu.

Logika změny velikosti karet v Delivery Plans

Ne všichni používají cílové datum nebo počáteční datum při sledování funkcí a námětů. Některé se rozhodnou použít kombinaci kalendářních dat a cesty iterace. V této verzi jsme vylepšili logiku, která odpovídajícím způsobem nastavila kombinaci cest iterace a polí kalendářních dat v závislosti na tom, jak se používají.

Pokud například cílové datum nepoužíváte a změníte velikost karty, nastaví se nová cesta iterace místo aktualizace cílového data.

Vylepšení dávkové aktualizace

Provedli jsme několik změn ve verzi 7.1 rozhraní API pro dávkové aktualizace pracovních položek. Patří mezi ně menší vylepšení výkonu a zpracování částečných selhání. To znamená, že pokud jedna oprava selže, ale ostatní ne, ostatní se úspěšně dokončí.

Kliknutím sem získáte další informace o rozhraní REST API pro dávkové aktualizace.

Rozhraní API pro dávkové odstranění

Tento nový koncový bod rozhraní REST API pro odstranění nebo zničení pracovních položek v dávce je teď veřejně dostupný. Další informace získáte po kliknutí sem.

Zabránit úpravám polí rozevíracích seznamů, které se dají sdílet

Vlastní pole se sdílí napříč procesy. To může způsobit problém s poli rozevíracího seznamu, protože správcům procesů umožňujeme přidávat nebo odebírat hodnoty z pole. Když to uděláte, změny ovlivní toto pole u každého procesu, který ho používá.

Abychom tento problém vyřešili, přidali jsme pro správce kolekce možnost "uzamknout" pole, které se upravuje. Pokud je pole rozevíracího seznamu uzamčeno, správce místního procesu nemůže změnit hodnoty tohoto rozevíracího seznamu. Můžou přidávat nebo odebírat pouze pole z procesu.

Nové oprávnění k ukládání komentářů

Možnost ukládat jenom komentáře pracovních položek byla nejvyšší žádostí v komunitě vývojářů. S radostí vám oznamujeme, že jsme tuto funkci implementovali. Začněme tím, že se podíváme na nejběžnější scénář:

"Chci některým uživatelům zabránit v úpravách polí pracovních položek, ale umožnit jim přispívat do diskuze."

Abyste toho dosáhli, musíte přejít do oblasti konfigurace > projektu nastavení > projektu. Potom vyberte vybranou cestu oblasti a klikněte na položku Zabezpečení.

Všimněte si nového oprávnění Upravit komentáře pracovních položek v tomto uzlu. Ve výchozím nastavení je oprávnění nastaveno na Nenastavit. To znamená, že se pracovní položka bude chovat stejně jako předtím. Pokud chcete skupině nebo uživatelům povolit ukládání komentářů, vyberte tuto skupinu nebo uživatele a změňte oprávnění Povolit.

Když uživatel otevře formulář pracovní položky v této cestě oblasti, bude moct přidávat komentáře, ale nemůže aktualizovat žádná další pole.

Doufáme, že tuto funkci milujete stejně jako my. Jako vždy, pokud máte nějaké připomínky nebo návrhy, dejte nám prosím vědět.

Interaktivní panely – sestavy

Interaktivní sestavy umístěné v centru Boards jsou v naší hostované verzi produktu přístupné několik let. Nahradí starší diagram kumulativního toku, rychlost a grafy Burndown sprintu. V této verzi je zpřístupňujeme.

Pokud chcete tyto grafy zobrazit, klikněte na umístění karty Analýza na stránkách Kanban Board, Backlog a Sprints.

Repos

Odebrání oprávnění k úpravám zásad pro tvůrce větví

Dříve, když jste vytvořili novou větev, máte udělená oprávnění k úpravám zásad v této větvi. V této aktualizacíměníme výchozí chování tak, aby se tato oprávnění neudělovala, i když je pro úložiště zapnuté nastavení Správa oprávnění.

Budete potřebovat oprávnění „Upravit zásady“ udělené explicitně (ručně nebo prostřednictvím rozhraní REST API) dědičností oprávnění zabezpečení nebo členstvím ve skupině.

Pipelines

Aktuální projekt nastavený jako výchozí obor pro přístupový token sestavení v klasických kanálech

Azure Pipelines používá tokeny přístupu k úlohám pro přístup k dalším prostředkům v Azure DevOps za běhu. Přístupový token úlohy je bezpečnostní token, který je dynamicky generován službou Azure Pipelines pro každou úlohu za běhu. Dříve při vytváření nových klasických kanálů byla výchozí hodnota přístupového tokenu nastavena na kolekci projektů. Při této aktualizaci nastavujeme obor autorizace úloh na aktuální projekt jako výchozí při vytváření nového klasického kanálu.

Další podrobnosti o přístupových tokenech úloh najdete v dokumentaci k úložištím, artefaktům a dalším prostředkům Accessu.

Změna výchozího rozsahu přístupových tokenů v klasických kanálech buildu

Pokud chcete zlepšit zabezpečení klasických kanálů sestavení, při vytváření nového kanálu bude obor autorizace úlohy sestavení ve výchozím nastavení Project. Doteď se používala jako kolekce projektů. Přečtěte si další informace o přístupových tokenech úloh. Tato změna nemá vliv na žádný z existujících kanálů. Týká se to jenom nových klasických kanálů buildu, které vytvoříte od tohoto okamžiku.

Podpora služby Azure Pipelines pro verze ServiceNow pro San Diego, Tokio a Utah

Azure Pipelines má existující integraci s ServiceNow. Integrace spoléhá na aplikaci v ServiceNow a rozšíření v Azure DevOps. Nyní jsme aplikaci aktualizovali tak, aby fungovala s verzemi ServiceNow v San Diego, Tokiu a Utahu. Pokud chcete zajistit, aby tato integrace fungovala, upgradujte na novou verzi aplikace (4.215.2) z úložiště ServiceNow.

Další informace najdete v dokumentaci integrace se správou změn ServiceNow.

Použití adres URL proxy serveru pro integraci GitHub Enterprise

Azure Pipelines se integruje s místními servery GitHub Enterprise a umožňuje spouštět průběžné integrace a sestavování žádostí o přijetí změn. V některých případech je GitHub Enterprise Server za bránou firewall a vyžaduje směrování provozu přes proxy server. Pro podporu tohoto scénáře vám připojení služby GitHub Enterprise Server v Azure DevOps umožní nakonfigurovat adresu URL proxy serveru. Dříve se přes tuto adresu URL proxy serveru nesměroval veškerý provoz z Azure DevOps. V této aktualizaci zajišťujeme směrování následujícího provozu ze služby Azure Pipelines, abychom prošli adresou URL proxy serveru:

• Získání větví
• Získání informací o žádosti o přijetí změn
• Sestava stavu sestavení

Připojení služby Container Registry teď můžou používat spravované identity Azure.

Spravovanou identitu přiřazenou systémem můžete použít při vytváření připojení služby Docker Registry pro Azure Container Registry. Díky tomu budete mít přístup ke službě Azure Container Registry pomocí spravované identity přidružené k agentovi Azure Pipelines v místním prostředí, což eliminuje nutnost spravovat přihlašovací údaje.

Poznámka:

Spravovaná identita použitá pro přístup ke službě Azure Container Registry bude potřebovat odpovídající přiřazení řízení přístupu na základě role (RBAC), např. role AcrPull nebo AcrPush.

Automatické tokeny vytvořené pro připojení ke službě Kubernetes Service

Vzhledem k tomu, že Kubernetes 1.24, tokeny se už při vytváření nového připojení ke službě Kubernetes Service nevytvořily automaticky. Tuto funkci jsme přidali zpět. Při přístupu k AKS se ale doporučuje použít připojení ke službě Azure. Další informace najdete v doprovodných materiálech pro připojení ke službě pro zákazníky AKS, kteří používají blogový příspěvek o úlohách Kubernetes.

Úlohy Kubernetes teď podporují kubelogin

Aktualizovali jsme úlohy KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 a AzureFunctionOnKubernetes@1 , aby podporovaly kubelogin. To vám umožní cílit na Azure Kubernetes Service (AKS) nakonfigurovanou s integrací Azure Active Directory.

Kubelogin není na hostovaných imagích předinstalovaný. Pokud chcete zajistit, aby výše uvedené úlohy používaly kubelogin, nainstalujte ho vložením úlohy KubeloginInstaller@0 před úkol, který na něm závisí:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Vylepšení oprávnění kanálu

Vylepšili jsme prostředí týkající se správy oprávnění kanálu, aby systém oprávnění zapamatoval, jestli kanál dříve používal chráněný prostředek, například připojení ke službě.

Pokud jste v minulosti při vytváření chráněného prostředku zaškrtli možnost Udělit přístup všem kanálům, ale pak jste omezili přístup k prostředku, potřeboval váš kanál pro použití prostředku novou autorizaci. Toto chování bylo nekonzistentní s následným otevřením a zavřením přístupu k prostředku, kdy se nevyžaduje nová autorizace. Toto je teď opravené.

Nový obor PAT pro správu autorizace a schvalování a kontrol kanálů

Abychom omezili poškození způsobené únikem tokenu PAT, přidali jsme nový obor PAT s názvem Pipeline Resources. Tento obor PAT můžete použít při správě autorizace kanálu pomocí chráněného prostředku, jako je připojení služby, nebo ke správě schválení a kontrol daného prostředku.

Následující volání rozhraní REST API podporují nový obor PAT následujícím způsobem:

• Aktualizace rozsahu podporuje schváleníPipeline Resources Use
• Správa kontrol podporuje obor Pipeline Resources Use and Manage
• Oprávnění kanálu aktualizace pro prostředky podporují obor Pipeline Resources Use and Manage
• Autorizace prostředků definice podporuje obor Pipeline Resources Use and Manage
• Autorizace zdrojů projektu podporuje obor Pipeline Resources Use and Manage

Omezení otevírání chráněných prostředků správcům prostředků

Aby se zlepšilo zabezpečení prostředků, které jsou pro vaši schopnost bezpečně sestavovat a nasazovat aplikace, služba Azure Pipelines teď při otevírání přístupu k prostředku pro všechny kanály vyžaduje roli správce typu prostředku.

Například obecná role správce připojení služeb je nutná k tomu, aby jakýkoli kanál mohl používat připojení služby. Toto omezení platí při vytváření chráněného prostředku nebo při úpravě konfigurace zabezpečení.

Kromě toho při vytváření připojení služby a nemáte dostatečná práva, je možnost Udělit přístup všem kanálům zakázaná.

Při pokusu o otevření přístupu k existujícímu prostředku a nemáte dostatečná práva, dostanete také oprávnění k otevření přístupu pro tuto zprávu o prostředku .

Vylepšení zabezpečení rozhraní REST API pro kanály

Většina rozhraní REST API v Azure DevOps používá tokeny PAT s vymezeným oborem. Některé z nich ale vyžadují plně vymezené tokeny PAT. Jinými slovy, token PAT byste museli vytvořit tak, že vyberete Úplný přístup, abyste mohli některá z těchto rozhraní API použít. Tyto tokeny představují bezpečnostní riziko, protože je možné je použít k volání libovolného rozhraní REST API. V Azure DevOps jsme vylepšili potřebu plně vymezených tokenů začleněním každého rozhraní REST API do konkrétního oboru. V rámci tohoto úsilí teď rozhraní REST API pro aktualizaci oprávnění kanálu pro prostředek vyžaduje konkrétní obor. Rozsah závisí na typu autorizovaného prostředku k použití:

• Code (read, write, and manage) pro prostředky typu repository
• Agent Pools (read, manage) nebo Environment (read, manage) pro prostředky typu queue a agentpool
• Secure Files (read, create, and manage) pro prostředky typu securefile
• Variable Groups (read, create and manage) pro prostředky typu variablegroup
• Service Endpoints (read, query and manage) pro prostředky typu endpoint
• Environment (read, manage) pro prostředky typu environment

K hromadné úpravě oprávnění kanálů budete stále potřebovat plně vymezený token PAT. Další informace o aktualizaci oprávnění kanálu pro prostředky najdete v dokumentaci k oprávněním kanálu – Aktualizovat oprávnění kanálu pro prostředky .

Jemně odstupňovaná správa přístupu pro fondy agentů

Fondy agentů umožňují určit a spravovat počítače, na kterých se kanály spouští.

Pokud jste dříve použili vlastní fond agentů a spravovali, ke kterým kanálům má přístup, byl hrubě odstupňovaný. Můžete povolit, aby je používaly všechny kanály, nebo můžete vyžadovat, aby každý kanál požádal o oprávnění. Když jste kanálu udělili oprávnění k přístupu k fondu agentů, nemůžete ho bohužel odvolat pomocí uživatelského rozhraní kanálů.

Azure Pipelines teď poskytuje podrobnou správu přístupu pro fondy agentů. Prostředí se podobá prostředí pro správu oprávnění kanálu pro připojení služeb.

Zabránění udělení přístupu ke všem kanálům chráněným prostředkům

Při vytváření chráněného prostředku, jako je připojení služby nebo prostředí, máte možnost zaškrtnout políčko Udělit přístup ke všem kanálům . Doteď byla tato možnost ve výchozím nastavení zaškrtnutá.

I když to usnadňuje používání nových chráněných prostředků kanály, opak spočívá v tom, že dává přednost náhodnému udělení příliš velkého počtu kanálů práv pro přístup k prostředku.

Pokud chcete zvýšit úroveň zabezpečené výchozí volby, Azure DevOps teď ponechá políčko nezaškrtané.

Možnost zakázat maskování krátkých tajných kódů

Azure Pipelines maskuje tajné kódy v protokolech. Tajné kódy můžou být označené jako tajné, proměnné ze skupin proměnných, které jsou propojené se službou Azure Key Vault nebo prvky připojení služby označené jako tajné zprostředkovatelem připojení služby.

Všechny výskyty tajné hodnoty jsou maskované. Maskování krátkých tajných kódů, například '1', '2', 'Dev' usnadňuje odhad jejich hodnot, například v datech: 'Jan 3, 202***'
Teď je jasné, že3 "' je tajemství. V takových případech můžete raději nezamaskovat tajný kód úplně. Pokud není možné hodnotu označit jako tajný klíč (např. hodnota je převzata ze služby Key Vault), můžete AZP_IGNORE_SECRETS_SHORTER_THAN nastavit knoflík na hodnotu až 4.

Node Runner – úloha stažení

Při přijímání verzí agenta, které vylučují spouštěč úloh Node 6, může být občas nutné spouštět úlohy, které nebyly aktualizovány, aby používal novější Node Runner. V tomto scénáři poskytujeme metodu, jak dál používat úlohy závislé na spouštěčích Node End-of-Life, viz blogový příspěvek s pokyny node runneru.

Následující úloha je metoda instalace běhu runneru Node 6, takže starý úkol může stále běžet:

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

Aktualizace ověřování spouštěče uzlů TFX

Autoři úloh k publikování rozšíření používají nástroj pro balení rozšíření (TFX). TFX byl aktualizován tak, aby prováděl ověřování ve verzích Node Runneru, viz blogový příspěvek s pokyny node runneru.

Toto upozornění se zobrazí rozšíření, která obsahují úlohy pomocí spouštěče Node 6:

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

Pokyny k ruční předběžné instalaci uzlu 6 na agentech kanálu

Pokud používáte pipeline- informační kanál agenta, nemáte v agentu zahrnutý uzel 6. V některých případech, kdy je úloha Marketplace stále závislá na Node 6 a agent nemůže použít úlohu NodeTaskRunnerInstaller (například kvůli omezením připojení), budete muset Node 6 předinstalovat samostatně. Chcete-li toho dosáhnout, podívejte se na pokyny, jak nainstalovat spouštěč Node 6 ručně.

Protokol změn úloh kanálu

Změny úloh kanálu teď publikujeme do tohoto protokolu změn. Ten obsahuje úplný seznam změn provedených v předdefinovaných úlohách kanálu. Zpětně jsme publikovali předchozí změny, takže protokol změn poskytuje historický záznam aktualizací úkolů.

Úlohy vydávání verzí používají rozhraní Microsoft Graph API

Aktualizovali jsme úlohy vydávání verzí tak, aby používaly rozhraní Microsoft Graph API. Tím se z našich úloh odebere použití rozhraní Graph API AAD.

Vylepšení výkonu úloh Windows PowerShellu

Pomocí úloh můžete definovat automatizaci v kanálu. Jednou z těchto úloh je PowerShell@2 úloha nástroje, která umožňuje spouštět skripty PowerShellu v kanálu. Pokud chcete k cílení na prostředí Azure použít skript PowerShellu, můžete tuto AzurePowerShell@5 úlohu použít. Některé příkazy PowerShellu, které můžou tisknout aktualizace průběhu, například Invoke-WebRequest, se teď spouštějí rychleji. Zlepšení je důležitější, pokud máte ve skriptu mnoho z těchto příkazů nebo pokud jsou dlouho spuštěné. Při této aktualizaci progressPreference je vlastnost PowerShell@2 a AzurePowerShell@5 úkoly nyní nastavena na SilentlyContinue výchozí hodnotu.

Agent Pipelines v3 v .NET 6

Agent kanálu byl upgradován tak, aby jako modul runtime používal .NET 3.1 Core na .NET 6. Představuje nativní podporu Apple Silicon i Windows Arm64.

Použití .NET 6 má vliv na požadavky na systém pro agenta. Konkrétně podporujeme následující operační systémy: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Viz dokumentace k softwaru agenta verze 3.

Tento skript lze použít k identifikaci kanálů, které používají agenty s nepodporovanými operačními systémy.

Důležité

Mějte na paměti, že agenti spuštění na některém z výše uvedených operačních systémů už nebudou aktualizovat nebo selžou, jakmile nasadíme agenta založeného na technologii .NET 6.

Určení verze agenta v rozšíření virtuálního počítače agenta

Virtuální počítače Azure je možné zahrnout do skupin nasazení pomocí rozšíření virtuálního počítače. Rozšíření virtuálního počítače bylo aktualizováno tak, aby volitelně určilo požadovanou verzi agenta, která se má nainstalovat:

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

Nové přepínače pro řízení vytváření klasických kanálů

Azure DevOps teď umožňuje zajistit, aby vaše kolekce projektů používala jenom kanály YAML, a to zakázáním vytváření klasických kanálů sestavení, klasických kanálů verzí, skupin úloh a skupin nasazení. Vaše stávající klasické kanály budou dál spuštěné a budete je moct upravovat, ale nebudete moct vytvářet nové kanály.

Azure DevOps teď umožňuje zajistit, aby vaše organizace používala pouze kanály YAML tím, že zakáže vytváření klasických kanálů sestavení, klasických kanálů verzí, skupin úloh a skupin nasazení. Vaše stávající klasické kanály budou dál spuštěné a budete je moct upravovat, ale nebudete moct vytvářet nové kanály.

Vytváření klasických kanálů na úrovni kolekce projektů nebo na úrovni projektu můžete zakázat zapnutím odpovídajících přepínačů. Přepínače najdete v Nastavení projektu nebo projektu –> Kanály –> Nastavení. Existují dva přepínače: jeden pro klasické kanály buildu a jeden pro kanály klasických verzí , skupiny nasazení a skupiny úloh.

Stav přepínačů je ve výchozím nastavení vypnutý a ke změně stavu budete potřebovat práva správce. Pokud je přepínač zapnutý na úrovni organizace, vynutí se zakázání pro všechny projekty. V opačném případě se každý projekt může rozhodnout, jestli se má vynutit nebo ne.

Při zakázání vytváření klasických kanálů se vynucují rozhraní REST API související s vytvářením klasických kanálů, skupin úloh a skupin nasazení selžou. Rozhraní REST API, která vytvářejí kanály YAML, budou fungovat.

Aktualizace události "Změna stavu fáze spuštění" služby Hook

Volání služeb umožňují spouštět úkoly na jiných službách, když dojde k událostem v projektu v Azure DevOps, změna stavu fáze spuštění je jednou z těchto událostí. Změněná událost stavu fáze spuštění musí obsahovat informace o spuštění, včetně názvu kanálu. Dříve obsahoval pouze informace o ID a názvu spuštění. V této aktualizaci jsme provedli změny události tak, aby obsahovaly chybějící informace.

Zakázání zobrazení poslední zprávy potvrzení pro spuštění kanálu

Dříve se uživatelské rozhraní Pipelines použilo k zobrazení poslední zprávy potvrzení při zobrazení spuštění kanálu.

Tato zpráva může být matoucí, například když kód kanálu YAML žije v úložišti, které se liší od toho, který obsahuje kód, který sestavuje. Slyšeli jsme vaši zpětnou vazbu od komunity vývojářů a požádali nás o způsob, jak povolit nebo zakázat připojení nejnovější zprávy potvrzení k názvu každého spuštění kanálu.

V této aktualizaci jsme přidali novou vlastnost YAML s názvem appendCommitMessageToRunName, která vám umožní přesně to udělat. Ve výchozím nastavení je vlastnost nastavena na true. Když ho nastavíte na false, spuštění kanálu se zobrazí BuildNumberpouze .

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.

Ikona přehledu stavu spuštění kanálu

V této verzi usnadňujeme přehled o celkovém stavu spuštění kanálu.

U kanálů YAML, které mají mnoho fází, je obtížné zjistit stav spuštění kanálu, tj. je stále spuštěný nebo dokončený. A pokud se dokončí, jaký je celkový stav: úspěšný, neúspěšný nebo zrušený. Tento problém jsme opravili přidáním ikony přehledu stavu spuštění.

Boční panel fáze kanálu

Kanály YAML můžou mít desítky fází a ne všechny se vejdou na obrazovku. I když ikona přehledu spuštění kanálu informuje o celkovém stavu spuštění, je stále obtížné zjistit, která fáze selhala nebo která fáze je stále spuštěná.

V této verzi jsme přidali boční panel fází kanálu, který vám umožní rychle zobrazit stav všech fází. Potom můžete kliknout na fázi a přejít přímo k jeho protokolům.

Hledání fází na bočním panelu

Usnadnili jsme nalezení fází, které hledáte na bočním panelu fází. Nyní můžete rychle filtrovat fáze na základě jejich stavu, například spuštěných fází nebo těch, které vyžadují ruční zásah. Fáze můžete vyhledat také podle jejich názvu.

Příprava rychlých akcí

Obrazovka Spuštění kanálu umožňuje rychlý přístup ke všem fázím spuštění. V této verzi jsme přidali panel fází, ze kterého můžete provádět akce pro každou fázi. Můžete například snadno spustit neúspěšné úlohy nebo znovu spustit celou fázi. Panel je k dispozici, pokud se všechny fáze nevejdou do uživatelského rozhraní, jak je vidět na následujícím snímku obrazovky.

Když ve sloupci fází kliknete na symbol +, zobrazí se panel dílčích fází a pak můžete provádět dílčí akce.

Kontroluje vylepšení uživatelského prostředí.

Usnadňujeme čtení protokolů kontrol. Protokoly kontrol poskytují důležité informace pro úspěch vašeho nasazení. Můžou vám říct, jestli jste zapomněli zavřít lístek pracovní položky nebo že potřebujete aktualizovat lístek ve službě ServiceNow. Dříve bylo obtížné vědět, že kontrola poskytla takové kritické informace.

Teď se na stránce podrobností o spuštění kanálu zobrazuje nejnovější protokol kontroly. Jedná se pouze o kontroly, které se řídí naším doporučeným využitím.

Aby se zabránilo omylem schváleným schválením, Azure DevOps zobrazí pokyny ke schvalovatelům na bočním panelu Schválení a kontroly na stránce podrobností spuštění kanálu.

Zakázání kontroly

Provedli jsme méně zdlouhavé kontroly ladění. Někdy nefunguje správná kontrola vyvolání funkce Azure nebo vyvolání rozhraní REST API a je potřeba ji opravit. Dříve jste tyto kontroly museli odstranit, aby se zabránilo chybnému blokování nasazení. Jakmile kontrolu opravíte, museli jste ji znovu přidat a správně ho nakonfigurovat, abyste měli jistotu, že jsou nastavená všechna požadovaná záhlaví nebo jsou správné parametry dotazu. To je zdlouhavé.

Teď můžete jenom zakázat kontrolu. Zakázaná kontrola se nespustí v následných vyhodnoceních sady kontrol.

Jakmile opravíte chybnou kontrolu, stačí ji povolit.

Spotřebované prostředky a parametry šablony v rozhraní REST API služby Pipelines Runs

Rozšířené rozhraní REST API pro spuštění kanálů teď vrací více typů artefaktů používaných spuštěním kanálu a parametry sloužícími k aktivaci tohoto spuštění. Vylepšili jsme rozhraní API tak, aby vracely container pipeline prostředky a parametry šablony použité při spuštění kanálu. Teď můžete například zapisovat kontroly dodržování předpisů, které vyhodnocují úložiště, kontejnery a další spuštění kanálu používané kanálem.

Tady je příklad nového textu odpovědi.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Obecná podpora šablon dostupnosti v editoru YAML

Šablony jsou běžně používanou funkcí v kanálech YAML. Představují snadný způsob sdílení fragmentů kódu kanálu. Jedná se také o výkonný mechanismus ověřování nebo vynucování zabezpečení a zásad správného řízení prostřednictvím vašeho kanálu.

Azure Pipelines podporuje editor YAML, který může být užitečný při úpravách kanálu. Editor však dosud nepodporuje šablony. Autoři kanálů YAML nemohli získat pomoc prostřednictvím technologie IntelliSense při použití šablony. Autoři šablon nemohli použít editor YAML. V této verzi přidáváme podporu šablon v editoru YAML.

Při úpravách hlavního souboru YAML služby Azure Pipelines můžete šablonu zahrnout nebo rozšířit . Když zadáte název šablony, zobrazí se výzva k ověření šablony. Po ověření editor YAML rozumí schématu šablony včetně vstupních parametrů.

Po ověření můžete přejít do šablony. Změny šablony budete moct provádět pomocí všech funkcí editoru YAML.

Existují známá omezení:

• Pokud šablona obsahuje požadované parametry, které nejsou zadané jako vstupy v hlavním souboru YAML, ověření selže a vyzve vás k zadání těchto vstupů. V ideálním prostředí by ověřování nemělo být blokováno a měli byste být schopni vyplnit vstupní parametry pomocí intellisense.
• V editoru nelze vytvořit novou šablonu. Můžete použít nebo upravit pouze existující šablony.

Nová předdefinovaná systémová proměnná

Zavedli jsme novou předdefinovanou systémovou proměnnou s názvem Build.DefinitionFolderPath, jejíž hodnotou je cesta ke složce definice kanálu buildu. Proměnná je k dispozici v kanálech YAML i classic buildu.

Pokud je váš kanál například umístěn ve FabrikamFiber\Chat složce v Azure Pipelines, hodnota Build.DefinitionFolderPath je FabrikamFiber\Chat.

Přidání podpory pro funkci rozdělení řetězců ve výrazech šablony YAML

Kanály YAML poskytují pohodlné způsoby, jak omezit duplikaci kódu, jako je například smyčka prostřednictvím each hodnoty seznamu nebo vlastnosti objektu.

V některých případech je sada položek, které se mají iterovat, reprezentována jako řetězec. Například pokud seznam prostředí, do které se má nasadit, definuje řetězec integration1, integration2.

Jak jsme si poslechli vaši zpětnou vazbu od komunity vývojářů, slyšeli jsme, že jste chtěli řetězcovou split funkci ve výrazech šablony YAML.

Teď můžete split řetězec a iterovat jeho podřetězce each .

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Výrazy šablony v definici prostředku úložiště

Přidali jsme podporu výrazů šablon při definování ref vlastnosti repository prostředku v kanálu YAML. To byla vysoce požadovaná funkce naší komunitou vývojářů.

Existují případy použití, kdy chcete, aby kanál zkontroloval různé větve stejného prostředku úložiště.

Řekněme například, že máte kanál, který sestaví vlastní úložiště, a proto musí rezervovat knihovnu z úložiště prostředků. Řekněme také, že chcete, aby váš kanál zkontroloval stejnou větev knihovny jako samotná. Pokud například kanál běží ve main větvi, měl by se podívat na main větev úložiště knihovny. Pokud kanály běží ve dev větvi, měla by se podívat na dev větev knihovny.

Až do dnešního dne jste museli explicitně zadat větev, která se má rezervovat, a změnit kód kanálu pokaždé, když se větev změní.

Teď můžete pomocí výrazů šablon zvolit větev prostředku úložiště. Podívejte se na následující příklad kódu YAML, který se má použít pro jiné než hlavní větve vašeho kanálu:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

Při spuštění kanálu můžete zadat větev, která se má rezervovat pro library úložiště.

Zadejte verzi šablony, která se má rozšířit v době fronty sestavení.

Šablony představují skvělý způsob, jak omezit duplikaci kódu a zlepšit zabezpečení kanálů.

Jedním zoblíbených Tím se snižuje propojení mezi šablonou a kanály, které ji rozšiřují, a usnadňuje nezávislému vývoji šablony a kanálů.

Podívejte se na následující příklad, ve kterém se šablona používá k monitorování provádění seznamu kroků. Kód šablony se nachází v Templates úložišti.

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

Řekněme, že máte kanál YAML, který rozšiřuje tuto šablonu, která se nachází v úložišti FabrikamFiber. Až do dnešního dne nebylo možné dynamicky určit ref vlastnost templates prostředku úložiště při použití úložiště jako zdroje šablony. To znamenalo, že jste museli změnit kód kanálu, pokud chcete, aby kanál rozšířil šablonu z jiné větve, a to ze stejného názvu větve jako váš kanál, bez ohledu na to, na které větvi jste kanál spustili.

Po zavedení výrazů šablony v definici prostředku úložiště můžete kanál zapsat následujícím způsobem:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Tím kanál rozšíří šablonu ve stejné větvi jako větev, na které se kanál spouští, abyste měli jistotu, že větve kanálu a šablony se vždy shodují. To znamená, že pokud kanál spustíte ve větvi dev, rozšíří se šablona určená souborem template.yml ve dev větvi templates úložiště.

Nebo můžete zvolit větev úložiště šablony, která se má použít, při sestavování fronty, napsáním následujícího kódu YAML.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

Teď můžete mít kanál ve větvi rozšíření šablony z větve main dev v jednom spuštění a rozšířit šablonu z větve main v jiném spuštění beze změny kódu kanálu.

Při zadávání výrazu šablony pro ref vlastnost prostředku úložiště můžete použít parameters a systémové předdefinované proměnné, ale nemůžete použít proměnné definované uživatelským rozhraním YAML nebo Pipelines.

Výrazy šablony v definici prostředku kontejneru

Přidali jsme podporu výrazů šablon při definování endpointvolumesportsprostředku v kanálu YAML .options container To byla vysoce požadovaná funkce naší komunitou vývojářů.

Teď můžete napsat kanály YAML, jako je následující.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

Můžete použít parameters. a variables. ve výrazech šablony. U proměnných můžete použít pouze ty definované v souboru YAML, ale ne ty, které jsou definované v uživatelském rozhraní Pipelines. Pokud předefinujete proměnnou, například pomocí příkazů protokolu agenta, nebude mít žádný vliv.

Vylepšení naplánovaných buildů

Opravili jsme problém, který způsoboval poškození informací o plánu kanálu a nenačítá se kanál. Příčinou byla například překročení určitého počtu znaků název větve.

Vylepšená chybová zpráva při selhání načítání kanálů

Azure Pipelines poskytuje několik typů triggerů pro konfiguraci spuštění kanálu. Jedním ze způsobů, jak spustit kanál, je použití plánovaných triggerů. Někdy se informace o plánovaném spuštění kanálu poškodí a můžou způsobit selhání zatížení. Dříve jsme zobrazili zavádějící chybovou zprávu s tvrzením, že kanál nebyl nalezen. V této aktualizaci jsme tento problém vyřešili a vrací informativní chybovou zprávu. V budoucnu se zobrazí zpráva podobná: Data plánu sestavení jsou poškozena , pokud se kanál nenačte.

Nesynchronizovat značky při načítání úložiště Git

Úloha rezervace používá --tags možnost při načítání obsahu úložiště Git. To způsobí, že server načte všechny značky a všechny objekty, na které tyto značky odkazují. Tím se zvýší doba spuštění úlohy v kanálu , zejména pokud máte velké úložiště s řadou značek. Kromě toho úloha rezervace synchronizuje značky i v případě, že povolíte možnost načtení mělké verze, a tím může porazit její účel. Abychom snížili množství dat načtených nebo načtených z úložiště Git, přidali jsme do úlohy novou možnost pro řízení chování synchronizačních značek. Tato možnost je dostupná jak v klasických kanálech, tak v kanálech YAML.

YAML

Toto chování může být řízeno ze souboru YAML nebo z uživatelského rozhraní.

Pokud se chcete odhlásit od synchronizace značek prostřednictvím souboru YAML, přidejte ho fetchTags: false do kroku rezervace. fetchTags Pokud není tato možnost zadaná, je stejná jako při fetchTags: true použití.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Pokud chcete změnit chování stávajících kanálů YAML, může být vhodnější tuto možnost nastavit v uživatelském rozhraní místo aktualizace souboru YAML. Pokud chcete přejít do uživatelského rozhraní, otevřete editor YAML pro kanál, vyberte Triggery, pak Proces a pak krok Rezervace.

Pokud toto nastavení zadáte jak v souboru YAML, tak v uživatelském rozhraní, bude mít přednost hodnota zadaná v souboru YAML.

Klasické

Pokud chcete zrušit synchronizaci značek, zrušte zaškrtnutí políčka Synchronizovat značky v kroku Získat zdroje.

U všech nových kanálů, které vytvoříte (YAML nebo Classic), se značky ve výchozím nastavení stále synchronizují. Tato možnost nemění chování existujících kanálů. Značky se budou v těchto kanálech dál synchronizovat, pokud explicitně nezměníte možnost, jak je popsáno výše.

Artifacts

Aktualizace výchozích oprávnění informačního kanálu

Účty služby Sestavení kolekce projektů teď budou mít ve výchozím nastavení roli Spolupracovníci , když se vytvoří nový informační kanál Azure Artifacts s vymezeným oborem kolekce projektů místo aktuální role přispěvatele .

Nové uživatelské rozhraní pro upstreamové vyhledávání balíčků

Dříve jste viděli upstreamové balíčky, pokud jste měli kopii informačního kanálu. Bod bolesti byl, že se vám nepodařilo vyhledat balíčky, které jsou k dispozici v upstreamu a které ještě nejsou uloženy v informačním kanálu. Nyní můžete vyhledat dostupné upstreamové balíčky pomocí nového uživatelského rozhraní informačního kanálu.

Azure Artifacts teď poskytuje uživatelské rozhraní, které umožňuje vyhledávat balíčky v upstreamových zdrojích a ukládat verze balíčků do informačního kanálu. To je v souladu s cílem Microsoftu zlepšit naše produkty a služby.

Sestavy

Zobrazit nadřazený prvek ve widgetu výsledků dotazu

Widget výsledků dotazu teď podporuje název nadřazeného objektu a přímý odkaz na tento nadřazený objekt.

Kopírovat řídicí panel

V této verzi zahrneme řídicí panel pro kopírování.

Datum posledního přístupu k řídicím panelům a změněno uživatelem

Jednou z výzev, jak týmům umožnit vytvářet několik řídicích panelů, je správa a vyčištění zastaralého a nepoužívaného řídicího panelu. Znalost posledního navštíveného nebo upraveného řídicího panelu je důležitou součástí porozumění tomu, které řídicí panel je možné odebrat. V této verzi jsme do stránky adresáře Řídicí panely zahrnuli dva nové sloupce. Datum posledního přístupu bude sledovat, kdy byl řídicí panel naposledy navštíven. Změněno sledováním , kdy byl řídicí panel naposledy upravován a kým.

Informace o úpravách se zobrazí také na samotné stránce řídicího panelu.

Doufáme, že tato nová pole pomáhají správcům projektů pochopit úroveň aktivity řídicích panelů, aby udělali informované rozhodnutí, jestli by se měli odebrat nebo ne.

Analytická zobrazení jsou nyní k dispozici.

Funkce Zobrazení analýz je ve stavu Preview po delší dobu v naší hostované verzi produktu. S touto verzí s radostí oznamujeme, že tato funkce je nyní k dispozici pro všechny kolekce projektů.

V navigaci se zobrazení Analýzy přesunula z karty Přehled na kartu Panely.

Zobrazení Analýza poskytuje zjednodušený způsob, jak zadat kritéria filtru pro sestavu Power BI na základě analytických dat. Pokud nejste obeznámeni s analytickými zobrazeními, tady je některá dokumentace, která vás seznámí s následujícími informacemi:

• Zobrazení Analýzy
• Vytvoření zobrazení Analytics v Azure DevOps
• Správa zobrazení Analýzy
• Vytvoření sestavy Power BI s výchozím zobrazením Analýzy
• Připojení k Analýzám pomocí datového konektoru Power BI

Widget žádosti o přijetí změn pro více úložišť je nyní k dispozici.

S radostí oznamujeme, že widget žádosti o přijetí změn pro více úložišť je k dispozici v Azure DevOps Serveru 2022.1. Díky tomuto novému widgetu můžete snadno zobrazovat žádosti o přijetí změn z až 10 různých úložišť v jediném zjednodušeném seznamu, což vám usnadní přehled o vašich žádostech o přijetí změn.

Lístek návrhů komunity

Představujeme vyřešené dokončení v burndownu a burnup grafech.

Rozumíme důležitosti přesného vyjádření průběhu týmu, včetně vyřešených položek jako dokončených v grafech. Pomocí jednoduché možnosti přepínacího tlačítka se teď můžete rozhodnout zobrazit vyřešené položky jako dokončené a poskytnout skutečný odraz stavu burndownu týmu. Toto vylepšení umožňuje přesnější sledování a plánování, což týmům umožňuje provádět informovaná rozhodnutí na základě skutečného pokroku. Vyzkoušejte si lepší transparentnost a lepší přehledy s aktualizovanými burndowny a burnup grafy v sestavách.

Wiki

Podpora dalších typů diagramů na stránkách wikiwebu

Upgradovali jsme verzi grafů mermaid použitých na wiki stránkách na 8.13.9. V tomto upgradu teď můžete na stránkách wikiwebu Azure DevOps zahrnout následující diagramy a vizualizace:

• Vývojový diagram
• Sekvenční diagramy
• Ganttovy diagramy
• Výsečové grafy
• Diagramy požadavků
• Diagramy stavů
• Cesta uživatele

Diagramy, které jsou v experimentálním režimu, jako je vztah entit a Git Graph, nejsou zahrnuté. Další informace o nových funkcích najdete v poznámkách k verzi mermaid.

---

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