Sdílet prostřednictvím

Vylepšení YAML ve službě Azure Pipelines – Aktualizace Sprint 142

  • Článek

Ve sprintu 142 Update Azure DevOps došlo k několika vylepšením YAML, jako je přidání vlastních čítačů do sestavení, určení větví, které se mají sestavit pro žádosti o přijetí změn, a použití vložených šablon. Také jsme zapnuli novou navigaci pro všechny uživatele, zavedli jsme tmavý motiv a vylepšili jsme prostředí pro propojení a přílohy v Azure Boards.

Další informace najdete v níže uvedeném seznamu funkcí .

Funkce

Obecné:

Azure Boards:

Azure Repos:

Azure Pipelines:

Azure Test Plans:

Azure Artifacts:

Wiki:

Správa:

Obecné

Pro všechny uživatele je zapnutá nová navigace.

Zapnuli jsme novou navigaci pro všechny uživatele. Jedná se o významný milník při zavádění našeho nového návrhu produktu. I když v této verzi přesouváme všechny uživatele na nový navigační model, uživatelé budou moct do 16. ledna 2019 stále odhlásit a používat starou navigaci. Můžete to zrušit tak, že v nabídce pod avatarem v pravém horním rohu každé stránky vyberete funkce Preview .

Další informace najdete v blogovém příspěvku Aktualizace navigace .

Tmavý motiv

Jednou z našich dlouhodobých žádostí o funkce je nabídnout tmavý motiv. S radostí vám dáme vědět, že je teď k dispozici jako součást nové navigace. Tmavý motiv můžete zapnout tak, že v nabídce pod avatarem v pravém horním rohu každé stránky vyberete Motiv .

Tmavý motiv

Azure Boards

Uspořádání referenčních materiálů pomocí rozsáhlejších příloh pracovních položek

Připojení souborů k pracovním položkám umožňuje vám a vašemu týmu centralizovat referenční materiály tak, aby byly vždy blízko, když je potřebujete. Teď je jednodušší přidat novou přílohu tak, že soubor přetáhnete kamkoli do formuláře pracovní položky. Přílohy můžete dál prohlížet jako seznam nebo přepnout do zobrazení mřížky a zobrazit náhled miniatury. Poklikáním na soubor otevřete náhled a cyklicky si ho projděte, abyste rychle našli potřebné informace.

Přílohy pracovních položek

Správa závislostí propojením pracovních položek v rámci organizace

Propojení související nebo závislé práce poskytuje širší kontext pro práci, kterou sledujete, a pomáhá spravovat závislosti s jinými týmy. Díky odkazům pro práci na dálku teď můžete sledovat práci v organizacích ve vaší společnosti. Jednoduše zkopírujte adresu URL existující pracovní položky, přejděte na jinou pracovní položku a vytvořte odkaz pomocí jednoho ze tří nových typů odkazů: Spotřebuje z, Produkuje pro a Vzdálený související. Další informace o sledovatelnosti v Azure Boards najdete v dokumentaci k propojení pracovních položek.

Poznámka

Oprávnění se respektují v obou organizacích Azure DevOps, které musí být podporovány stejným tenantem Azure AD.

Vzdálené propojení

Jakmile začnete spravovat několik závislostí, použijte nové pole Počet vzdálených propojení v dotazech k zobrazení seznamu pracovních položek, které mají vzdálené závislosti v projektu, nebo zvažte instalaci rozšíření Sledování závislostí . Toto rozšíření, které bylo vytvořeno skupinou Windows v Microsoftu, aby vyhovovalo jejich požadavkům na škálování, staví na vzdálených odkazech, které zobrazují bohatou hierarchii a grafické znázornění závislostí.

Dříve nešlo pracovní položku otevřít ze stránky výsledků hledání, pokud bylo podokno náhledu pracovní položky vypnuté. To by ztěžovalo probádání výsledků hledání. Teď můžete kliknutím na název pracovní položky otevřít pracovní položky v modálním okně. Tato funkce byla upřednostněna z UserVoice.

