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

---

| | Developer Community Požadavky na systém a kompatibilita | Licenční podmínky | ProDevOps Blog | Hash SHA-256 |

---

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

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

Pokud si chcete stáhnout Azure DevOps Server produkty, navštivte stránku Azure DevOps Server Ke stažení.

Přímý upgrade na Azure DevOps Server 2022 Update 1 se podporuje od Azure DevOps Server 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ěkteré dílčí kroky. Další informace najdete na stránce Instalace .

---

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

File	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 proxy server přestal fungovat po instalaci opravy Patch 2.
• Opravili jsme problém s vykreslováním na stránce podrobností o rozšíření, který ovlivnil jazyky, které nebyly v angličtině.

Azure DevOps Server 2022 Update 1 Patch 2 Datum vydání: 13. února 2024

File	Hodnota hash SHA-256
devops2022.1patch2.exe	59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

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í v rozšíření vyhledávání
• Opravili jsme chybu, kdy se nesprávně vypočítalo místo na disku využité složkou mezipaměti proxy serveru a složka nebyla správně vyčištěna.
• CVE-2024-20667: Azure DevOps Server ohrožení zabezpečení z důvodu vzdáleného spuštění kódu.

Azure DevOps Server 2022 Update 1 Patch 1 Datum vydání: 12. prosince 2023

File	Hodnota hash SHA-256
devops2022.1patch1.exe	9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

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

• Zabránit nastavení requested for při spuštění kanálu do fronty

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

Poznámka

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

1. Verze agenta se po upgradu na Azure DevOps Server 2022.1 a použití agenta aktualizace v konfiguraci fondu agentů neaktualizuje. V současné době pracujeme na opravě, která tento problém vyřeší, a postupně budeme sdílet aktualizace v Developer Community. Mezitím najdete alternativní řešení tohoto problému v tomto lístku Developer Community.
2. Kompatibilita Mavenu 3.9.x. Maven 3.9.x zavedl zásadní změny v Azure Artifacts aktualizací výchozího přenosu Překladače Mavenu na nativní http ze služby Wagon. 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 dál používat Maven 3.9.x s vlastností -Dmaven.resolver.transport=wagon. Tato změna přinutí Maven používat Vůz Resolver Transport. Další podrobnosti najdete v této dokumentaci.

Azure DevOps Server 2022.1 je soubor oprav chyb. Obsahuje všechny funkce dříve vydané verze Azure DevOps Server 2022.1 RC2.

Poznámka

Existuje známý problém s kompatibilitou Mavenu 3.9.x. Maven 3.9.x zavedl zásadní změny v Azure Artifacts aktualizací výchozího přenosu Překladače Mavenu na nativní http ze služby Wagon. 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 dál používat Maven 3.9.x s vlastností -Dmaven.resolver.transport=wagon. Tato změna přinutí Maven používat Vůz Resolver Transport. Další podrobnosti najdete v této dokumentaci.

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

Azure DevOps Server 2022.1 RC2 je sada oprav chyb. Obsahuje všechny funkce dříve vydané verze Azure DevOps Server 2022.1 RC1.

Poznámka

Existuje známý problém s kompatibilitou Mavenu 3.9.x. Maven 3.9.x zavedl zásadní změny v Azure Artifacts aktualizací výchozího přenosu Překladače Mavenu na nativní http ze služby Wagon. 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 dál používat Maven 3.9.x s vlastností -Dmaven.resolver.transport=wagon. Tato změna přinutí Maven používat Vůz Resolver Transport. Další podrobnosti najdete v této 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ých názvů.
• 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 ideografy pro čínštinu, japonštinu a korejštinu (CJK) došlo k chybě. Když název týmového projektu nebo soubory obsahoval CJK, zobrazil se u protokolu RAW otazník.
• Opravili jsme problém při instalaci služby Search, kdy virtuální počítač Java (JVM) nemohl přidělit dostatek paměti pro proces 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 libovolném prostředí Java Runtime Environment (JRE) předinstalovaném na cílovém serveru.

