Zpráva k vydání verze pro Team Foundation Server 2018

---

| Developer Community Požadavky na systém a kompatibilita | Licenční podmínky | pro TFS DevOps Blog | o hashech | SHA-1Nejnovější zpráva k vydání verze sady Visual Studio 2019

---

---

V tomto článku najdete informace o Team Foundation Serveru 2018. Klikněte na tlačítko pro stažení.

Další informace o Team Foundation Serveru 2018 najdete na stránce Compatibility Team Foundation Server . Další produkty TFS 2018 si můžete stáhnout z webu visualstudio.com/downloads.

Další informace najdete na stránce o instalaci TFS.

---

Datum vydání : 15. listopadu 2017

Shrnutí novinek v TFS 2018

Do Team Foundation Serveru 2018 jsme přidali spoustu nových vylepšení. Mezi nejzajímavější z nich patří:

• Vylepšili jsme průvodce vytvořením projektu a správce šablon procesů na webu.
• Teď můžete přizpůsobovat záhlaví formuláře pracovní položky.
• Optimalizovali jsme mobilní verzi formuláře pracovní položky.
• Přidali jsme podporu forků Git.
• Můžete spravovat masivní úložiště Git pomocí GVFS
• Můžete zobrazovat, filtrovat a nastavovat zabezpečení značek Git.
• Do úprav webového kódu jsme přidali minimapu souboru, párování závorek a přepínání prázdných znaků.
• Hodně jsme vylepšili žádosti o přijetí změn.
• Máme nové vylepšené prostředí wiki.
• Přidali jsme podporu balíčků Maven.
• Můžete importovat a exportovat a pozastavit definice sestavení.
• Nový editor definic vydaných verzí je standardně povolen.
• Nasazení můžete provádět pomocí nasazení virtuálních počítačů.
• Vylepšili jsme sledovatelnost nahodilého testování.
• Přidali jsme dávkování testů.
• Teď si můžete zobrazit widget pro grafy pro testovací plány a testovací sady.

Novinky ve verzi TFS 2018 – video

Sestavení XAML

Původně jsme sestavení XAML uvedli jako odebrané z verze TFS 2018 RTW a Update 1. Následkem toho ale příliš mnoho zákazníků nemohlo provést upgrade nebo muselo po dokončení upgradu žádat podporu o opětovné povolení. Ve verzi TFS 2018 Update 2 je sestavení XAML povolené, ale označené jako zastaralé. To znamená, že do sestavení XAML nebudeme nadále investovat a Microsoft Test Manager už nepodporuje použití sestavení XAML. Důrazně doporučujeme provést převod na jeden z novějších formátů definice sestavení. Ve verzi TFS 2018 Update 2 se můžete nadále připojovat ke kontrolerům XAML a spouštět sestavení XAML. Další informace

Funkce odebrané ve verzi TFS 2018 RTW

• Odebrali jsme podporu centra testovacích prostředí a toků automatizovaného testování z Microsoft Test Manageru.
• Ukončili jsme rozšíření TFS pro SharePoint.
• Odebrali jsme funkci týmové místnosti.

---

Podrobnosti o novinkách v TFS 2018

Sledování pracovních položek

Průvodce vytvořením projektu na webu

Vylepšili jsme prostředí pro vytváření týmových projektů při přístupu z webu. Teď obsahuje většinu funkcí, které jsou dostupné při vytváření týmového projektu v klientovi sady Visual Studio. Výhoda používání webového rozhraní spočívá v tom, že nemusíte mít shodnou verzi sady Visual Studio. Rozdíl mezi použitím sady Visual Studio a webové verze je v tom, že webová verze nezřizuje vaše sestavy v SSRS. Pokud jste týmový projekt vytvořili ve webové verzi, můžete sestavy SSRS zřídit nebo aktualizovat spuštěním příkazu tfsconfig na aplikační vrstvě.

Správce šablon procesů na webu

V TFS 2018 můžete šablony procesů odesílat přes web. Webové rozhraní se používá snadněji, protože nemusíte instalovat správnou verzi sady Visual Studio, abyste mohli pracovat se šablonami procesů. I když v sadě Visual Studio 2017 Update 4 a dřívějších verzích dialogové okno Správce šablon procesů stále najdete, doporučujeme používat webové rozhraní. Visual Studio 2017 Update 5 a novější verze vás přesměrují na web automaticky.

Přizpůsobení záhlaví formuláře pracovní položky

Teď můžete přizpůsobovat oblast záhlaví formuláře pracovní položky nahrazením stávajících ovládacích prvků nebo skrytím ovládacích prvků, které pro váš proces nejsou relevantní. Umožní to nahradit Cestu oblasti vlastním polem Tým, skrýt Iteraci, pokud se vaše týmy zaměřují víc na kanban, a nahradit Důvod vlastním polem. Pole Stav skrýt ani nahradit nejde.

Mobilní verze formuláře pracovní položky

Máme plnohodnotné, komplexní prostředí, které nabízí optimalizovaný vzhled a rozhraní pro pracovní položky (Obrázek 1) . Umožňuje vám pomocí telefonu snadno pracovat s položkami, které vám byly přiřazeny, které sledujete a které jste nedávno navštívili nebo upravili.

Spolu s pěkným vzhledem prostředí podporuje optimalizované ovládací prvky pro všechny typy polí (obrázek 2) .

Díky nové mobilní navigaci (obrázek 3) se uživatelé můžou spojit se všemi dalšími částmi TFS připravenými pro mobilní zařízení a vrátit se na plný desktopový web pro případ, že by potřebovali komunikovat s jinými rozbočovači.

Filtrování backlogů, karet Kanban, sprintů a dotazů

Všechna prostředí mřížek pro sledování pracovních položek (dotazů, backlogů, karet Kanban, backlogů sprintů a správu testovacích případů) teď využívají naši běžnou a konzistentní součást pro filtrování (obrázek 4) . Kromě použití filtrování podle klíčových slov v zobrazených sloupcích a výběru značek teď můžete filtrovat také typy, stavy a přiřazení pracovních položek, abyste se rychle dostali k pracovním položkám, které hledáte.

Rozbalení a zobrazení prázdných polí na kartě Kanban

Dnes máte možnost přidat na kartu další pole a pak v nastavení panelu skrýt prázdná pole(obrázek 5), abyste z panelu odstranili nepotřebné nepotřebné informace. Nevýhodou této funkce bylo to, že po skrytí prázdného pole jste ho mohli aktualizovat jenom tak, že jste otevřeli formulář pracovní položky. Nově dostupná možnost rozbalování na kartách Kanban vám umožňuje i nadále skrývat prázdná pole na kartě, ale jedním kliknutím získáte přístup k aktualizaci konkrétního pole na kartě. Stačí najet myší na kartu a po kliknutí na dvojitou šipku dolů v dolní části karty aktualizovat skryté pole.

Kliknutím na dvojitou šipku dolů v dolní části karty pole aktualizujte (Obrázek 6).

Blokování ukládání pracovních položek pomocí rozšíření

Vlastní ovládací prvky, skupiny a stránky na formuláři pracovní položky nyní mohou blokovat ukládání pracovních položek, aby bylo možné ověřovat data a zajistit, že uživatel vyplní všechny povinné informace předtím, než formulář pracovní položky uloží.

Přímé přidávání do Delivery Plans (plánů doručení)

Nové nápady na funkce můžou přijít kdykoliv, takže jsme usnadnili přidávání nových funkcí přímo do vašich plánů doručení(Obrázek 7). Stačí kliknout na tlačítko New item (Nová položka), které se zobrazí při najetí myší, zadat název a stisknout Enter. Vytvoří se nová funkce s cestou oblasti a cestou iterace podle vašeho očekávání.

Správa verzí

Forky

TFS 2018 přidává podporu forků Git (Obrázek 8) . Fork je kopie úložiště na straně serveru. Pomocí forků můžete celé řadě lidí umožnit přispívat do úložiště, aniž byste jim museli udělit přímý přístup k potvrzení. Místo toho tito uživatelé potvrdí svoji práci do vlastního forku úložiště. Tím získáte možnost zkontrolovat jejich změny v žádosti o přijetí změn, než jejich změny přijmete do centrálního úložiště.

GVFS

Odteď je podporovaný Git Virtual File System (GVFS). GVFS umožňuje úložištím Git škálovat se na miliony souborů díky virtualizaci a optimalizaci toho, jak Git pracuje se systémem souborů.

Vytvoření složky v úložišti pomocí webu

