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

---

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

---

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

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

Pokud chcete stáhnout produkty Azure DevOps Serveru, přejděte na stránku pro stahování Azure DevOps Serveru.

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

Soubor	SHA-256 hash
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 wiki a pracovních položkách, kdy výsledky hledání nebyly k dispozici pro projekty, které měly turecké "I" v názvu pro turecké jazykové nastavení.

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

Soubor	SHA-256 hash
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	SHA-256 hash
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í pro 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í Azure DevOps Server 2022 Aktualizace 1 Oprava 1: 12. prosince 2023

Soubor	SHA-256 hash
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 zařazování spuštění kanálu do fronty.

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 neaktualizuje po upgradu na Azure DevOps Server 2022.1 a použití funkce Update Agent v konfiguraci fondu agentů. 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 můžete najít alternativní řešení pro tento problém v této vývojářské komunitě.
2. Kompatibilita Maven 3.9.x Maven 3.9.x zavedl zásadní změny s Azure Artifacts aktualizací výchozího transportu Maven Resolver na native HTTP z 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 i nadále používat Maven 3.9.x s vlastností -Dmaven.resolver.transport=wagon. Tato změna vynutí Maven používat Wagon Resolver Transport. Další podrobnosti najdete v dokumentaci.

Azure DevOps Server 2022.1 je kompilace 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 s Azure Artifacts aktualizací výchozího transportu Maven Resolver na native HTTP z 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 i nadále používat Maven 3.9.x s vlastností -Dmaven.resolver.transport=wagon. Tato změna vynutí Maven používat Wagon Resolver Transport. 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 s Azure Artifacts aktualizací výchozího transportu Maven Resolver na native HTTP z 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 i nadále používat Maven 3.9.x s vlastností -Dmaven.resolver.transport=wagon. Tato změna vynutí Maven používat Wagon Resolver Transport. 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í záložek z Kódu na jinou záložku na stránce Hledání v rámci systému 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
• Funkce @CurrentIteration v Plánech dodání
• 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é
• Vývěsky
• Repos
• Potrubí
• Artefakty
• Podávání zpráv
• Wikiweb

---

Obecné

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

V minulosti nebylo několik veřejně zdokumentovaných rozhraní REST API Azure DevOps přidruženo k žádným rozsahům (např. čtení pracovní položky), což vedlo k tomu, že zákazníci museli používat plné rozsahy k využívání těchto rozhraní API prostřednictvím neinteraktivních metod ověřování, jako jsou osobní přístupové tokeny (PAT). Použití osobního přístupového tokenu s úplným rozsahem zvyšuje riziko, pokud padne do rukou škodlivého uživatele. To je jeden z hlavních důvodů, proč mnoho našich zákazníků nevyužilo naplno zásady řízení kontroly 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 rozsahy.

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.

Rady

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í. Klikněte znovu pro vypnutí řádků.

)

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 úkolu a rozhraních REST API pro hlášení. 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.

Zvyšte limit týmu v Plánech 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 backlogů týmů, což zahrnovalo mix backlogů a týmů z různých projektů. V této verzi jsme zvýšili maximální limit z 15 na 20.

Opravená chyba v rozhraní API pro získání odkazů na pracovní položky v reportingu

Opravili jsme chybu v rozhraní API pro generování sestav, která nyní vrací správnou hodnotu remoteUrl pro System.LinkTypes.Remote.Related typy odkazů pracovních položek. 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 příkladů tvůrců rozšíření, kteří se pokoušejí spustit neuložené dotazy předáním příkazu WIQL (Work Item Query Language) pomocí dotazovacího řetězce. 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í přes dotazovací řetězec 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 hromadné čištění může být omezeno tempo zpracování. Jako reakci na danou situaci jsme přidali nový koncový bod API pro dávkové odstranění a/nebo smazání pracovních položek.

@CurrentIteration makro v Plánech doručení

V této aktualizaci jsme přidali podporu makra @CurrentIteration pro styly v Dodacích plánech. 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 každý používá cílové datum a/nebo počáteční datum při sledování stavu funkcí a epik. 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í hromadné aktualizace

Provedli jsme několik změn v rozhraní API pro dávkové aktualizace pracovních položek ve verzi 7.1. 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 hromadné odstranění a/nebo zničení pracovních položek je nyní veřejně dostupný. Další informace získáte po kliknutí sem.