Azure DevOps Server 2022 Update 1 RC1 Datum vydání: 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.
• Sloupec Poslední přístup na stránce Delivery Plans
• Vizualizace všech závislostí na plánech doručení
• @CurrentIteration makra 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ý objekt 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é oddíly a zobrazit všechny nové funkce pro každou službu:

• Obecné
• Boards
• Repos
• Pipelines
• Artifacts
• Generování sestav
• Wiki

---

Obecné

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

Dříve nebylo několik veřejně zdokumentovaných rozhraní REST API Azure DevOps přidruženo k oborům (např. čtení pracovní položky), což vedlo k tomu, že zákazníci používali úplná rozsahy těchto rozhraní API prostřednictvím neinteraktivních ověřovacích mechanismů, jako jsou osobní přístupové tokeny (PAT). Použití tokenu personal access v plném rozsahu zvyšuje riziko, když se může dostat do rukou uživatele se zlými úmysly. To je jeden z hlavních důvodů, proč mnoho našich zákazníků nevyužilo naplno zásady řídicí roviny k omezení používání a chování tokenu PAT.

Teď jsou všechna veřejná rozhraní REST API Azure DevOps přidružená k a podporují podrobný obor PAT. Pokud aktuálně k ověřování v některém z veřejných rozhraní REST API Azure DevOps používáte plně vymezený token PAT, zvažte migraci na token PAT s konkrétním oborem, který rozhraní API akceptuje, 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 je zde tabulka oborů.

Rozšíření by měla zobrazovat své obory.

Při instalaci rozšíření do kolekce Azure DevOps můžete v rámci instalace zkontrolovat oprávnění, která rozšíření potřebuje. Po instalaci se ale oprávnění rozšíření v nastavení rozšíření nezobrazí. To představuje výzvu pro správce, kteří potřebují pravidelně kontrolovat nainstalovaná rozšíření. Teď jsme do nastavení rozšíření přidali oprávnění rozšíření, abychom vám pomohli zkontrolovat a přijmout informované rozhodnutí, jestli je chcete zachovat, nebo ne.

Boards

Sloupec Poslední přístup na stránce Delivery Plans

Stránka adresáře Delivery Plans (Plány doručení) poskytuje seznam plánů definovaných pro váš projekt. Můžete řadit podle: Název, Autor, Popis, Naposledy nakonfigurováno nebo Oblíbené položky. 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 na co se podíval. 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í na Delivery Plans

Delivery Plans vždy poskytoval možnost zobrazit závislosti mezi pracovními položkami. Čáry závislostí můžete vizualizovat jednu po druhé. V této verzi jsme vylepšili prostředí tím, že vám umožnili zobrazit všechny závislosti napříč všemi pracovními položkami na obrazovce. Stačí kliknout na přepínací tlačítko závislostí v pravém horním rohu plánu doručení. Dalším kliknutím řádky vypnete.

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

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

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

Zvýšení limitu pro tým Delivery Plans z 15 na 20

Delivery Plans vám umožní 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 v odkazech pro vytváření sestav pracovních položek – Získání rozhraní API

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

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

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

Další informace najdete na stránce dokumentace k rozhraní REST API dočasných dotazů.

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

V současné době je jediným způsobem, jak odebrat pracovní položky z koše, použít toto rozhraní REST API k jejich odstranění po jednom. Tento proces může být pomalý a při pokusu o jakýkoli druh čištění hmoty podléhá omezování rychlosti. V reakci na to jsme přidali nový koncový bod rozhraní REST API pro odstranění nebo zničení pracovních položek v dávce.

@CurrentIteration makro v části Delivery Plans

