Nové sestavy Analytics a aplikace Azure Boards pro Slack – Aktualizace Sprintu 155
V aktualizaci Sprint 155 sady Azure DevOps představujeme nové sestavy Azure Boards, které vám usnadní sledování důležitých týmových metrik. Nové sestavy se budou zobrazovat na kartě analýz v centrech pro Boards, backlog a Sprint. Tyto sestavy jsou plně interaktivní a umožňují, abyste si je upravili podle vašich potřeb.
Dál s radostí oznamujeme novou aplikaci Azure Boards pro Slack. Tato aplikace vám umožní monitorovat aktivity pracovních položek a vytvářet pracovní položky z vašeho kanálu Slack.
Další informace najdete v následujícím seznamu funkcí .
Co je nového v Azure DevOps
Funkce
Obecné:
Azure Boards:
- Získání přehledu o stavu vašich týmů pomocí tří nových sestav Azure Boards
- Aplikace Azure Boards pro Slack
- Přizpůsobení sloupců panelů úloh
- Přepínač pro zobrazení nebo skrytí dokončených podřízených pracovních položek v backlogu
- Hledání panelů, backlogů, dotazů a sprintu z pole pro okamžité hledání
- Naposledy zobrazené značky při označování pracovní položky
Azure Repos:
- Vylepšené možnosti filtrování pro hledání kódu
- Metriky pokrytí kódu a zásady větví pro žádosti o přijetí změn
- Filtrování komentářových oznámení ze žádostí o přijetí změn
- Volané služby pro komentáře žádostí o přijetí změn
Azure Artifacts:
Azure Pipelines:
Vícefázové kanály YAML
- Schválení ve vícefázových kanálech YAML
- Správa proměnných kanálů v editoru YAML
- Nové předdefinované proměnné v kanálu YAML
- Zrušení fáze ve spuštění vícefázového kanálu YAML
- Zobrazení správných informací o fondech pro každou úlohu
- Propojení pracovních položek s vícefázovými kanály YAML
- Triggery CI pro nové větve
- Ukládání kanálů do mezipaměti (Public Preview)
Hostované virtuální počítače
Kubernetes
- kustomize a kompose jako simulační možnosti v úloze KubernetesManifest
- Podpora pro přihlašovací údaje správce clusteru v úloze HelmDeploy
Test
Prostředí Azure
- Vylepšení centra nasazování pro webové aplikace na webu Azure Portal
- Vylepšení projektu DevOps pro virtuální počítač
Integrace
OBECNÉ
Pozvání spolupracovníků GitHubu do Azure DevOps
Teď můžete pozvat spolupracovníky z GitHubu do Azure DevOps, když jste přihlášení pomocí své identity GitHubu. Ostatní uživatele GitHubu můžete vyhledávat a zvát z domovské stránky Projectu a na stránce Uživatelé v nastavení organizace.
Tato funkce musí být pro stávající organizace povolená prostřednictvím nastavení v části Zásady v nastavení organizace. Ve výchozím nastavení je ale pro organizace vytvořené identitou GitHubu zapnutá.
Poznámka:
Tato funkce není dostupná pro uživatele mimo GitHub, i když je zásada zapnutá.
Další informace o pozvání členů týmu najdete v této dokumentaci. Pokud máte problémy s připojením k Azure DevOps pomocí GitHubu, přečtěte si nejčastější dotazy k řešení potíží s ověřováním a pozváním uživatelů GitHubu.
Azure Boards
Získání přehledu o stavu vašich týmů pomocí tří nových sestav Azure Boards
Nemůžete opravit, co nevidíte. Proto chcete mít přehled o stavu a stavu jejich pracovních procesů. Díky těmto sestavám usnadňujeme sledování důležitých metrik s minimálním úsilím v Azure Boards.
Tři nové interaktivní sestavy jsou: Burndown, Kumulativní vývojový diagram (CFD) a Rychlost. Sestavy můžete zobrazit na nové kartě analýzy.
Metriky, jako je burndown sprintu, rychlost práce a týmu, poskytují přehled o průběhu vašeho týmu a pomáhají zodpovědět otázky, jako jsou:
- Kolik práce zbývá v tomto sprintu? Jsme na cestě, abychom to dokončili?
- Jaký krok procesu vývoje trvá nejdéle? Můžeme s tím něco udělat?
- Na základě předchozích iterací bychom měli naplánovat, kolik práce bychom měli naplánovat na další sprint?
Poznámka:
Dříve zobrazené grafy byly nahrazeny těmito vylepšenými sestavami.
Nové sestavy jsou plně interaktivní a umožňují vám je upravit podle svých potřeb. Nové sestavy najdete na kartě Analýza v každém centru.
Burndown chart najdete v centru Sprints .
Sestavy CFD a Velocity jsou přístupné z karty Analýza v části Panely a backlogy kliknutím na příslušnou kartu.
Díky novým sestavám máte větší kontrolu a informace o vašem týmu. Několik příkladů:
- Sestavy Sprint Burndown a Velocity lze nastavit tak, aby používaly počet pracovních položek nebo součet zbývající práce.
- Časový rámec burndownu sprintu můžete upravit, aniž by to mělo vliv na data projektu. Takže pokud váš tým obvykle stráví první den plánování sprintů, můžete se shodovat s grafem, aby to odráželo.
- Graf Burndown teď obsahuje vodoznak zobrazující víkendy.
- Sestava CFD umožňuje odebrat sloupce panelu, jako je Návrh, abyste se mohli více soustředit na tok, na kterém týmy mají kontrolu.
Tady je příklad sestavy CFD zobrazující tok za posledních 30 dnů backlogu scénářů.
Graf Rychlost je teď možné sledovat pro všechny úrovně backlogu. Teď můžete například přidat funkce i náměty, zatímco předchozí graf podporuje pouze požadavky. Tady je příklad sestavy rychlosti pro posledních 6 iterací backlogu funkcí.
Aplikace Azure Boards pro Slack
S radostí oznamujeme novou aplikaci Azure Boards pro Slack. Pomocí této aplikace můžete monitorovat aktivitu pracovních položek a vytvářet pracovní položky z kanálu Slack.
Aplikace umožňuje nastavit a spravovat odběry událostí, včetně vytváření a aktualizací pracovních položek, a dostávat oznámení o těchto událostech v kanálu Slack. Konverzace v kanálu Slack se dají použít k vytváření pracovních položek. Když vám budou přiřazeny pracovní položky, dostanete také osobní oznámení. Kromě toho vám náhledy adres URL pracovních položek umožní zahájit diskuze.
Pokud chcete nainstalovat aplikaci Azure Boards, klikněte sem.
Přizpůsobení sloupců taskboardu
S radostí oznamujeme, že jsme přidali možnost, která vám umožní přizpůsobit sloupce na panelu úloh. Teď můžete sloupce přidávat, odebírat, přejmenovávat a měnit jejich pořadí.
Pokud chcete nakonfigurovat sloupce na panelu Úloh, přejděte na Možnosti sloupců.
Tato funkce byla upřednostněna na základě návrhu komunity vývojářů.
Přepínač pro zobrazení nebo skrytí dokončených podřízených pracovních položek v backlogu
Při upřesňování backlogu často chcete zobrazit jenom položky, které nebyly dokončeny. Teď máte možnost zobrazit nebo skrýt dokončené podřízené položky v backlogu.
Pokud je přepínač zapnutý, zobrazí se všechny podřízené položky v dokončeném stavu. Když je přepínač vypnutý, budou všechny podřízené položky v dokončeném stavu skryté v backlogu.
Hledání panelů, backlogů, dotazů a sprintu z pole pro okamžité hledání
Teď můžete snadno získat přístup k naposledy navštíveným panelům, backlogům, dotazům a sprintům z vyhledávacího pole aktivací vyhledávacího pole v Azure Boards.
Kromě toho můžete hledat panely, backlogy, dotazy a sprinty v celém projektu zadáním názvu panelu do vyhledávacího pole. Teď jsou panely, které jsou pro vás nejdůležitější, jen jedním kliknutím pryč.
Naposledy zobrazené značky při označování pracovní položky
Při označování pracovní položky se teď možnost automatického dokončování zobrazí až pět z naposledy použitých značek. To vám usnadní přidání správných informací do pracovních položek.
Azure Repos
Vylepšené možnosti filtrování pro hledání kódu
Dříve vyhledávání kódu podporovalo 39 filtrů hledání kódu, jako je komentář: a def:. Data naznačují, že se nepoužívá mnoho filtrů, proto odebíráme několik filtrů a slučujeme další. Při této aktualizaci jsme snížili počet filtrů na 19. To vám pomůže tím, že v rozhraní zefektivní vyhledávací dotazy kódu a omezí nepotřebné prvky.
Například func: mapuje na metodu:, tj. pokud hledáte func:Account Správa, výsledky se namapují na metodu:Account Správa. Podobně se makrodef: a makroref: jsou mapovány na makro:. Na druhé straně byly filtry, jako jsou sjednocení: a organizace, zastaralé kvůli nedostatku použití.
Metriky pokrytí kódu a zásady větví pro žádosti o přijetí změn
Teď můžete vidět metriky pokrytí kódu pro změny v zobrazení žádosti o přijetí změn. Tím zajistíte, že jste změny odpovídajícím způsobem otestovali prostřednictvím automatizovaných testů. Stav pokrytí se zobrazí jako komentář v přehledu žádosti o přijetí změn. Můžete zobrazit podrobnosti o informacích o pokrytí pro každý řádek kódu, který se změnil v zobrazení rozdílu souboru.
Vlastníci úložiště teď navíc můžou nastavit zásady pokrytí kódu a zabránit sloučení velkých a neotestovaných změn do větve. Požadované prahové hodnoty pokrytí je možné definovat v azurepipelines-coverage.yml souboru nastavení, který je vrácený se změnami v kořenovém adresáři úložiště a zásad pokrytí, pomocí existující konfigurace zásad větve pro další funkce služeb v Azure Repos.
Filtrování komentářových oznámení ze žádostí o přijetí změn
Komentáře v žádostech o přijetí změn můžou často generovat velký šum z důvodu oznámení. Přidali jsme vlastní předplatné, které vám umožňuje filtrovat oznámení komentářů, která se přihlásíte k odběru podle věku komentářů, komentátora, odstraněného komentáře, zmíněných uživatelů, autora žádosti o přijetí změn, cílové větve a účastníků vlákna. Tato odběry oznámení můžete vytvořit kliknutím na ikonu uživatele v pravém horním rohu a přechodem do nastavení uživatele.
Volané služby pro komentáře žádostí o přijetí změn
Teď můžete vytvářet volání služeb pro komentáře v žádosti o přijetí změn na základě úložiště a cílové větve.
Azure Artifacts
Veřejné sdílení balíčků s využitím veřejných kanálů (Preview)
Balíčky teď můžete vytvářet a ukládat do veřejných informačních kanálů. Balíčky uložené ve veřejných informačních kanálech jsou dostupné všem uživatelům na internetu bez ověřování, ať už jsou ve vaší organizaci, nebo se dokonce přihlašují k organizaci Azure DevOps. Přečtěte si další informace o veřejných informačních kanálech v dokumentaci k informačním kanálům nebo přejděte přímo do našeho kurzu pro veřejné sdílení balíčků.
Azure Pipelines
kustomize a kompose jako simulační možnosti v úloze KubernetesManifest
Kustomize (část Kubernetes sig-cli) umožňuje přizpůsobit nezpracované soubory YAML bez šablon pro více účelů a nechat původní YAML nedotčený. V rámci akce bake úlohy KubernetesManifest byla přidána možnost kustomize, aby se ke generování souborů manifestu použitých v akci nasazení úlohy KubernetesManifest daly použít všechny složky obsahující soubory kustomization.yaml.
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
renderType: kustomize
kustomizationPath: folderContainingKustomizationFile
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
kompose transformuje soubory Docker Compose na prostředek Kubernetes.
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
renderType: kompose
dockerComposeFile: docker-compose.yaml
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
Podpora pro přihlašovací údaje správce clusteru v úloze HelmDeploy
Dříve úloha HelmDeploy použila pro nasazení přihlašovací údaje uživatele clusteru. Výsledkem byly interaktivní výzvy k přihlášení a neúspěšné kanály pro cluster s podporou RBAC založeného na Azure Active Directory. Abychom tento problém vyřešili, přidali jsme zaškrtávací políčko, které umožňuje místo přihlašovacích údajů uživatele clusteru používat přihlašovací údaje správce clusteru.
Správa proměnných kanálů v editoru YAML
Aktualizovali jsme prostředí pro správu proměnných kanálu v editoru YAML. Už nemusíte přejít do klasického editoru, abyste mohli přidávat nebo aktualizovat proměnné v kanálech YAML.
Nové předdefinované proměnné v kanálu YAML
Proměnné vám poskytují pohodlný způsob, jak získat klíčové bity dat do různých částí vašeho kanálu. V této aktualizaci jsme do úlohy nasazení přidali několik předdefinovaných proměnných. Tyto proměnné jsou automaticky nastaveny systémem, vymezeny na konkrétní úlohu nasazení a jsou jen pro čtení.
- Environment.Id – ID prostředí.
- Environment.Name – název prostředí, na které cílí úloha nasazení.
- Environment.ResourceId – ID prostředku v prostředí, na které cílí úloha nasazení.
- Environment.ResourceName – název prostředku v prostředí, na které cílí úloha nasazení.
Propojení pracovních položek s vícefázovými kanály YAML
V současné době můžete pracovní položky automaticky propojit s klasickými buildy. U kanálů YAML to ale nebylo možné. V této aktualizaci jsme tuto mezeru vyřešili. Když kanál úspěšně spustíte pomocí kódu ze zadané větve, Azure Pipelines automaticky přidruží spuštění ke všem pracovním položkám (které se odvozují prostřednictvím potvrzení v tomto kódu). Když pracovní položku otevřete, uvidíte spuštění, ve kterých byl vytvořen kód pro danou pracovní položku. Ke konfiguraci použijte panel nastavení kanálu.
Zrušení fáze ve spuštění vícefázového kanálu YAML
Při spuštění kanálu YAML s více fázemi teď můžete během provádění fáze zrušit. To je užitečné, pokud víte, že fáze selže nebo pokud máte další spuštění, které chcete spustit. Tato funkce je také předpokladem pro podporu opakování neúspěšné fáze v budoucnu.
Schválení ve vícefázových kanálech YAML
Kanály YAML ve vícefázových fázích dál vylepšujeme, takže teď do těchto kanálů přidáme ruční schválení. Vlastníci infrastruktury můžou chránit svá prostředí a vyhledávat ruční schválení před fází v jakémkoli kanálu, který do nich nasadí. Díky úplnému oddělení rolí mezi vlastníky infrastruktury (prostředí) a aplikací (kanálu) zajistíte ruční odhlášení pro nasazení v konkrétním kanálu a centrální kontrolu při použití stejných kontrol ve všech nasazeních v prostředí.
Kanál, který se nasazuje do vývojového prostředí, se zastaví ke schválení na začátku fáze.
Aktualizace imagí hostovaných kanálů
Provedli jsme aktualizace několika imagí virtuálních počítačů hostovaných službou Azure Pipelines. Další podrobnosti o nejnovějších verzích najdete tady. V rámci této aktualizace byly přidány následující změny:
Pro VS2017 a VS2019:
- Přidání Azul Java 7
- Připnuté image Dockeru uložené v mezipaměti tak, aby odpovídaly verzi jádra hostitele
- Přidání modulu Az PowerShellu v2.3.2
- Připnuto Mercurial na verzi 5.0.0
- Aktualizace Pythonu na verze 2.7.16, 3.4.4, 3.5.4, 3.6.8, 3.7.4
- Přidání knihovny přenosných tříd (jenom VS 2019)
- Změna výchozích cest Rustu a proměnných prostředí
Pro Ubuntu 16.04:
- Aktualizace helmu tak, aby vždy stáhl nejnovější (už není připnutá na verzi 2.14.0)
- Přidání několika oblíbených kontejnerů Dockeru
- Aktualizace Pythonu na verze 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4
- Změna výchozích cest Rustu a proměnných prostředí
Pro všechny image jsme přidali proměnnou
ImageVersionprostředí pro verzi image.
Úplný seznam nástrojů dostupných pro konkrétní image najdete v části Nastavení > Podrobnosti o fondech > agentů.
Vylepšení projektu DevOps pro virtuální počítač
V této aktualizaci jsme vylepšili pracovní postup virtuálního počítače DevOps Projects tak, aby zahrnoval virtuální počítače, které nevyhovují omezení kvóty pro každou lokalitu. Dříve jste museli vybrat virtuální počítač podle názvu a nabídky. Teď máte zobrazení na vyžádání s dalšími podrobnostmi o nabídkách virtuálních počítačů, jako jsou náklady za měsíc, paměť RAM, datové disky atd. To usnadňuje výběr virtuálního počítače, který potřebujete.
Jeden hostovaný fond
V posledním sprintu jsme oznámili, že zavádíme nový hostovaný fond s názvem Azure Pipelines, který nahradí všechny ostatní hostované fondy – hostované, hostované VS2017, Hostované Ubuntu 1604, Hostované Windows 2019 s VS2019, hostovaným macOS a hostovaným macOS High Sierra. Tato změna se implementuje v této verzi.
Občas může být několik hostovaných fondů matoucí. Nemáte přesný přehled o tom, kde se využívá souběžnost. Pokud máte například souběžnost 10 paralelních úloh, uvidíte v každém hostovaných fondech 10 virtuálních agentů, což není přesné. Když vaše úloha čeká na konkrétní hostovaný fond (např. Hostovaný VS2017) se všemi nečinnými agenty, můžete si myslet, že služba Azure Pipelines je poškozená, aniž byste si uvědomili, že souběžnost se pravděpodobně využívá v jiných hostovaných fondech (např. Hostované Ubuntu 1604).
Díky této změně uvidíte jeden hostovaný fond, který vám poskytne přesný přehled o tom, kolik úloh v tomto fondu běží. Tuto změnu plánujeme zavést v několika dalších sprintech. Nebudete muset v kanálech provádět žádné změny, protože úlohy ze starých hostovaných fondů automaticky přesměrujeme na příslušnou image v novém sjednoceném fondu.
Zobrazení správných informací o fondech pro každou úlohu
Když jste dříve použili matici k rozbalení úloh nebo proměnné k identifikaci fondu, měli jsme potíže se zobrazením správných informací o fondu na stránkách protokolů. V této aktualizaci jsme opravili problémy, které způsobovaly zobrazení nesprávných informací o fondu pro určité úlohy.
Produktová podpora pro správu nespolehlivých testů
Flaky testy můžou ovlivnit produktivitu vývojářů, protože selhání testů nemusí souviset se změnami v testu. Můžou také ovlivnit kvalitu expedovaného kódu. Proto jsme přidali podporu v rámci produktu pro přehlednou správu testů. Tato funkce podporuje kompletní životní cyklus díky detekci, generování sestav a řešení. Flaky test management podporuje systém a vlastní detekci.
Detekce systému je dostupná prostřednictvím funkce opětovného spuštění úlohy VSTest. Flaky test je test, který poskytuje různé výsledky, jako je úspěšné nebo neúspěšné, i když ve zdrojovém kódu nebo spouštěcím prostředí nedošlo k žádným změnám. Všechna další spuštění testu pro stejnou větev se také označí jako flaky, dokud se nevyřeší a neoznačí. Pomocí našich rozhraní API můžete také připojit svůj vlastní mechanismus detekce. Jakmile je test identifikován jako záležený, můžete získat podrobnosti v kontextové sestavě testu v kanálu. Pak se můžete rozhodnout, jestli záležné testy ovlivní selhání kanálu. Ve výchozím nastavení jsou podrobné testovací informace k dispozici jako další metadata.
Tady je příklad sestavy se souhrnem testu.
Další podrobnosti o foukané správě testů najdete v dokumentaci zde.
Vylepšení Centra nasazení pro webovou aplikaci na webu Azure Portal
Vylepšili jsme Centrum nasazení pro webovou aplikaci na webu Azure Portal s podporou kanálů s více artefakty. Pokud je teď ve webové aplikaci nasazen jiný než primární artefakt služby Azure Pipelines, získáte relevantní podrobnosti z webu Azure Portal. Také budete mít přímý odkaz na nasazené úložiště a přejít přímo do úložiště z webu Azure Portal. Úložiště je možné hostovat v Azure Repos nebo na GitHubu.
Triggery CI pro nové větve
Jedná se o dlouho čekající požadavek, aby neaktivoval sestavení CI při vytvoření nové větve a když tato větev neobsahuje změny. Zvažte následující příklady:
- Pomocí webového rozhraní vytvoříte novou větev založenou na existující větvi. To by okamžitě aktivovalo nové sestavení CI, pokud filtr větve odpovídá názvu nové větve. To je nežádoucí, protože obsah nové větve je stejný ve srovnání s existující větví.
- Máte úložiště se dvěma složkami – aplikace a dokumenty. Nastavíte filtr cesty pro CI tak, aby odpovídal "aplikaci". Jinými slovy, nechcete vytvořit nové sestavení, pokud byla změna vložena do dokumentace. Novou větev vytvoříte místně, provedete nějaké změny v dokumentaci a pak tuto větev nasdílíte na server. Použili jsme k aktivaci nového sestavení CI. To je nežádoucí, protože jste explicitně požádali, abyste ve složce docs nehledali změny. Vzhledem k tomu, jak jsme ale zpracovali novou událost větve, by to vypadalo, jako by se změna udělala i ve složce aplikace.
Teď máme lepší způsob zpracování CI pro nové větve, abychom tyto problémy vyřešili. Při publikování nové větve explicitně vyhledáme nová potvrzení v této větvi a zkontrolujeme, jestli odpovídají filtrům cest.
Integrace Terraformu se službou Azure Pipelines
Terraform je opensourcový nástroj pro vývoj, změnu a správu verzí infrastruktury bezpečně a efektivně. Terraform rozlišuje rozhraní API do deklarativních konfiguračních souborů, které umožňují definovat a zřizovat infrastrukturu pomocí základního konfiguračního jazyka. Pomocí rozšíření Terraform můžete vytvářet prostředky napříč všemi hlavními poskytovateli infrastruktury: Azure, Amazon Web Services (AWS) a Google Cloud Platform (GCP).
Další informace o rozšíření Terraform najdete v této dokumentaci.
Integrace se službou Google Analytics
Architektura experimentů Google Analytics umožňuje testovat téměř jakoukoli změnu nebo variantu webu nebo aplikace a měřit její dopad na konkrétní cíl. Můžete mít například aktivity, které chcete, aby vaši uživatelé dokončili (např. provést nákup, zaregistrovat se k bulletinu) nebo metriky, které chcete zlepšit (například výnosy, doba trvání relace, míra nedoručitelnosti). Tyto aktivity umožňují identifikovat změny, které stojí za implementaci na základě přímého dopadu na výkon vaší funkce.
Rozšíření experimentů Google Analytics pro Azure DevOps přidává kroky experimentování do kanálů sestavení a verzí, takže můžete průběžně iterovat, učit se a nasazovat rychleji tím, že experimenty průběžně spravujete a současně získáváte všechny výhody DevOps z Azure Pipelines.
Rozšíření Experimenty Google Analytics si můžete stáhnout z Marketplace.
Ukládání kanálů do mezipaměti (Public Preview)
Ukládání do mezipaměti kanálu umožňuje uložit výsledky dlouhotrvající operace, jako je obnovení balíčku nebo kompilace závislostí, a obnovit je zpět během dalšího spuštění kanálu. To může vést k rychlejším sestavením.
Další podrobnosti najdete v blogovém příspěvku s úplným oznámením zde.
Skupina proměnných kanálů a příkazy pro správu proměnných
Přenos kanálů založených na YAML z jednoho projektu do druhého může být náročný, protože potřebujete ručně nastavit proměnné kanálu a skupiny proměnných. Pomocí skupin proměnných kanálu a příkazů pro správu proměnných teď můžete skriptovat nastavení a správu proměnných kanálů a skupin proměnných, které se pak dají řídit verzí, což vám umožní snadno sdílet pokyny pro přesun a nastavení kanálů z jednoho projektu do druhého.
Spuštění kanálu pro větev žádosti o přijetí změn
Při vytváření žádosti o přijetí změn může být obtížné ověřit, jestli by změny mohly narušit spuštění kanálu v cílové větvi. Díky možnosti aktivovat spuštění kanálu nebo za frontu sestavení pro větev pr teď můžete ověřit a vizualizovat změny probíhající spuštěním v cílovém kanálu. Další informace najdete v dokumentaci k příkazům az pipelines run a az pipelines build queue.
Přeskočit první spuštění kanálu
Při vytváření kanálů někdy chcete vytvořit a potvrdit soubor YAML a neaktivovat spuštění kanálu, protože může vést k chybnému spuštění z různých důvodů – infrastruktura není připravená nebo potřebuje vytvořit a aktualizovat skupiny proměnných nebo proměnných atd. Pomocí Azure DevOps CLI teď můžete přeskočit první automatizované spuštění kanálu při vytváření kanálu zahrnutím parametru --skip-first-run. Další informace najdete v dokumentaci k příkazu az pipeline create.
Vylepšení příkazu koncového bodu služby
Příkazy rozhraní příkazového řádku koncového bodu služby podporují pouze nastavení a správu koncového bodu služby Azure rm a github. V této verzi ale příkazy koncového bodu služby umožňují vytvořit libovolný koncový bod služby tím, že poskytne konfiguraci prostřednictvím souboru a poskytuje optimalizované příkazy – az devops service-endpoint github a az devops service-endpoint azurerm, které poskytují prvotřídní podporu pro vytváření koncových bodů služby těchto typů. Další informace najdete v dokumentaci k příkazu.
Další kroky
Poznámka:
Tyto funkce se budou zavádět během následujících dvou až tří týdnů.
Přejděte na Azure DevOps a podívejte se na ně.
Jak poskytnout zpětnou vazbu
Rádi bychom slyšeli, co si o těchto funkcích myslíte. Pomocí nabídky pro odeslání názoru můžete nahlásit problém nebo poskytnout návrh.
Můžete také získat rady a své otázky zodpovězené komunitou ve službě Stack Overflow.
Díky,
Sam Guckenheimer