Zabránit úpravám polí ve výběrových seznamech, které lze 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 Nastavení projektu > Konfigurace projektu > Oblastní cesta. 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í tabule – zprávy

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, byla vám udělena oprávnění k úpravám zásad v nové větvi. Při této aktualizaci měníme výchozí chování tak, aby toto 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ě.

Potrubní systémy

Stávající projekt je určen jako výchozí rozsah pro přístupový token pro 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 token zabezpečení, který se dynamicky generuje 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 sestavovacích procesů, při vytváření nového procesu bude obor autorizace úlohy sestavení ve výchozím nastavení nastaven na projekt. 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ískat informace o žádosti o sloučení
• Hlá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. 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. Díky tomu můžete cílit na službu 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 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

Zažijte vylepšení oprávnění v pipeline

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. To 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 schválení podporuje rozsahPipeline Resources Use
• Správa kontrol podporuje rozsah Pipeline Resources Use and Manage
• Oprávnění pro aktualizaci kanálu pro zdroje podporuje obor Pipeline Resources Use and Manage
• Autorizace prostředků definice podporuje obor Pipeline Resources Use and Manage
• Autorizace zdrojů projektu podporuje rozsah 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 kritické pro vaši schopnost bezpečně sestavovat a nasazovat aplikace, služba Azure Pipelines nyní vyžaduje roli správce typu prostředku při poskytnutí přístupu k prostředkům pro všechny pipeliny.

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, pokud při vytváření připojení služby nemáte dostatečná práva, je možnost Udělit přístup k potrubím zakázaná.

Také při pokusu o otevření přístupu k existujícímu prostředku, a pokud nemáte dostatečná práva, obdržíte zprávu Nemáte oprávnění k otevření přístupu k tomuto prostředku.

Vylepšení zabezpečení rozhraní REST API pro pipeliny

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 provedli zlepšení napříč platformou, abychom odstranili 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ů

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

Dříve, pokud jste použili vlastní fond agentů, bylo spravování toho, které kanály k němu mají přístup, hrubě nastavené. 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í. Bohužel, když jste udělili pipeline oprávnění k přístupu k fondu agentů, nemohli jste ho odvolat pomocí uživatelského rozhraní pipeline.

Azure Pipelines teď poskytuje podrobnou správu přístupu pro fondy agentů. Zkušenost se podobá té při správě oprávnění pro kanály v rámci připojení služeb.

Zamezení tomu, aby všechny pipelines měly přístup k chráněným prostředkům

Když vytvoříte chráněný prostředek, jako je připojení služby nebo prostředí, máte možnost zaškrtnout políčko Udělit povolení přístupu všem kanálům. Doteď byla tato možnost ve výchozím nastavení zaškrtnutá.

Ačkoli to usnadňuje potrubím používání nových chráněných prostředků, riziko spočívá v tom, že může dojít k neúmyslnému udělení práva na přístup k prostředku příliš mnoha potrubím.

Pokud chcete podpořit zabezpečení ve výchozím nastavení, Azure DevOps nyní ponechává políčko nezaškrtnuté.

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é, že '3' 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 Node 6 v režimu just-in-time, aby stará úloha mohla stále běžet:

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

Aktualizované ověření spouštěče uzlu 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.

Rozšíření, která obsahují úlohy využívající běhové prostředí Node 6, uvidí toto varová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 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 Pipeline 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 úloha nástroje PowerShell@2, která umožňuje spouštět skripty PowerShellu v potrubí. 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 je vlastnost úkolů progressPreference a PowerShell@2 nyní nastavena jako výchozí hodnota na AzurePowerShell@5.

Agent Pipelines v3 v .NET 6

Agent kanálu byl upgradován, aby jako modul runtime používal .NET Core z verze 3.1 na verzi 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ě ukončujeme podporu pro 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čete verzi agenta v rozšíření VM 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é pipeliny budou nadále 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 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é pipeliny budou nadále běžet a budete je moct upravovat, ale nebudete moct vytvářet nové.

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 Projekt / Nastavení 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, zakázání bude vynuceno pro všechny projekty. V opačném případě má každý projekt volnost v rozhodnutí, zda vynutí deaktivaci či nikoli.

Pokud je vynuceno zakázání vytváření klasických kanálů, selžou rozhraní REST API související s vytvářením klasických kanálů, skupin úloh a skupin nasazení. 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

