Sdílet prostřednictvím


Centrum Pracovních položek a projekt Azure DevOps založený na virtuálních počítačích – aktualizace VSTS Sprint 131

Ve sprintu 131 Update of Visual Studio Team Services (VSTS) existuje několik funkcí, které obdržely velké množství zpětné vazby a aktivit na UserVoice. Jedním z nich je centrum Pracovní položky, které se teď stává obecně dostupným, aby se důležitá práce dostala do popředí každodenního pracovního postupu. Přidali jsme také virtuální počítač jako možnost konfigurace azure DevOps Projects , protože víme, že pro některé je důležité zachovat si kontrolu nad webovými aplikacemi na nižší úrovni.

Mezi další vylepšení patří:

Novinky ve VSTS

Kód

Zabránění přepisům a zachování výkonu pomocí nastavení úložiště

V této aktualizaci najdete dvě nová nastavení úložiště, která umožní bezproblémovou spolupráci s Gitem.

Vynucování velkých a malých písmen přepne server z výchozího režimu rozlišující malá a malá písmena, kde se liší "File.txt" a "file.txt", do režimu vhodného pro Windows a macOS, kde "File.txt" a "file.txt" jsou stejný soubor. Toto nastavení ovlivňuje soubory, složky, větve a značky. Zároveň přispěvatelům brání v nechtěném zanesení rozdílů spočívajících jen ve velikosti písmen. Vynucení velikosti písmen se doporučuje povolit, pokud většina přispěvatelů pracuje ve Windows nebo macOS.

Limit file sizes (Omezit velikost souborů) umožňuje zabránit, aby velikost nových nebo aktualizovaných souborů překročila nastavený limit. Čím větší množství velkých souborů existuje v historii úložiště Gitu, tím horší bude výkon operací klonování a načítání změn. Toto nastavení brání v nechtěném zanesení těchto souborů.

Práce

Zaměřte se na důležitou práci pomocí centra Pracovní položky.

I když dotazy, backlogy a panely nabízejí řadu způsobů, jak zobrazit svou práci, chceme, aby práce, která je pro vás nejdůležitější, byla na dosah ruky. Po 6měsíčním náhledu centra Pracovní položky je teď dostupné všem uživatelům. Od začátku verze Preview jsme v centru hodně iterated a níže najdete několik změn, které jsme udělali.

Centrum Pracovní položky teď obsahuje 4 pivoty zaměřené na osoby, které vám umožňují zaměřit se na to, co je pro vás důležité, a také 3 zobrazení zaměřená na projekt, abyste získali lepší představu o práci vašeho projektu.

  • Přiřazeno mně – všechny pracovní položky přiřazené v projektu v pořadí, v jakém byly naposledy aktualizovány
  • Sledování – všechny pracovní položky, které sledujete
  • Zmínka – všechny pracovní položky, ve kterých jste byli zmíněni, za posledních 30 dnů
  • Moje aktivita – všechny pracovní položky, které jste nedávno zobrazili nebo aktualizovali
  • Poslední aktualizace – všechny pracovní položky v projektu, které byly naposledy aktualizovány
  • Nedávno dokončeno – všechny pracovní položky v projektu, které byly nedávno dokončeny
  • Nedávno vytvořené – všechny pracovní položky nedávno vytvořené v projektu

Kontingenční tabulky Pracovních položek

Každý pivot projektu se teď dá seřadit podle různých možností, včetně názvu, cesty k oblasti nebo data vytvoření. Můžete také zvolit zobrazení těchto pracovních položek vzestupně nebo sestupně.

Možnosti řazení pracovních položek

Dotazování v rámci plánu iterace pomocí +/- @CurrentIteration