Teď ve svých úložištích Git a TFVC můžete vytvářet složky prostřednictvím webu (Obrázek 9) . Nahrazuje se tím rozšíření Správa složek, které se teď postupně přestane používat.

Pokud chcete vytvořit složku, klikněte na Nová > složka na panelu příkazů nebo v místní nabídce:

V TFVC zadáte název složky a pak ji vrátíte se změnami. V Gitu nejsou povolené prázdné složky, proto budete muset zadat také název souboru, který můžete upravit, a pak ho potvrdíte.

Kromě toho byl v Gitu vylepšen dialog Nový soubor(Obrázek 10) , aby přijímal lomítka k vytváření podsložek.

Minimapa souboru

Teď si můžete při prohlížení nebo úpravách zobrazit minimapu souboru, abyste získali rychlý přehled kódu (Obrázek 11) . Minimapu zapnete tak, že otevřete Paletu příkazů (pomocí F1 nebo kliknutím pravým tlačítkem) a vyberete Toggle Minimap (Přepnout minimapu).

Párování závorek

Při úpravách nebo prohlížení souboru jsou teď vlevo vodítka, které usnadňují párování závorek (Obrázek 12) .

Přepínání prázdných znaků

Při prohlížení nebo úpravách souboru teď můžete zapnout nebo vypnout prázdné znaky. Vyvíjíme funkci, která vám umožní přepínat prázdné znaky při porovnávání. Pokud chcete zobrazit prázdné znaky (Obrázek 13) , otevřete Paletu příkazů (pomocí F1 nebo kliknutím pravým tlačítkem) a vyberte Toggle White Space (Přepnout prázdné znaky). To vám umožní rozlišovat mezi mezerami a tabulátory.

Nastavení vypnutí webových úprav úložiště TFVC

Týmy, které používají TFVC, často využívají zásady vracení se změnami v sadě Visual Studio, aby zajistily kvalitu kódu. Vzhledem k tomu, že se zásady vracení se změnami vynucují v klientovi, kód upravovaný na webu nepodléhá stejným zásadám.

Někteří uživatelé požadovali možnost zakázat webové úpravy, aby zabránili změnám, které obcházejí zásady vracení se změnami. Zpřístupnili jsme vám možnost vypínání webových úprav (přidávání, odstraňování, přejmenování a úpravy) TFVC u projektu nebo úložiště.

Pokud chcete zakázat webové úpravy na stránce Soubory, přejděte na Nastavení a pak na Správa verzí(obrázek 14). Ve stromu klikněte na úložiště TFVC, přejděte na pivot Možnosti a zrušte zaškrtnutí možnosti Povolit webové úpravy tohoto úložiště TFVC. Ve výchozím nastavení jsou webové úpravy povoleny.

Pokud se na webu pokusíte upravit projekt, u kterého je možnost webových úprav zakázaná, zobrazí se oznámení, že webové úpravy nejsou povolené (Obrázek 15) .

Identifikace zastaralých větví

Když odstraníte větve, které už nepotřebujete, a budete úložiště udržovat čisté, budou týmy moct vyhledat větve, o které se starají, a nastavit oblíbené položky na správnou úroveň podrobností. Pokud ale máte v úložišti spoustu větví, může být obtížné zjistit, které nejsou aktivní a které je tedy možné je odstranit. Nyní jsme usnadnili identifikaci „zastaralých“ větví (větví, které ukazují na potvrzení starší než 3 měsíce). Zastaralé větve si můžete zobrazit tak, že přejdete na pivot Zastaralé na stránce Větve(Obrázek 16) .

Vyhledání odstraněné větve a její nové vytvoření

Když větev omylem odstraníte ze serveru, může být obtížné zjistit, co se s ní stalo. Nyní si můžete odstraněnou větev vyhledat, podívat se, kdo a kdy ji odstranil, a v případě potřeby ji znovu vytvořit.

Pokud chcete vyhledat odstraněnou větev, zadejte celý název větve do pole pro vyhledávání větví. Hledání vrátí všechny existující větve, které odpovídají hledanému textu. Zobrazí se vám také možnost vyhledat přesnou shodu v seznamu odstraněných větví. Odstraněné větve můžete vyhledat kliknutím na odkaz (Obrázek 17) .

Pokud se najde shoda, zobrazí se informace o tom, kdo a kdy větev odstranil. Větev můžete také obnovit (Obrázek 18) .

Obnovením odstraněnou větev znovu vytvoříte v potvrzení, na které naposledy ukazovala. Neobnoví se ale zásady ani oprávnění.

Vyhledání potvrzení ve větvích začínajících prefixem

Pokud máte strukturu větví v hierarchickém formátu, ve kterém mají všechny větve prefix ve formě textového řetězce, pomůže vám tato funkce vyhledat potvrzení ve všech větvích začínajících textovým řetězcem. Pokud například chcete zjistit, jestli se potvrzení promítlo do všech větví s předponou "dev", zadejte do vyhledávacího pole "dev" a vyberte Hledat ve větvích začínajících na "dev"(Obrázek 19).

Rozsáhlejší bublinové popisky žádostí o přijetí změn na stránce podrobností potvrzení

Bublinové popisky žádostí o přijetí změn na stránce podrobností potvrzení zobrazují relevantnější informace, abyste mohli provádět lepší diagnostiku (Obrázek 20) . Nyní se v bublinovém popisku zobrazuje také první žádost o přijetí změn, která uvedla potvrzení do všech větví, a žádost o přijetí změn přidružená k výchozí větvi.

Filtrování stromového zobrazení v kódu

Nyní už nemusíte procházet všechny soubory, které mohlo potvrzení změnit, abyste se dostali k požadovaným souborům. Stromové zobrazení na stránce podrobností potvrzení, žádostí o přijetí změn, podrobností sad odložených změn a podrobností sad změn nyní podporuje filtrování souborů a složek. Jedná se o inteligentní filtr, který při filtrování podle názvu složky zobrazuje podřízené soubory složky a při filtrování podle názvu souboru sbalené stromové zobrazení, aby byla patrná hierarchie souborů.

Vyhledání souboru nebo složky pomocí filtrování ve stromu potvrzení (Obrázek 21) a (Obrázek 22) :

Změna stránky aktualizace větví na stránku Vložení

Stránka Aktualizace větví nabízí skvělé možnosti. Byla ale skrytá v podobě pivotu v centru Historie. Teď je stránka aktualizací větví viditelná jako centrum s názvem Vložení(obrázek 23) v části Kód spolu s potvrzeními, větvemi, značkami a žádostmi o přijetí změn. Nová adresa URL pro stránku Vložení je: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. Staré adresy URL budou i nadále fungovat.

Současně se centrum Historie přejmenuje na Potvrzení(Obrázek 24), protože v centru se zobrazují jenom potvrzení. Dostali jsme zpětnou vazbu, že se lidem obtížně odstraňují potíže související s potvrzením, protože zobrazení seznamu potvrzení obsahuje jenom podrobný čas přechodu. Nyní zobrazení seznamu potvrzení v celé instanci bude zobrazovat datum a čas ve formátu dd/mm/rr hh:mm. Nová adresa URL pro stránku Potvrzení je: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. Staré adresy URL budou i nadále fungovat.

Zachování názvu souboru při přechodu ze souborů do potvrzení

Dostali jsme od uživatelů zpětnou vazbu, že když si z adresáře vyfiltrují konkrétní soubor v pivotu Soubory v centru Kód a potom přejdou na pivot Historie, název souboru se nezachová v případě, že potvrzení změnilo více než 1 000 souborů. Kvůli tomu museli uživatelé načítat více souborů a filtrovat obsah, aby našli požadovaný soubor. To mělo vliv na produktivitu. Vývojáři běžně pracují ve stejném adresáři a při sledování změn se chtějí držet adresářů, v nichž pracují. Nyní se název souboru při přechodu mezi pivoty centra Kód zachová bez ohledu na počet souborů, které byly v potvrzení změněny. To znamená, že při hledání požadovaného souboru už nemusíte klikat na Načíst další.

Zobrazení značek Git

Na stránce Značky(Obrázek 25) si můžete zobrazit všechny značky v úložišti. Pokud spravujete všechny značky jako vydané verze, může uživatel navštívit stránku značek a získat celkový přehled o všech vydaných verzích produktu.

Rozdíl mezi zjednodušenou a anotovanou značkou tady poznáte na první pohled. U anotovaných značek se spolu s potvrzením zobrazuje označovatel a datum vytvoření, zatímco u zjednodušených značek najdete jenom informace o potvrzení.

