Dodržování předpisů kanálu a ověření zabezpečení – aktualizace Sprint 141

V červnu tohoto roku jsme zavedli první iteraci našeho nového navigačního modelu. V létě jsme toto prostředí vylepšovali na základě zpětné vazby, kterou vám mnozí z vás poskytli. Děkujeme! Naším dalším krokem je přejít z nového modelu, který je náhledem, k navigaci pro produkt. Přečtěte si náš blogový příspěvek popisující nedávné změny spolu s plánem, jak nový model přinést do všech organizací.

Chápeme důležitost vyhledávání a vracíme zpět rozšířené vyhledávací pole v záhlaví produktu. Kromě toho teď můžete vyhledávací pole vyvolat jednoduše kliknutím na "/" na libovolné stránce služby v Azure DevOps. Tato funkce byla upřednostněna na základě návrhu uživatelského hlasu.

Tady je výchozí vyhledávací pole:

Výchozí vyhledávací pole

Jakmile zadáte "/", zobrazí se rozbalené vyhledávací pole:

Rozbalené vyhledávací pole

Azure Pipelines

Azure Policy dodržování předpisů a ověření zabezpečení v pipelines

Chceme zajistit stabilitu a zabezpečení softwaru v rané fázi procesu vývoje a zároveň chceme spojit vývoj, zabezpečení a provoz. K tomu jsme přidali podporu pro Azure Policy.

Azure Policy pomáhá zajišťovat správu a prevenci potíží s IT prostřednictvím definic zásad, které vynucují pravidla a efekty pro vaše prostředky. Když používáte Azure Policy, prostředky zůstanou v souladu s vašimi firemními standardy a smlouvami o úrovni služeb.

Abychom v rámci procesu vydávání verzí dodržovali pokyny pro dodržování předpisů a zabezpečení, vylepšili jsme prostředí pro nasazení skupiny prostředků Azure. Teď při nasazování šablon ARM dochází k selhání úlohy nasazení skupiny prostředků Azure s příslušnými chybami souvisejícími se zásadami.

Azure Policy

Kromě toho jsme přidali Azure Policy šablonu definice vydané verze. To umožní uživatelům vytvářet zásady Azure a přiřazovat je prostředkům, předplatným nebo skupinám pro správu ze samotné definice vydané verze.

šablona Azure Policy

Zjednodušené průběžné doručování na virtuální počítače Azure

V této verzi jsme přidali nového průvodce, který zjednodušuje proces nastavení průběžného doručování do Azure Virtual Machines. Jakmile určíte organizaci Azure DevOps a skupinu nasazení pro registraci virtuálního počítače, automaticky se vytvoří kanál verze s ukázkovým krokem skriptu. Pokud potřebujete zřídit další prostředky Azure, spouštět skripty, upgradovat aplikaci nebo spouštět další ověřovací testy, můžete tento kanál verze snadno přizpůsobit.

Průběžná integrace do virtuálních počítačů Azure

Úloha Xcode podporuje nově vydané Xcode 10.

V souladu s vydáním Xcode 10 od Společnosti Apple teď můžete nastavit své projekty tak, aby se sestavovaly nebo byly testovány konkrétně pomocí Xcode 10. Váš kanál může také spouštět úlohy paralelně s maticí verzí Xcode. Ke spouštění těchto sestavení můžete použít fond agentů macOS hostovaný Microsoftem. Projděte si doprovodné materiály k používání Xcode v Azure Pipelines.

Xcode 10

Vylepšení výkonu při řazení sestavení do fronty

Když použijete hostovaného agenta, získáte pro každou úlohu nový virtuální počítač. To poskytuje další vrstvu zabezpečení a kontroly. Nikdy se nemusíte starat o to, že předchozí build opustí výstupy nebo udělá na počítači něco škodlivého. Aktivity při prvním spuštění ale dříve znamenaly prodlevy mezi kliknutím na Zařadit sestavení do fronty a tím, kdy je kanál skutečně spuštěný. Provedli jsme šetření a opravili jsme mnoho z těchto zpoždění a teď v době fronty do zahájení napříč hostovanými fondy dochází k 5krát rychlejšímu. Buildy teď můžete začít rychleji, což znamená, že můžete rychleji iterovat.

Vytvoření připojení služby Azure pomocí instančního objektu, který se ověřuje pomocí certifikátu

Teď můžete definovat připojení služby Azure v Azure Pipelines nebo Team Foundation Serveru (TFS) s instančním objektem a certifikátem pro ověřování. Připojení služby Azure teď podporuje instanční objekt, který se ověřuje pomocí certifikátu, a můžete ho nasadit do služby Azure Stack s nakonfigurovanou službou AD FS. Pokud chcete vytvořit instanční objekt s ověřováním certifikátu, přečtěte si článek věnovaný vytvoření instančního objektu, který se ověřuje pomocí certifikátu.

Připojení s využitím instančního objektu

Zobrazení testovací analýzy v pipelines

Sledování kvality testů v průběhu času a zlepšování doprovodu testů je klíčem k zachování dobrého kanálu. Funkce analýzy testů poskytuje téměř v reálném čase přehled o testovacích datech pro buildy a kanály verzí. Pomáhá zlepšit efektivitu kanálu tím, že identifikuje opakující se problémy s kvalitou s vysokým dopadem.

