Vyšší efektivita zabezpečení a pracovního postupu
Tento sprint přináší různá vylepšení zaměřená na zvýšení efektivity pracovního postupu zabezpečení a zjednodušení. Mezi tato vylepšení patří prostředí pro vytváření připojení služby ve službě Azure Pipelines. To týmům umožňuje nastavit připojení služeb s využitím existujících spravovaných identit s federací identit úloh. Zjednodušuje také konfiguraci a snižuje riziko nadměrně privilegovaných identit.
Kromě toho s radostí oznamujeme, že v Azure Repos se teď soubory Markdown se syntaxí mermaid vykreslují jako diagramy v náhledech souborů a žádostech o přijetí změn a poskytují jasnější vizuály pro vaši dokumentaci.
A konečně, v GitHub Advanced Security teď poznámky žádostí o přijetí změn poskytují in-line oznámení pro kontrolu závislostí a kódu, což zjednodušuje proces, který týmům umožňuje detekovat a řešit potenciální problémy během kontrol kódu.
Podrobnosti najdete v poznámkách k verzi.
OBECNÉ
Pokročilé zabezpečení GitHubu pro Azure DevOps
- Poznámky žádosti o přijetí změn pro kontrolu závislostí a kódu
- Nová strategie detekce pipů pro kontrolu závislostí
Azure Boards:
- Vylepšená správa značek ve formuláři pracovní položky
- Vylepšená podpora obrázků v komentářích pracovních položek
- Přehledy žádostí o přijetí změn GitHubu
Azure Repos
- Konfigurace cílových větví pro žádosti o přijetí změn
- Podpora diagramů mermaid v náhledu souboru Markdown
Azure Pipelines
- Ubuntu 24.04 v agentech hostovaných v Azure Pipelines
- Použití federace identit úloh v testech integrace Azure
- Nové prostředí pro vytváření připojení ke službě Azure s vylepšenou podporou spravované identity
- Spuštění podřízených fází v případě selhání nadřazené fáze
Azure Artifacts
Wiki
OBECNÉ
Kopírování bloku kódu do schránky
V reakci na vaši zpětnou vazbu v komunitě vývojářů jsme představili tlačítko Kopírovat do schránky pro všechny bloky kódu v vykreslované markdownu. Toto vylepšení je k dispozici na stránkách wikiwebu, náhledech souborů Markdown v repos, diskuzích o žádostech o přijetí změn a popisech a diskuzích pracovních položek.
Informace o profilu Microsoft Entra (Preview)
S radostí představíme integraci informací o profilu Microsoft Entra v Azure DevOps a odebereme potřebu samostatných aktualizací profilu. Pokud chcete vyzkoušet verzi Preview, povolte informace o profilu Microsoft Entra ve funkcích preview.
Po povolení se nastavení vašeho profilu automaticky vyplní jen pro čtení z Microsoft Entra. Pokud se chcete vrátit k předchozímu nastavení nebo poskytnout zpětnou vazbu, vypněte náhled a sdílejte komentáře.
Pokročilé zabezpečení GitHubu pro Azure DevOps
Poznámky žádosti o přijetí změn pro kontrolu závislostí a kódu
V rámci plánu rozšířeného zabezpečení jsou teď k dispozici poznámky žádostí o přijetí změn. Na všechny žádosti o přijetí změn, které používají kanál přidružený k zásadám ověření sestavení, které zahrnují úlohy kontroly závislostí nebo kódu, obdržíte vložené poznámky.
Kromě vytváření zásad ověření sestavení pro příslušné větve se nevyžaduje žádná další výslovný souhlas.
Kliknutím Show more details na poznámku se zobrazí zobrazení podrobností výstrahy pro danou výstrahu.
Další informace najdete v našem nejnovějším blogovém příspěvku zde.
Nová strategie detekce pipů pro kontrolu závislostí
Kontrola závislostí teď používá novou strategii detekce pro Python: PipReport na základě funkčnosti sestavy instalace pip. Tato aktualizace zlepšuje přesnost tím, že respektuje specifikátory prostředí k určení přesných verzí, které by skutečné pip install spuštění načetlo. Detektor ve výchozím nastavení používá pypi.org k sestavení grafu závislostí. Volitelně můžete nastavit proměnnou prostředí kanálu pro PIP_INDEX_URL vytvoření grafu závislostí. Pokud při přístupu k vašemu informačnímu kanálu dochází k problémům s ověřováním, možná budete potřebovat PipAuthenticate@1 nastavit úlohu kanálu, aby byl váš informační kanál přístupný.
Další informace o strategii detekce najdete v dokumentaci k detekci pipů.
Azure Boards
Vylepšená správa značek ve formuláři pracovní položky
Správa značek ve službě Azure Boards byla vylepšena tak, aby poskytovala efektivnější prostředí. Odstraněné značky se už nezobrazují v navrhovaném seznamu ve formulářích pracovních položek a zajišťují, aby se zobrazovaly jenom aktivní značky.
Vylepšená podpora obrázků v komentářích pracovních položek
Vylepšili jsme podporu vkládání obrázků do komentářů pracovních položek. Do oddílu diskuze pracovní položky teď můžete vložit obrázky přímo ze zdrojů, jako jsou Microsoft Teams, e-maily a wordové dokumenty.
Přehledy žádostí o přijetí změn GitHubu
Vylepšili jsme integraci mezi žádostmi o přijetí změn GitHubu a Azure Boards. Kromě zobrazení otevřených a uzavřených stavů teď můžete zjistit, jestli je žádost o přijetí změn v režimu konceptu, vyžaduje kontrolu a stav Kontroly. To vše bez nutnosti otevřít žádost o přijetí změn.
Pokud chcete tuto funkci povolit, nezapomeňte přejít do aplikace Boards na GitHubu a přijmout požadovaná aktualizovaná oprávnění pro přístup ke čtení a zápisu do kontrol.
Azure Repos
Konfigurace cílových větví pro žádosti o přijetí změn
Správa více větví v úložišti může být náročná, zejména při vytváření nových žádostí o přijetí změn. Díky nové funkci Konfigurovat cílové větve pro žádosti o přijetí změn teď můžete zadat seznam upřednostňovaných cílových větví, abyste zajistili přesnější a relevantnější návrhy žádostí o přijetí změn. To vám pomůže zjednodušit pracovní postup a snížit riziko cílení na nesprávnou větev.
Pokud chcete tuto funkci použít, vytvořte .azuredevops/pull_request_targets.yml ve výchozí větvi úložiště soubor. Tento soubor YAML by měl obsahovat seznam s názvy pull_request_targets větví nebo předponami, které odpovídají kandidátským větvím. Příklad:
pull_request_targets:
- main
- release/*
- feature/*
V této konfiguraci má hlavní větev prioritu, ale větve začínající release/ nebo feature/ budou považovány za vhodné. Konfigurace se použije v následujících scénářích:
- Návrhy žádostí o přijetí změn: Po nasdílení větve do Azure DevOps může stránka Úložiště navrhnout vytvoření žádosti o přijetí změn z této větve a dynamicky zvolit cílovou větev.
- Adresa URL žádosti o přijetí změn: Když přejdete přímo na stránku pro vytvoření žádosti o přijetí změn pomocí parametru sourceRef, ale vynecháte parametr targetRef, Azure DevOps vybere cílovou větev na základě této dynamické volby.
Doporučuje se zahrnout pouze větve chráněné zásadami žádostí o přijetí změn, aby se zajistila konzistence v první nadřazené historii potvrzení tipu.
Podpora diagramů mermaid v náhledu souboru Markdown
Soubory Markdown obsahující syntaxi mermaid se teď vykreslují jako diagramy v náhledech souborů v prohlížeči souborů repos a v žádostech o přijetí změn. To vám může pomoct přidat do úložišť bohatší dokumentaci.
Azure Pipelines
Ubuntu 24.04 v agentech hostovaných v Azure Pipelines
Image Ubuntu 24.04 je teď dostupná pro agenty hostované v Azure Pipelines. Chcete-li použít tento obrázek, aktualizujte soubor YAML tak, aby zahrnoval vmImage:'ubuntu-24.04':
- job: ubuntu2404
pool:
vmImage: 'ubuntu-24.04'
steps:
- bash: |
echo Hello from Ubuntu 24.04
lsb_release -d
Poznámka:
Popisek ubuntu-latest obrázku bude dál odkazovat na ubuntu-22.04 až do konce tohoto roku.
Viz soubor Readme image Ubuntu 24.04 pro nainstalovaný software.
Použití federace identit úloh v testech integrace Azure
V červnu přidaly knihovny identit Azure for.NET, C++, Go, Java, JavaScript a Python podporu pro federaci identit úloh. Tím se přidala možnost provádění kódu z AzureCLI@2 a AzurePowerShell@5 úloh pro ověření pomocí Microsoft Entra (například pro přístup k Azure) pomocí AzurePipelinesCredential třídy.
Mnoho zákazníků používá knihovny identit Azure v integračních testech vyvolané z jiných úloh. Přidali jsme podporu pro AzurePipelinesCredential úkoly DotNetCoreCLI@2, Maven@4 a VSTest@3 .
Vlastnost můžete nastavit connectedService na připojení služby Azure nakonfigurované s federací identit úloh. SYSTEM_ACCESSTOKEN Vyžaduje AzurePipelinesCredential se nastavení.
- task: DotNetCoreCLI@2
inputs:
command: 'run'
connectedService: <Azure service connection configured with workload identity federation>
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
Další informace najdete v AzurePipelinesCredentialtomto blogovém příspěvku.
Nové prostředí pro vytváření připojení ke službě Azure s vylepšenou podporou spravované identity
Nové prostředí pro vytváření připojení ke službě Azure poskytuje větší flexibilitu a zabezpečené výchozí hodnoty. Sjednocuje také terminologii s Microsoft Entra ID, takže uživatelé, kteří vytvářejí objekty Microsoft Entra ID ručně, se při navigaci na různých portálech lépe orientují.
Při vytváření nového připojení služby Azure Resource Manager jsou teď různé možnosti konfigurace identity dostupné v jednom sjednoceném dialogovém okně, které nahrazuje jedinečné položky nejvyšší úrovně použité dříve:
Typ identity obsahuje seznam všech schémat ověřování, která připojení služby Azure podporuje:
U registrací aplikací můžete nezávisle vybrat přihlašovací údaje , které mají být federace identit úloh nebo tajný klíč.
Podpora spravované identity připojení ke službě Azure
Teď můžete vybrat existující spravovanou identitu a použít ji ke konfiguraci připojení služby, které používá federaci identit úloh. Nejprve vytvořte spravovanou identitu přiřazenou uživatelem.
Pak vytvořte připojení ke službě Azure a vyberte typ identity spravované identity . Tím se pro spravovanou identitu konfigurují přihlašovací údaje federované identity.
Možnost použít spravovanou identitu přiřazenou k agentovi (fondu) byla přejmenována spravovaná identita (přiřazená agentem). Pokud chcete zabránit sdílení nadprivilegovaných spravovaných identit, doporučujeme místo spravovaných identit přiřazených k fondům agentů použít spravovanou identitu s federací identit úloh.
Spravovaná identita je také doporučenou možností pro uživatele, kteří nemůžou vytvořit registraci aplikace, pokud je tato možnost zakázaná v Microsoft Entra ID.
Pokud chcete použít spravovanou identitu s federací identit úloh, nejprve vyberte předplatné a skupinu prostředků, ve které je vaše spravovaná identita. To se může lišit od předplatného, ke které má připojení ke službě přístup v úlohách kanálu. Vyberte spravovanou identitu nakonfigurovanou pro federaci identit úloh. Aby uživatel vytvořil přihlašovací údaje federované identity, potřebuje pro spravovanou identitu roli Přispěvatel spravované identity nebo ekvivalentní oprávnění.
Pokračujte výběrem předplatného, které se použije jako rozsah nasazení pro připojení služby.
Pole Referenční dokumentace ke správě služeb
Některé organizace vyžadují , aby se referenční informace o správě služeb registrace aplikace naplnily relevantními kontextovými informacemi z databáze ITSM. V případě potřeby můžou uživatelé zadat tento odkaz při vytváření připojení služby.
Více informací
Nové prostředí pro vytváření připojení ke službě Azure se zavádí v příštím měsíci. Další informace naleznete v tématu:
Spuštění podřízených fází v případě selhání nadřazené fáze
Usnadnili jsme nasazení pomocí Azure Pipelines. To je užitečné, například když pomocí Pipelines nasadíte nové verze aplikace napříč několika oblastmi Azure.
Řekněme, že je potřeba nasadit do pěti po sobě jdoucích oblastí Azure. Předpokládejme, že váš kanál má fázi pro každou oblast a každá fáze má úlohu, která spouští AzureResourceManagerTemplateDeployment úlohu, a pak protokoluje určitou telemetrii. Ten druhý je milý mít, ale není kritický. Představte si, že dochází k problému s protokolováním telemetrie. Teď fáze selže a nasazení se zastaví.
Počínaje tímto sprintem můžete v případě selhání fáze pokračovat ve spouštění podřízených fází.
Azure Artifacts
Ověřování k Azure Artifacts pomocí veřejného informačního kanálu a Cargo
Kvůli omezení klienta Cargo bylo ověřování úplně nebo nic. U privátních informačních kanálů by se odeslalo ověřování, ale u veřejných informačních kanálů, které potřebují povolit anonymním uživatelům, se neposílalo žádné ověřování, i když bylo k dispozici nebo potřeba.
Teď se ověření uživatelé můžou připojit k veřejnému informačnímu kanálu Azure Artifacts stejně jako privátní informační kanál. Pokud máte vy nebo váš agent kanálu oprávnění ukládat balíčky z upstreamových zdrojů, můžete přistupovat k balíčkům z crates.io prostřednictvím informačního kanálu. Tato změna dává kontrolu nad tím, které balíčky mohou přijít do informačního kanálu zpět v rukou správců informačních kanálů. Jakmile se balíčky převedou do informačního kanálu z upstreamového zdroje, budou k nim mít anonymní uživatelé přístup.
Pokud chcete zajistit ověření, připojte ~force-auth k názvu informačního kanálu v adrese URL registru. Další podrobnosti najdete v naší veřejné dokumentaci.
Wiki
Vylepšení vkládání obsahu založeného na HTML do wikiwebů
Usnadnili jsme vkládání obsahu založeného na HTML do wikiwebů. Teď se prvky HTML, jako jsou odkazy, seznamy, tabulky, obrázky, excelové listy, zprávy, e-maily a dotazy Azure Data Exploreru, automaticky převedou na syntaxi Markdownu pro plynulejší úpravy.
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 nápovědy 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,
Dan Hellem