V této aktualizaci jsme přidali podporu makra pro @CurrentIteration 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 karty 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ěkteří se rozhodnou použít kombinaci kalendářních dat a cesty iterace. V této verzi jsme vylepšili logiku tak, aby se správně nastavily kombinace polí iterace a pole data v závislosti na tom, jak se používají.

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

Vylepšení dávkových aktualizací

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 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ánění úpravám polí rozevíracích seznamů umožňujících sdílení

Vlastní pole se sdílí napříč procesy. To může způsobovat 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 před úpravami. Pokud je pole rozevíracího seznamu uzamčené, nemůže správce místního procesu změnit hodnoty tohoto rozevíracího seznamu. Můžou pole jenom přidat nebo odebrat z procesu.

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

Možnost ukládat jenom komentáře k pracovním položkám je v komunitě vývojářů nejčastějším požadavkem. S radostí vám oznamujeme, že jsme tuto funkci implementovali. Pro začátek si projdeme 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."

Chcete-li toho dosáhnout, musíte přejít do nastavení > projektu Cesta k oblasti konfigurace > projektu. Pak vyberte zvolenou cestu oblasti a klikněte na 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 Nenastavěné. To znamená, že pracovní položka se 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í na Povolit.

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

Doufáme, že se vám tato funkce líbí 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.

Sestavy interaktivních panelů

Interaktivní sestavy umístěné v centru Boards jsou v naší hostované verzi produktu přístupné několik let. Nahrazují starší grafy Kumulativní vývojový diagram, Rychlost a Sprint Burndown. V této verzi je zpřístupňujeme.

Pokud chcete tyto grafy zobrazit, klikněte na kartu Analýza na stránkách Kanban Board, Backlog a Sprints.

Repos

Odebrání oprávnění Upravit zásady pro tvůrce větví

Když jste dříve 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á přístupové tokeny úloh k přístupu k dalším prostředkům v Azure DevOps za běhu. Přístupový token úlohy je token zabezpečení, který služba Azure Pipelines dynamicky generuje pro každou úlohu za běhu. Při vytváření nových klasických kanálů byla dříve výchozí hodnota přístupového tokenu nastavená na Kolekci projektů. V této aktualizaci nastavujeme obor autorizace úlohy 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

Aby se zlepšilo zabezpečení klasických kanálů sestavení, bude při vytváření nového ve výchozím nastavení oborem autorizace úlohy sestaveníProject. Až dosud to byla 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 v San Diegu, Tokiu & Utahu

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

Další informace najdete v dokumentaci k integraci se službou ServiceNow Change Management.

Použití adres URL proxy serveru pro integraci GitHubu 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žňují nakonfigurovat adresu URL proxy serveru. Dříve se přes tuto adresu URL proxy serveru nesměroval veškerý provoz z Azure DevOps. S touto aktualizací zajišťujeme, že budeme směrovat následující provoz z Azure Pipelines, aby procházel přes adresu URL proxy serveru:

• Získání větví
• Získání informací o žádosti o přijetí změn
• Nahlásit stav 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. To vám umožní přistupovat k Azure Container Registry pomocí spravované identity přidružené k místnímu agentu Azure Pipelines, takže nemusíte spravovat přihlašovací údaje.

Poznámka

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

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

Od verze Kubernetes 1.24 se tokeny už při vytváření nového připojení služby Kubernetes Service nevytvářely automaticky. Tuto funkci jsme přidali zpět. Při přístupu k AKS se ale doporučuje použít připojení služby Azure. Další informace najdete v blogovém příspěvku Pokyny k připojení služby pro zákazníky AKS, kteří používají úlohy Kubernetes.

Úlohy Kubernetes teď podporují kubelogin

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

Kubelogin není předinstalovaný na hostovaných imagích. Abyste měli jistotu, že výše uvedené úlohy používají kubelogin, nainstalujte ho vložením KubeloginInstaller@0 úkolu 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

Zkušenosti s vylepšeními oprávnění kanálu