Odstranění značek Git

Může nastat situace, kdy budete chtít odstranit značku ze vzdáleného úložiště. Důvodem může být překlep v názvu značky nebo označení nesprávného potvrzení. Značky můžete snadno odstranit z webového uživatelského rozhraní kliknutím na místní nabídku značky na stránce Značky a výběrem možnosti Odstranit značku(obrázek 26).

Filtrování značek Git

U starých úložišť může postupem času počet značek značně narůst. Mohou také existovat úložiště, v nichž jsou značky vytvořeny hierarchicky, což může ztěžovat vyhledávání značek.

Pokud se vám na stránce Značky nedaří vyhledat požadovanou značku, můžete název značky jednoduše vyhledat pomocí filtru, který se nachází nahoře na stránce Značky(obrázek 27) .

Zabezpečení značek Git

Nyní můžete uživatelům úložiště udělit přesné oprávnění ke správě značek. Uživatelům můžete udělit oprávnění k odstraňování nebo správě značek z tohoto rozhraní (Obrázek 28) .

Automatické dokončování pracovních položek při dokončování žádostí o přijetí změn

Pokud propojujete pracovní položky se žádostmi o přijetí změn, bude pro vás aktualizace všech informací snazší. Při dokončování žádosti o přijetí změn teď máte k dispozici možnost automatického dokončení propojených pracovních položek po úspěšném sloučení žádosti o přijetí změn (Obrázek 29) . Pokud používáte zásady a nastavíte žádosti o přijetí změn na automatické dokončování, zobrazí se stejná možnost. Po dokončení žádosti o přijetí změn si už nemusíte pamatovat, že se máte k pracovním položkám vrátit, když budete chtít aktualizovat jejich stav. To se automaticky provede za vás.

Resetování hlasů při vložení nebo nové iteraci

Týmy, které vyžadují přísnější schvalovací pracovní postup v žádostech o přijetí změn, můžou teď vyjádřit výslovný souhlas a resetovat hlasy při vložení nových změn (Obrázek 30) . Toto nové nastavení představuje možnost v rámci zásad, které vyžadují minimální počet revidujících.

Při nastavení této možnosti se všechny hlasy od všech revidujících resetují vždy, když se aktualizuje zdrojová větev žádosti o přijetí změn. Časová osa žádosti o přijetí změn vytvoří záznam vždy, když se hlasy resetují v důsledku použití této možnosti (Obrázek 31) .

Filtrování stromu žádostí o přijetí změn podle názvu souboru

Vyhledání konkrétního souboru v žádosti o přijetí změn je snazší než kdy dříve. Nové pole filtrování v zobrazení Soubory umožňuje uživatelům vyfiltrovat seznam souborů ve stromovém zobrazení (Obrázek 32) .

Filtr hledá shodu ve všech částech cesty k souboru v žádosti o přijetí změn, takže můžete vyhledávat podle názvu složky, částečné cesty, názvu souboru nebo přípon (Obrázek 33) .

Další možnosti filtrování komentářů k žádostem o přijetí změn

Jak v přehledu žádostí o přijetí změn, tak v zobrazení souborů mají teď komentáře stejné možnosti (Obrázek 34) . Můžete si také vyfiltrovat jenom diskuze, do kterých jste se zapojili.

Zobrazení původního rozdílu u komentářů ke kódu v podrobnostech žádostí o přijetí změn

Někdy je těžké vyznat se v komentáři k žádosti o přijetí změn, když se změní kód, na který komentář odkazuje (v mnoha případech právě po provedení požadované změny) (Obrázek 35) .

Když taková situace nastane, uvidíte nově odznáček s číslem aktualizace, na který můžete kliknout a podívat se, jak kód vypadal v době, kdy uživatel komentář původně vytvořil (Obrázek 36) .

Sbalitelné komentáře k žádostem o přijetí změn

Revize kódu tvoří nepostradatelnou část procesu žádosti o přijetí změn, a proto jsme přidali nové funkce, díky nimž se revidující mohou snadněji zaměřit na samotný kód. Uživatelé revidující kód si můžou komentáře jednoduše skrýt, aby je při první revizi nového kódu nerušily (Obrázek 37) .

Když skryjete komentáře (Obrázek 38) , skryjete je ve stromovém zobrazení a sbalíte vlákna komentářů v zobrazení souborů:

Sbalené komentáře můžete snadno rozbalit kliknutím na ikonu na okraji a potom je snadno dalším kliknutím zase sbalit. Popisy tlačítek(obrázek 39) umožňují snadno nahlédnout do komentáře, aniž by bylo vidět celé vlákno.

Seznamy úloh v popisech žádostí o přijetí změn a komentářích k nim

Když připravujete žádost o přijetí změn nebo ji komentujete, máte někdy krátký seznam věcí, které chcete sledovat, ale potom skončíte u úprav textu nebo přidávání více komentářů. Zjednodušené seznamy úloh představují skvělý způsob, jak můžete sledovat postup u seznamu úloh, ať už jako autor žádosti o přijetí změn nebo revidující v popisu nebo jednom konsolidovaném komentáři. Po kliknutí na panel nástrojů Markdown se můžete pustit do práce nebo použít formát u vybraného textu (Obrázek 40) .

Po přidání seznamu úloh (Obrázek 41) můžete jednoduše zaškrtávat políčka a označovat tak položky jako dokončené. Ty se pak zobrazují a ukládají v komentářích jako [ ] a [x] v Markdownu. Další informace najdete v článku věnovanému pokynům pro Markdown.

Možnost lajkovat komentáře v žádostech o přijetí změn

Svou podporu komentáře k žádosti o přijetí změn můžete projevit jediným kliknutím na tlačítko pro olajkování(Obrázek 42) . Když najedete myší na tlačítko, zobrazí se seznam lidí, kteří komentář lajkovali.

Vylepšený pracovní postup při schvalování návrhů

Použití automatického dokončování(Obrázek 43) se žádostmi o přijetí změn pomáhá zvyšovat produktivitu, nemělo by ale přerušit aktivní diskuze s vašimi kolegy, kteří provádějí revize kódu. Pro větší usnadnění takových diskuzí hlas Schválit s návrhy nyní zobrazí výzvu, když je žádost o přijetí změn nastavena na automatické dokončování. Uživatel bude mít možnost zrušit automatické dokončování, aby bylo možné číst jeho zpětnou vazbu, nebo zachovat nastavení automatického dokončování a povolit automatické dokončování žádostí o přijetí změn při splnění všech zásad.

Podpora filtrování cesty u oznámení Git

Místo zobrazování oznámení pro všechny složky v úložišti si nyní můžete zvolit, že chcete dostávat oznámení, když členové týmu vytvoří žádosti o přijetí změn nebo vloží kód jenom ve složkách, které vás zajímají. Při vytváření odběru e-mailových oznámení o vlastních vloženích Git nebo žádostech o přijetí změn Git uvidíte novou možnost, která umožňuje filtrovat tato oznámení podle cesty ke složce (Obrázek 44) .

Aktualizované e-mailové šablony pro pracovní postupy žádostí o přijetí změn

E-mailová upozornění na žádosti o přijetí změn jsme aktualizovali tak, aby byla jasná, stručná a snadno se používala (Obrázek 45) . Řádek předmětu teď začíná názvem žádosti o přijetí změn a sekundárními informacemi, jako je název úložiště. Na konec se přidá ID. Do předmětu jsme přidali jméno autora, aby bylo možné snadněji použít pravidla a filtry podle osoby, která žádost o přijetí změn vytvořila.

Text e-mailového upozornění má aktualizovanou šablonu, ve které je nejprve uvedeno, proč se upozornění poslalo, dále důležitá metadata (název, názvy větví a popis) a potom tlačítko s hlavní výzvou k akci. Další podrobnosti, jako jsou revidující, soubory a potvrzení, jsou uvedeny dále v e-mailu.

U většiny upozornění výzva k akci (Obrázek 46) uživatele žádá, aby zobrazil žádost o přijetí změn na webu. Když vám ale dojde oznámení o konkrétním komentáři, bude výzva k akci odkazovat přímo na daný komentář, abyste mohli snadno vyhledat kód a předchozí konverzaci kvůli kontextu.

Aktualizované e-mailové šablony pro nabízená oznámení (o vložení)