Výsledky testů můžete seskupit podle různých prvků, identifikovat klíčové testy pro vaši větev nebo testovací soubory nebo přejít k podrobnostem konkrétního testu, abyste viděli trendy a porozuměli problémům s kvalitou, jako je přehlednost.

Podívejte se na testovací analýzy buildů a vydaných verzí, které jsou ve verzi Preview:

Testování analýzy

Další informace najdete v naší dokumentaci.

Azure Repos

Změna cílové větve žádosti o přijetí změn

U většiny týmů cílí téměř všechny žádosti o přijetí změn na stejnou větev, například master nebo develop. V případě, že potřebujete cílit na jinou větev, je ale snadné zapomenout změnit výchozí cílovou větev. S novou funkcí, která mění cílovou větev aktivní žádosti o přijetí změn, je to teď jednoduchá akce. Stačí kliknout na ikonu tužky v blízkosti názvu cílové větve v hlavičce žádosti o přijetí změn.

Změnit cílovou větev

Funkce pro změnu cílových větví kromě pouhé opravy chyb také usnadňuje "opětovné cílení" žádosti o přijetí změn v případě, že se cílová větev sloučí nebo odstraní. Představte si scénář, ve kterém máte žádost o přijetí změn zaměřenou na větev funkcí, která obsahuje některé funkce, na kterých jsou vaše změny závislé. Závislé změny chcete zkontrolovat izolovaně od ostatních změn ve větvi funkce, takže budete zpočátku cílit features/new-featurena . Revidující pak uvidí jenom vaše změny a zanechají příslušné komentáře.

Teď zvažte, co by se stalo, kdyby větev funkce měla také aktivní žádost o přijetí změn a sloučila se s před vašimi master změnami? Dříve byste museli upustit od změn a vytvořit novou žádost o přijetí změn do master, nebo sloučit žádost o přijetí změn do features/new-featurea pak vytvořit další žádost o přijetí změn z features/new-feature do master. Pomocí této nové akce pro aktualizaci cílové větve můžete jednoduše změnit cílovou větev žádosti o přijetí změn z features/new-feature na mastera zachovat veškerý kontext a komentáře. Při změně cílové větve se dokonce vytvoří nová aktualizace žádosti o přijetí změn, která usnadňuje pohled na předchozí rozdíly před změnou cílové větve.

Aktualizace cílové větve

Ochrana úložišť Git pomocí nastavení kompatibility mezi platformami

Vzhledem k tomu, že Git je technologie pro různé platformy, je možné, aby soubory nebo adresáře našly cestu do systému souborů, kde můžou být nekompatibilní na konkrétní platformě. Podrobnosti o těchto nekompatibilitě najdete v naší dokumentaci.

Abychom týmům pomohli chránit jejich úložiště a jeho vývojáře, přidali jsme nová nastavení úložiště pro blokování nasdílení změn obsahujících potvrzení se soubory nebo adresáři, které nejsou kompatibilní s jednou nebo více platformami operačního systému. Přečtěte si další informace o těchto nastaveních.

Správa

Podpora uživatelů AAD v účtech MSA

Azure DevOps teď podporuje uživatele AzureAD (AAD), kteří přistupují k organizacím, které jsou podporovány msa. Pro správce to znamená, že pokud vaše organizace Azure DevOps používá účty MSA pro podnikové uživatele, můžete teď mít přístup k novým zaměstnancům pomocí jejich přihlašovacích údajů AAD a nemusíte vytvářet novou identitu MSA výhradně pro použití s Azure DevOps.

Stále věříme, že pro podnikové uživatele je nejlepší připojit Azure DevOps k AAD, ale začátkem tohoto roku jsme zjistili, že správci potřebují k provedení tohoto převodu více času. Když uživatelům AAD povolíte přístup k organizacím s podporou MSA, budou mít noví uživatelé přístup k Azure DevOps, jakmile Azure DevOps na konci měsíce zabrání vytváření nových uživatelů MSA s vlastními názvy domén založenými na AzureAD.

Pro organizace, které už používají identity AAD s Azure DevOps, tato funkce neplatí. U organizací, které aktuálně používají identity MSA, mějte na paměti, že všichni stávající uživatelé se můžou i nadále přihlašovat pomocí svých identit MSA stejně jako dnes. To platí jenom pro uživatele přidané v budoucnu (kteří potenciálně nemůžou vytvořit účet MSA se svojí firemní e-mailovou adresou).

Tady je příklad scénáře, ve kterém může být toto prostředí užitečné: Dorothy je vlastníkem organizace Azure DevOps pro svou společnost Fabrikam. Ona i její tým 10 členů týmu se přihlašují k Azure DevOps pomocí identit MSA, které používají jejich firemní e-mailovou adresu, například Dorothy@fabrikam.com. Sam je nový člen týmu, který dnes vstoupil do společnosti. Dorothy ho pozve do Azure DevOps pomocí jeho e-mailu sam@fabrikam.com. Když v e-mailu klikne na odkaz připojit se, může se přihlásit k Azure DevOps se stejnou identitou AAD, kterou dostal pro přístup ke svému e-mailu v Microsoftu 365. To samovi umožní spolupracovat s jeho 11 kolegy a Dorothy může připojit svou organizaci Azure DevOps k AAD, až bude připravená.

Další informace najdete v našem blogovém příspěvku .

Jak poskytnout zpětnou vazbu

Rádi bychom se dozvěděli, 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 Stack Overflow.

Díky,

Gopinath Chigakkagari (Twitter)

Sdílet prostřednictvím