Vylepšili jsme prostředí správy oprávnění kanálu, aby si systém oprávnění pamatoval, jestli kanál dříve používal chráněný prostředek, například připojení služby.

Pokud jste v minulosti při vytváření chráněného prostředku odškrtli možnost Udělit přístup ke všem kanálům, ale pak jste přístup k prostředku omezili, váš kanál potřeboval k 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, kde se nevyžaduje nová autorizace. To je teď opravené.

Nový obor PAT pro správu autorizace kanálů, schválení a kontrol

Abychom omezili škody 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 pro daný prostředek.

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

• Aktualizace schválení podporuje obor Pipeline Resources Use
• Správa kontrol podporuje obor Pipeline Resources Use and Manage
• Aktualizace oprávnění kanálu pro prostředky podporuje 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, 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 služby Connections se vyžaduje k tomu, aby libovolný 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ách jeho konfigurace zabezpečení.

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

Také když se pokusíte otevřít přístup k existujícímu prostředku a nemáte dostatečná práva, zobrazí se zpráva Nemáte oprávnění k otevření přístupu k tomuto 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, abyste mohli některá z těchto rozhraní API použít, musíte vytvořit token PAT výběrem možnosti Úplný přístup. 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 provedli vylepšení, abychom odstranili potřebu plně omezených tokenů začleněním jednotlivých rozhraní REST API do konkrétního oboru. V rámci tohoto úsilí teď rozhraní REST API k aktualizaci oprávnění kanálu pro prostředek vyžaduje konkrétní obor. Rozsah závisí na typu prostředku, který je autorizován pro 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

Pokud chcete oprávnění kanálů hromadně upravovat, budete stále potřebovat token PAT s plně vymezeným oborem. Další informace o aktualizaci oprávnění kanálu pro prostředky najdete v dokumentaci Oprávnění kanálu – Aktualizace 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 běží vaše kanály.

Pokud jste dříve používali vlastní fond agentů, správa kanálů, ke kterým k němu mají přístup, byla hrubě odstupňovaná. Můžete povolit, aby ho používaly všechny kanály, nebo můžete vyžadovat, aby každý kanál požádal o oprávnění. Jakmile udělíte přístupové oprávnění ke kanálu fondu agentů, nemůžete ho bohužel odvolat pomocí uživatelského rozhraní kanálů.

Azure Pipelines teď poskytuje jemně odstupňovanou správu přístupu pro fondy agentů. Prostředí je podobné prostředí pro správu oprávnění kanálu pro service Connections.

Zabránění udělení přístupu k chráněným prostředkům všem kanálů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 oprávnění přístupu ke všem kanálům . Až dosud byla tato možnost ve výchozím nastavení zaškrtnutá.

Kanály tím sice usnadňují používání nových chráněných prostředků, ale naopak je to, že dává přednost náhodnému udělení práva pro přístup k prostředku příliš mnoha kanálům.

Pokud chcete zvýšit úroveň možnosti zabezpečení ve výchozím nastavení, 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 proměnné označené jako tajný klíč, proměnné ze skupin proměnných, které jsou propojené s Azure Key Vault, nebo prvky připojení služby označené jako tajný klíč poskytovatelem připojení služby.

Všechny výskyty hodnoty tajného kódu jsou maskované. Maskování krátkých tajných kódů, například '1', '2', 'Dev' usnadňuje uhodnutí jejich hodnot, například v datu:Jan 3, 202***
Teď je jasné, že je3 to tajemství. V takových případech možná nechcete tajemství zcela maskovat. Pokud není možné označit hodnotu jako tajný (např. hodnota je převzata z Key Vault), můžete nastavit AZP_IGNORE_SECRETS_SHORTER_THAN knoflík až na hodnotu 4.

Úloha stažení nástroje Node Runner