Nabízená oznámení (o vložení) byla aktualizována, aby odpovídala novým e-mailovým šablonám, které jsou optimalizované tak, aby byly jasné, stručné a umožňovaly provádění následných akcí (Obrázek 47) . Řádek předmětu pomáhá jasně rozlišit e-maily s nabízenými oznámeními (o vložení), identifikovat větev, úložiště a autora a shrnout počet potvrzení zahrnutých ve vložení. Tyto změny také usnadňují vytváření pravidel a filtrů ke správě těchto e-mailových oznámení.

Text e-mailu je konzistentní s ostatními e-maily a zdůrazňuje, proč byl e-mail zaslán, kdo inicioval akci a co přesně se stalo. Pro upozornění na vložení je specifické, že obsahují podrobnosti o úložišti, větvi, souborech a potvrzeních, které příjemce pomáhají informovat o rozsahu změn. Hlavní výzva k akci v upozorněních na vložení je View Push (Zobrazit vložení). Tím se otevře zobrazení vložení pro konkrétní vložení, které upozornění vygenerovalo.

Wiki

Každý projekt teď podporuje vlastní wiki (Obrázek 48) . Teď můžete pohodlně psát stránky, které vašemu týmu pomohou pochopit a používat projekt a přispívat do něj.

Mezi klíčové funkce nové wiki patří:

• Zjednodušené prostředí pro úpravy využívající syntaxi markdownu.
• Na nové stránce můžete zadat název a přidat obsah. (Obrázek 49)

• Podpora značek HTML v markdownu (Obrázek 50) .

• Pohodlná změna velikosti obrázků ve složce markdownu (Obrázek 51) .

• Výkoný panel pro správu stránky, který vám umožňuje měnit řazení, nadřazení a správu stránek.
• Možnost filtrovat stránky podle názvu u rozsáhlých wiki (Obrázek 52) .

• Offline aktualizace wiki u členů skupiny Power Users.

S tím, jak budete více a více používat wiki, existuje možnost, že si uložíte nechtěné změny. Teď můžete vrátit revizi wikistránky tak, že přejdete na podrobnosti revize a kliknete na tlačítko Vrátit(Obrázek 53) .

Vytvoření stránky wiki z nefunkčního odkazu

Při vytváření wiki jsme opakovaně zaznamenali, že součástí obsahu na stránce wiki byly neexistující odkazy (Obrázek 54) . Uživatelé by při pokusu o vytvoření skutečné stránky mohli na tyto odkazy kliknout. Dříve jsme v takovém případě zobrazili upozornění, že je odkaz poškozený nebo že daná stránka neexistuje. Nyní tento postup považujeme u wiki za standardní scénář a umožňujeme vám místo toho vytvářet stránky.

Přímé odkazování na wikistránce

Wiki teď podporuje sekce přímého odkazování v rámci stránky i mezi stránkami. To se hodí hlavně pro vytváření obsahů. Na nadpis na stejné stránce nebo jiné stránce můžete odkazovat pomocí této syntaxe:

• Stejná stránka:[text to display](#section-name)
• Jiná stránka:[text to display](/page-name#section-name)

Rozšíření wiki na Marketplace je nyní vyřazeno. Pokud stále používáte existující rozšíření wiki, můžete svoje wikistránky migrovat na novou wiki pomocí tohoto nástroje pro migraci. Přečtěte si další informace o tom, jak provést migraci existujících wikistránek na novou wiki.

Správa balíčků

Aktualizace prostředí pro správu balíčků

Adresy URL balíčků nyní pracují s názvy a verzemi balíčků místo používání identifikátorů GUID. To usnadňuje ruční vytváření adres URL balíčků (Obrázek 55) . Formát je: \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package.

Teď můžete skrýt odstraněné verze balíčků (Obrázek 56) ze zobrazení všech uživatelů informačního kanálu. Už žádné přeškrtávání balíčků!

Všechny akce, které můžete provést na stránce podrobností balíčku, můžete nyní provést i z místní nabídky v seznamu balíčků.

Seznam balíčků obsahuje nový sloupec Naposledy vloženo(Obrázek 57) s čitelnějším datem, abyste mohli snadno vyhledat naposledy aktualizované balíčky.

Balíčky Maven

Spustili jsme podporu hostování artefaktů Maven v TFS 2018 (Obrázek 58) . Artefakty Maven umožňují vývojářům v jazyce Java snadno sdílet kód a komponenty. Podívejte se na naši příručku Začínáme, kde najdete postupy sdílení artefaktů Maven pomocí správy balíčků.

Nová jednotná úloha NuGet

Zkombinovali jsme úlohu obnovení NuGetu, nástroje pro sestavování balíčků NuGet a vydavatele NuGetu do jednotné úlohy sestavení NuGet, aby lépe odpovídala zbývající části knihovny úloh sestavení. Nová úloha standardně používá NuGet 4.0.0. Z tohoto důvodu jsou staré úlohy vyřazeny a doporučujeme v nejbližší možné době přejít na novou úlohu NuGet. Tato změna je v souladu se skupinou vylepšení popsaných níže, k nimž budete moci přistupovat pouze prostřednictvím kombinované úlohy.

V rámci této iniciativy jsme také vydali novou úlohu instalačního programu nástrojů NuGet, která řídí verzi NuGetu dostupnou v proměnné PATH a používá ji nová úloha NuGet. Pokud tedy chcete používat novější verzi NuGetu, stačí, když na začátek sestavení přidáte úlohu instalačního programu nástrojů NuGet(Obrázek 59) .

Možnost NuGetu povolit vynechávání duplicit

Mnoho zákazníků NuGetu nás informovalo, že když generují sadu balíčků, mají aktualizace (a tudíž aktualizovaná čísla verze) jenom některé z nich. Úloha sestavení NuGet obsahuje novou možnost povolení vynechávání duplicit, která umožní úloze pokračovat, když se pokusí vložit balíčky do informačního kanálu VSTS/TFS, v němž se už daná verze používá.

Aktualizace úlohy sestavení npm

Bez ohledu na to, jestli sestavujete projekt npm v systému Windows, Linux nebo Mac, bude nová úloha sestavení NPM fungovat bez problémů. Úlohu jsme také reorganizovali, abychom usnadnili jak instalaci npm, tak i publikování npm. U instalace a publikování jsme zjednodušili získání přihlašovacích údajů, aby bylo možné přihlašovací údaje k registrům uvedeným v souboru .npmrc projektu bezpečně uložit v koncovém bodu služby. Případně pokud používáte informační kanál VSTS/TFS, můžete si pomocí ovládacího prvku pro výběr vybrat informační kanál. Potom se vygeneruje .npmrc s požadovanými přihlašovacími údaji, které bude používat agent sestavení.

Maven nyní podporuje ověřené informační kanály

Na rozdíl od NuGetu a npm, úloha sestavení Maven dříve nefungovala s ověřenými informačními kanály. Úlohu Maven jsme aktualizovali, abyste snadno mohli pracovat s informačními kanály VSTS/TFS (Obrázek 60) .

Úloha dotnet podporuje ověřené informační kanály a webové projekty

Další hlavní verze úlohy dotnet (2.x) řeší celou řadu vašich žádostí a opravuje skupinu chyb, které už chvíli vedeme v patrnosti. Ta zahrnují následující:

1. Dotnet nyní podporuje ověřené zdroje balíčků, jako je Správa balíčků, takže už nemusíte používat úlohu NuGet k obnovení balíčků z privátních zdrojů balíčků.
2. Chování pole Cesta k projektům se ve verzi 2.0 úlohy změnilo. Pokud se v předchozích verzích úlohy soubory projektu odpovídající zadanému vzoru nenašly, úloha zaprotokolovala upozornění a potom se úspěšně provedla. V takových scénářích může být někdy docela oříšek zjistit, proč se sestavení zdařilo, ale závislosti se neobnovily. Nyní se úloha nezdaří, pokud se soubory projektu odpovídající zadanému vzoru nenajdou. Toto je v souladu s chováním ostatních úloh a tato úloha je snadno pochopitelná a použitelná.
3. V předchozích verzích příkazu pro publikování úlohy úloha změnila výstupní cestu tak, že umístila všechny soubory do složky s názvem souboru projektu, a to i když jste předali explicitní výstupní cestu. Kvůli tomu se obtížně řetězily příkazy dohromady. Teď máte kontrolu nad souborem ve výstupní cestě.

Také jsme vydali novou úlohu instalačního programu nástrojů dotnet, která řídí verzi dotnetu dostupnou v proměnné PATH a kterou používá nová úloha dotnet. Pokud tedy chcete používat novější verzi dotnetu, stačí, když na začátek sestavení přidáte úlohu instalačního programu nástrojů dotnet.

Práce mimo účet nebo kolekci

Práce s informačními kanály (Obrázek 61) mimo server TFS nebo účet VSTS je teď snazší, a to bez ohledu na to, jestli se jedná o informační kanály Správa balíčků v jiném účtu VSTS nebo na serveru TFS, nebo o jiné informační kanály, jako jsou NuGet.org/npmjs.com, Artifactory či MyGet (Obrázek 60) . Vyhrazené typy koncového bodu služby pro NuGet a npm usnadňují zadávání správných přihlašovacích údajů a umožňují bezproblémovou funkci úloh sestavení ve všech operacích stahování a vkládání balíčků.

Výběr informačního kanálu pro informační kanály VSTS/TFS

Vždy doporučujeme konfigurační soubor (například NuGet.Config, .npmrc atd.) vracet se změnami, aby zdrojové úložiště mělo záznam o tom, odkud balíčky pocházejí. Zjistili jsme ale, že existuje řada scénářů, kdy to není ideální, a proto jsme přidali novou možnost Používat balíčky z tohoto informačního kanálu VSTS/TFS, která umožňuje vybrat informační kanál a automaticky vygenerovat konfigurační soubor, který se použije v daném kroku sestavení (Obrázek 62) .

Sestavení a vydaná verze

Sestavení XAML

V TFS 2015 jsme představili webový a víceplatformový systém sestavení. Sestavení XAML nejsou podporovaná ve verzi TFS 2018 RTW ani Update 1, ale ve verzi TFS 2018 Update 2 jsme je znovu povolili. Doporučujeme, abyste migrovali svoje sestavení XAML. Pokud ještě nejste na migraci připravení a potřebujete i nadále používat sestavení XAML, upgradujte prosím na verzi TFS 2018 Update 2.

Při upgradu na verzi TFS 2018 RTW nebo Update 1:

• Pokud máte v kolekci týmových projektů data sestavení XAML, zobrazí se vám upozornění na odebrání funkcí sestavení XAML.

• Můžete zobrazit dokončená sestavení XAML, ale nebudete moct zařazovat do fronty nová.

• V TFS 2018 neexistuje nová verze kontroleru ani agenta sestavení XAML.

Při upgradu na verzi TFS 2018 Update 2:

• Pokud máte v kolekci týmových projektů data sestavení XAML, zobrazí se vám upozornění na zastarání funkcí sestavení XAML.

• K úpravě definic sestavení XAML nebo zařazení nových sestavení XAML do fronty musíte použít Visual Studio nebo Team Explorer 2017.

• Pokud potřebujete vytvořit nové agenty sestavení XAML, budete je muset nainstalovat pomocí instalačního programu agenta sestavení TFS 2015.

Export a import definic sestavení

Definice sestavení se implementují interně jako soubory .json, takže si můžete zobrazit podrobnosti o změnách v historii souboru. Přestože už nyní můžete definice sestavení klonovat a vytvářet z nich šablony, mnoho uživatelů si chce zkopírovat svoji logiku sestavení CI a znovu ji použít v jiném týmovém projektu. Šlo o jednu z deseti nejčastějších žádostí na UserVoice.

S radostí vám oznamujeme, že máte k dispozici (Obrázek 63) a (Obrázek 64) .

Rozšíření pomocí šablon sestavení

Pomocí šablon sestavení můžete uživatelům vytvořit základnu, aby mohli začít definovat svůj proces sestavení. Jako součást produktu v současné době dodáváme celou řadu těchto šablon a přestože můžete do svého účtu odesílat nové šablony, autoři rozšíření nikdy nemohli zahrnout nové šablony do svých rozšíření. Nyní můžete šablony sestavení zahrnout do svých rozšíření. Příklad:

{  "id": "Template1", 
   "type": "ms.vss-build.template", 
   "targets": [ "ms.vss-build.templates" ], 
   "properties": { "name": "Template1" } }

Úplný příklad najdete na stránce https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

Vyřazení úlohy v rozšíření

Nyní můžete vyřadit úlohu v rozšíření. Aby to fungovalo, musíte do nejnovější verze úlohy přidat následující proměnnou:

"deprecated": true

Když uživatel vyhledává zastaralé úlohy (Obrázek 65) , odsuneme tyto úlohy na konec a seskupíme je do sbalitelného oddílu (ve výchozím nastavení je sbalený). Pokud se v definici stále používá vyřazená úloha, zobrazíme odznáček vyřazené úlohy, abychom uživatele přiměli přejít na náhradní úlohu.

Uživatelům můžete dát vědět o náhradní úloze tak, že ji zmíníte v popisu úlohy (Obrázek 66) . Popis pak uživatelům úlohy ukáže správný směr jak z katalogu úloh, tak i existujících definic sestavení nebo vydané verze.

Možnost řízení viditelnosti oddílu pomocí oddílů sestavení v rámci příspěvku

Pokud jste dříve používali rozšíření, které obsahovalo úlohy sestavení a souhrnné oddíly sestavení, zobrazoval se vám souhrnný oddíl sestavení, i když jste v daném sestavení úlohu sestavení nepoužili. Nyní si můžete zvolit, zda chcete tento oddíl na stránce se souhrnem sestavení skrýt nebo zobrazit. Uděláte to tak, že do kódu rozšíření přidáte následující řádek a nastavíte hodnotu na True nebo False:

VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);

Podívejte se na ukázku v úložišti Microsoft vsts-extension-samples.

Podpora skupiny proměnných

Skupiny proměnných byly k dispozici pro použití v definicích vydaných verzí a nyní jsou připraveny k použití také v definicích sestavení. Přečtěte si další informace o vytvoření skupiny proměnných. Tato možnost byla vyvinuta a upřednostněna na základě souvisejících návrhů týkajících se proměnných sestavení nebo vydané verze na úrovni projektu a skupin proměnných v definicích sestavení.

Práce se zabezpečenými soubory, například certifikáty Apple

Přidali jsme knihovnu zabezpečených souborů pro obecné účely(Obrázek 67).

Knihovna zabezpečených souborů slouží k ukládání souborů, jako jsou podpisové certifikáty, zřizovací profily Apple, soubory úložiště klíčů Android a klíče SSH, na server bez nutnosti potvrzovat je do zdrojového úložiště.

Obsah zabezpečených souborů je šifrovaný a je možné ho použít jenom během procesu sestavení nebo vydané verze pomocí odkazu z úlohy. Zabezpečené soubory jsou dostupné v různých definicích sestavení a vydané verze v týmovém projektu na základě nastavení zabezpečení. Zabezpečené soubory se řídí modelem zabezpečení knihovny.

Přidali jsme také některé úlohy Apple, které tuto novou funkci využívají:

• Nástroj: Instalace certifikátu Apple

• Nástroj: Instalace zřizovacího profilu Apple

Pozastavení definic sestavení

Teď můžete pozastavit nebo vypnout definice sestavení. Pokud plánujete udělat změny v definici sestavení a chcete se vyhnout řazení nových sestavení do fronty, dokud změny nedokončíte, stačí definici sestavení vypnout. Podobně pokud plánujete upgrade počítačů agentů, můžete definici sestavení pozastavit. VSTS tak může stále přijímat nové žádosti o sestavení, ale bude je držet ve frontě bez spuštění, dokud definici znovu nespustíte.

Podpora ověřování zadávání úloh

Při zadávání parametrů v úlohách definic sestavení může někdy docházet k chybám. Pomocí ověřování zadávání úloh můžou autoři úloh zajistit, aby byly zadány správné hodnoty. Ověřovací výrazy používají známou syntaxi výrazů, která se používá pro podmínky úloh, a vedle obecných funkcí podporovaných podmínkami úloh můžou použít libovolné podporované funkce, včetně adresy URL, IPV4, e-mailu, rozsahu čísel, sha1, délky nebo shody.

Nový editor definic vydané verze

Pokračujeme v oživení prostředí sestavení a vydaných verzí a přepracovali jsme editor definic vydané verze, aby byl intuitivnější, opravili jsme některé palčivé problémy a přidali nové funkce. Jednou z nejlepších funkcí nového editoru je jeho schopnost pomoci vám vizualizovat postup nasazení do vašeho prostředí. Kromě toho jsou nyní schválení a nastavení vlastností prostředí a nasazení zasazeny do kontextu a je možné je snadno konfigurovat.

Vizualizace kanálu

Kanál (Obrázek 68) v editoru poskytuje grafické znázornění postupu nasazení ve vydané verzi. Artefakty se využívají vydanou verzí a nasazují se do prostředí. Rozložení a propojení prostředí odráží nastavení aktivační události definované pro jednotlivá prostředí.

Uživatelské rozhraní pro konfiguraci v kontextu

Artefakty, aktivační události vydané verze, schválení před a po nasazení, vlastnosti prostředí a nastavení nasazení jsou teď zasazené do kontextu a dají se snadno konfigurovat (Obrázek 69) .

Začínáme se šablonami nasazení

Všechny integrované šablony nasazení jsou vybavené parametry procesu. Uživatelé tak můžou snadno začít zadáním nejdůležitějších parametrů, aniž by museli úlohy hlouběji zkoumat (Obrázek 70) .

Zjednodušená správa proměnných vydaných verzí a prostředí

Pomocí zobrazení Seznam můžete rychle přidat proměnné vydaných verzí nebo prostředí a pomocí zobrazení Mřížka můžete porovnat a upravit proměnné napříč rozsahy vedle sebe (Obrázek 71) . Kromě toho můžete sadu proměnných spravovat pomocí filtru a vyhledávání klíčových slov pro práci v obou zobrazeních.

Vylepšený editor úloh a fází

Všechna vylepšení v novém editoru definic sestavení jsou teď dostupná také v editoru definic vydané verze (Obrázek 72) . Můžete úlohy vyhledat a přidat je buď pomocí tlačítka Přidat, nebo pomocí přetažení. Přetažením můžete úlohy znovu seřadit nebo naklonovat.

Karty Skupiny proměnných, Uchovávání a Možnosti

Na kartě Možnosti teď můžete vytvořit propojení se skupinami proměnných (a také ho zrušit) (Obrázek 73) , nastavit zásady uchovávání informací pro jednotlivá prostředí a změnit nastavení na úrovni definic vydané verze, jako je formát čísla vydané verze. Na kartě Úlohy můžete také uložit prostředí jako šablonu nasazení, nastavit oprávnění na úrovni prostředí a změnit pořadí fází.

Operace na úrovni prostředí můžete využít k ukládání jako šablon a k nastavení zabezpečení (Obrázek 74) .

Nasazení virtuálního počítače pomocí skupin nasazení

Release Management nyní podporuje robustní dodávané nasazení na více počítačů. Nyní můžete orchestrovat nasazení na více počítačů a provádět kumulativní aktualizace a současně zajistit vysokou dostupnost celé aplikace.

Funkce nasazení na základě agenta spoléhá na stejné agenty sestavení a nasazení. Na rozdíl od současného přístupu, kdy jste instalovali agenty sestavení a nasazení na skupinu proxy serverů ve fondu agentů a řídili nasazení na vzdálené cílové servery, instalujete ale agenta na každý cílový server přímo a řídíte kumulativní nasazení na tyto servery. Na cílových počítačích můžete využít celý katalog úloh.

Skupina nasazení (Obrázek 75) je logická skupina cílů (počítačů) s agenty nainstalovanými na každém z nich. Skupiny nasazení představují vaše fyzická prostředí, například vývojové prostředí v jednom rámečku, kontrolu kvality pro více počítačů nebo farmu počítačů pro UAT/Prod. Specifikují také kontext zabezpečení vašich fyzických prostředí.

Skupiny nasazení můžete použít na libovolném virtuálním počítači, na kterém je zaregistrován náš agent. Také jsme velmi usnadnili registraci v Azure pomocí podpory rozšíření virtuálního počítače Azure, které automaticky nainstaluje agenta při spuštění virtuálního počítače. Po registraci virtuálního počítače Azure se automaticky budou dědit jeho značky.

Jakmile máte skupinu nasazení, můžete jednoduše nakonfigurovat úlohy, které v ní chcete provádět (Obrázek 76) . Pomocí značek můžete řídit, co a na kterých počítačích se bude spouštět, a také jak rychle nebo pomalu se bude provádět uvedení.

Při spuštění nasazení se v protokolech zobrazuje jeho průběh v celé skupině počítačů, na které cílíte (Obrázek 77) .

Tato funkce nyní tvoří nedílnou součást Release Managementu. Nejsou potřeba žádné další licence.

Vylepšené uživatelské rozhraní Deployment Groups (skupin nasazení)

Pokračujeme v oživení prostředí sestavení a vydaných verzí a přepracovali jsme stránky skupin nasazení, aby byly přehlednější a intuitivnější (Obrázek 78) . Z cílové stránky si můžete zobrazit stav cílů ve skupině nasazení. Můžete také spravovat zabezpečení jednotlivé skupiny nasazení nebo nastavit výchozí oprávnění ve všech skupinách nasazení.

Pro cíl ve skupině nasazení můžete zobrazit souhrn, poslední nasazení a možnosti cíle (Obrázek 79) . Můžete na cíli nastavit značky a řídit, co se na každém cíli spouští. V budoucích verzích přidáme podporu filtru pro skupiny nasazení.

Odkazy na skupinu úloh

Skupiny úloh vám umožňují definovat sadu úloh, které si můžete přidat do definic sestavení nebo vydané verze (Obrázek 80) . To přijde vhod, když potřebujete použít stejné seskupení úloh ve více sestaveních nebo vydaných verzích. Abychom vám pomohli sledovat uživatele skupiny úloh, máte teď možnost zobrazit si definice sestavení a vydaných verzí a skupiny úloh, které odkazují na vaši skupinu úloh (Obrázek 79) .

Když se pokusíte odstranit skupinu úloh, na kterou se stále odkazuje, zobrazí se vám upozornění a odkaz na tuto stránku.

Správa verzí skupiny úloh

Provádění změn u skupin úloh může být riskantní, protože změny se promítnou u všech definic, které danou skupinu úloh používají. Pomocí správy verzí skupiny úloh můžete nyní vytvořit koncept a verzi Preview skupiny úloh, ale současně stále nabízíme stabilní verze vašich nejdůležitějších definic, dokud nebudete připraveni na přepnutí. Po vytvoření konceptu a iteraci můžete publikovat stabilní verzi a při publikování – v případě mimořádných změn – si můžete zvolit, že se má skupina úloh publikovat jako verze Preview (nová hlavní verze). Můžete ji také publikovat přímo jako aktualizovanou stabilní verzi (Obrázek 81) .

Když je dostupná nová hlavní verze (neboli verze Preview) skupiny úloh, editor definic vás upozorní, že existuje nová verze. Pokud tato hlavní verze představuje verzi Preview, zobrazí se i zpráva, abyste si ji vyzkoušeli. Pokud skupina úloh pochází z verze Preview, definice, které ji používají, se automaticky aktualizují a posunou se v tomto hlavním kanálu (Obrázek 82) .

Import a export skupiny úloh

Přestože můžete v rámci projektu skupiny úloh opakovaně používat, je nám jasné, že opakované vytváření skupiny úloh v různých projektech a účtech je namáhavé. Při importu a exportu skupiny úlohy (Obrázek 83) (stejně jako u definic vydané verze) teď můžete exportovat soubor JSON a naimportovat ho do požadovaného umístění. Povolili jsme také vnořené skupiny úloh, které se poprvé rozbalí při exportu.

Podpora více konfigurací v úlohách na straně serveru (bez využití agentů)

Zadáním multiplikátoru proměnných pro úlohy na straně serveru (bez agenta) (Obrázek 84) teď můžete spustit stejnou sadu úloh ve fázi pro více konfigurací, které běží paralelně.

Podpora proměnných v úloze Ruční zásah

Úloha Ruční zásah(Obrázek 85) teď podporuje používání proměnných v návodném textu, který se uživatelům zobrazí při spuštění, v okamžiku, kdy uživatel může obnovit spuštění procesu vydané verze nebo ho odmítnout. Můžete zahrnout všechny proměnné definované a dostupné ve vydané verzi. Hodnoty se použijí v oznámeních i v e-mailech poslaných uživatelům (Obrázek 86) .

Řízení vydaných verzí v prostředí na základě zdrojové větve

Definici vydané verze je možné nakonfigurovat tak, aby aktivovala nasazení automaticky při vytvoření nové vydané verze. Obvykle se tak děje po úspěšném sestavení zdroje. Můžete ale chtít nasadit jenom sestavení z konkrétních větví zdroje a nikoli až poté, co se některé sestavení úspěšně provede.

Můžete například chtít nasadit všechna sestavení, která se mají nasadit do vývojového a testovacího prostředí, ale jenom konkrétní sestavení nasazené do produkčního prostředí. Dříve jste pro tento účel museli udržovat dva kanály vydané verze, jeden pro vývojové a testovací prostředí a druhý pro produkční prostředí.

Release Management nyní podporuje použití filtrů artefaktů pro každé prostředí. To znamená, že můžete zadat vydané verze, které se nasadí do jednotlivých prostředí při splnění podmínek aktivace nasazení (například úspěšné sestavení a vytvoření nové vydané verze). V oddílu Aktivační událost v dialogovém okně prostředí Podmínky nasazení(Obrázek 87) vyberte podmínky artefaktů, například zdrojovou větev a značky pro sestavení, které aktivují nové nasazení do daného prostředí.

Kromě toho se teď na stránce souhrnu vydané verze(Obrázek 88) automaticky otevírá tip, který označuje důvod nespuštění všech nasazení v tomto stavu a navrhuje způsob spuštění nasazení nebo dobu, kdy se má spustit.

Aktivační procedury vydané verze pro úložiště Git jako zdroj artefaktu

Release Management teď podporuje konfiguraci aktivační události pro průběžné nasazování u úložišť Git (Obrázek 89) , která jsou propojena s definicí vydané verze v libovolném týmovém projektu ve stejném účtu. To vám umožňuje automaticky aktivovat vydanou verzi, když se do úložiště provede nové potvrzení. Můžete také zadat větev v úložišti Git, pro kterou se vydaná verze aktivuje.

Aktivační události vydané verze: Průběžné nasazování změn vložených do úložiště Git

Release Management stále poskytuje možnost konfigurace průběžného nasazování při dokončení sestavení. Nyní ale můžete nakonfigurovat průběžné nasazování také u git push. To znamená, že můžete propojit úložiště GitHub a Team Foundation Git jako zdroje artefaktů s definicí vydané verze a potom automaticky aktivovat vydané verze pro aplikace, jako jsou Node.JS a PHP, které se negenerují ze sestavení, a proto pro průběžné nasazování nevyžadují akci sestavení.

Filtry větví v aktivačních událostech prostředí

V novém editoru definic vydané verze teď můžete určit podmínky artefaktů pro konkrétní prostředí. Pomocí těchto podmínek artefaktů budete mít podrobnější kontrolu nad tím, které artefakty by měly být do konkrétního prostředí nasazeny. Třeba pro produkční prostředí můžete chtít, aby se nasadila sestavení vygenerovaná jenom z hlavní větve. Tento filtr se musí nastavit pro všechny artefakty, které by podle vás měly toto kritérium splňovat.

Pro každý artefakt, který je s definicí vydané verze propojený, můžete také přidat víc filtrů (Obrázek 90) . Nasazení se do tohoto prostředí spustí jenom v případě, že jsou úspěšně splněné všechny podmínky artefaktů.

Vylepšení úloh na straně serveru

U úloh na straně serveru (úloh, které se spouští v serverové fázi) jsme provedli dvě vylepšení.

Přidali jsme novou úlohu, která vyvolává libovolné obecné rozhraní HTTP REST API (Obrázek 91) v rámci automatizovaného kanálu. Můžete ji například použít k vyvolání konkrétního zpracování pomocí funkce Azure a počkat na její dokončení.

Do všech úloh na straně serveru jsme také přidali oddíl Možnosti ovládacího prvku(obrázek 92). Chování úlohy nyní zahrnuje nastavení možností Povolené, Při chybě pokračovat, Vždycky spouštět a Časový limit.

Odznáček stavu vydané verze v centru Kód

Pokud v současné době chcete vědět, zda je potvrzení nasazeno v produkčním prostředí zákazníka, musíte nejprve identifikovat sestavení, které využívá potvrzení, a potom zkontrolovat všechny vydané verze prostředí, kde je toto sestavení nasazeno. Nyní je tento postup mnohem snazší díky integraci stavu nasazení v odznáčku stavu centra Kód, který zobrazuje seznam prostředí, v nichž je váš kód nasazen. U každého nasazení se stav zveřejní v posledním potvrzení, které bylo součástí nasazení. Pokud je potvrzení nasazeno do více definic vydané verze (s více prostředími), bude každá definice obsahovat odznáček se stavem pro každé prostředí (Obrázek 93) . To vylepšuje sledovatelnost potvrzení kódu do nasazení.

Když ve výchozím nastavení vytvoříte definici vydané verze, stav nasazení se zveřejní pro všechna prostředí. Můžete si ale zvolit konkrétní prostředí, jejichž stav nasazení by se měl v odznáčku zobrazovat (například se bude zobrazovat jenom pro produkční prostředí) (Obrázek 94) .

Vylepšení nabídky definic sestavení při přidávání artefaktů

Když přidáváte artefakty sestavení do definice vydané verze, můžete si teď zobrazit definice s informacemi o uspořádání složek. To vám usnadní volbu požadované definice (Obrázek 95) . Díky tomu snadněji rozlišíte stejný název definice sestavení, ale v různých složkách.

Seznam definic se filtruje na základě těch, které obsahují termín filtru.

Vrácení definice vydané verze na starší verzi

V současné době platí, že pokud je definice vydané verze aktualizována, nemůžete se přímo vrátit k její předchozí verzi. Jediným způsobem je vyhledat rozdíly ve změnách v historii definic vydané verze a potom ručně definici vydané verze upravit. Teď můžete pomocí funkce Původní definice(Obrázek 96) zvolit na kartě Historie definice vydané verze kteroukoli starší verzi definice a vrátit se k ní.

Přizpůsobená oznámení pro vydané verze

Oznámení o vydaných verzích jsou teď integrovaná s nastaveními oznámení VSTS. Ti, kdo spravují vydané verze, teď automaticky dostávají oznámení o čekajících akcích (schválení nebo ruční zásahy) a závažných selháních nasazení. Tato oznámení můžete vypnout tak, že přejdete do nastavení Oznámení v nabídce profilu a vypnete Release Subscriptions (Odběry vydaných verzí). Můžete také odebírat další oznámení vytvořením vlastních odběrů. Správci můžou řídit odběry pro týmy a skupiny z nastavení Oznámení v nastaveních týmu a účtu.

Autoři definic vydaných verzí už nemusí ručně odesílat e-maily ohledně schválení a dokončení nasazení.

To je užitečné hlavně pro velké účty, které mají pro vydané verze více zúčastněných stran, a pro jiné uživatele, než je schvalovatel, tvůrce vydané verze a vlastník prostředí, kteří můžou chtít oznámení dostávat (Obrázek 97) .

Testování

Odebrání podpory centra testovacích prostředí a toků automatizovaného testování v Microsoft Test Manageru

Spolu s vývojem správy sestavení a vydaných verzí se už sestavení XAML v TFS 2018 nepodporují, a proto aktualizujeme podporu používání Microsoft Test Manageru (MTM) s TFS. Počínaje verzí TFS 2018 už TFS nadále nepodporuje používání centra testování a centra testovacích prostředí pro automatizované testování v MTM. Pokud ještě nejste připraveni na migraci ze sestavení XAML a centra testovacích prostředí, neměli byste upgradovat na TFS 2018.

Níže najdete dopad upgradu na TFS 2018:

Centrum testovacích prostředí:

• Nadále se nepodporuje:
  • Testovací kontroléry není možné zaregistrovat v TFS za účelem vytváření a správy testovacích prostředí.
  • Všechny existující testovací kontroléry zaregistrované v TFS přejdou do režimu offline a existující testovací prostředí se zobrazí jako nepřipravené.
• Doporučená alternativa:
  • Pomocí rozšíření SCVMM pro TFS se můžete připojit k serveru SCVMM, kde můžete vytvořit a spravovat virtuální počítače a spouštět pracovní postupy. Další podrobnosti najdete v článku věnovanému způsobu provádění operací Lab Management v sestavení a vydané verzi.

Automatizované testování:

• Nadále se nepodporuje:
  • Pracovní postupy automatizovaného testování, které spoléhají na testovací kontrolér a testovací prostředí, jako je pracovní postup XAML pro sestavení, nasazení a testování, nebo na automatizované testy z testovacího plánu pomocí MTM, se už nepodporují.
• Doporučené alternativy:
  • Můžete spustit automatizované testy v sestavení a vydané verzi.
  • Můžete spustit automatizované testy z testovacího plánu pomocí centra testování.

Manuální testování:

• Všechny scénáře manuálního testování jsou stále plně podporovány. Přestože v TFS 2018 můžete manuální testování spustit pomocí MTM, nemůžete manuální testování spouštět pomocí testovacích prostředí.
• Pro všechny scénáře manuálního testování důrazně doporučujeme používat centrum testování ve webové verzi TFS.

Vylepšení sledovatelnosti průzkumného testování u propojení pracovních položek, iterací a cest oblasti

Na základě zpětné vazby, kterou jsme obdrželi od týmů provádějících průzkumné testování, vylepšujeme propojení sledovatelnosti a současně umožňujeme evidovat chyby, úlohy a testovací případy z rozšíření Test & Feedback. Chyby a úlohy vytvořené při průzkumu požadavků se teď budou vytvářet pomocí stejné cesty oblasti a iterace, jako má požadavek, a nikoli pomocí výchozích hodnot týmu. Testovací případy vytvořené při zkoumání požadavků se teď propojí odkazem Testy <–> Testoval by místo odkazu Nadřazený <–> Podřízený , aby se testovací případy, které vytvoříte, automaticky přidaly do testovacích sad založených na požadavcích. Pracovní položky, které se vytvoří, aniž by se konkrétně zkoumaly jakékoli požadavky, se zařadí do výchozí iterace týmu místo do aktuální iterace, aby se po dokončení plánování sprintu nepřidávaly do aktuální iterace žádné nové pracovní položky.

Filtry pro pracovní položky testovacích případů v testovacích plánech a sadách testů v centru testování

Kromě filtrů polí testu , jako jsou Výsledek, Konfigurace a Tester, teď můžete filtrovat pole pracovních položek testovacího případu, jako jsou Název, Stav a Přiřazeno(Obrázek 98).

Grafy trendů testů pro prostředí vydaných verzí a testovací běhy

Přidáváme podporu prostředí vydaných verzí ve widgetu Test Result Trend(Obrázek 99) , abyste mohli sledovat stav testovacích prostředí na řídicích panelech VSTS. Stejným způsobem jako u výsledků testů v sestavení můžete nyní vytvářet grafy trendů zobrazující úspěšnost testů, celkový počet testů, počet úspěšných a neúspěšných testů a dobu trvání testů u prostředí vydaných verzí. Pomocí filtru s názvem Testovací běh si můžete z grafů vyfiltrovat také konkrétní testovací běh v rámci prostředí.

Podpora formátování markdownu pro komentáře k testovacím běhům a výsledkům testů

Přidáváme podporu formátování komentářů k testovacím běhům a výsledkům testů pomocí syntaxe markdownu. Pomocí této funkce můžete ve svých komentářích vytvořit formátovaný text nebo rychlé odkazy na adresy URL. Komentáře k výsledkům testůmůžete aktualizovat na stránce Souhrn výsledků pomocí možnosti Analýza aktualizace a komentáře k testovacímu běhu na stránce Shrnutí běhu pomocí možnosti Aktualizovat komentáře v centru Testování.

Přidání odkazu na existující chybu u neúspěšného testu

Při analýze výsledku testu na stránce souhrnu sestavení nebo vydané verze, případně v centru Testování, můžete nyní přidružit existující chybu k neúspěšnému testu. To je užitečné, když se test nezdaří ze známého důvodu, u kterého je už chyba zaevidována.

Odesílání příloh do testovacích běhů a výsledky testů

Teď můžete k testovacím běhům nebo výsledkům testů připojovat další informace v podobě souborů, jako jsou snímky obrazovky a soubory protokolů. Dosud byla tato možnost dostupná jenom prostřednictvím klienta Microsoft Test Manager (MTM), takže jste museli přepínat kontext mezi centrem Test ve VSTS/TFS a klientem MTM.

Dávkování testů

V úkolu vytvoření testu sady Visual Studio ve správě sestavení / vydané verze jsou k dispozici možnosti k řízení toho, jak mají být testy seskupené (dávkované), aby se prováděly efektivně. Testy můžou být seskupené dvěma způsoby:

1. Na základě počtu testů a agentů podílejících se na spuštění, čímž se testy prostě seskupí do několika dávek zadané velikosti.
2. Na základě minulé doby spuštění testů, což s ohledem na minulou dobu spuštění vytvoří dávky testů tak, aby každá dávka měla přibližně stejnou dobu spuštění (Obrázek 100) . Testy s krátkou dobou spuštění se dostanou do stejné dávky, zatímco testy s delší dobou spuštění se můžou dostat do samostatné dávky. Tuto možnost můžete zkombinovat s nastavením fáze více agentů, aby se celková doba testování zkrátila na minimum.

Spouštění webových testů pomocí úkolu VSTest

Pomocí úkolu vytvoření testu sady Visual Studio se teď webové testy, známé také jako testy výkonnosti webu, můžou spouštět v kanálu CI/CD. Webové testy můžete spustit zadáním testů ke spuštění ve vstupu sestavení úkolu. Všechny pracovní položky testovacího případu, které mají s webovým testem propojenou „přidruženou automatizaci“, můžete spustit také tak, že v úkolu vyberete testovací plán / sadu testů (Obrázek 101) .

Výsledky webového testu jsou k dispozici jako příloha výsledků testu (Obrázek 102) . Tu můžete stáhnout pro offline analýzu v sadě Visual Studio.

Tato schopnost závisí na změnách v testovací platformě sady Visual Studio a vyžaduje, aby na agentu sestavení / vydané verze byla nainstalovaná sada Visual Studio 2017 Update 4. Pomocí předchozích verzí sady Visual Studio webové testy spouštět nejde.

Podobně jde webové testy spouštět pomocí úlohy Run Functional Test (Spustit funkční test). Tato schopnost je závislá na změnách v testovacím agentu, které budou k dispozici ve verzi Visual Studio 2017 Update 5.

Widget pro grafy pro testovací plány a testovací sady

V minulosti jste mohli grafy pro testovací plány a sady vytvořit v centru Test a připnout je na řídicí panel. Teď jsme přidali widget, který umožňuje vytváření grafů pro testovacích plány a sady z katalogu widgetů na řídicím panelu. Můžete vytvářet grafy pro stav vytvoření testu nebo stav spuštění testu. Kromě toho vám přidávání grafů z widgetu umožní vytvářet větší grafy, když máte víc dat, která se v grafu mají zobrazit (Obrázek 103) .

Podpora snímků obrazovky a poznámek pro desktopové aplikace s prohlížečem Chrome pro ruční testy

Přidáváme podporu pro jeden z nejčastějších návrhů z ručního testování – pořizování snímků obrazovky desktopových aplikací z nástroje Web Test Runner (Spouštěč webových testů) v centru Test. Dosud bylo k zachycení snímků obrazovky desktopových aplikací nutné použít Test Runner v Microsoft Test Manageru. K používání této funkce musíte nainstalovat rozšíření Test & Feedback (Testování a zpětná vazba). Zavádíme podporu pro prohlížeč Chrome a brzo bude následovat Firefox.

Ukončení rozšíření TFS pro SharePoint

TFS 2018 a novější verze už nebudou podporovat rozšíření TFS pro SharePoint. Kromě toho jsme z Konzoly pro správu serveru Team Foundation odebrali obrazovky používané ke konfiguraci integrace mezi TFS Serverem a SharePoint serverem.

Vytvořili jsme řešení, které umožňuje integraci na serveru SharePointu vypnout. Další informace najdete v příspěvku o budoucnosti naší integrace TFS/SharePointu.

Ukončení týmových místností

Moderní vývojové týmy velmi závisí na spolupráci. Lidé chtějí (a potřebují) místo, kde budou monitorovat aktivitu (oznámení) a kde si budou moci o ní promluvit (chatovat). Před několika lety jsme si tento trend uvědomili a pro podporu těchto scénářů vytvořili týmové místnosti. Od té doby se na trhu objevuje stále více řešení pro spolupráci. Zejména se jedná o Slack. A v poslední době je to řešení Microsoft Teams.

Vzhledem k tomu, že je k dispozici tolik vhodných řešení, která se dobře integrují s TFS a službou Visual Studio Team Services, oznámili jsme v lednu záměr odebrat funkci týmové místnosti jak z TFS 2018, tak i služby Visual Studio Team Services.

---

Jak si stojíme?

Chceme znát váš názor. Na portálu Komunita vývojářů může nahlásit a sledovat problém. Rady můžete získat na webu Stack Overflow.

---

Začátek stránky