Azure Repos

Autoři rozšíření se můžou dotazovat na kontext aktuálního úložiště.

Jednou z výzev pro autora rozšíření správy verzí je získání kontextu úložiště, které se uživateli zobrazuje, jako je jméno, ID a adresa URL. Abychom tomu pomohli, přidali jsme VersionControlRepositoryService jako službu s podporou rozšíření. Autor rozšíření se tak může dotazovat na informace o aktuálním kontextu úložiště Git v rámci webového uživatelského rozhraní. V současné době má jednu metodu getCurrentGitRepository().

  • Pokud je vybrané úložiště Git, vrátí se objekt GitRepository se základními daty o úložišti (název, ID a adresa URL).
  • Pokud je vybrané úložiště TFVC nebo se ke službě přistupuje mimo stránky Azure Repos, vrátí se hodnota null.

Tady je ukázkové rozšíření , které tuto službu používá.

Azure Pipelines

Přidání vlastních čítačů sestavení do sestavení

Čítače sestavení poskytují způsob, jak jedinečně očíslovat a označovat sestavení. Dříve jste k tomu mohli použít speciální proměnnou $(rev:r). Teď můžete v definici sestavení definovat vlastní proměnné čítačů, které se automaticky zvýší při každém spuštění sestavení. Provedete to na kartě proměnných definice. Tato nová funkce poskytuje větší výkon následujícími způsoby:

  • Můžete definovat vlastní čítač a nastavit jeho počáteční hodnotu. Můžete například spustit čítač na 100. $(rev:r) začíná vždy na hodnotě 0.
  • K resetování čítače můžete použít vlastní logiku. $(rev:r) je svázaná s generováním čísla sestavení a automaticky se resetuje vždy, když je v čísle sestavení nová předpona.
  • Na definici můžete definovat více čítačů.
  • Můžete se dotazovat na hodnotu čítače mimo sestavení. Pomocí čítače můžete například spočítat počet sestavení, která se spustila od posledního resetování.

Další informace o čítačích sestavení najdete v dokumentaci k uživatelem definovaným proměnným .

Použití YAML k určení větví, které se mají sestavit pro žádosti o přijetí změn

Kanály YAML můžou určit, které větve se mají sestavit pro žádosti o přijetí změn (žádosti o přijetí změn). Můžete zvolit větve, které chcete zahrnout a vyloučit. Tato schopnost byla dříve dostupná ve webovém uživatelském rozhraní. Přesunutím do souboru YAML se stane součástí pracovního postupu konfigurace jako kódu.

Příklad použití triggerů žádosti o přijetí změn může vypadat takto:

pr:
  branches:
    include:
    - features/*
    exclude:
    - features/experimental/*
  paths:
    include:
    - **/*.cs

steps:
- script: echo My PR build!

Použití vložených výrazů šablon YAML

Šablony YAML představují účinný způsob opakovaného použití částí kanálů. Kromě faktoringu běžného kódu umožňují výrazy šablony měnit hodnoty a řídit, co YAML obsahuje. Až dosud musel výraz šablony zabírat celou hodnotu ve výrazu YAML. Tento příklad by fungoval, protože výraz je celá hodnota vlastnosti řešení .

- task: msbuild@1
  inputs:
    solution: ${{ parameters.solution }}

Teď jsme omezení zmírnili a povolili vložené šablony, jak vidíte v následujícím příkladu.

- script: echo The solution file is ${{ parameters.solution }}

Vylepšení řešení potíží s protokolem inicializace kanálu

Při spuštění kanálu musí Azure Pipelines zajistit správnost definice kanálu, rozhodnout, jaké úlohy se mají naplánovat, požádat agenty o spuštění úloh atd. Až dosud byl tento proces zcela neprůhlhlý, takže když se něco pokazilo, bylo pro zákazníka téměř nemožné problém vyřešit. Zavádíme nový druh protokolu, který se nazývá protokol inicializace kanálu, díky kterému jsou tyto podrobnosti viditelné. K protokolu inicializace kanálu se dostanete tak, že u dokončeného sestavení zvolíte možnost Stáhnout všechny protokoly .