Při přijímání verzí agenta, které vylučují spouštěč úloh Node 6 , můžete mít příležitostně potřebu spouštět úlohy, které nebyly aktualizovány, aby používaly novější node runner. Pro tento scénář poskytujeme metodu, jak stále používat úlohy závislé na běžcích konce životnosti uzlů, viz blogový příspěvek s pokyny pro Node runner.

Následující úloha je metoda, jak nainstalovat node 6 runner za běhu, aby se stále mohl provést starý úkol:

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

Aktualizované ověření runneru uzlů TFX

Autoři úkolů používají k publikování rozšíření nástroj TFX (Extension Packaging Tool). TFX byl aktualizován tak, aby prováděl ověřování ve verzích Node Runner, viz blogový příspěvek s pokyny pro Node Runner.

Rozšíření, která obsahují úlohy používající node 6 runner, se zobrazí toto upozornění:

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 pro ruční předběžnou 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 vydané verze používají Microsoft Graph API

Aktualizovali jsme úlohy vydané verze tak, aby používaly Graph API Microsoftu. Tím se z našich úkolů odebere používání Graph API AAD.

Windows PowerShell zlepšení výkonu úloh

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 použít skript PowerShellu k cílení na prostředí Azure, můžete použít AzurePowerShell@5 úlohu . 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é. S touto aktualizací progressPreference je vlastnost PowerShell@2 úkolů a AzurePowerShell@5 ve výchozím nastavení nastavená na SilentlyContinue hodnotu .

Pipelines Agent v3 v .NET 6

Agent kanálu byl upgradován tak, aby jako modul runtime používal .NET 3.1 Core na .NET 6. Tím se zavádí nativní podpora pro Apple Silicon i Windows Arm64.

Použití .NET 6 má vliv na požadavky na systém pro agenta. Konkrétně jsme odstranili podporu následujících operačních systémů: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Projděte si dokumentaci k softwaru Agent 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 běžící v některém z výše uvedených operačních systémů se po zavedení agenta založeného na .NET 6 buď neaktualizovat nebo selžou.

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čovalo 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 tím, že zakáže vytváření klasických kanálů buildu, kanálů verze Classic, skupin úloh a skupin nasazení. Vaše stávající klasické kanály budou dál běžet a budete je moct upravovat, ale nebudete moct vytvářet nové.

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

Můžete zakázat vytváření klasických kanálů na úrovni kolekce projektů nebo na úrovni projektu zapnutím odpovídajících přepínačů. Přepínače najdete v nastavení projektu / projektu –> Kanály –> Nastavení. K dispozici jsou dva přepínače: jeden pro klasické kanály buildu a druhý pro klasické kanály vydaný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, zákaz se vynucuje pro všechny projekty. V opačném případě si každý projekt může zvolit, jestli se má zákaz vynucovat, nebo ne.

Při vynucení zákazu vytváření klasických kanálů se nezdaří rozhraní REST API související s vytvářením klasických kanálů, skupin úloh a skupin nasazení. Budou fungovat rozhraní REST API, která vytvářejí kanály YAML.

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

Připojení služby umožňují spouštět úkoly v jiných službách, když v projektu v Azure DevOps dojde k událostem. Jednou z těchto událostí je změna stavu fáze spuštění . Událost Změna 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.

Zákaz zobrazení poslední zprávy potvrzení pro spuštění kanálu

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

Tato zpráva může být matoucí, například když se kód kanálu YAML nachází v jiném úložišti než v úložišti, které obsahuje kód, který vytváří. Vyslyšeli jsme vaši zpětnou vazbu od Developer Community s žádostí o způsob, jak povolit nebo zakázat připojení nejnovější zprávy o potvrzení k názvu každého spuštění kanálu.

S touto aktualizací 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 nastavená na true. Když ho nastavíte na false, zobrazí se při spuštění kanálu pouze BuildNumber.

Zvýšené limity azure pipeline, aby odpovídaly maximální velikosti šablony Azure Resource Manager (ARM) 4 MB.