Makro @CurrentIteration , které pomáhá týmu sledovat práci na základě plánu iterace, teď podporuje celočíselné posuny. Snadno si udržujte přehled o práci, která se nezavřela s @CurrentIteration – 1, nebo se podívejte dopředu na práci naplánovanou pro budoucí iterace s @CurrentIteration + 1. Další informace najdete v @CurrentIteration příspěvku na blogu Microsoft DevOps. Tato funkce byla upřednostněna na základě toho, co je aktuálně 456 hlasy na #12 nejvyšším hlasem.

Objasnění plánů iterace dotazů pomocí parametru @CurrentIteration Team

Pokud jste makro používali @CurrentIteration v dotazech v minulosti, možná jste si všimli, že výsledky se můžou lišit, pokud se kontext týmu v teams změní s různými plány iterace. Když teď vytvoříte nebo upravíte dotaz pomocí @CurrentIteration makra, budete muset také vybrat tým s plánem iterace, který je pro dotaz relevantní. Pomocí parametru Team můžete makro použít @CurrentIteration ve stejném dotazu, ale v rámci týmů. Jedním z příkladů může být dotaz na pracovní položky ve dvou různých týmových projektech s použitím různých názvů iterací a dokonce i plánů. To znamená, že při změně sprintů už nemusíte aktualizovat dotazy. Další informace najdete v @CurrentIteration příspěvku na blogu Microsoft DevOps. Tato funkce dostala prioritu na základě návrhu.

Parametr týmu

Sestavení a vydaná verze

Zachovejte si větší kontrolu nad aplikací nasazením projektu Azure DevOps na virtuální počítač.

Azure DevOps Project umožňuje nastavit plně nakonfigurovaný kanál CI/CD v několika krocích. Zatímco jsme začali s Azure Web Apps, teď můžete provést nasazení na virtuální počítač Azure s Windows, pokud chcete. Když začínáte s ASP.NET nebo ASP.NET Core aplikací, jednoduše vyberte možnost Virtuální počítač.

Možnost virtuálního počítače Projektu DevOps

Zkrácení doby vydání díky částečnému stahování artefaktů

V minulosti jste během fáze nasazení mohli zvolit, jestli se mají všechny artefakty stáhnout nebo přeskočit. Teď můžete zvolit artefakty, které je potřeba stáhnout. Protože agent musí stáhnout jen to, co potřebuje, můžete ušetřit čas. Další informace najdete v dokumentaci k artefaktům vydané verze. Tato funkce dostala prioritu na základě návrhu.

Částečné stažení artefaktů

Zlepšení kvality kódu pomocí nejnovějších rozšíření ze SonarSource

SonarSource nedávno vydal aktualizované rozšíření SonarQube a nové rozšíření SonarCloud, které umožňují statickou analýzu kódu pro mnoho jazyků. Úlohy VSTS Gradle a Maven využívají tato rozšíření zejména pro sestavení Java. Stačí povolit spuštění SonarQube nebo SonarCloud Analysis ve verzi 2.* úlohy Gradle nebo Maven a pak přidat úlohy Připravit a publikovat SonarQube/SonarCloud, jak je znázorněno níže.

Úkoly pro Gradle a Maven

Vysledování zdrojových kódů GitHubu k sestavením pomocí značek sestavení

Sestavení z GitHubu nebo GitHubu Enterprise už odkazují na příslušné potvrzení. Stejně důležitá je ale možnost vysledovat potvrzení k sestavením, která sestavilo. To je teď možné díky povolení označování zdrojového kódu ve VSTS. Při výběru úložiště GitHubu v definici sestavení můžete vybrat typy sestavení, která chcete označit, a formát značek.

Možnosti zdrojů značek

Značky sestavení se pak objeví v úložišti GitHubu nebo GitHubu Enterprise.

Příklady označených zdrojů v GitHubu

Izolace koncových bodů služby Azure Resource Manager do skupin prostředků