Výchozí uchovávání pro kanály YAML

Pracujeme na tom, aby uživatelé mohli nakonfigurovat zásady uchovávání informací pro kanály YAML. Dokud nebude tato nová funkce dostupná, zvýšili jsme výchozí uchovávání pro všechny buildy YAML na 30 dnů, protože mnoho uživatelů chce své buildy uchovávat déle, než je výchozí uchovávání předchozích 10 dnů. V editoru pro kanály YAML jsme odebrali kartu uchovávání informací, dokud nebude nový model zaveden.

Sestavování na 32bitových platformách Linux/ARM a Windows

Multiplatformní agent Azure Pipelines open source byl vždy podporován v 64bitových (x64) systémech Windows, macOS a Linux. V tomto sprintu představujeme dvě nové podporované platformy: Linux/ARM a Windows/32-bit. Tyto nové platformy vám umožňují stavět na méně běžných, ale ne méně důležitých platformách, jako je Raspberry Pi, počítač s Linuxem nebo ARM.

Klonování skupin proměnných

Přidali jsme podporu klonování skupin proměnných. Kdykoli chcete replikovat skupinu proměnných a jenom aktualizovat několik proměnných, nemusíte procházet zdlouhavým procesem přidávání proměnných jeden po druhém. Teď můžete rychle vytvořit kopii skupiny proměnných, odpovídajícím způsobem aktualizovat hodnoty a uložit ji jako novou skupinu proměnných.

Klonovat skupinu proměnných

Poznámka

Při klonování skupiny proměnných se nezkopírují hodnoty tajných proměnných. Musíte aktualizovat šifrované proměnné a pak uložit naklonovanou skupinu proměnných.

Zobrazení potvrzení a pracovních položek pro všechny propojené zdroje

S radostí oznamujeme, že zákazníci teď můžou zobrazit podrobnosti potvrzení a pracovních položek pro všechny artefakty propojené s kanálem. Ve výchozím nastavení se potvrzení a pracovní položka porovnávají s posledním nasazením do stejné fáze. V případě potřeby ale můžete porovnat s jakýmkoli jiným předchozím nasazením.

Propojené zdroje

Spuštění z balíčku podporovaného v nasazeních Azure App Service

Verze úlohy Azure App Service Deploy (4.*) teď podporuje RunFromPackage (dříve s názvem RunFromZip).

App Service podporuje řadu různých technik nasazení souborů, jako jsou msdeploy (neboli WebDeploy), git, ARM a další. Ale všechny tyto techniky mají omezení. Vaše soubory se nasadí do složky wwwroot (konkrétně d:\home\site\wwwroot) a modul runtime pak spustí soubory z této složky.

U příkazu Spustit z balíčku už neexistuje krok nasazení, který zkopíruje jednotlivé soubory na wwwroot. Místo toho ho jednoduše nasměrujete na soubor ZIP a zip se připojí k wwwroot jako systém souborů jen pro čtení. To má několik výhod:

  • Snižuje riziko problémů se zamykáním kopírování souborů.
  • Dá se nasadit do produkční aplikace (s restartováním).
  • Můžete si být jistí, které soubory běží ve vaší aplikaci.
  • Zlepšuje výkon nasazení Azure App Service.
  • Může zkrátit časy studeného spuštění, zejména u funkcí JavaScriptu s velkými stromy balíčků npm.

Nasazení linuxových kontejnerů pomocí úlohy Nasazení aplikačního serveru

Verze 4.* úlohy Azure App Service Deploy teď podporuje nasazení vlastního kontejneru do Azure Functions v Linuxu.