K vytvoření infrastruktury Azure můžete použít úlohu Nasazení šablon Azure Resource Manager. V reakci na vaši zpětnou vazbu jsme zvýšili limit integrace Azure Pipelines z 2 MB na 4 MB. To bude v souladu s maximální velikostí šablon ARM 4 MB , která řeší omezení velikosti během integrace 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í, bylo obtížné zjistit stav spuštění kanálu, tj. jestli 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 vyřešili 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 vaši obrazovku. I když ikona přehledu spuštění kanálu informuje o celkovém stavu spuštění, stále je 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ý umožňuje rychle zobrazit stav všech fází. Potom můžete kliknout na určitou fázi a dostat se přímo k jejím protokolům.

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

Usnadnili jsme vyhledání fází, které hledáte, na bočním panelu fází. Teď 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 také vyhledat podle jejich názvu.

Příprava rychlých akcí

Obrazovka Spuštění kanálu poskytuje 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 jednotlivé fáze. Můžete například snadno znovu spustit neúspěšné úlohy nebo znovu spustit celou fázi. Panel je k dispozici, pokud se do uživatelského rozhraní nevejdou všechny fáze, jak je vidět na následujícím snímku obrazovky.

Když kliknete na znaménko + ve sloupci fází, zobrazí se panel fází a pak můžete provádět akce fáze.

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

Zjednodušujeme protokoly kontroly čtení. Protokoly obsahují 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 v ServiceNow. Dříve bylo obtížné vědět, že kontrola poskytla takové důležité informace.

Teď se na stránce s podrobnostmi spuštění kanálu zobrazuje nejnovější protokol kontroly. To platí jenom pro kontroly, které se řídí doporučeným využitím.

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

Zakázání kontroly

Kontroly ladění byly méně zdlouhavé. Někdy kontrola vyvolání funkce Azure nebo vyvolání rozhraní REST API nefunguje správně a je potřeba ji opravit. Dříve jste takové kontroly museli odstranit, aby se zabránilo chybnému blokování nasazení. Jakmile jste kontrolu opravili, museli jste ji znovu přidat a správně nakonfigurovat, abyste měli jistotu, že jsou nastavené všechny požadované hlavičky nebo jsou správné parametry dotazu. Je to zdlouhavé.

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

Jakmile chybnou kontrolu opravíte, můžete ji jednoduše povolit.

Spotřebované prostředky a parametry šablony v rozhraní REST API spuštění kanálů

Rozšířené rozhraní REST API spouštění kanálů teď vrací více typů artefaktů používaných spuštěním kanálu a parametry použité k aktivaci tohoto spuštění. Vylepšili jsme rozhraní API tak, aby vracela container prostředky a pipeline a parametry šablony použité při spuštění kanálu. Teď můžete například napsat kontroly dodržování předpisů, které vyhodnotí ú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"
}

Podpora šablon pro obecnou dostupnost v editoru YAML

Šablony jsou běžně používanou funkcí v kanálech YAML. Představují snadný způsob, jak sdílet fragmenty kódu kanálu. Jsou také výkonným mechanismem při 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 ale šablony až dosud nepodpořil. Autoři kanálů YAML nemohli získat pomoc prostřednictvím Technologie IntelliSense při použití šablony. Autoři šablon nemohli využí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í se nezdaří a zobrazí se výzva 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.
• Z 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 sestavení. Proměnná je k dispozici v kanálech sestavení YAML i Classic.

Pokud je váš kanál například uložený ve FabrikamFiber\Chat složce v Azure Pipelines, hodnota je Build.DefinitionFolderPathFabrikamFiber\Chat.

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

Kanály YAML poskytují pohodlné způsoby, jak omezit duplikaci kódu, jako je například procházení each hodnoty seznamu nebo vlastnosti objektu.

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

