Události
Vytváření inteligentních aplikací
17. 3. 21 - 21. 3. 10
Připojte se k řadě meetupů a vytvořte škálovatelná řešení AI založená na skutečných případech použití s kolegy vývojáři a odborníky.
ZaregistrovatNové 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í .
- 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
- 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
- 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)
- kustomize a kompose jako simulační možnosti v úloze KubernetesManifest
- Podpora pro přihlašovací údaje správce clusteru v úloze HelmDeploy
- Vylepšení centra nasazování pro webové aplikace na webu Azure Portal
- Vylepšení projektu DevOps pro virtuální počítač
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.
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í.
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.
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ř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.
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č.
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.
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í.
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.
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.
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.
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ů.
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.
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.
YAML
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)
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.
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.
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í.
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.
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.
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.
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ů.
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.
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.
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.
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š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.
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.
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.
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í 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.
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.
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ř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.
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.
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ě.
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
Další materiály
Školení
Postup výuky
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
Certifikace
Microsoft Certified: DevOps Engineer Expert - Certifications
Tato certifikace měří vaši schopnost provádět následující technické úlohy: Návrh a implementace procesů a komunikací, návrh a implementace strategie správy zdrojového kódu, návrh a implementace kanálů sestavení a verzí, vývoj plánu zabezpečení a dodržování předpisů a implementace strategie instrumentace.
Dokumentace
-
Integrace Kubernetes se službou Azure Pipelines – Oznámení o sestavení Microsoftu
Konference Microsoft Build se konala ve dnech 6. až 8. května v Seattlu.
-
Přehled integrace GitHubu - Azure DevOps
Přečtěte si o integraci Azure DevOps s GitHubem.
-
Poznámky k verzi Azure DevOps – Zvýšení produktivity a snížení latence
V **Sprintu 167*** zahrnujeme vylepšení možností akcí žádostí o přijetí změn, zabezpečení kanálu a dodržování předpisů a výkon rozhraní NPM API.