Model hostování Linuxu pro Azure Functions je založený na kontejnerech Dockeru, které přinášejí větší flexibilitu z hlediska balení a využití závislostí specifických pro aplikace. Funkce v Linuxu je možné hostovat ve 2 různých režimech:

  1. Integrovaná image kontejneru: Přinášíte kód aplikace funkcí a Azure poskytuje a spravuje kontejner (integrovaný režim image), takže se nevyžadují žádné konkrétní znalosti související s Dockerem. To je podporováno ve stávající verzi úlohy App Service Deploy.
  2. Vlastní image kontejneru: Vylepšili jsme úlohu App Service Deploy tak, aby podporovala nasazování vlastních imagí kontejnerů do Azure Functions v Linuxu. Pokud vaše funkce potřebují konkrétní verzi jazyka nebo vyžadují konkrétní závislost nebo konfiguraci, která není k dispozici v integrované imagi, můžete vytvořit a nasadit vlastní image do funkce Azure Functions v Linuxu pomocí Azure Pipelines.

Azure Test Plans

Klient Azure Test Runneru pro spouštění ručních testů pro desktopové aplikace

Teď můžete pomocí klienta Azure Test Runner (ATR) spouštět ruční testy pro desktopové aplikace. To vám pomůže přejít z Microsoft Test Manageru na Azure Test Plans. Projděte si prosím naše doprovodné materiály tady. Pomocí klienta ATR můžete spouštět ruční testy a zaznamenávat výsledky testů pro každý krok testu. Máte také možnosti shromažďování dat, jako je snímek obrazovky, protokol akcí obrázku a záznam zvukového videa. Pokud při testování narazíte na problém, vytvořte pomocí nástroje Test Runner chybu s testovacími kroky, snímky obrazovky a komentáři, které jsou automaticky zahrnuty do chyby.

ATR vyžaduje jednorázové stažení a instalaci runneru. Vyberte Spustit pro desktopovou aplikaci , jak je znázorněno níže.

Azure Test Runner

Instalace Azure Test Runneru

Azure Artifacts

Verze Public Preview artefaktů kanálu

Vydáváme verzi Public Preview artefaktů kanálu, nového vysoce škálovatelného typu artefaktů navržených pro použití se službou Azure Pipelines. Artefakty kanálů jsou založeny na stejné technologii, kterou používá nedávno oznámená funkce Univerzální balíčky , a může výrazně zkrátit dobu potřebnou k ukládání výstupů sestavení pro sestavení velkých podnikových tříd.

Wiki

Publikování kódu jako wikiwebu s oprávněními k přispívání

Dříve mohli jako wiki publikovat kód jenom uživatelé s oprávněním k vytvoření úložiště Git. Správci nebo tvůrci úložiště tak vytvořili kritický bod pro všechny požadavky na publikování souborů Markdownu hostovaných v úložištích Git jako wikiwebů. Teď můžete publikovat kód jako wikiweb , pokud máte jenom oprávnění k přispívání v úložišti kódu.

Správa

Paty vynucují CAP

V únoru 2017 jsme oznámili podporu zásad podmíněného přístupu (CAP) služby Azure Active Directory, ale bylo omezení, že alternativní mechanismy ověřování, jako jsou tokeny osobního přístupu, nebudou vynucovat CAP. S radostí oznamujeme, že jsme tuto mezeru vyplnili a Azure DevOps teď bude při používání patů, klíčů SSH, alternativních přihlašovacích údajů a OAuth dodržovat zásady ohraničení IP adres CAP. Správci nemusí dělat nic, aby mohli tuto funkci využívat. Automaticky se použije pro všechny existující zásady.

Další kroky

Poznámka

Tyto funkce budou zpřístupněné během následujících dvou až tří týdnů.

Přečtěte si o nových funkcích níže a přejděte do Azure DevOps, kde si je můžete vyzkoušet sami.

Přejít na Azure DevOps

Jak poskytnout zpětnou vazbu

Rádi bychom slyšeli, co si o těchto funkcích myslíte. Pomocí nabídky zpětné vazby můžete nahlásit problém nebo poskytnout návrh.

Vytvoření návrhu

Můžete také získat rady a odpovědi na vaše otázky od komunity na Webu Stack Overflow.

Díky,

Aaron Bjork