Když jsme si vyslechli vaši zpětnou vazbu od Developer Community, slyšeli jsme, že chcete ve výrazech šablon YAML použít funkci řetězcesplit.

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

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. Naši Developer Community tuto funkci velmi požadovali.

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

Řekněme například, že máte kanál, který vytváří vlastní úložiště, a k tomu potřebuje rezervovat knihovnu z úložiště prostředků. Kromě toho řekněme, že chcete, aby váš kanál rezervovat stejnou větev knihovny, kterou sám používá. Pokud například váš kanál běží ve main větvi, měl by rezervovat main větev úložiště knihovny. Pokud kanály běží ve dev větvi, měla by se rezervovat dev větev knihovny.

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

Teď můžete pomocí výrazů šablony zvolit větev prostředku úložiště. Podívejte se na následující příklad kódu YAML, který se použije 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á pro library úložiště rezervovat.

Určení verze šablony, která se má rozšířit v době fronty sestavení

Šablony představují skvělý způsob, jak omezit duplicitu kódu azlepšit zabezpečení vašich kanálů.

Jedním z oblíbených případů použití je vytvoření šablon ve vlastním úložišti. Tím se omezí spojení mezi šablonou a kanály, které ji rozšiřují, a usnadníte si nezávisle vyvíjet šablonu a kanály.

Představte si 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 úložišti Templates .

# 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ý tuto šablonu rozšiřuje, umístěný v úložišti FabrikamFiber. Až do dnešního dne nebylo možné dynamicky zadat ref vlastnost templates prostředku úložiště při použití úložiště jako zdroje šablony. To znamená, že jste museli změnit kód kanálu, pokud chcete, aby váš kanál: Rozšíření šablony z jiné větve rozšíření šablony o stejný název větve jako váš kanál bez ohledu na to, ve které větvi jste kanál spustili.

Se zavedením výrazů šablon v definici prostředku úložiště můžete kanál napsat 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

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

Nebo můžete v době fronty sestavení zvolit, kterou větev úložiště šablon se má použít, 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 nechat kanál ve větvi main rozšířit šablonu z větve dev v jednom spuštění a rozšířit šablonu z větve main v jiném spuštění, aniž byste museli měnit kód kanálu.

Při zadávání výrazu šablony pro ref vlastnost prostředku úložiště můžete použít parameters předdefinované proměnné a systému, 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í endpointvlastností container , volumes, portsa options prostředku v kanálu YAML. Naši Developer Community tuto funkci velmi požadovali.

Teď můžete napsat kanály YAML jako v následujícím příkladu.

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'

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

Vylepšení plánovaných buildů

Opravili jsme problém, který způsoboval poškození informací o plánu kanálu a nenačetl se kanál. Příčinou je například překročení určitého počtu znaků v názvu 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 způsobu 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 naplánovaném spuštění kanálu poškodí a můžou způsobit selhání zatížení. Dříve jsme zobrazovali zavádějící chybovou zprávu s tvrzením, že se kanál nenašel. Touto aktualizací jsme tento problém vyřešili a vracíme informativní chybovou zprávu. V budoucnu se zobrazí zpráva podobná této: Data plánu sestavení jsou poškozena , pokud se nepodaří načíst kanál.

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 také všechny objekty, na které tyto značky odkazuje. Tím se prodlužuje doba spuštění úlohy v kanálu – zejména pokud máte velké úložiště s několika značkami. Kromě toho úloha pokladny synchronizuje značky i v případě, že povolíte možnost mělkého načtení, čímž může dojít k ukončení jejího účelu. Abychom snížili množství dat načtených nebo načítaných z úložiště Git, přidali jsme do úlohy novou možnost, která řídí chování synchronizace značek. Tato možnost je k dispozici v klasických kanálech i kanálech YAML.

YAML

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

