Team Foundation Server 2017

Last Update: 30. 10. 2017

Informace o nejnovějších aktualizacích najdete ve zprávě k vydání verze v angličtině.

Datum vydání: 16. listopadu 2016

V tomto článku najdete informace týkající se Team Foundation Serveru 2017. Tato vydaná verze zahrnuje nejnovější funkce a vylepšení. Chtěli bychom upozornit na to, že se pro Team Foundation Server 2017 změnily požadavky. Další podrobnosti najdete na stránce Požadavky a kompatibilita pro Team Foundation Server. Pokud zde není zpráva k vydání verze, kterou jste čekali, přešli jste ke zprávě k vydání pro nejaktuálnější verzi.

Klikněte na tlačítko a stáhněte si Team Foundation Server 2017.

Download the latest version of Team Foundation Server

Informace o dalších souvisejících souborech ke stažení najdete na stránce Ke stažení.

Co je nového?

Známé problémy


Co je nového

Vyhledávání kódu

Vyhledávání kódu poskytuje možnost rychlého, flexibilního a přesného hledání ve vašem kódu. S tím, jak se váš kód rozšiřuje a rozděluje do různých projektů a úložišť, se hledání kódu, který právě potřebujete, stává čím dál složitějším. Pokud chcete maximalizovat sdílení kódu a týmovou spolupráci, pomocí funkce Vyhledávání kódu můžete rychle a efektivně najít požadované informace napříč všemi svými projekty.

Vyhledávání kódu nabízí komplexní řešení pro všechny potřeby zkoumání kódu a řešení potíží od vyhledávání příkladů implementace rozhraní API přes procházení jeho definice až po hledání textů chyb (obrázek 1).

Vyhledávání kódu umožňuje:

  • Prohledávání jednoho nebo několika projektů
  • Sémantické hodnocení
  • Bohaté možnosti filtrování
  • Spolupráci nad kódem

Code Search

(Obrázek 1) Vyhledávání kódu

Podrobnosti viz téma Vyhledávání ve všech vašich kódech.

Správa balíčků

Balíčky umožňují sdílet kód v rámci vaší organizace: můžete vytvářet velký produkt, vyvíjet více produktů založených na společné sdílené architektuře nebo vytvářet a sdílet opakovaně použitelné komponenty a knihovny. Správa balíčků (obrázek 2) usnadňuje sdílení kódu na základě hostování balíčků, jejich sdílení s vybranými osobami a snadného zpřístupnění pro týmové sestavení a správu verzí.

Správa balíčků eliminuje nutnost hostit samostatný NuGet server nebo soubor, protože se balíčky NuGet hostují přímo na Team Foundation Serveru. Má ve své třídě nejlepší podporu pro NuGet 3.x i starší verze klientů NuGet 2.x. Funguje bezproblémově se stávající infrastrukturou, týmy a oprávněními TFS, takže není nutné řešit synchronizaci identit, správu skupin na více místech atd. Snadno se také integruje s týmovým sestavením, takže je možné vytvářet a používat balíčky v pracovních postupech nepřetržité integrace.

Další podrobnosti najdete v tématu Přehled správy balíčků.

Package Management

(Obrázek 2) Správa balíčků

Vylepšení agility

V Team Foundation Serveru 2017 přibyly nové možnosti a funkce pracovních položek a karet Kanban.

Formulář nové pracovní položky

Formulář nové pracovní položky (obrázek 3) má nový vzhled a chování. Přidává také některé skvělé nové funkce:

  • Bohaté možnosti diskusí nad pracovními položkami.
  • Podpora přetahování pro přílohy
  • Vylepšená práce s historií (Historie a auditování)
  • Vylepšená integrace psaní kódu a sestavování
  • Barevné zvýrazňování stavu
  • Responzivní návrh
Poznámka

Formulář nové pracovní položky je výchozí jenom pro nové kolekce. Pokud migrujete existující kolekci, budete muset povolit formulář nové pracovní položky z nastavení pro správu. Další informace najdete v tématu Správa distribuce nového webového formuláře.

New WIT Form

(Obrázek 3) Nový formulář WIT

Sledování pracovní položky

Nyní můžete nastavit oznámení pro sledování změn v určité pracovní položce jednoduše kliknutím na tlačítko „Sledovat“ (obrázek 4) ve formuláři. Pokud sledujete pracovní položku, budete upozorněni na veškeré její změny – včetně aktualizace polí, odkazů, příloh a komentářů.

Follow Work Item

(Obrázek 4) Sledování pracovní položky

Podrobnosti najdete v tématu Sledování pracovní položky.

Aktualizace kanbanových karet

Vaše karta Kanban je teď živá.

Už vás omrzelo stále mačkat F5, abyste zjistili, co je na kartě Kanban nového? Vyzkoušejte ikonu na snímku obrazovky dole (obrázek 5).

Kanban live updates

(Obrázek 5) Živé aktualizace karty Kanban

Pokud kdokoli ve vašem týmu vytvoří, změní nebo odstraní pracovní položku na kartě, projeví se tato změna na vaší kartě okamžitě. Také v případě, že správce aktualizuje kartu nebo provede změnu na úrovni týmu, například přidá sloupec nebo povolí chyby v backlogu, budete upozorněni na potřebu aktualizace panelu, aby se změny projevily. K tomu všemu stačí stisknout ikonu věže na kartě Kanban a začít spolupracovat v týmu.

Další informace najdete v tématu Kanban – základy.

Vylepšení kontrolních seznamů

Provedli jsme několik vylepšení funkce kontrolních seznamů.

Kontrolní seznamy se nyní zobrazí jako hypertextové odkazy (obrázek 6). Kliknutím na nadpis můžete otevřít formulář pracovní položky.

Checklist improvements

(Obrázek 6) Kontrolní seznam s hypertextovými odkazy

Kontrolní seznamy teď také podporují místní nabídky, které vám umožní otevřít, upravit nebo odstranit položky kontrolního seznamu (obrázek 7).

Checklist context menu

(Obrázek 7) Místní nabídka kontrolního seznamu

Podrobnosti najdete v tématu Přidání kontrolních seznamů úloh.

Přechod k podrobnostem na kartách Námět a Funkce

Nyní máte možnost snadno přejít k podrobnostem na kartách Námět a Funkce (obrázek 8). Formát kontrolního seznamu vám umožní snadno označit práci jako dokončenou a poskytuje užitečný pohled z ptačí perspektivy na porovnání dokončené a zbývající práce.

Epic Feature drilldown

(Obrázek 8) Přechod k podrobnostem námětů a funkcí

Další informace najdete v tématu Kanban – funkce a náměty.

Zapnutí a vypnutí poznámek na kartě

Nabízíme vám lepší kontrolu nad dalšími informacemi, které se zobrazují na vašich kartách. Nyní můžete vybrat poznámky, které chcete na kartě Kanban zobrazit (obrázek 9). Nebo jednoduše zrušte výběr poznámky a ta z karty Kanban zmizí. První dvě zobrazené poznámky jsou podřízené pracovní položky (v tomto příkladu úkoly) a poznámka Test.

Turn on/off board annotations

(Obrázek 9) Zapnutí a vypnutí poznámek na kartách

Další informace najdete v tématu Přizpůsobení karet.

Příkaz Vymazat formátování

Přidali jsme nový příkaz pro všechny ovládací prvky s formátovaným textem v pracovní položce, který umožňuje vymazat z vybraného textu veškeré formátování. Možná stejně jako já bojujete s tím, že do těchto polí zkopírujete formátovaný text a pak se formátování nemůžete zbavit. Teď stačí označit jakýkoli text, stisknout na panelu nástrojů tlačítko Vymazat formátování (nebo stisknout Ctrl+Mezerník) a text se zobrazí ve výchozím formátu.

Filtrování na kanbanové kartě

Přizpůsobte si karty Kanban nastavením filtrů podle uživatelů, iterací, typů pracovních položek a značek (obrázek 10). Tyto filtry se uloží tak, abyste se na svoji přizpůsobenou kartu mohli podívat z kteréhokoli zařízení.

Filtering in Kanban

(Obrázek 10) Filtrování na kartě Kanban

Členové týmu také si můžou filtrovat panely a zobrazit tak vývoj směrem k určité nadřazené pracovní položce. Uživatel může například zobrazit uživatelské scénáře, které jsou propojeny s určitou funkcí, nebo zobrazit souhrnnou práci pro dvě nebo více funkcí. Tato funkce podobně jako kontrolní seznamy je dalším krokem v našem úsilí zlepšovat přehlednost na různých úrovních backlogu.

Podrobnosti najdete v tématu Filtr karty Kanban.

Výchozí cesta iterace pro nové pracovní položky

Když vytvoříte novou pracovní položku z karty Dotazy nebo z widgetu Nová pracovní položka, cesta iterace nové pracovní položky bude vždy nastavena na aktuální iteraci. To není vždy to, co tým potřebuje, protože to znamená, že se chyby můžou na panelu úkolu zobrazit okamžitě. Díky tomuto vylepšení můžou týmy určit výchozí cestu iterace (buď určitou, nebo aktuální), která by se měla používat pro nové pracovní položky. Výchozí iteraci vyberte v nastavení správy pro váš tým.

Další informace najdete na stránce o přizpůsobení oblasti a cest iterace.

Ovládací prvek CheckBox

Ke svým pracovním položkám teď můžete přidat ovládací prvek se zaškrtávacím políčkem (obrázek 11). Tento nový typ pole (Boolean) má všechny vlastnosti normálních polí a je možné ho přidat do libovolného typu v procesu. Při zobrazení na kartách nebo ve výsledku dotazu je hodnota zobrazena jako True nebo False.

Checkbox control

(Obrázek 11) Ovládací prvek se zaškrtávacím políčkem

Podrobnosti najdete v tématu Přizpůsobení pole.

Hromadné úpravy značek

Teď můžete přidávat a odebírat značky z více pracovních položek pomocí dialogového okna hromadných úprav (obrázek 12).

Bulk edit dialog

(Obrázek 12) Dialogové okno hromadných úprav

Podrobnosti najdete v tématu Přidání značek k pracovním položkám.

Nové rozšiřovací body

Přidali jsme na stránku panelu a backlogu nový bod příspěvků, který umožňuje psát rozšíření, jako pivotovou kartu vedle karet panelu, backlogu a kapacity.

Představili jsme nový rozšiřovací bod backlogu. Rozšíření můžou cílit na podokno na pravé straně, kde se dnes nachází mapování a podrobné pracovní informace (obrázek 13).

Backlog extension points

(Obrázek 13) Rozšiřovací body backlogu

Další informace o rozšířeních najdete v tématu Rozšiřovací body.

Vylepšení e-mailu

Podstatně jsme zlepšili formátování a použitelnost výstrah, sledování a e-mailů @mention u pracovních položek posílaných serverem TFS (obrázek 14). E-maily nyní mají konzistentní záhlaví, jasnou výzvu k akci a vylepšené formátování, aby obsažená informace byla přehledná a srozumitelná. Kromě toho jsou všechny tyto e-maily navrženy tak, aby se dobře vykreslovaly i na mobilních zařízeních.