Ve výchozím nastavení získají roli Přispěvatel v předplatném koncové body služby Azure Resource Manager, které jsou automaticky nakonfigurované ve VSTS. Teď máte možnost vytvořit koncový bod a omezit rozsah na konkrétní skupinu prostředků v rámci předplatného, což poskytuje určitou izolaci, aby koncový bod pracoval jenom s tím, co by měl. Po zobrazení výzvy k autorizaci předplatného Azure vyberte Upřesnit možnosti.

Rozšířené možnosti autorizace předplatného Azure

Správa zabezpečení konkrétní entity

Když byly v minulosti při zabezpečení na základě rolí nastaveny role zabezpečeného přístupu, byly pro skupiny nasazení, skupiny proměnných, fronty agentů a koncové body služby nastaveny pro uživatele nebo skupinu na úrovni centra. U konkrétní entity teď můžete dědičnost zapnout a vypnout a nakonfigurovat zabezpečení tak, jak potřebujete.

Dialogové okno Zabezpečení

Sdílení stavu nasazení pomocí odznaku

Stejně jako v buildu teď můžete ve vydané verzi nakonfigurovat odznáčky, které zobrazují stav posledního dokončeného nasazení do prostředí. Tyto odznáčky jsou veřejně přístupné prostřednictvím adresy URL, která může být vložena do libovolného úložiště, aby byla pro uživatele a přispěvatele transparentnější.

Možnosti odznáčku

Po povolení autorizovaným členem projektu může každý, kdo má přístup k adrese URL odznaku, zobrazit stav nasazení do vybraných prostředí.

Odznáček v readme

Selektivní nasazení na základě artefaktu, který aktivuje vydanou verzi

Do definice verze lze přidat několik zdrojů artefaktů a nakonfigurovat je k aktivaci vydané verze. Nová vydaná verze se vytvoří, když je pro některý z těchto zdrojů dostupné nové sestavení. Stejný proces nasazení se provádí bez ohledu na to, který zdroj vydanou verzi aktivoval. Proces nasazení teď můžete přizpůsobit na základě aktivačního zdroje. U automaticky aktivovaných vydaných verzí je teď proměnná vydané verze Release.TriggeringArtifact.Alias vyplněna a identifikuje zdroj artefaktu, který vydanou verzi aktivoval. V podmínkách úloh, podmínkách fází a parametrech úloh to lze využít k dynamické úpravě procesu. Například když potřebujete nasadit jen artefakty, které se změnily v rámci různých prostředí.

Předplatná

Využití stávajícího předplatného s využitím alternativního e-mailového účtu založeného na AAD

Pokud bylo v minulosti předplatné sady Visual Studio přiřazeno k e-mailové adrese Azure Active Directory (Azure AD), museli jste být ve VSTS přidáni pomocí stejné e-mailové adresy, aby bylo rozpoznáno jako předplatitel sady Visual Studio. Pro předplatná přiřazená k účtu Microsoft (MSA) ale můžete přidat alternativní Azure AD e-mailový účet na portálu Moje sada Visual Studio a použít tento Azure AD e-mail pro přístup k VSTS.

Tato funkce byla rozšířena a umožňuje předplatitelům sady Visual Studio založeným na AAD přidávat další e-mailový účet AAD na portálu Moje sada Visual Studio . To vám umožní používat ve VSTS jiný e-mail AAD, než ke kterému je předplatné přiřazené.

Přidání alternativního účtu k předplatným

Postup přidání alternativního účtu k předplatnému najdete v tématu Moje sada Visual Studio – nejčastější dotazy. Další informace najdete v příspěvku Předplatná VS a propojení účtu VSTS s AzureAD na blogu Microsoft DevOps.

Další kroky a zpětná vazba

Rádi bychom se dozvěděli, co si o těchto funkcích myslíte. Nahlaste problém nebo poskytněte návrh, pokud máte nápady na věci, u kterých bychom měli prioritu, prostřednictvím nabídky pro zpětnou vazbu.

Nabídka Zpětná vazba

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

Díky,

Jamie Cool