Pokud chcete zrušit synchronizaci značek prostřednictvím souboru YAML, přidejte fetchTags: false do kroku rezervace příkaz . fetchTags Pokud možnost není zadaná, je stejná, jako kdyby fetchTags: true se použila.

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í existujících kanálů YAML, může být vhodnější nastavit tuto možnost 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 Aktivační události, pak Proces a pak krok Rezervace.

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

Klasický

Pokud chcete synchronizaci značek zrušit, zrušte zaškrtnutí políčka Synchronizovat značky v kroku získání zdrojů.

U všech nových kanálů, které vytvoříte (YAML nebo Classic), se značky stále synchronizují ve výchozím nastavení. Tato možnost nemění chování existujících kanálů. Značky se v těchto kanálech budou 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ík při vytvoření nového kanálu Azure Artifacts s oborem kolekce projektů místo aktuální role Přispěvatel .

Nové uživatelské rozhraní pro vyhledávání nadřazených balíčků

Dříve jste mohli zobrazit upstreamové balíčky, pokud jste měli kopii informačního kanálu. Nebylo možné vyhledat balíčky, které jsou k dispozici v upstreamu a které ještě nejsou uložené v informačním kanálu. Teď 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 nadřazených zdrojích a ukládat verze balíčků do informačního kanálu. To je v souladu s cílem Microsoftu vylepšovat naše produkty a služby.

Generování sestav

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

Widget Výsledky dotazu teď podporuje jméno rodiče a přímý odkaz na tento nadřazený objekt.

Kopírovat řídicí panel

V této verzi zahrnujeme kopírování řídicího panelu.

Datum posledního přístupu na řídicích panelech a autor změny

Jednou z výzev, které týmům umožňují vytvářet několik řídicích panelů, je správa a vyčištění zastaralých a nepoužívaných řídicích panelů. Informace o tom, kdy byl řídicí panel naposledy navštíven nebo změněn, je důležitou součástí toho, abyste pochopili, které řídicí panely je možné odebrat. V této verzi jsme na stránku 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: Sleduje, kdy byl řídicí panel naposledy upravován a kým.

Informace Změněno uživatelem se zobrazí také na samotné stránce řídicího panelu.

Doufáme, že tato nová pole pomohou správcům projektů pochopit úroveň aktivity řídicích panelů, aby se mohli dobře rozhodnout, jestli se mají odebrat nebo ne.

K dispozici jsou teď analytická zobrazení.

Funkce Zobrazení analýzy je v naší hostované verzi produktu po delší dobu ve verzi Preview. V této verzi s radostí oznamujeme, že tato funkce je nyní dostupná pro všechny kolekce projektů.

V navigaci se zobrazení Analytics 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ě dat analýzy. Pokud nemáte zkušenosti s analytickými zobrazeními, tady je několik dokumentace, která vás seznámí:

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

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

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

Lístek návrhů komunity

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

Chápeme, jak je důležité přesně odrážet týmový pokrok, včetně vyřešených položek, které jsou v grafech dokončené. Pomocí jednoduchého přepínače teď můžete zvolit zobrazení vyřešených položek jako dokončených a poskytnout tak skutečnou reflexi stavu burndownu týmu. Toto vylepšení umožňuje přesnější sledování a plánování a umožňuje týmům činit informovaná rozhodnutí na základě skutečného pokroku. Díky aktualizovaným grafům burndownu a burnupu v generování sestav můžete získat lepší transparentnost a lepší přehledy.

Wiki

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

Upgradovali jsme verzi grafů mořské panny používané na wiki stránkách na verzi 8.13.9. Díky tomuto upgradu teď můžete na stránky wikiwebu Azure DevOps zahrnout následující diagramy a vizualizace:

• Vývojový diagram
• Sekvenční diagramy
• Ganttův diagram
• 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.

---

Zpětná vazba

Chceme znát váš názor. Můžete nahlásit problém nebo poskytnout nápad a sledovat ho prostřednictvím Developer Community a získat rady ke službě Stack Overflow.

---

Začátek stránky