Email improvements

(Obrázek 14) Vylepšení e-mailu

Další informace najdete v tématu Výstrahy k pracovním položkám.

Šablony pracovních položek

Přímo do nativního webového prostředí jsme přidali možnost vytvářet detailní šablony pracovních položek (obrázek 15). Tato funkce byla dříve na webu velmi omezená a v této nové podobě dostupná pouze prostřednictvím výkonného nástroje sady Visual Studio. Týmy teď můžou vytvářet a spravovat sadu šablon, které slouží k rychlé úpravě běžných polí.

Work item templates

(Obrázek 15) Šablony pracovních položek

Podrobnosti najdete v tématu Šablony pracovních položek.

Integrace s Project Serverem už není podporovaná

Team Foundation Server 2017 a novější verze už nepodporují integraci s Project Serverem. Od verze RC2 se vám při upgradu databáze TFS, která má nakonfigurovanou integraci s Project Serverem, zobrazí následující upozornění:

Zjistili jsme, že u této databáze máte nakonfigurovanou integraci s Project Serverem. Team Foundation Server 2017 a novější verze už nepodporují integraci s Project Serverem.

Po upgradu už integrace s Project Serverem nebude fungovat.

Počítáme s tím, že naši partneři v budoucnu poskytnou řešení pro integraci.

Další informace o této změně najdete v tématu Synchronizace sady TFS se serverem Project Server.

Vylepšení řídicích panelů a widgetů

V Team Foundation Serveru 2017 bylo vylepšeno několik widgetů, třeba Dlaždice dotazu a Žádost o přijetí změn.

Přepracovaný katalog widgetů

Přepracovali jsme katalog widgetů, abychom zpřehlednili rostoucí nabídku widgetů a usnadnili jejich výběr (obrázek 16). Nový vzhled zahrnuje vylepšené vyhledávání a byl přepracován tak, aby odpovídal vzhledu vašich panelů pro konfiguraci widgetů.

Widget catalog

(Obrázek 16) Katalog widgetů

Další podrobnosti najdete v tématu Katalog widgetů.

Aktualizace widgetů

Widget Dlaždice dotazu teď podporuje až 10 podmíněných pravidel a jde pro něj vybrat barvy (obrázek 17). To je velmi užitečné, pokud chcete použít tyto dlaždice jako klíčové ukazatele výkonu k identifikaci stavu nebo k doporučení potřebných akcí.

Dashboard updates

(Obrázek 17) Aktualizace řídicích panelů

Widget Žádost o přijetí změn teď podporuje více velikostí, což umožňuje uživatelům řídit výšku widgetu. Pracujeme na tom, aby co nejvíce našich widgetů podporovalo změnu velikosti, nezapomeňte se sem občas vrátit.

Widget Nová pracovní položka teď umožňuje vybrat výchozí typ pracovní položky, namísto nutnosti vybírat nejčastěji vytvářený typ stále dokola.

Widgety grafů WIT nyní umožňují změnu velikosti. To umožňuje uživatelům vidět rozšířené zobrazení libovolného grafu WIT na řídicím panelu bez ohledu na jeho původní velikost.

Widget členů týmu byl aktualizován, aby usnadňoval přidání dalších členů týmu (obrázek 18).

Widget Update

(Obrázek 18) Aktualizace widgetů

Týmy teď mohou nakonfigurovat na řídicím panelu velikost widgetu výsledků dotazu a zobrazit tak více výsledků.

Přepracovali jsme widget Přehled sprintu, aby se týmům snadněji sledovalo, jak jsou na tom s postupem práce.

Widget Přiřazeno mně pomáhá uživatelům spravovat práci, která jim byla přiřazena, aniž by museli opustit řídicí panel (obrázek 19). Správci týmů, kteří takový widget poskytnou, můžou dodat tuto funkci na řídicí panely velmi snadno – ušetří šestnáct kliknutí a nemusí přepínat kontext ani nic zadávat. Uživatelé teď můžou přiřazenou práci zobrazit, řadit, filtrovat a spravovat přímo prostřednictvím widgetu.

Assigned to me

(Obrázek 19) Přiřazeno mně

Rozhraní REST API pro řídicí panely

Nyní můžete pomocí rozhraní REST API programově přidávat a odstraňovat prvky řídicího panelu a získávat z nich informace. Rozhraní API také umožňují přidávat, aktualizovat a odebírat jednotlivé widgety i jejich skupiny a získávat o nich informace. Dokumentace je k dispozici v rámci online dokumentace pro Visual Studio.

Přípustné řídicí panely

Uživatelé bez oprávnění správce teď můžou vytvářet a spravovat řídicí panely týmu. Správci týmu můžou tato oprávnění pro uživatele, kteří správci nejsou, omezit prostřednictvím správce řídicího panelu.

Další informace najdete v tématu Řídicí panely.

Vylepšení úložiště Git

Důležité změny byly provedeny i v úložišti Git pro Team Foundation Server 2017. Mezi ně patří změna vzhledu stránky Větve a nová možnost „squash merge“.

Přepracovaná stránka Větve

Stránku Větve jsme kompletně přepracovali. Novým prvkem je pivot „moje“ obsahující větve, které jste vytvořili, vložili nebo označili jako oblíbené (obrázek 20). U každé větve je uveden její stav sestavení a vložení spolu s dalšími příkazy, jako je Odstranit. Pokud je v názvu větve lomítko, např. features/jirka/bug-fix, zobrazuje se jako strom, takže můžete snadno procházet rozsáhlý strom větví. Pokud znáte název požadované větve, můžete ji rychle vyhledat.

Redesigned branches page

(Obrázek 20) Přepracovaná stránka Větve

Další podrobnosti týkající se větví najdete v části Správa větví.

Nové prostředí žádostí o přijetí změn

U žádostí o přijetí změn došlo v této verzi k několika významným aktualizacím, které přinesly skutečně výkonné funkce diff, nové prostředí pro přidávání komentářů a přepracované uživatelské rozhraní.

Další podrobnosti najdete v tématu Kontrola kódu s žádostmi o přijetí změn.

Přepracované uživatelské rozhraní

Při otevírání žádosti o přijetí změn poznáte na první pohled změnu vzhledu a chování (obrázek 21). Uspořádali jsme nově záhlaví tak, aby zobrazovalo souhrn všech kritických stavů a akcí, které tak budete mít při práci kdykoliv po ruce.

Pull request header

(Obrázek 21) Žádost o přijetí změn – záhlaví

Přehled

Přehled nyní zvýrazňuje popis žádosti o přijetí změn, díky čemuž je přidání zpětné vazby snadnější než kdy předtím (obrázek 22). V událostech a komentářích se zobrazují nejnovější položky nahoře, aby měli kontroloři nejnovější změny a komentáře přímo před očima. Zásady, pracovní položky a kontroloři se nyní zobrazují podrobně a došlo i ke změně uspořádání – díky tomu je vše jasné a stručné.

Pull request overview

(Obrázek 22) Žádost o přijetí změn – přehled

Soubory

Největší nová funkce v této verzi je možnost zobrazit dřívější aktualizace provedené u žádosti o přijetí změn (obrázek 23). V předchozích verzích Preview jsme přidali možnost plnohodnotně sledovat komentáře při aktualizacích žádosti o přijetí změn. Není však vždy jednoduché určit, co se stalo mezi aktualizacemi. Ve zobrazení Soubory nyní přesně uvidíte, co se změnilo pokaždé, když se k žádosti o přijetí změn přidal nový kód. To je velmi užitečné, pokud jste ke kódu přidali zpětnou vazbu a chcete se podívat, jak přesně se změnil, izolovaně od všech ostatních změn v revizi.

Pull request files

(Obrázek 23) Žádost o přijetí změn – soubory

Aktualizace

Nové zobrazení Aktualizace ukazuje, jak se žádost o přijetí změn mění v průběhu času (obrázek 24). Zatímco zobrazení Soubory ukazuje, jak se v průběhu času měnily soubory, zobrazení Aktualizace ukazuje potvrzení přidaná v každé aktualizaci. Pokud dojde k vynucení metodou push, bude zobrazení Aktualizace nadále zobrazovat dřívější aktualizace přesně tak, jak v minulosti proběhly.

Pull request updates

(Obrázek 24) Žádost o přijetí změn – aktualizace

Komentáře nyní podporují markdown a emoji

Ve všech diskusích plně využijte potenciál markdownu, včetně formátování, zvýrazňování syntaxe kódu, odkazů, obrázků a emoji (obrázek 25). Úprava komentářů je navíc mnohem jednodušší a umožňuje například upravit (a uložit) několik komentářů najednou.

Pull request comments

(Obrázek 25) Žádost o přijetí změn – komentáře

Přidání a odebrání revidujících k žádostem o přijetí změn

Nyní je mnohem snadnější přidávat revidující k žádostem o přijetí změn nebo je odebírat. K přidání revidujícího nebo skupiny k žádosti o přijetí změn stačí jednoduše zadat jméno do vyhledávacího pole v části Revidující. Pokud chcete revidujícího odebrat, umístěte ukazatel myši nad jeho dlaždici v části Revidující a klikněte na tlačítko X (obrázek 26).

Add reviewers in pull requests

(Obrázek 26) Přidání revidujících k žádostem o přijetí změn

Zlepšení sledovatelnosti sestavení a žádostí o přijetí změn

Sledovatelnost mezi sestaveními a žádostmi o přijetí změn se zlepšila, což usnadňuje přechod od PR k sestavení a zpět. V zobrazení Podrobnosti o sestavení pro sestavení spuštěná pomocí žádosti o přijetí změn teď bude zdroj obsahovat odkaz na žádost o přijetí změn, která dané sestavení vyvolala. V zobrazení Definice sestavení bude každé sestavení vyvolané žádostí o přijetí změn obsahovat odkaz na danou žádost ve sloupci Inicioval. A konečně Průzkumník sestavení poskytne seznam žádosti o přijetí změn ve sloupci zdroje.

Sledování komentářů u žádostí o přijetí změn

Žádosti o přijetí změn ve VSTS byly vylepšeny, aby zobrazovaly komentáře ponechané v souborech na správných řádcích, i když došlo v těchto souborech od vložení komentáře ke změně. Dříve byly komentáře vždy zobrazeny na řádku, kde byly přidány původně, i když se obsah souboru změnil. Například komentář na řádku 10 se vždy zobrazoval na řádku 10. S nejnovějším vylepšením komentáře následují kód a zobrazují se tam, kde je uživatel očekává – pokud byl komentář přidán na řádku 10 a následně byly na začátek souboru přidány dva nové řádky, bude se komentář zobrazovat na řádku 12.

Tady je příklad s komentářem na řádku 13 (obrázek 27):

Comment tracking

(Obrázek 27) Sledování komentáře

Komentář se zobrazuje na očekávaném místě i po úpravě kódu a posunutí řádku s původním komentářem z řádku 13 na řádek 14 (komentář je na řádku 14) (obrázek 28).

Comment tracking with change

(Obrázek 28) Sledování komentáře se změnou