Napojení služeb umožňují spouštět úkoly na jiných službách, když ve vašem projektu na Azure DevOps nastanou události, změna stavu fáze spuštění je jednou z těchto událostí. Událost změny stavu fáze spuštění musí obsahovat informace o spuštění, včetně názvu potrubí. 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.

Háček služby pro změnu stavu úlohy

Služby háků umožňují reakci na události související se změnami stavu během běhů vašeho kanálu. Až dosud jste mohli nakonfigurovat připojení služeb pro změny stavu běhu a etap potrubí.

Nyní můžete nakonfigurovat servisní hooky, které se aktivují, když se změní stav úlohy ve vašem skriptu. Struktura datové části nové události je znázorněna v následujícím příkladu.

{
    "subscriptionId": "8d91ad83-1db5-4d43-8c5a-9bb2239644b1",
    "notificationId": 29,
    "id": "fcad4962-f3a6-4fbf-9653-2058c304503f",
    "eventType": "ms.vss-pipelines.job-state-changed-event",
    "publisherId": "pipelines",
    "message":
    {
        "text": "Run 20221121.5 stage Build job Compile succeeded.",
        "html": "Run 20221121.5 stage Build job <a href=\"https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088\">Compile</a> succeeded.",
        "markdown": "Run 20221121.5 stage Build job [Compile](https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088) succeeded."
    },
    "detailedMessage":
    {
        "text": "Run 20221121.5 stage Build job Compile succeeded.",
        "html": "Run 20221121.5 stage Build job <a href=\"https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088\">Compile</a> succeeded.",
        "markdown": "Run 20221121.5 stage Build job [Compile](https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088) succeeded."
    },
    "resource":
    {
        "job":
        {
            "_links":
            {
                "web":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088"
                },
                "pipeline.web":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/definition?definitionId=4647"
                }
            },
            "id": "e87e3d16-29b0-5003-7d86-82b704b96244",
            "name": "Compile",
            "state": "completed",
            "result": "succeeded",
            "startTime": "2022-11-21T16:10:28.49Z",
            "finishTime": "2022-11-21T16:10:53.66Z"
        },
        "stage": { ... },
        "run": { ... },
        "pipeline": { ... },
        "repositories": [ ... ]
    },
    "resourceVersion": "5.1-preview.1",
    "createdDate": "2022-11-21T16:11:02.9207334Z"
}

Události háku služby pro změnu stavu běhu, fáze a úlohy teď obsahují repository vlastnost, která obsahuje seznam úložišť Azure spotřebovaných během pipelinové práce. Například:

"repositories":
[
    {
        "type": "Git",
        "change":
        {
            "author":
            {
                "name": "Fabrikam John",
                "email": "john@fabrikamfiber.com",
                "date": "2022-11-11T15:09:21Z"
            },
            "committer":
            {
                "name": "Fabrikam John",
                "email": "john@fabrikamfiber.com",
                "date": "2022-11-11T15:09:21Z"
            },
            "message": "Added Viva support"
        },
        "url": "https://fabrikamfiber@dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_git/fabrikamfiber"
    }
]

Zakázat zobrazení poslední zprávy potvrzení pro běh pipeline.

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

Tato zpráva může být matoucí, například když kód YAML kanálu je v jiném úložišti než 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, zobrazí se pouze BuildNumber ve spuštění kanálu.

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

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

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

S touto verzí usnadňujeme přehled o celkovém stavu běhu pipeline.

U YAML kanálů, které mají mnoho fází, bylo obtížné zjistit stav běhu kanálu, tedy zda je stále spuštěný nebo zda už skončil. 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 stupňů potrubí

Kanály YAML můžou mít desítky fází a ne všechny se vejdou na obrazovku. Ačkoliv ikona přehledu běhu datového toku informuje o celkovém stavu vašeho běhu, 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.

Zorganizujte rychlé akce

Obrazovka Běhy pipelineu umožňuje rychlý přístup ke všem etapám běhu. 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 schválení omylem, Azure DevOps zobrazí pokyny pro schvalovatele na bočním panelu Schválení a kontroly na stránce s podrobnostmi o spuštění kanálu.

Zakázání kontroly