Automatické dokončování žádostí o přijetí změn, které čekají na zásady

Týmy, které používají zásady pro větev (https://www.visualstudio.com/cs-cz/docs/git/branch-policies) k ochraně větví, budou chtít seznámit s akcí automatického dokončení. Autoři žádostí o přijetí změn jsou mnohdy připravení žádosti sloučit, ale musejí čekat na dokončení buildu, aby mohli kliknout na Dokončit. Jindy je zase build dokončený, ale jeden z kontrolorů ještě neudělil finální schválení. V těchto případech umožní akce automatického dokončení autorovi nastavit automatické dokončení žádosti v okamžiku, kdy budou všechny zásady schválené (obrázek 29).

Auto-complete

(Obrázek 29) Automatické dokončování

Stejně jako u ručního dokončení má autor možnost přizpůsobit zprávu o potvrzení sloučení a vybrat odpovídající možnosti sloučení (obrázek 30).

Autodialog

(Obrázek 30) Dialogové okno automatického dokončování

Po nastavení automatického dokončování zobrazí žádost o přijetí změn nápis s potvrzením, že bylo automatické dokončení nastaveno a čeká se na dokončení zásad (obrázek 31).

Auto-complete confirmation

(Obrázek 31) Potvrzení automatického dokončování

Po splnění všech zásad (například dokončení buildu nebo udělení finálního schválení) se žádost o přijetí změn sloučí podle určených možností a komentářů. Pokud dojde k selhání sestavení nebo kontrolor neudělí schválení, zůstane samozřejmě žádost o přijetí změn aktivní, dokud zásady nebudou splněny.

Žádosti o přijetí změn typu „squash merge“

Při dokončování žádosti o přijetí změn můžete použít možnost „squash merge“ (obrázek 32). Tato nová možnost vytvoří jediné potvrzení obsahující změny z větve, které se použijí pro cílovou větev. Nejdůležitější rozdíl mezi běžným sloučením a metodou „squash merge“ je, že sloučení „squash merge“ bude mít jen jedno nadřazené potvrzení. To znamená jednodušší graf historie potvrzení, protože se ve výsledném grafu skryjí všechna přechodová potvrzení změn provedených ve větvi.

Squash merge pull request

(Obrázek 32) Žádost o přijetí změn typu „squash merge“

Další informace najdete v tématu Žádosti o přijetí změn typu „squash merge“.

Sledovatelnost potvrzení

Stav sestavení (úspěch nebo neúspěch) je teď jasně viditelný v zobrazeních Průzkumník kódu a Podrobnosti o potvrzení (obrázek 33). Další podrobnosti jsou na dosah jednoho kliknutí, takže budete vždy vědět, zda se potvrzené změny promítly do sestavení nebo nikoli. Můžete také určit, která sestavení zveřejní stav v možnostech úložiště pro definici sestavení. A navíc vám nejnovější změny v zobrazení Podrobnosti o potvrzení poskytnou hlubší přehled o vašich změnách. Pokud ke sloučení vašich změn používáte žádosti o přijetí změn, uvidíte odkaz na žádost o přijetí změn, která provedla změny v hlavní větvi (nebo v případě potvrzení sloučení, PR, který žádost vytvořil). Pokud vaše změny dosáhly hlavní verzi, objeví se odkaz na větev potvrzující, že změny byly zahrnuty.

Commit Traceability

(Obrázek 33) Sledovatelnost potvrzení

Zobrazení souborů v úložišti Git LFS na webu

Pokud už pracujete s velkými soubory v úložišti Git (zvuk, video, datové sady atd.), pak víte, že úložiště Git LFS (Large File Storage) nahradí tyto soubory ukazateli na obsah uložený na vzdáleném serveru. To umožňuje zobrazit úplný obsah těchto velkých souborů jednoduše kliknutím na soubor ve vašem úložišti.

Další informace najdete v tématu Správa velkých souborů pomocí Gitu.

Reference na části kódu můžete snadno sdílet pomocí odkazů na kód (obrázek 34). Stačí vybrat text v rámci souboru a kliknout na ikonu propojení. Tím zkopírujete odkaz na vybraný úsek kódu. Když někdo tento odkaz zobrazí, uvidí vámi vybraný úsek zvýrazněný zlatým pozadím. Platí to i pro výběr neúplných řádků.

Send links to code

(Obrázek 34) Odesílání odkazů na kód

Status API

Úspěch nebo neúspěch sestavení je teď jasně viditelný v zobrazeních Průzkumník kódu a Podrobnosti o potvrzení (obrázek 35). Další podrobnosti jsou na dosah jednoho kliknutí, takže budete vždy vědět, jestli se potvrzené změny promítly do sestavení nebo ne. V možnostech úložiště pro definici sestavení můžete také určit, která sestavení zveřejňují stav sestavení.

Status API

(Obrázek 35) Status API

Ikony typu souboru

Uvidíte nové ikony souborů, které odpovídají příponám souborů v průzkumníkovi, žádostech o přijetí změn, potvrzení podrobností, sadě odložených změn, sadě změn a ve všech ostatních zobrazeních, která obsahují seznam souborů (obrázek 36).

File type example

(Obrázek 36) Příklady typů souborů

Přidání souboru ReadMe při vytvoření úložiště

Vytvoření nového úložiště Git bylo vylepšeno o možnost, že uživatel může přidávat soubor ReadMe (obrázek 37). Přidání souboru ReadMe do úložiště nejen pomáhá ostatním uživatelům pochopit smysl dotyčného kódu, ale umožní také okamžité klonování úložiště.

Add a ReadMe file

(Obrázek 37) Přidání souboru ReadMe

Vylepšení sestavení

V této verzi jsme mimo jiné zvětšili velikost protokolů, přidali šablony sestavení Java a vylepšili podporu pro Xamarin.

Přepracovaná karta Fronta sestavení

Implementovali jsme nový návrh stránky fronty sestavení, která teď zobrazuje delší seznam čekajících a běžících sestavení v mnohem intuitivnější podobě (obrázek 38).

Build queue tab

(Obrázek 38) Karta fronty sestavení

Další informace najdete v tématu Správa systému sestavení.

Rozšíření výsledku sestavení teď můžou specifikovat pořadí a sloupec

Rozšíření oddílu výsledku sestavení teď můžou určit sloupec a pořadí, ve kterém jsou zobrazeny (obrázek 39). Výsledné zobrazení má dva sloupce a ve výchozím stavu budou všechna rozšíření v prvním z nich. Poznámka: Všechna rozšíření jiných výrobců se objeví po oddílech výsledků sestavení, které zahrnujeme.

Build order and column

(Obrázek 39) Pořadí a sloupec sestavení

Od sestavení k číslu řádku

Nyní můžete přejít z chyby sestavení přímo na řádek kódu, který ji způsobil. Když se podíváte na nejnovější chybu v primárním sestavení, které interně používáme jako zásadu pro žádosti o přijetí změn, uvidíte toto (obrázek 40):

Build to line number

(Obrázek 40) Od sestavení k číslu řádku

Zobrazení protokolu sestavení podporuje mnohem větší protokoly

Předchozí prohlížeč protokolu podporoval jen protokoly s méně než 10 000 řádků. Nový prohlížeč je založen na editoru Monaco používaném v produktu VS Code a bude podporovat protokoly až do 150 000 řádků.

Šablony sestavení Java

Vývojářům v jazyce Java jsme usnadnili zahájení práce se sestavením díky šablonám sestavení pro Ant, Maven a Gradle (obrázek 41).

Java build templates

(Obrázek 41) Šablony sestavení Java

Další informace o šablonách najdete v tématu Kroky sestavení.

Úkoly sestavení Xamarin

Provedli jsme několik významných vylepšení podpory pro Xamarin:

Krok s licencí Xamarin už není nutný a byl odebrán z šablon sestavení. Spolu s tím jsme tento úkol označili jako zastaralý. Všechny definice buildů, které využívají tento úkol, je třeba aktualizovat, aby po konečném odebrání úkolu nedošlo k narušení.

A konečně byly vylepšeny šablony definice sestavení Xamarin pro použití těchto nových úkolů. Sestavení vaší aplikace Xamarin.

Integrace Dockeru pro správu sestavení a verzí

Využijte výhod možností sestavování k vytvoření imagí Dockeru a k jejich nahrávání do úložiště Docker Hub v rámci vašeho procesu plynulé integrace (obrázek 42). Pak můžete tyto image nasadit na celou řadu hostitelů Docker v rámci správy verzí. Rozšíření Marketplace přidává všechny typy koncových bodů služby a úkoly, které jsou nezbytné pro práci s Dockerem.

Docker images

(Obrázek 42) Image Dockeru

Výsledky SonarQube v zobrazení žádostí o přijetí změn

Pokud sestavení vytvořené v důsledku žádosti o přijetí změn obsahuje úkol MSBuild SonarQube, uvidíte teď nové problémy zjištěné při analýze kódu jako komentáře v diskuzi k žádosti o přijetí změn (obrázek 43). Tato funkce funguje pro každý jazyk, pro který je na serveru SonarQube instalovaný modul plug-in. Další informace viz článek na blogu SonarQube Code Analysis issues integration into Pull Requests.

SonarQube pull requests

(Obrázek 43) SonarQube v žádostech o schválení změn

Konfigurace hlášení o rozhraní Status API pro definici sestavení

Teď můžete zvolit, které definice sestavení budou oznamovat svůj stav zpět do Status API úložiště Git. To je zvlášť užitečné, pokud máte mnoho definic, které sestavují určité úložiště nebo větev, ale přitom jen jedna reprezentuje skutečný stav sestavení.

Další informace najdete v tématu Referenční informace k REST API sestavení.

Podpora sestavení vNext v týmových místnostech

V týmové místnosti bylo vždy možné přidat oznámení o sestaveních XAML. V tomto sprintu uživatelé mohou také přijímat oznámení o dokončení sestavení vNext.

Povolení filtrů cest pro aktivační události Git CI

Aktivační události CI pro hostovaná úložiště Git mohou zahrnovat nebo vylučovat určité cesty. To umožňuje nakonfigurovat definici sestavení, aby byla spouštěna pouze tehdy, pokud se změnily soubory v určitých cestách (obrázek 44).

Git CI Triggers

(Obrázek 44) Aktivační události Git CI

Vylepšení nástroje Release Management

Od uvedení webového nástroje Release Management na serveru Team Foundation Server 2015 byla v této verzi provedeno několik vylepšení.

Klonování, export a import definice verzí

Centrum verzí jsme rozšířili o možnost klonovat, exportovat a importovat definice verzí bez nutnosti instalovat rozšíření (obrázek 45).

Clone and export commands on release summary page

(Obrázek 45) Příkazy klonování a exportování na stránce souhrnu vydaných verzí

Další podrobnosti najdete v dokumentaci Klonování, export a import definice vydané verze.

Výsledky testů zobrazené v souhrnu verzí

Na stránce souhrnu verzí jsme povolili příspěvkový bod externí služby pro účely zobrazení informací specifických pro prostředí.

V Team Services slouží tato funkce k zobrazení shrnutí výsledků testu při spouštění testů jako součásti prostředí verzí (obrázek 46).

Test results displayed in the release summary

(Obrázek 46) Výsledky testů zobrazené v souhrnu vydaných verzí

Další podrobnosti najdete v dokumentaci Vysvětlení souhrnného pohledu na verzi.

Předání tokenů OAuth do skriptů

Pokud potřebujete spustit vlastní skript prostředí PowerShell, který vyvolá rozhraní REST API ve službě Team Services, například k vytvoření pracovní položky nebo dotazu na informace v sestavení, je potřeba ve skriptu předat token OAuth.

Nová možnost při konfiguraci prostředí umožňuje spouštět skripty jako úlohy v prostředí kvůli možnosti přístupu k aktuálnímu tokenu OAuth (obrázek 47).

Pass OAuth tokens to scripts

(Obrázek 47) Předání tokenů OAuth do skriptů

Další podrobnosti najdete v dokumentaci Obecné možnosti prostředí.

Jednoduchý příklad, jak získat definici sestavení (obrázek 48):

Example script using passed oAuth token

(Obrázek 48) Příklad skriptu s použitím předaného tokenu oAuth

Aktivace při částečně úspěšném nasazení

Úkoly sestavení a vydání mají u každého úkolu možnost Pokračovat při chybě dostupnou jako parametr Možnosti řízení.

Pokud selže úkol, který má nastavenou tuto možnost, vede to v definici sestavení k výsledku Sestavení bylo částečně dokončeno.

Stejné chování je nyní k dispozici v definici vydání. Pokud se úkol nezdaří, celkový výsledek vydání bude „Vydání bylo částečně dokončeno“ (obrázek 49).

Release summary shows partially successful releases in orange color

(Obrázek 49) Souhrn vydané verze zobrazuje částečně úspěšné vydané verze oranžovou barvou

Ve výchozím nastavení částečně úspěšné vydání nezpůsobí automaticky aktivaci vydání do následného prostředí, i když je toto chování zadáno v možnostech nasazení prostředí.

V každé verzi prostředí však lze nastavit novou možnost, která informuje Release Management, aby vyvolal vydání do následných prostředí, pokud je předchozí vydání částečně úspěšné (obrázek 50).

Setting the option to trigger from a partially successful release

(Obrázek 50) Nastavení možnosti k aktivaci po částečně úspěšné vydané verzi

Další podrobnosti najdete v dokumentaci Aktivační události nasazení prostředí.

Přímé využití artefaktů v Githubu

Artefakty, které jsou uložené v systému správy verzí, někdy můžete chtít použít přímo, aniž by prošly procesem sestavení, jak popisuje toto téma.

To samé můžete nyní provést, pokud je váš kód uložen v úložišti GitHub (obrázek 51).

Linking code in a GutHub repository to a release definition

(Obrázek 51) Propojení kódu v úložišti GitHub s definicí vydané verze

Další podrobnosti najdete v dokumentaci Zdroje pro TFVC, Git a Github.

Nasazení webové aplikace službou ARM

K dispozici je nová verze úlohy nasazení webové aplikace Azure, která se nazývá Nasazení webové aplikace AzureRM (obrázek 52).

Používá MSDeploy a koncový bod připojení služby Azure Resource Manager. Vedle nasazení webových aplikací využívajících ASP.NET 4, Node a Python slouží tato úloha k nasazení aplikací Azure Web Jobs a API Azure.

Tato úloha podporuje také běžné možnosti publikování, jako je schopnost uchovat data aplikací, převést aplikaci do offline režimu a odebrat další soubory v cílovém umístění.

V budoucích verzích se můžou objevit další funkce, jako například transformace konfigurace (obrázek 52.

Web app deployment using ARM

(Obrázek 52) Nasazení webové aplikace službou ARM

Skupiny úloh

Skupina úloh umožňuje zapouzdřit posloupnost úloh už definovaných v sestavení nebo definici verze do jediné opakovaně použitelné úlohy, kterou je možné přidat do sestavení nebo definice verze stejně jako jakoukoliv jinou úlohu (obrázek 53).

Můžete extrahovat parametry ze zapouzdřených úloh jako proměnné konfigurace a oddělit zbývající informace úlohy.

Nová skupina úloh se automaticky přidá do katalogu úloh, kde je připravená pro přidání k dalším definicím verzí a sestavení.

Linking code in a GutHub repository to a release definition

(Obrázek 53) Propojení kódu v úložišti GitHub s definicí vydané verze

Další podrobnosti najdete v dokumentaci Skupiny úloh.

Obnovitelné odstranění verzí

Když odstraníte verzi nebo když se verze odstraní automaticky podle zásad uchovávání informací, odebere se verze ze seznamu přehledu a podrobností.

Před tím, než se trvale odstraní, ale zůstane po určitou dobu uchovaná s definicí verze (obvykle je to 14 dní).

Během této doby bude uvedená v seznamech přehledu a podrobností na kartě Odstraněno.

Kteroukoliv z těchto verzí můžete obnovit tak, že otevřete místní nabídku a zvolíte Zrušit odstranění (obrázek 54).

Undelete releases

(obrázek 54) Zrušení odstranění verzí

Další podrobnosti najdete v dokumentaci Obnovení odstraněných verzí.

Uchování verzí a sestavení pro jednotlivá prostředí

Zásady uchovávání informací verzí pro určitou definici verze určují, jak dlouho se bude verze a s ní spojené sestavení uchovávat.

Ve výchozím nastavení se verze uchovává 60 dní – verze, které se během této doby nenasadí nebo neupraví, se automaticky odstraní.

Můžete ale chtít uchovat více verzí nasazených do konkrétních prostředí, jako například do produkčního prostředí, nebo je můžete chtít uchovat po dobu delší než ty, které byly nasazeny pouze v jiných prostředích, jako je například testování, příprava nebo kontrola kvality.

Můžete také chtít po stejnou dobu jako verzi uchovat sestavení propojené s verzí, aby bylo zajištěno, že budou k dispozici artefakty, pokud bude nutné tuto verzi znovu nasadit (obrázek 55).

Retain releases

(obrázek 55) Uchování verzí

Další podrobnosti najdete v dokumentaci Uchování verzí a sestavení.

Vylepšení propojených artefaktů

Práci s artefakty a zdroji artefaktů usnadňují dvě nové funkce:

  • S definicí verze můžete propojit více zdrojů artefaktů (obrázek 56). Každý artefakt se stáhne do složky na agentovi nazvaném alias zdroje. Alias zdroje propojeného artefaktu teď můžete upravit. Když například změníte název definice sestavení, můžete upravit alias zdroje tak, aby odrážel název definice sestavení.

Linked artifact improvements

(obrázek 56) Vylepšení propojených artefaktů

For more details, see [Artifact source alias](https://www.visualstudio.com/en-us/docs/release/author-release-definition/understanding-artifacts#source-alias) documentation.
  • Pro použití v parametrech úloh je k dispozici řada proměnných formátu Build.* (například Build.BuildId a Build.BuildNumber). Když má verze přidružených více zdrojů, naplní se teď tyto proměnné hodnotami ze zdroje artefaktů, který zadáte jako primární zdroj. Další podrobnosti najdete v dokumentaci Proměnné artefaktů.

Nasazení – úloha ručního zásahu

Nyní je možné během nasazování do prostředí pozastavit provádění.

Díky zahrnutí úlohy ručního zásahu do prostředí teď máte možnost dočasně pozastavit nasazování, provést ruční kroky a pak znovu pokračovat v provádění automatizovaných kroků.

Můžete také odmítnout nasazení a po ručním zásahu zabránit spuštění dalších kroků (obrázek 57).

Manual intervention task

(obrázek 57) Úloha ručního zásahu

Další podrobnosti najdete v dokumentaci Ruční zásah.

Skripty úloh při nasazení databáze SQL

Úloha Nasazení databáze Azure SQL (obrázek 58) byla vylepšena, aby bylo možné spouštět skripty SQL v databázi Azure SQL. Skripty můžou být ve formě souboru nebo vložené v úloze.

SQL database deployment task scripts

(obrázek 58) Skripty úloh při nasazení databáze SQL

Souhrn definice vydání – widget řídicího panelu

Připněte si na řídicí panel definici verze – snadný způsob, jak zviditelnit celému týmu souhrn vydání pro tuto definici.

Další podrobnosti najdete v dokumentaci Přidání informací o verzi na řídicí panel.

Nasazení vydaných verzí do prostředí v zadaném čase

Chcete provést všechna nasazení do produkčního prostředí o půlnoci? V prostředí můžete nakonfigurovat podmínku, která vybere úspěšné nasazení (nebo pouze to nejnovější) z jiného prostředí a v určený čas ho nasadí (obrázek 59).

Schedule release to an environment

(obrázek 59) Plán vydání pro prostředí

Nasazení na základě podmínek ve více prostředích

Až do předchozí verze bylo možné provádět paralelní nasazení (rozvětvit nasazení), ale nebylo možné spustit nasazení do prostředí na základě stavu více prostředí (spojit nasazení). Teď to možné je.

Další podrobnosti najdete v dokumentaci Paralelní rozvětvená a spojená nasazení.

REST API pro Release Management

Rozhraní REST API pro službu Release Management můžete použít k vytvoření definic vydání a vydání a spravovat tak řadu aspektů nasazení vydání.

Další informace najdete v tématu Referenční dokumentace rozhraní API. V blogovém příspěvku Použití REST API ve správě verzí najdete některé základní příklady použití rozhraní API.

Integrace zavěšení služby

Odesílá oznámení o vydání, pokud jsou vytvořena nová vydání, jsou zahájena nebo dokončena nasazení nebo existují čekající nebo dokončená schválení. Chcete-li přijímat taková oznámení, můžete provést integraci s nástroji třetích stran, například Slack.

Nasazení do národních cloudů Azure

Použijte nové nastavení Prostředí v koncovém bodu služby Azure Classic k zacílení na konkrétní cloud Azure, včetně předem definovaných národních cloudů, například cloud Azure China, Azure US Government a Azure German (obrázek 60).

Deployment to national Azure clouds

(Obrázek 60) Nasazení do národních cloudů Azure

Další podrobnosti najdete v dokumentaci Koncový bod služby Azure Classic.

Vylepšení testování

Team Foundation Server 2017 přináší klíčová vylepšení testování.

Aktualizované schéma úložiště pro výsledky testování

V této verzi jsme provedli migraci artefaktů výsledků testování do nového kompaktního a efektivního schématu úložiště. Vzhledem k tomu, že výsledky testů jsou jedním z hlavních spotřebitelů úložného prostoru v databázích TFS, očekáváme, že tato změna povede ke zmenšení prostorových nároků databází TFS. Pro zákazníky, kteří upgradují z předchozích verzí sady TFS budou výsledky testu migrovány na nové schéma během upgradu serveru TFS. Tento upgrade může trvat poměrně dlouho, v závislosti na tom, kolik dat s výsledky testů v databázích máte. Před upgradem doporučujeme nakonfigurovat zásady uchovávání testů a vyčkat, než nové zásady začnou fungovat a zmenší prostor v úložišti, který výsledky testů zabírají. Upgrade TFS pak bude rychlejší. Po instalaci serveru TFS, ale před upgradem instance TFS, můžete použít nástroj TFSConfig.exe k vyčištění výsledků testů. Další podrobnosti najdete v nápovědě k nástroji TFSConfig.exe. Pokud nemáte možnost konfigurace uchovávání testů nebo nemůžete před upgradem provést vyčištění výsledků testů, ujistěte se, máte pro upgrade naplánované dostatečně velké časové okno. Další příklady týkající se konfigurace zásad uchovávání testu najdete v tématu Uchovávání výsledků testů v produktu Team Foundation Server 2015.

Vylepšení centra testování

Správa konfigurace testů v centru testování

Do centra testování jsme přidali novou kartu Konfigurace, která nabízí nové uživatelské rozhraní pro správu konfigurací testů (obrázek 61). Teď můžete vytvářet a spravovat konfigurace testů a proměnné pro konfigurace testů přímo v rámci centra testování.

Configurations hub

(obrázek 61) Centrum konfigurací

Další informace najdete v tématu Vytváření konfigurací a konfiguračních proměnných.

Přiřazení konfigurací k testovacím plánům, sadám a případům

Přiřazení konfigurací je teď jednodušší – můžete přiřadit konfigurace testů k testovacímu plánu, testovací sadě nebo testovacím případům, a to přímo v centru testování(obrázek 62). Klikněte pravým tlačítkem na položku, vyberte Přiřadit konfigurace... a je hotovo. V centru testování můžete také filtrovat podle konfigurací (obrázek 63).

Assign Configurations

(obrázek 62) Přiřazení konfigurací

Configurations Filter

(obrázek 63) Filtr konfigurací

Další informace najdete v tématu Přiřazení konfigurací testovacím plánům a sadám.

Zobrazení sloupců testovacího plánu a testovací sady v podokně Výsledky testu

Do podokna Výsledky testu jsme přidali nové sloupce, které obsahují testovací plán a testovací sadu, pod kterými byl test proveden. Tyto sloupce poskytují velmi potřebný kontext při přechodu k podrobnostem výsledků testů (obrázek 64).

Test Results Pane

(obrázek 64) Podokno Výsledky testu

Seřazení testů v centru testování a na kartách

Nyní můžete uspořádat ruční testy v rámci centra testování (obrázek 65) bez ohledu na typ sady, ve které jsou zahrnuty: statické, založené na požadavcích nebo na dotazech. Testy můžete přeuspořádat pomocí místní nabídky nebo jednoduše přetažením. Po uspořádání můžete testy seřadit podle pole Pořadí a pak je v daném pořadí spustit ve Web runneru. Testy můžete také uspořádat přímo na kartě Kanban uživatelského scénáře (obrázek 66). Tím je splněna jedna z uživateli dlouho požadovaných položek (s 495 hlasy) v oblasti ručního testování.

Order tests

(obrázek 65) Seřazení testů

Order tests on card

(obrázek 66) Seřazení testů na kartě

Seřazení testovacích sad v centru testování

Testovací týmy mohou nyní seřadit testovací sady podle svých potřeb – než byla k dispozici tato možnost, byly sady řazeny pouze abecedně. Teď můžete pořadí sad upravit v centru testování buď přetažením mezi ostatní sady, nebo přesunutím na jinou sadu v hierarchii (obrázek 67). To řeší následující ikona hlasu uživatele pod ručním testováním/správou testovacích případů.

Order Test suites

(Obrázek 67) Seřazení testovacích sad

Hledání uživatelů v rámci přiřazení testerů

Jako součást zavádění nových prvků pro výběr identity mezi různými uzly v centru testování jsme také umožnili vyhledávat uživatele v rámci přiřazení testerů k jednomu nebo více testům (obrázek 68). To je velmi užitečné v situacích, kde je velký počet členů týmu, ale v místní nabídce se zobrazuje pouze omezená sada položek *(obrázek 69).

Search users

(Obrázek 68) Hledání uživatelů

Assign Users

(obrázek 69) Přiřazení uživatelů

Výběr sestavení pro testování

Nyní můžete vybrat sestavení, které chcete testovat, a v centru testování spustit Web Runner pomocí příkazu „Spustit s možnostmi“ (obrázek 70). Jakákoli chyba zaznamenaná za běhu bude automaticky přidružena k vybranému sestavení. Dále bude publikován výsledek testu k tomuto konkrétnímu sestavení.

Pick a build

(Obrázek 70) Výběr sestavení

Spuštění klienta Microsoft Test Runner z centra testování s kolekcemi dat

Nyní si můžete zvolit kolekce dat a sestavení, které chcete přidružit ke spuštění testu (obrázek 71), a spustit Microsoft Test Runner 2017 (klient) výkonným způsobem z centra testování, aniž by bylo nutné je nakonfigurovat pomocí klienta Microsoft Test Manager. Spustí se Microsoft Test Runner, aniž by bylo otevřeno prostředí Microsoft Test Manager, a po dokončení provádění testů dojde k jeho vypnutí.

Run with options

(obrázek 71) Spustit s možnostmi

Další informace najdete v tématu Spuštění testů desktopových aplikací.

Výběr kolekcí dat a spuštění klienta Exploratory Runner z centra testování

Nyní si můžete zvolit kolekce dat a spustit Exploratory Runner 2017 (klient) výkonným způsobem z centra testování, aniž by bylo nutné je konfigurovat pomocí klienta Microsoft Test Manager. Z místní nabídky (obrázek 72) sady založené na požadavcích vyberte Spustit s možnostmi a vyberte Exploratory runner spolu s kolekcemi dat, které potřebujete. Exploratory runner se spustí podobně jako Microsoft Test Runner popsaný výše.

Run with Options - XT

(obrázek 72) Spustit s možnostmi – rozšíření

Konfigurace výsledků testu pro testy z různých testovacích sad

Přidali jsme nyní možnost konfigurovat chování výsledků testu pro testy, které jsou sdíleny napříč různými testovacími sadami v rámci stejného testovacího plánu (obrázek 73). Pokud je tato možnost vybraná a nastavíte výsledek testu (označíte ho jako správný, chybný nebo zablokovaný prostřednictvím centra testování, Web runneru, Microsoft Test Runneru nebo karet na kartě Kanban), rozšíří se tento výsledek i na všechny ostatní testy napříč různými testovacími sadami v rámci stejného testovacího plánu se stejnou konfigurací. Uživatelé můžou nastavit možnost konfigurace výsledků testů pro konkrétní testovací plán buď z místní nabídky testovacího plánu v centru testování, nebo ze stránky testů karty Kanban pomocí dialogu konfigurace běžných nastavení. Tato možnost je ve výchozím nastavení vypnutá a je třeba ji explicitně povolit.

Configure test outcomes

(obrázek 73) Konfigurace výsledků testu

Kontrola chyb z pracovní položky

Chybu teď můžete ověřit na základě opětovného spuštění testů, které zjistily chyby (obrázek 74). Pokud budete chtít spustit příslušný testovací případ ve Web runneru, můžete možnost ověření vyvolat z místní nabídky formuláře pracovní položky chyby. Proveďte ověření pomocí Web runneru a aktualizujte pracovní položku chyby přímo ve Web runneru.

Verify bugs

(obrázek 74) Ověření chyb

Rozhraní REST API pro klonování testovacích plánů a sad

Připravili jsme rozhraní REST API pro klonování testovacích plánů a sad. Najdete je v části Správa testování na našem webu integrace týmových služeb.

Průběh testování z kanbanové karty

Nyní můžete přidat, zobrazit a kontrolovat testovací případy přímo z vašich scénářů na kartě Kanban. Pomocí nové možnosti nabídky Přidat test můžete vytvořit propojený testovací případ a pak přímo z karty průběžně monitorovat jeho stav (obrázek 75).

Inline tests

(obrázek 75) Vložené testy

S touto novou možností můžete přímo z vaší karty provádět tyto akce:

  • Přidávat testy
  • Otvírat testy
  • Přiřazovat testy jiné nadřazené položce jednoduše přetažením z jednoho uživatelského scénáře do jiného
  • Kopírovat určitý test do jiného uživatelského scénáře přes schránku nebo přetažením (pro scénáře, kde stejný testovací případ testuje více než jeden uživatelský scénář).
  • Aktualizovat stav testu rychlým označením Splněno/Selhal atd.
  • Spustit test jeho spuštěním v nástroji Web Test Runner, ze kterého můžete nastavit splnění nebo selhání jednotlivých kroků, zapisovat chyby atd.
  • Zobrazit souhrn zahrnutí stavu indikující, kolik testů bylo splněno a kolik jich v daném scénáři zbývá

Pokud potřebujete pokročilé možnosti správy testů (jako přiřazení testerů, přiřazení konfigurací, centralizované parametry, export výsledků testů atd.) můžete přejít do centra testování a začít používat výchozí testovací plány / sady založené na požadavcích, vytvořených pro vás automaticky. Další informace najdete v tématu Přidání, spuštění a aktualizace vložených testů.

Přechod k testovacímu plánu nebo testovací sadě z karty

Teď se můžete snadno dostat k podkladovému testovacímu plánu nebo testovací sadě, pod kterou jsou testy vytvořeny, přímo z karty na kartě Kanban. Kliknutím na tento odkaz (obrázek 76) můžete přejít k centru testování, otevřít správný testovací plán a pak vybrat konkrétní sadu, která řídí tyto vložené testy.

Traverse to plan/suite

(obrázek 76) Přechod k plánu/sadě

Stránka testů v konfiguraci společného nastavení na kartě Kanban

Pomocí nové stránky testů v dialogu konfigurace společného nastavení na panelu Kanban můžete řídit testovací plán, ve kterém jsou vytvořeny vložené testy (obrázek 77). Dříve by všechny testy vytvořené na kartě byly automaticky přidány do nově vytvořeného testovacího plánu, pokud by neexistovaly žádné plány s odpovídající oblastí a cestou na kartě. Toto chování lze nyní přepsat tak, že nakonfigurujete libovolný existující testovací plán – všechny testy budou poté přidány do vybraného testovacího plánu. Tato funkce je povolena, pouze pokud je zapnutá funkce poznámek k testům.

Common settings

(obrázek 77) Obecná nastavení

Vylepšení Web runneru

Přidávání příloh testovacích kroků během manuálního testování

Vylepšili jsme Web Test Runner a nově vám tak umožnili přidat přílohy testovacích kroků během ručního testování (obrázek 78). Tyto přílohy výsledků kroků se automaticky zobrazí v každé chybě, kterou v rámci relace vytvoříte, a následně také v podokně výsledků testu.

Test Step attachments

(obrázek 78) Přílohy testovacích kroků

Podpora pro snímky obrazovky, zaznamenávání obrazovky, obrazové protokoly akcí a informace o systému ve Web Runneru (za použití prohlížeče Chrome)

Když použijete Web Runner v prohlížeči Chrome, můžete nyní pořizovat snímky obrazovky a přímo je komentovat (obrázek 79). Na vyžádání můžete také zachytit záznam obrazovky nejen webových, ale i desktopových aplikací. Tyto snímky a záznamy obrazovky se automaticky přidají do aktuálního testovacího kroku. Kromě snímků obrazovky a záznamů obrazovky můžete také na vyžádání zaznamenat obrazový protokol akcí z webových aplikací. Je potřeba zadat okno prohlížeče, na kterém chcete zaznamenat akce – všechny akce tohoto okna (jakékoli existující nebo nově otevřené karty v tomto okně) nebo jakákoli nově otevřená podřízená okna prohlížeče se automaticky zaznamenají a porovnají s kroky testovanými ve Web runneru. Tyto snímky, záznamy obrazovek a obrazové protokoly akcí se potom přidají ke všem chybám, které ukládáte za běhu, a připojí se k výsledku aktuálního testu. Podobně se automaticky zaznamenávají informace o systému a zahrnují se do veškerých chyb, které z Web runneru vytvoříte. Všechna popisovaná vylepšení využívají funkce rozšíření Test & Feedback prohlížeče Chrome.

Web runner using Chrome browser

(obrázek 79) Web Runner s použitím prohlížeče Chrome

Další informace najdete v tématu Shromažďování diagnostických dat během testů.

Chyby zaznamenávané jako podřízené položky – Web Runner a rozšíření Test & Feedback

Při spouštění testů ve Webové runneru, spuštěného buď z karty na panelu nebo ze sady založené na požadavku v centru testování jsou všechny nové chyby automaticky vytvořené jako podřízené tomuto uživatelskému scénáři. Podobně když zkoumáte uživatelský scénář z rozšíření Exploratory testing, veškeré nově vytvořené chyby se také vytvoří jako podřízené tomuto scénáři. Toto nové chování umožňuje jednodušší sledovatelnost v rámci scénářů a chyb. To platí jenom v případě, že je u nastavení Práce s chybami na stránce společného nastavení konfigurace nastavená možnost Chyby se nezobrazují v backlozích ani na panelech nebo Chyby se zobrazují v backlogu a na panelech s požadavky. U všech ostatních nastavení pro možnost Práce s chybami a u některých dalších scénářů, jako je například při doplňování existující chyby, která už má definovanou nadřazenou položku, se místo toho vytvoří odkaz Související.

Aktualizace existujících chyb z Web Runneru

Kromě toho, že můžete vytvářet nové chyby z Web Runneru, můžete teď také aktualizovat stávající chyby (obrázek 80). Veškerá shromážděná diagnostická data, kroky pro reprodukci a odkazy umožňující sledovatelnost z aktuální relace se automaticky přidají ke stávající chybě.

Add to existing bug

(obrázek 80) Přidání ke stávající chybě

Rozšíření Test & Feedback – vylepšení

Rozšíření Test & Feedback založené na prohlížeči můžete nainstalovat z webu Visual Studio Marketplace. Podporuje Visual Studio Team Services i Team Foundation Server (2015 a novější verze).

Seznámení s pracovními položkami

Můžete teď provádět průzkumné testování konkrétní pracovní položky (obrázek 81). Umožní vám to přidružit vybranou pracovní položku k probíhající testovací relaci a přímo z rozšíření zobrazit kritéria přijetí a popis. Zajistí se tím také úplná sledovatelnost mezi chybami a úkoly, které zaznamenáte u vybrané pracovní položky. Pracovní položku můžete prozkoumat přímo z ní samotné nebo z tohoto rozšíření:

• Přímo z pracovní položky (obrázek 81): Spusťte relaci průzkumného testování pro konkrétní pracovní položku přímo z produktu s použitím možnosti Provést průzkumné testování v místní nabídce. Přidali jsme vstupní body na všechny karty, mřížky a do centra testování.

• Z rozšíření (obrázek 82): Pracovní položku můžete vyhledat v relaci rozšíření a pak ji přidružit k probíhající relaci.

XT from card

(obrázek 81) Rozšíření – z pracovní položky

Explore work item

(obrázek 82) Rozšíření – z rozšíření

Další informace najdete v tématu Prozkoumání pracovních položek rozšířením Test & Feedback.

Zaznamenání obrazového protokolu akcí, nahrávek obrazovky a dat načítaných webovou stránkou pomocí rozšíření Test & Feedback

Obrázkový protokol akcí: Toto rozšíření nabízí novou možnost automaticky jedním kliknutím přidat kroky, které vedou k chybě. Vyberte možnost Include image action log (Zahrnout obrazový protokol akcí) (obrázek 83) a zaznamenejte akce myši, klávesnice a dotykového ovládání a přidejte příslušný text a obrázky přímo k chybě nebo úloze.

Nahrávání obrazovky jako videa: Pomocí rozšíření také můžete na vyžádání zachytit záznam obrazovky. Tyto záznamy obrazovky můžete pořídit nejen z webových, ale i desktopových aplikací. Rozšíření můžete nakonfigurovat tak, aby se nahrávání obrazovky automaticky zastavilo a aby se záznamy připojily k chybě, která se zaznamená s použitím stránky s možnostmi rozšíření.

Data načtení stránky: Přidali jsme k rozšíření novou funkci zachytávání na pozadí – zachytávání dat načítaných webovou stránkou. Stejně jako protokol obrázků a akcí zaznamenával akce prováděné zkoumanou webovou aplikací v podobě obrázků na pozadí, funkce načítání stránky automaticky zaznamenává podrobnosti potřebné k dokončení načtení webové stránky. Místo toho, abyste spoléhali na subjektivně vnímané posouzení pomalosti při načítání webové stránky, můžete teď pomalost v chybě objektivně kvantifikovat. Jakmile je chyba zapsána, je k ní připojena kromě dlaždicového zobrazení také podrobná zpráva, která pomůže vývojáři v počátečních krocích zkoumání.

XT Image Action Log

(obrázek 83) Rozšíření – obrázkový protokol akcí

Vytvoření testovacích případů na základě dat obrázkového protokolu akcí

Když v rámci relace nahodilého testování vytváříte testovací případy, automaticky se vyplní testovací kroky s obrázky (obrázek 84). Souběžný návrh a provádění testu je základem skutečně nahodilého testování a tato nová funkce ho pomáhá uskutečnit. Můžete upravit zachycený text, přidat očekávaný výsledek, zrušit zaškrtnutí irelevantních řádků a uložit výsledek pro budoucí testování.

XT Create Test Cases

(obrázek 84) Rozšíření – Vytváření testovacích případů

Další informace najdete v tématu Vytvoření testovacích případů na základě dat v protokolu obrázků a akcí.

Přehled o relacích nahodilého testování

K dispozici je teď možnost zobrazit dokončené relace průzkumného testování pro zadané časové období na úrovni týmu nebo jednotlivců vytvořené pomocí rozšíření Test & Feedback. Ke stránce tohoto přehledu se můžete dostat kliknutím na „Poslední nahodilé relace“ v centru Runs v rámci skupiny centra testování ve webovém přístupu. Toto nové zobrazení pomáhá odvodit smysluplné přehledy, včetně:

  • Souhrnné zobrazení obsahuje rozpis prozkoumaných pracovních položek, vytvořených položek a vlastníků relací a také celkový čas strávený nad těmito relacemi (obrázek 85).
  • Zobrazení může být neseskupené nebo seskupené podle prozkoumaných pracovních položek, relací nebo vlastníků relací. Pro všechna seskupení můžete buď zobrazit seznam všech vytvořených pracovních položek (chyby, úkoly, testovací případy), nebo seznam omezit na určitý typ pracovní položky.
  • Zobrazení podokna podrobností obsahuje informace pro výběr provedený v seskupeném zobrazení. Pro vybraný způsob seskupování (například prozkoumané pracovní položky) můžete v podokně podrobností zobrazit jeho souhrnné informace, jako je celkový počet relací, celkový čas na nich strávený, vlastníci relací, kteří je zkoumali a chyby/úkoly/testy pro ně vytvořené, spolu se stavem a prioritou. Pro vybrané řádky pracovních položek můžete přímo na místě zobrazit formulář pracovní položky a provést změny podle potřeby.

XT Session insights

(obrázek 85) Rozšíření – Přehled relací

Další informace najdete v tématu Získání přehledu o relacích průzkumného testování.

Relace nahodilého testování: zobrazení neprozkoumaných pracovních položek

Kromě toho, že je možné v zobrazení nejnovějších relací nahodilého testování zobrazit všechny podrobnosti o neprozkoumaných pracovních položkách s filtrem na všechny/vlastní relace, je teď dostupná možnost zobrazit ve stejném zobrazení také seznam všech pracovních položek, které NEBYLY prozkoumány (obrázek 86). Začít můžete zadáním sdíleného dotazu na pracovní položky, které vás zajímají, a stránka relace zobrazí seznam všech pracovních položek z dotazu, s rozpisem prozkoumaných a neprozkoumaných položek v souhrnné části. Pomocí skupiny Neprozkoumané pracovní položky je také možné zobrazit seznam všech položek, které dosud nebyly prozkoumány. To je velmi užitečné ke sledování počtu scénářů, které dosud nebyly prozkoumány nebo neprošly procesem zpracování chyb.

View unexplored WIT

(obrázek 86) Zobrazení neprozkoumaných pracovních položek

Proces zpětné vazby mezi koncovými účastníky
Žádost o zpětnou vazbu

Uživatelé se základní úrovní přístupu si teď můžou vyžádat zpětnou vazbu od účastníků přímo u zpracovávaných nebo dokončených funkcí nebo scénářů s použitím možnosti Vyžádat zpětnou vazbu v nabídce pracovní položky (obrázek 87). Otevře se formulář Vyžádat zpětnou vazbu, kde můžete vybrat účastníky, od kterých chcete zpětnou vazbu, a volitelně můžete zadat jednoduchou sadu instrukcí s informacemi o tom, k jakým oblastem produktu by se měli vyjádřit. Vybraným účastníkům se pošlou samostatné e-maily a případné pokyny.

XT Feedback Flow

(obrázek 87) Proces u rozšíření Feedback

Další informace najdete v tématu Vyžádání zpětné vazby od účastníků prostřednictvím rozšíření Test & Feedback.

Poskytnutí zpětné vazby

Účastníci můžou reagovat na žádost o zpětnou vazbu kliknutím na odkaz Poskytnout zpětnou vazbu, který dostanou v e-mailu. Automaticky se nakonfiguruje rozšíření Test & Feedback (dříve rozšíření Průzkumné testování) s vybraným požadavkem na zpětnou vazbu (pokud rozšíření ještě není nainstalované, zobrazí se výzva k jeho instalaci). Účastníci pak můžou použít úplné možnosti zaznamenání, které jsou k dispozici v rozšíření, k zachycení svých zjištění a odeslání zpětné vazby ve formě pracovní položky s odpovědí se zpětnou vazbou, chybou nebo úlohou. Kromě toho můžou účastníci přejít na stránku Žádosti zpětné vazby, kde si na jednom místě zobrazí všechny přijaté žádosti o zpětnou vazbu. V seznamu můžou vybrat žádost o zpětnou vazbu, ke které chtějí poskytnout informace, spravovat žádosti o zpětnou vazbu čekající na vyřízení (obrázek 88) tím, že je označí jako dokončené nebo odmítnou, a přepínat mezi různými typy žádostí o zpětnou vazbu kliknutím na příslušný přepínač (obrázek 89).

Provide feedback link

(obrázek 88) Poskytnutí odkazu na zpětnou vazbu

XT Feedback Flow

(obrázek 89) Proces u rozšíření Feedback

Další informace najdete v tématu Poskytnutí zpětné vazby prostřednictvím rozšíření Test & Feedback.

Dobrovolná zpětná vazba

Vedle postupu s vyžádáním zpětné vazby uvedeného výše můžou účastníci využít toto rozšíření také k dobrovolnému zadání zpětné vazby (obrázek 90). Můžou otevřít rozšíření, na stránce nastavení připojení zvolit režim Připojeno a připojit se k účtu a projektu nebo týmu, pro který chtějí zpětný názor zadat. Potom můžou s použitím rozšíření zaznamenat to, co zjistili, a poslat svoji zpětnou vazbu ve formě pracovní položky s odpovědí se zpětnou vazbou, chybou nebo úlohou.

Voluntary Feedback

(obrázek 90) Dobrovolná zpětná vazba

Další informace najdete v tématu Poskytnutí dobrovolné zpětné vazby prostřednictvím rozšíření Test & Feedback.

Vylepšení automatizovaného testování

Protokoly konzoly a doba trvání testu na kartě Testy v souhrnu Sestavení a verze

Protokoly konzoly s výsledky testu zaznamenanými v souborech .trx se extrahují a publikují jako přílohy s výsledky testů (obrázek 91). Jejich náhled si můžete zobrazit na kartě Testy. K zobrazení protokolů už nemusíte stahovat soubor trx.

Console logs and duration

(obrázek 91) Protokoly konzoly a doby trvání

Widget Trend testů pro sestavení

Do galerie widgetů jsme přidali nový widget „Trend výsledků testů“ (obrázek 92). Pomocí tohoto widgetu můžete pro danou definici sestavení přidat graf trendů výsledků testů na řídicí panel až pro 30 nejnovějších sestavení. Možnosti konfigurace widgetu vám umožní přizpůsobit graf zahrnutím pivotů jako je počet úspěšných testů, počet neúspěšných testů, celkový počet testů, procento úspěšnosti a doba trvání testu.

'Test result trend' widget

(obrázek 92) Widget trendu výsledků testů

Souhrn stavu testování a prostředí vydání

Je doporučeným postupem používat prostředí vydání k nasazení aplikací a provádění testů s nimi. V této verzi jsme integrovali rychlost průchodu testů v prostředí vydání do části Prostředí na stránce souhrnu vydání (obrázek 93). Jak uvádí snímek obrazovky, pokud dojde k selhání prostředí, můžete ve sloupci Testy rychle zjistit, jestli došlo k selhání z důvodu selhání testů. Kliknutím na rychlost průchodu lze přejít na kartu Testy a prozkoumat testy, které v daném prostředí selhaly.

Test status with Release Environment summary

(obrázek 93) Souhrn stavu testování a prostředí vydání

Automatická historie testů pro prostředí větví a vydání

Je běžným scénářem, že se jeden test spouští na více větvích, prostředích a konfiguracích. Pokud takový test selže, je důležité identifikovat, jestli se chybu podařilo udržet ve vývojových větvích, jako je hlavní větev, nebo má selhání vliv i na vydané větve, které se nasazují do provozního prostředí. Teď můžete sledovat historii testu mezi různými větvemi, na kterých probíhá, zobrazením karty Historie na stránce souhrnu výsledků (obrázek 94). Podobně můžete seskupením pivotu prostředí vizualizovat historii testu mezi různými prostředími vydání, ve kterých je test spuštěn.

Test status with Release Environment summary

(obrázek 94) Souhrn stavu testování a prostředí vydání

Sledovatelnost pomocí nepřetržitého testování

Uživatelé teď mohou sledovat kvalitu svých požadavků přímo na řídicím panelu (obrázek 95). Už máme řešení kvality požadavků pro plánované testovací uživatele a přinášíme je uživatelům, kteří provádějí nepřetržité testování. Uživatelé budou moct propojit automatizované testy přímo k požadavkům. Pak bude možné pomocí widgetů řídicího panelu sledovat kvalitu příslušných požadavků a získávat data kvality ze sestavení nebo vydání.

Requirement Quality Widget

(obrázek 95) Widget kvality požadavků

Vzdálené testování – distribuce testů na základě počtu počítačů

Umožnili jsme distribuci testů v rámci sestavení na vzdálené počítače pomocí úkolu pro spuštění funkčních testů (obrázek 96). V TFS 2015 jste mohli distribuovat testy jenom na úrovni sestavení. To může být povoleno pomocí zaškrtávacího políčka v úkolu, jak je uvedeno níže.

Task Setting

(obrázek 96) Nastavení úkolu

Automatizované testování pro SCVMM a VMWare

Uživatelé můžou dynamicky nastavovat testovací počítače v cloudu s Azure nebo v místním prostředí pomocí SCVMM nebo VMWare a využívat tyto počítače k distribuovanému spuštění testů. Uživatelé můžou ke spuštění testů použít jeden z úkolů zřízení počítače – Azure, SCVMM nebo VMWare – následovaný úkolem spuštění funkčních testů.

Analýza SonarQube v úlohách Maven a Gradle

V úkolech buildu Maven a Gradle teď můžete vyvolat analýzu SonarQube tím způsobem, že zaškrtnete políčko Spustit analýzu SonarQube, zadáte koncový bod, název projektu SonarQube, klíč projektu a verzi (obrázek 97).

Run SonarQube Analysis

(obrázek 97) Spuštění analýzy SonarQube

Také teď získáte odkaz na projekt SonarQube (obrázek 98). Můžete si vyžádat úplnou analýzu, zobrazit podrobnosti bran kvality a rozhodnout o přerušení sestavení, pokud nebudou splněny.

Run SonarQube Analysis

(obrázek 98) Spuštění analýzy SonarQube

Další informace najdete v tématu Úloha sestavení Gradle nyní podporuje analýzu SonarQube.

Vylepšení Marketplace

Správci kolekcí projektů teď můžou ze Team Foundation Server přejít na web Visual Studio Marketplace a instalovat bezplatná rozšíření do týmové kolekce projektů. Rozšíření se automaticky stáhnou z webu Visual Studio Marketplace, nahrají se na Team Foundation Server a nainstalují do vybrané týmové kolekce projektů (obrázek 99).

Install Free Extension

(obrázek 99) Instalace rozšíření zdarma

Zakoupení a instalace placených rozšíření

Správci kolekcí projektů teď můžou z Team Foundation Serveru přejít na web Visual Studio Marketplace a koupit si placená rozšíření, která si nainstalují do vybrané týmové kolekce projektů (obrázek 100). Správce může za rozšíření platit prostřednictvím předplatného Azure a vybrat počet uživatelů, kterým tato rozšíření přiřadí. Rozšíření se automaticky stáhnou z webu Visual Studio Marketplace, nahrají se na Team Foundation Server a nainstalují do vybrané týmové kolekce projektů.

Purchase Paid Extension

(obrázek 100) Zakoupení placeného rozšíření

Další podrobnosti najdete v dokumentaci Získání rozšíření pro Team Foundation Server.

Vylepšení správy

Ověřování systému Windows

V předchozích verzích jste se při konfiguraci nasazení TFS (Team Foundation Server) připojeného k doméně museli rozhodovat mezi zprostředkovateli podpory zabezpečení NTLM a Negotiate. Ve verzi 2017 jsme toto nastavení z konfiguračního prostředí odebrali. Pokud chcete ve verzi 2017 dál používat ověřování protokolem NTLM, nemusíte nic dělat. Pokud jste používali ověřování protokolem Kerberos a chcete s tím pokračovat i ve verzi 2017, nemusíte nic dělat. TFS 2017 teď vždy konfiguruje jak zprostředkovatele podpory zabezpečení Negotiate, tak NTLM (v tomto pořadí). Díky této konfiguraci se všude, kde je to možné, použije ověřování protokolem Kerberos, které poskytuje vyšší zabezpečení. Pokud protokol Kerberos nelze použít, použije se ověřování protokolem NTLM. Důkladnými testy jsme zajistili, aby tato změna neměla žádný dopad na existující nasazení TFS, která využívají ověřování protokolem NTLM.

Moderní navigační prostředí

V této verzi jsme uvolnili nový a vylepšený horní navigační panel. U nové navigace existují dva základní cíle:

  • Zvýšit efektivitu navigace v různých oblastech produktu, která umožní rychlý přístup k různým uzlům jediným kliknutím
  • Přinést moderní stylový vzhled a kvalitní ovládání produktu

Vzhledem k tomu, že se pro uživatele jedná o velkou změnu a ve funkci ještě probíhají změny, rozhodli jsme se nové chování navigace ve výchozím nastavení vypnout. Pokud ho chcete vyzkoušet, můžete ho povolit v oblasti pro správu Team Foundation Server výběrem možnosti „Zapnout novou navigaci“. Je třeba upozornit, že tím bude navigace povolena pro všechny uživatele na serveru.

Oprávnění k přejmenování týmového projektu

Došlo ke změně oprávnění určujícího, kteří uživatelé mohou přejmenovat týmový projekt. Dříve mohli týmový projekt přejmenovat uživatelé s oprávněním k úpravám projektu. Nyní je možné oprávnění k přejmenování týmového projektu uživatelům přidělit nebo odebrat pomocí samostatného Oprávnění k přejmenování týmového projektu.

Centrum Práce v nastavení správy

Zavedli jsme nové centrum „Práce“ na stránce nastavení správy, které kombinuje obecná nastavení (obrázek 101), iterace a oblasti do jedné karty. Díky této změně uživatelé jasně uvidí rozdíly mezi nastaveními na úrovni projektu a na úrovni týmu. Pro nastavení týmu uživatelé uvidí jen ty oblasti a iterace, které jsou relevantní pro jejich tým. Na úrovni projektu umožní stránka nastavení správcům správu oblastí a iterací pro celý projekt. Kromě toho byl pro cesty oblastí projektu přidán nový sloupec s názvem „Týmy“, který správcům usnadňuje zjištění, které týmy si vybraly specifickou cestu oblasti.

Admin work hub

(obrázek 101) Centrum Práce v nastavení správy

Rozhraní REST API pro konfiguraci procesů

Toto veřejné rozhraní API umožňuje uživatelům konfiguraci procesu pro daný projekt. Konfigurace procesu obsahuje následující nastavení:

  • TypeFields: abstrakce přizpůsobitelných polí použitých pro agilní nástroje. Například typem pole „Body scénáře“ je „Úsilí“.
  • Definice backlogu: určují, které typy pracovních položek jsou v každém z backlogů. Toto rozhraní API je často vyžadované zákazníky, kteří vyvíjejí rozšíření. S těmito daty mohou rozšíření vědět, jak využít pole specifické pro proces k podpoře běžných scénářů v agilních nástrojích (například změna aktivity nebo úsilí pracovní položky – se znalostí toho, které pracovní položky jsou zahrnuty na dané úrovni backlogu, nebo se zjištěním, zda jsou týmy identifikovány cestou oblasti nebo vlastním polem). Další informace najdete v tématu Přehled práce.

Team Foundation Server 2017 zavádí nové prostředí pro správu skupin a členství ve skupinách. Ve službě Active Directory nebo v místním počítači můžete vyhledávat uživatele a skupiny podle předpony jména uživatele nebo názvu skupiny. Zadejte například „Jan D“ nebo nazevjanovauctu (například „podnikovadomena\jand“) a prohlédněte si kartu kontaktu uživatele nebo skupiny.

Nastavení uživatelského zabezpečení

V novém prostředí „Mé zabezpečení“ můžete spravovat tokeny osobního přístupu a SSH (obrázek 102). Uživatelé, kteří používali ke správě SSH stránku „Můj profil“, budou teď muset spravovat své veřejné klíče SSH v nastavení uživatelského zabezpečení (obrázek 103).

My security

(obrázek 102) Mé zabezpečení

My profile

(obrázek 103) Můj profil

Jednotný průvodce konfigurací

V předchozích verzích jste si mohli vybrat jednoho z několika průvodců konfigurací pro nasazení TFS podle toho, jakou akci jste chtěli provádět – základní a úplný průvodce byl určen ke konfiguraci nového nasazení, průvodce upgradem mohl být použit pro upgrade v produkčním a předprodukčním prostředí. Průvodce pouze pro aplikační vrstvu bylo možné použít pro různé scénáře včetně škálování existujícího nasazení, nahrazení aplikační vrstvy novým hardwarem a podobně. V TFS 2017 jsou všechny tyto scénáře sjednocené do jediného průvodce konfigurací serveru, který vás jednoduchými otázkami na tyto scénáře navede a pak v nich pokračuje. Kromě toho se nyní v rozšířených konfiguracích, například předprovozních upgradech a klonování existujících nasazení, automatizují akce, které je nutné provádět příkazem tfsconfig.exe, včetně změny ID serveru, přemapování připojovacích řetězců databáze a odstranění odkazů na externí závislosti (které je nutné provést příkazem tfsconfig.exe PrepareClone).

Nová úroveň přístupu

S novou skupinou sady Visual Studio Enterprise přidanou do portálu správce mezi úrovně přístupu v serverech Team Foundation nyní můžete rychle identifikovat uživatele s předplatným Visual Studio Enterprise. Po identifikaci získají tito uživatelé bez dalšího poplatku úplný přístup ke všem rozšířením TFS první strany nainstalovaným z Visual Studio Marketplace.

Osobní přístupové tokeny

K libovolnému serveru Team Foundation Server se teď můžete připojit kromě připojení SSH také pomocí osobního přístupového tokenu (obrázek 104). To je užitečné, pokud vyvíjíte v systému Linux nebo Mac a chcete použít libovolné automatizační nástroje a GIT. Své osobní přístupové tokeny můžete spravovat na stránce nastavení uživatelského zabezpečení.

Personal Access Tokens

(obrázek 104) Osobní přístupové tokeny

Známé problémy

Toto je úplný seznam známých problémů v této verzi.

Team Foundation Server 2017 nenabízí nástroje Power Tools

  • Problém:

    Pro TFS 2017 nebyly vydány žádné nástroje Power Tools.

  • Alternativní řešení:

    Jsme rádi, že vám můžeme oznámit, že v TFS 2017 je integrovaná většina předchozích nástrojů Power Tools. Process Template Editor není integrovaný editor, ale můžete ho získat na webu Visual Studio Marketplace.

Aktualizace rozšíření vlastního ovládacího prvku

Chyba při importu definice typu pracovní položky

  • Problém:

    Zákazníkům s nainstalovaným rozšířením stránky pracovní položky, kteří exportují definici typu pracovní položky a pak tuto definici importují, se zobrazí chyba s informacemi o tom, že není deklarovaný atribut LayoutMode.

  • Alternativní řešení:

    Vždy, když exportujete definici typu pracovní položky, je u elementu PageContribution navíc jeden atribut LayoutMode. Před importováním definice vyhledejte režim PageContribution a atribut LayoutMode odeberte. Odeberte například LayoutMode="FirstColumnWide".

Zákazníci by měli provést aktualizaci na Git LFS verze 1.3.1 nebo vyšší

  • Problém:

    Verze Git LFS nižší než 1.3.1 nebudou v budoucích vydáních podporovány.

  • Alternativní řešení:

    Zákazníkům, kteří používají Git LFS, důrazně doporučujeme, aby aktualizovali na verzi 1.3.1 nebo vyšší. Starší verze klienta LFS nejsou kompatibilní se změnami ověřování v této verzi TFS. Abychom zákazníkům dali čas na migraci, implementovali jsme pro RTW krátkodobé alternativní řešení. Toto alternativní řešení se odebere v aktualizaci Update 1. V důsledku toho nebudou funkční klienti Git LFS nižších verzí než 1.3.1.

NuGet Restore nenachází balíčky, které existují v nuget.org

  • Problém:

    Pokud používáte NuGet 3.4.3 nebo vyšší, úloha NuGet Restore neobnoví balíčky z NuGet.org, pokud se nejedná o explicitní zdroj uvedený v NuGet.Config.

  • Alternativní řešení:

    Přidejte NuGet.org do souboru NuGet.Config.


Úkoly sestavení a vydání NuGet nejsou ověřeny

  • Problém:

    Při použití Team Foundation Server / správy balíčků nedojde k ověření úkolů buildu a vydání NuGet vůči kanálům, pokud je agent spuštěn jako uživatel NETWORK SERVICE – což je výchozí nastavení, pokud je agent sestavení spuštěn jako služba. K tomu dochází, protože verze NuGet starší než 3.5 používají přihlašovací údaje uživatelského účtu, který spouští agenta sestavení, a ne přihlašovací údaje poskytnuté úlohou sestavení.

  • Alternativní řešení:

    Pokud chcete použít úlohy sestavení/vydání NuGet spolu s kanály TFS pomocí agenta, který je spuštěn jako NETWORK SERVICE, je nutné použít NuGet 3.5 nebo vyšší.

Úlohy sestavení a vydání NuGet používají přihlašovací údaje agenta

  • Problém:

    Verze NuGet starší než 3.5 používají přihlašovací údaje uživatelského účtu, který spouští agenta sestavení, a ne přihlašovací údaje poskytnuté úlohou sestavení. To může způsobit neočekávaný přístup nebo zamezení přístupu ke kanálům.

  • Alternativní řešení:

    U agentů sestavení TFS používejte NuGet 3.5 nebo vyšší.

Při upgradu TFS se neupgraduje automaticky externí rozšíření

  • Problém:

    Pokud jste stáhli rozšíření z webu Visual Studio Marketplace, publikovali ho v instalaci sady TFS 2015 a potom upgradovali na TFS 2017, nebude se rozšíření automaticky aktualizovat, když se na webu Marketplace publikují nové verze tohoto rozšíření.

  • Alternativní řešení:

    Po upgradu na TFS 2017 odinstalujte rozšíření, která jste nainstalovali v TFS 2015. Potom znovu nainstalujte nejnovější rozšíření. V TFS 2017 jsme přidali funkci, která automaticky jednou denně zjišťuje aktualizovaná externí rozšíření a upgraduje je.

V definicích verzí není možné spustit úlohu Jenkins Queue Job

  • Problém:

    Při spuštění úlohy Jenkins Queue Job v definici verze se zákazníkům zobrazí chyba 500.

  • Alternativní řešení:

    V současné době je možné spustit úlohu Jenkins Queue Job jako součást definic sestavení TFS, ale ne jako součást definic verzí. Tuto možnost přidáme v budoucí verzi.

Vlastní moduly plug-in serveru TFS je potřeba znovu sestavit na knihovnách DLL TFS 2017

  • Problém:

    Vlastní moduly plug-in serveru TFS po upgradu na TFS 2017 nefungují.

  • Alternativní řešení:

    Znovu sestavte vlastní moduly plug-in serveru na sestaveních TFS 2017.

Objektový model serveru pro vlastní moduly plug-in serveru TFS se od TFS 2015 RTM změnil

  • Problém:

    Vlastní moduly plug-in serveru TFS se nekompilují.

  • Alternativní řešení:

    Opravte zdrojový kód podle pokynů v tomto blogovém příspěvku.

Při použití akcí správce dochází k výjimce

  • Problém:

    Když správci týmů na stránce Správa upozornění použijí vyhledávání Najít upozornění pro konkrétního uživatele k vyhledání předplatného týmu, může se zobrazit výjimka.

  • Alternativní řešení:

    • 1. možnost: Klikněte na uzel Všechna upozornění a nastavte filtr Všechna upozornění mého týmu. Zobrazí se všechna upozornění pro všechny skupiny, ke kterým má uživatel přístup.

    • 2. možnost: Pokud je skupina týmem, nehledejte název týmu, ale přejděte na stránku Správa upozornění daného týmu, kde můžete spravovat předplatné.

Problém při používání úloh pro spouštění funkčních testů u týmových sestavení / správy verzí

  • Problém:

    Při spouštění funkčních testů u týmových sestavení / správy verzí s použitím úkolů nasazení služby Visual Studio Test Agent a spuštění funkčních testů z katalogu úloh se v současnosti používá aktualizace Agents for Visual Studio 2015 Update 3 a tyto funkční testy je možné použít jenom k spuštění testů vytvořených s použitím sady Visual Studio 2013 a Visual Studio 2015. Tyto úlohy není možné použít ke spuštění testů vytvořených pomocí sady Visual Studio 2017 RC. Další podrobnosti najdete v tomto blogovém příspěvku.

  • Alternativní řešení:

    Pro tento problém neexistuje alternativní řešení. Podpora pro použití služby Test Agent 2017 a spouštění testů vytvořených pomocí sady Visual Studio 2017 bude přidána v časovém rámci vydání aktualizace TFS 2017 Update 1.

Rozšíření se automaticky neaktualizují

  • Problém:

    Pokud upgradujete dřívější verzi serveru TFS na TFS 2017 a TFS 2017 běží v připojeném režimu, nebudou se rozšíření aktualizovat, jak by měla.

  • Alternativní řešení:

    Pro tento problém zatím neexistuje alternativní řešení. Tento problém jsme vyřešili a oprava chování automatických aktualizací vám bude doručena prostřednictvím aktualizace Update 2 pro TFS 2017. Pokud z nějakého důvodu nemůžete na aktualizaci Update 2 čekat, kontaktujte nás přes kanál podpory a my vám opravu zpřístupníme dříve.

Pokud narazíte na problémy, které brání v nasazení do produkčního prostředí (živý provoz), kontaktujte prosím podporu produktů Microsoft. (jen v angličtině) Pracovní doba jen USA (po–pá 6:00–18:00 PST), odpověď do 1 pracovního dne.

Na začátek stránky