Učinili jsme proces ladění méně zdlouhavým. 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 jste kontrolu opravili, museli jste ji znovu přidat a správně nakonfigurovat, abyste měli jistotu, že jsou nastavená všechna požadovaná záhlaví a 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 vrací container i 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 jiné běhy kanálu používané tímto 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ů pipeline. 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 procesu.

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 podporu prostřednictvím 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 YAML i klasických buildových pipelinech.

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, například procházením pomocí smyčky prvky 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 je seznam prostředí, do kterých se má nasadit, definován řetězcem 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 zdroje ú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 váš pipeline zkontroloval různé větve stejného repozitáře.

Řekněme například, že máte pipeline, která sestaví vlastní úložiště, a proto musí získat knihovnu z repozitáře zdrojů. Navíc předpokládejme, že chcete, aby váš datový kanál použil stejnou větev knihovny, jakou sám používá. Například, pokud váš pipeline běží ve main větvi, měl by přepnout na main větev repozitáře 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, na kterou se má přepnout, a změnit kód pipeline pokaždé, když se větev změní.

Teď mohou pomocí šablonových výrazů zvolit větev zdroje ú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 azlepšit zabezpečení kanálů.

Jedním z oblíbených případů použití je ukládat šablony ve vlastní úložišti. 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. Do dnešního dne nebylo možné vlastnost ref prostředku úložiště templates dynamicky určit 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 zdrojů úložiště můžete váš pipeline 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í. Znamená to, že když spustíte svůj kanál ve větvi dev, šablona určená souborem template.yml se rozšíří ve větvi dev úložiště templates.

Nebo si můžete při vytváření fronty sestavování zvolit větev úložiště šablony, která se má použít, zadá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 svůj kanál ve větvi main, který v jednom spuštění rozšíří šablonu z větve dev, a v jiném spuštění rozšíří šablonu z větve main, a to bez nutnosti měnit kód vašeho 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 zdrojů kontejneru

Přidali jsme podporu výrazů šablon při definování endpointvolumesportsprostředku v kanálu YAML .optionscontainer 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 potrubí a bránil načtení potrubí. Toto bylo způsobeno například, když název větve překročil určitý počet znaků.

Vylepšená chybová zpráva v případě neúspěšného načítání potrubí

Azure Pipelines poskytuje několik typů spouštěčů pro nastavení spuštění vašeho kanálu. Jedním ze způsobů spuštění potrubí je použití plánovaných spouště. 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. Pokud se nepodaří nahrát pipelinu, zobrazí se zpráva podobná: Data plánu sestavení jsou poškozena.

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

Úloha checkout používá možnost --tags pro načtení 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ýší čas potřebný k provedení úlohy v potrubí, zejména pokud máte velké úložiště s množstvím značek. Kromě toho úloha "checkout" synchronizuje značky i v případě, že povolíte možnost mělkého načítání, čímž může změnit 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.

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 fetchTags: false do kroku pokladny. Pokud není fetchTags možnost zadaná, je stejná, jako kdyby byla použita možnost fetchTags: true.

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 datový tok, vyberte Spouštěče, pak Proces a pak krok Převzetí.

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 pipelinách dál synchronizovat, pokud explicitně nezměníte nastavení, jak je popsáno výše.

Artefakty

Aktualizováno výchozí 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 kanálu. Problém spočíval v tom, že jste nemohli 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é balíčky z upstreamu pomocí nového uživatelského rozhraní feedu.

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.

Reportování

Zobrazit nadřazenou položku 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 analytické přehledy přesunuly z karty Přehled na kartě Panely.

Analytické zobrazení poskytuje zjednodušený způsob zadávání filtračních kritérií pro sestavu Power BI vycházející z 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:

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

Widget Pull Requestu pro více úložišť je nyní dostupný.

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, že stav "vyřešené" je nyní označen jako "dokončené" v burndown a burnup grafech.

Rozumíme důležitosti přesného zobrazení pokroku týmu, zahrnující dokončené vyřešené položky v grafech. Pomocí jednoduché možnosti přepínače se teď můžete rozhodnout zobrazit dokončené vyřešené položky, což poskytuje skutečný přehled o 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. Zažijte zvýšenou transparentnost a lepší přehled s aktualizovanými grafy úbytku a nárůstu v reportech.

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
• 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é. Najdete v poznámkách k verzi Mermaid další informace o nových funkcích.

---

Zpětná vazba

Rádi bychom vás slyšeli! 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