Team Foundation Server 2017 – poznámky k vydání

---

Komunita vývojářů | Požadavky na systém a kompatibilita | Licenční podmínky | Blog TFS DevOps | Hodnoty hash SHA-1 | | Nejnovější zpráva k vydání verze pro Visual Studio 2019|

---

Poznámka:

Toto není nejnovější verze Team Foundation Serveru. Pokud si chcete stáhnout nejnovější verzi, přejděte na aktuální zprávu k vydání verze pro Team Foundation Server 2018 Update 3. Jazyk této stránky můžete změnit kliknutím na ikonu zeměkoule v zápatí stránky a výběrem požadovaného jazyka.

---

V tomto článku najdete informace týkající se Team Foundation Serveru 2017. Klikněte na tlačítko pro stažení.

Další informace o Team Foundation Serveru 2017 najdete na stránce Požadavky pro Team Foundation Server a jeho kompatibilita.

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

---

Datum vydání: 28. února 2018

Tato aktualizace řeší potenciální skriptování mezi weby (XSS) a další chyby zabezpečení. Další informace najdete v tomto blogovém příspěvku. Jedná se o úplný upgrade, proto můžete upgradovat přímo na TFS 2017.0.1.

Datum vydání: 16. listopadu 2016

Souhrn novinek v Team Foundation Serveru 2017

• Vyhledávání kódu
• Správa balíčků
• Vylepšení pro agilní metodiky
• Vylepšení řídicích panelů a widgetů
• Vylepšení Git
• Vylepšení sestavení
• Vylepšení nástroje Release Management
• Vylepšení testování
• Vylepšení Marketplace
• Vylepšení správy
• Osobní přístupové tokeny

Známé problémy

• Známé problémy

---

Podrobné informace o novinkách Team Foundation Serveru 2017

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í rozšíření Code Search 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áce na 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. Bez problémů funguje s vaší stávající infrastrukturou, týmy a oprávněními TFS, takže není potřeba řešit synchronizaci identit, správu skupin na více místech atd. Integruje se také snadno s týmovým sestavením, takže můžete vytvářet a používat balíčky v pracovních postupech kontinuální integrace.

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

(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á zkušenost s historií (Historie a audit)
• 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.

(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ářů.

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

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

Aktualizace kanbanových karet

Vaše nástěnka Kanban je teď spuštěna.

Už jste celý den mačkali F5, abyste zjistili, co se děje s vaší Kanban tabulí? Vyzkoušejte ikonu na snímku obrazovky dole (obrázek 5).

(Obrázek 5) Živé aktualizace 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ě. Pokud správce provede aktualizace na nástěnce nebo na úrovni týmu, například přidá nový sloupec nebo povolí sledování chyb v backlogu, budete upozorněni, abyste si obnovili nástěnku pro aktualizaci jejího rozložení. K tomu všemu stačí povolit ikonu věže na kartě Kanban a začít spolupracovat se svým týmem.

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.

(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).

(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 ponořit se do podrobností na tabulích Epic a Feature (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.

(Obrázek 8) Podrobný rozbor epických prvků

Další informace najdete v tématu Kanban – funkce a epiky.

Zapnutí a vypnutí poznámek na tabuli

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). Stačí jednoduše zrušit výběr poznámky a ta z karty Kanban zmizí. První dvě anotace, které se zde zobrazí, jsou podřízené pracovní položky (v tomto příkladu úkoly) a anotace Test.

(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í. Pokud jste jako většina uživatelů, pravděpodobně vás v minulosti zklamalo, když jste do tohoto pole zkopírovali formátovaný text a nemohli ho vrátit zpět nebo odstranit. 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é desce

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 přetrvávají, takže se můžete podívat na svoji přizpůsobenou nástěnku, i když se připojujete z více zařízení.

(Obrázek 10) Filtrování v Kanbanu

Č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.

(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).

(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 nový bod přispění na stránky panelu a backlogu, který vám umožní psát rozšíření jako pivotovou kartu vedle karet Panelu, Backlogu a Kapacity.

Zveřejnili jsme nový milník v 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).

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

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 zobrazovaly na mobilních zařízeních.

(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í.

(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 zajistili celkově lepší prostředí (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ů.

(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í.

(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, takže sledujte zde další novinky.

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

Upravili jsme widgety grafů WIT tak, aby byly nastavitelné co do 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 Členové týmu byl aktualizován, aby usnadňoval přidání dalších členů týmu (obrázek 18).

(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řehledu 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.

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

Rozhraní REST API pro dashboardy

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í 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 „sloučení squash“.

Přepracovaná stránka Větve

Stránka Branches byla kompletně přepracována. Má pivot „můj“, který zobrazuje 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/jeremy/fix-bug", zobrazuje se jako seznam, takže je snadné procházet rozsáhlý seznam větví. Pokud znáte název požadované větve, můžete ji rychle vyhledat.

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

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.

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

Přehled

Přehled nyní zvýrazňuje popis pull requestu, 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é.

(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 náhledech jsme přidali možnost správně sledovat komentáře při aktualizacích pull requestu. 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 do vašeho pull requestu přidá 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.

(Obrázek 23) Pull request – soubory

Aktualizace

Nové zobrazení Aktualizace ukazuje, jak se PR 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 někdy dojde k vynucenému push, pohled na Aktualizace bude nadále ukazovat předchozí aktualizace přesně tak, jak proběhly v minulosti.

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

Komentáře nyní s markdownem 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.

(Obrázek 25) Pull request – komentáře

Přidávání a odebírání recenzentů v pull requestech

Nyní je mnohem snadnější přidávat a/nebo odebírat revidující z vašich pull requestů. K přidání recenzenta nebo skupiny do pull requestu stačí jednoduše zadat jejich jméno do vyhledávacího pole v sekci Recenzenti. 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).

(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 pull requestů

Žá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šími vylepšeními následují komentáře po kódu 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 změny s komentářem ve řádku 13 (obrázek 27):

(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).

(Obrázek 28) Sledování změn v komentáři

Automatické dokončování žádostí o přijetí změn čekajících na schválení zásad

Týmy, které používají zásady větví k ochraně svých větví, by se měly seznámit s funkcí automatického dokončení. Mnohokrát je autor pull requestu připravený svůj PR sloučit, ale čeká na dokončení sestavení, aby mohl kliknout na Dokončit. Jindy je zase sestavení dokončené, ale jeden z revidujících 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).

(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).

(Obrázek 30) Autodialog

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).

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

Po splnění všech zásad (například dokončení sestavení 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 revidující neudělí schválení, zůstane žádost o přijetí změn aktivní, tak jak se očekávalo, dokud nebudou splněny příslušné podmínky.

Žá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 tzv. "squash merge" (obrázek 32). Tato nová možnost vytvoří jediný commit obsahující změny z tématické větve, aplikované na 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 bude znamenat jednodušší graf historie revizí, protože všechna mezilehlá potvrzení provedená ve větvi tématu nebudou ve výsledném grafu potvrzení dostupná.

(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 commitů

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, jestli změny v commitu prošly sestavením nebo ne. 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 pull requesty, uvidíte odkaz na pull request, který vnesl změny do hlavní větve (nebo v případě potvrzení sloučení, PR, který ho vytvořil). Pokud vaše změny dosáhly hlavní verzi, objeví se odkaz na větev potvrzující, že změny byly zahrnuty.

(Obrázek 33) Sledovatelnost potvrzení

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

Pokud už pracujete s velkými soubory v Git (zvukové, video soubory, datové sady atd.), pak víte, že Git Large File Storage (LFS) nahrazuje tyto soubory ukazateli uvnitř Git, zatímco skutečný obsah souborů uloží 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.

Vytvoření a odeslání odkazů na určité části kódu

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ěry neúplných řádků.

(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í.

(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).

(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ě.

(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 fronty 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).

(Obrázek 38) Karta fronty sestavení

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

Povolit rozšíření výsledků sestavení ke specifikaci pořadí a sloupců

Rozšíření sekce výsledků sestavení nyní mohou určit, který sloupec a v jakém pořadí se zobrazí (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.

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

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):

(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).

(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 Xamarin.Android teď podporuje Mac a Linux.
• Krok Xamarin.iOS teď podporuje podepisování a zabalení.
• Xamarin Test Cloud zobrazuje výsledky přímo na stránce souhrnu sestavení.
• Nový krok Xamarin component restore.
• Krok NuGet Installer teď podporuje Mac OS.

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ě jsme vylepšili š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.

(Obrázek 42) Obrázky Dockeru

Výsledky SonarQube v zobrazení pull requestu

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. Pro více informací si přečtěte příspěvek na blogu Integrace problémů analýzy kódu SonarQube do pull requestů.

(Obrázek 43) Žádosti o začlenění v SonarQube

Konfigurace hlášení o status API pro definici sestavení

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

Další informace viz Referenční informace k sestavení REST API.

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

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

Povolte filtry cest pro spouštěče 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).

(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).

(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 zprávy

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).

(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).

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

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

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

(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 definicích verzí. Pokud se úkol nezdaří, celkový výsledek vydání bude „Vydání bylo částečně dokončeno“ (obrázek 49).

(Obrázek 49) Souhrn vydání zobrazuje částečně úspěšná vydání ve oranžové barvě

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ém vydávacím prostředí lze však nastavit novou možnost, která pověří Release Management vyvoláním vydání do následujícího prostředí, pokud je předchozí vydání částečně úspěšné (obrázek 50).

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

Pro více podrobností se podívejte do dokumentace Aktivační události nasazení prostředí.

Přímé využití artefaktů uložených 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).

(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.

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.

(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 konfigurační proměnné a abstrahovat zbývající informace o úlohách.

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í.

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

Další podrobnosti najdete v dokumentaci Skupiny úloh.

Dočasné 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í.

Po určitou dobu (obvykle 14 dní) je však uchovaná spolu s definicí verze, než je trvale odstraněna.

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 otevřením místní nabídky a zvolením Zrušit odstranění(obrázek 54).

(Obrázek 54) Obnovení odstraněných 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í dobu uchovávání verze a s ní spojeného sestavení.

Ve výchozím nastavení se verze uchovává 60 dní. Verze, které během této doby nebyly nasazeny nebo upraveny, 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é uchovávat sestavení propojené s verzí po stejně dlouhou dobu jako verzi, aby bylo zajištěno, že artefakty budou k dispozici, pokud bude nutné tuto verzi znovu nasadit (obrázek 55).

(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 v úložišti agenta s názvem aliasu 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í.

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

Další podrobnosti najdete v dokumentaci [Alias zdroje artefaktů](/vsts/pipelines/release/artifacts?preserve-view=true&view=vsts#source-alias).

• Pro použití v parametrech úloh je k dispozici řada proměnných formátu Build.* (například Build.BuildId a Build.BuildNumber). Když je s vydáním spojeno více zdrojů, se tyto proměnné nyní naplní hodnotami ze zdroje artefaktu, který určíte jako primární. 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).

(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.

(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).

(Obrázek 59) Naplánovat vydání do prostředí

Nasazovat na základě podmínek v různých 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 naleznete v dokumentaci Paralelní rozvětvená a sloučená nasazení.

REST API pro řízení vydání

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.

Integrace služebních háčků

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.

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. Doporučujeme nakonfigurovat zásady uchovávání testů a vyčkat, než 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, že 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 testů

Do centra testování jsme přidali novou kartu Konfigurace, která nabízí nové webové 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 testů.

(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 scénářů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 k …, a můžete začít. V centru testování můžete také filtrovat podle konfigurací (obrázek 63).

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

(Obrázek 63) Filtr konfigurací

Pro více informací viz Přiřazení konfigurací k testovacím plánům a testovacím 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).

(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é objednat přímo na kartě uživatelského scénáře na Kanban desce (obrázek 66).

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

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

Seřaďte testovací sady v centru testování

Testovací týmy mohou nyní testovací sady seřadit podle svých potřeb. Předtím byly tyto sady seř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).

(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).

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

(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í.

(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 se otevřelo prostředí Microsoft Test Manager, a po dokončení provádění testů dojde k jeho vypnutí.

(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.

(Obrázek 72) Spuštění 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.

(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.

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

Rozhraní REST API pro klonování testovacího plánu a testovací sady

Přidali 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.

Ověření postupu z Kanban karet

Nyní můžete přidat, zobrazit a interagovat s testovacími případy přímo ve vašich scénářích na Kanban tabuli. 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).

(Obrázek 75) Vložené testy

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

• Přidat testy
• Otevřít testy
• Změnit nadřazenou položku testu přetažením z jednoho uživatelského scénáře do jiného.
• Zkopírujte stejný test do jiného uživatelského příběhu pomocí CTRL+Přetáhnout/Pustit (pro případy, kdy stejný testovací případ testuje více než jeden uživatelský příběh).
• 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 celkového stavu, který ukazuje, kolik testů bylo splněno a kolik jich zbývá pro daný příběh.

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 části Přidání, spuštění a aktualizace vložených testů.

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

Teď se můžete snadno dostat k základnímu testovacímu plánu nebo testovací sadě, pod kterou byly testy vytvořeny, přímo z kartičky na tabuli 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.

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

Testovací stránka v konfiguraci sdíleného nastavení na tabuli 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 testy, které byly vytvořeny na kartě, byly automaticky přidány do nově vytvořeného testovacího plánu, pokud by neexistovaly žádné plány, které by odpovídaly oblastem a cestám iterace karty. Toto chování teď můžete přepsat tak, že nakonfigurujete libovolný existující testovací plán – všechny testy se přidají do vybraného testovacího plánu. Tato funkce je povolena, pouze pokud je zapnutá funkce poznámek k testům.

(Obrázek 77) Společná 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.

(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í. Musíte specifikovat okno prohlížeče, na kterém chcete zaznamenat své akce – všechny akce v tomto okně (jakékoli existující nebo nově otevřené karty v tomto okně) nebo veškerá nově otevřená podřízená okna prohlížeče se automaticky zaznamenají a porovnají s kroky testovanými v nástroji Web runner. 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 informace o systému automaticky zaznamenávají a zahrnují do každé chyby, kterou nahlásíte z aplikace Web Runner. Všechna popisovaná vylepšení využívají funkce rozšíření Test & Feedback prohlížeče Chrome.

(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 podané jako podřízené položky – Rozšíření pro Web Runner a Test & Feedback.

Při spouštění testů ve webovém testeru, spuštěného buď z karty na tabuli nebo ze sady založené na požadavku v Test Hubu, jsou všechny nové chyby automaticky vytvořené jako podřízené tomuto uživatelskému příběhu. Podobně když zkoumáte uživatelský příběh z rozšíření průzkumného testování, jakékoli nově zaznamenané chyby budou také vytvořeny jako podřízené tomuto příběhu. Toto nové chování umožňuje jednodušší sledovatelnost v rámci scénářů a chyb. To platí jen v případě, že v nastavení "Práce s chybami" na stránce společné konfigurace nastavení je zvoleno buď "Chyby se nezobrazují v backlozích ani na panelech" nebo "Chyby se zobrazují v backlozích a na panelech spolu s úkoly". 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ě.

(Obrázek 80) Přidat 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 buď přímo z pracovní položky, nebo z 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 pomocí možnosti Provádět 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.

(Obrázek 81) XT z pracovní položky

(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 zahrnutí obrázkového protokolu 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 připojilo jej k podanému hlášení chyby na stránce nastavení 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 obrázkový protokol 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í.

(Obrázek 83) XT 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 Vytváření testovacích případů

(Obrázek 84) XT Vytvoř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 průzkumné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í relace průzkumného testování 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í seskupení může být otočeno podle prozkoumaných pracovních položek, relací, vlastníků relací nebo žádného z nich. 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í detailního podokna, které zobrazuje informace na základě výběru v seskupeném pohledu. Pro vybraný kontingenční řádek (například prozkoumané pracovní položky) můžete v podokně podrobností zobrazit jeho souhrnné informace, jako je celkový počet relací, celkový čas strávený během těchto relací, vlastníci relací, kteří je prozkoumali, a chyby/úkoly/testy, které byly pro ně vytvořeny, 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.

(Obrázek 85) Přehled relací XT Session

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

Pracovní sezení zkušebního testování: Zobrazení neprozkoumaných pracovních položek

Kromě zobrazení podrobností o všech prozkoumaných pracovních položkách ve zobrazení „nedávné průzkumné relace“, filtrované na všechny/moje relace pro zadané časové období, jsme nyní přidali možnost zobrazit také seznam všech pracovních položek, které NEBYLY prozkoumány, ve stejném zobrazení (obrázek 86). Začněte zadáním sdíleného dotazu na pracovní položky, které vás zajímají, a na stránce relace se zobrazí seznam všech pracovních položek z dotazu s rozpisem prozkoumaných a neprozkoumaných položek v souhrnné části. Kromě toho můžete pomocí rozdělení "Neprozkoumaná pracovní položka" podle osy zobrazit seznam 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.

(Obrázek 86) Zobrazení neprozkoumaných WIT

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ář pro vyžádání zpětné vazby, 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.

(Obrázek 87) Tok zpětné vazby XT

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

Poskytnutí názorů

Úč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). Zainteresované strany mohou poté využít plné možnosti rozšíření k zachycení svých zjištění a odeslání zpětné vazby ve formě pracovní položky pro zpětnou vazbu, chyby nebo úkoly. 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í napsat svůj názor, můžou spravovat žádosti o zpětnou vazbu čekající na vyřízení (obrázek 88) tím, že je označí jako dokončené nebo je 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).

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

(Obrázek 89) XT tok zpětné vazby

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ětnou vazbu 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.

(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.

(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.

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

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

Doporučuje se používat prostředí vydaných verzí 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 míru úspěšnosti lze přejít na kartu Testy a analyzovat neúspěšné testy v daném prostředí.

(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í. Nyní si můžete prohlédnout historii testu napříč různými větvemi, na kterých probíhá, kliknutím na záložku 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.

(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í.

(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 je povoleno pomocí zaškrtávacího políčka v úkolu, jak je uvedeno níže.

(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).

(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 a zobrazit podrobnosti bran kvality. Poté se můžete rozhodnout přerušit proces sestavení, pokud nebudou splněny požadované podmínky.

(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).

(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ů.

(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 poskytovateli podpory zabezpečení NTLM a Negotiate pro ověřování Windows. 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 nejde 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 jde o významnou změnu pro naše uživatele a že na funkci stále probíhají úpravy, rozhodli jsme se nové uživatelské prostředí navigace ve výchozím stavu deaktivovat. Pokud ho chcete vyzkoušet, můžete ho povolit v oblasti pro správu Team Foundation Serveru výběrem možnosti zapnutí nové navigace. Mějte na paměti, že to povolí všem uživatelům 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.

Nastavení správce: Centrum práce

Na stránce Nastavení správy jsme zavedli nové centrum Práce, které kombinuje obecná nastavení (obrázek 101), iterace a oblasti na jedné kartě. Díky této změně uvidí uživatelé jasné rozdíly mezi nastavením na úrovni projektu a nastavením 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.

(Obrázek 101) Centrum pro administrativní práci

Konfigurace procesů - rozhraní REST API

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 „story pointy“ 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í zjistit, jak využít pole specifická pro proces k umožnění běžných scénářů v agilních nástrojích (například změnou aktivity nebo úsilí pracovní položky, zjištěním, které pracovní položky jsou zahrnuty na dané úrovni backlogu, nebo určením, zda jsou týmy identifikovány cestou oblasti nebo vlastním polem). Další informace najdete v tématu Přehled práce.

Nové prostředí pro správce s hledáním ve službě Active Directory podle předpony

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 samanázevúčtu (například „podniková doména\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).

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

(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 jste mohli použít 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ředprodukční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 Visual Studio Enterprise přidanou do portálu pro správu úrovní přístupu v Team Foundation Server můžete nyní rychle identifikovat, kdo má předplatné 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

Můžete se teď připojit k libovolnému serveru Team Foundation Server kromě připojení SSH také pomocí osobního přístupového tokenu. 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í.

---

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.

• Náhradní ř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. Bohužel Process Template Editor nebyl integrován, ale můžete ho získat v Visual Studio Marketplace.

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

• Problém:

  Schéma polí ve formuláři pracovní položky se změnilo. Změnila se i dokumentace rozšíření vlastního ovládacího prvku.

• Alternativní řešení:

  Podívejte se do nové dokumentace: Přidání vlastního ovládacího prvku do formuláře pracovní položky.

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í následující 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.

  <packageSources><add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3">
  </packageSources>

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

• Problém:

  Při použití Team Foundation Serveru / Správy balíčků se úkoly sestavení a vydání NuGet neověří vůči zdrojům, pokud je agent spuštěn jako uživatel NETWORK SERVICE, což je výchozí nastavení, když 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í.

• Řešení:

  Pro použití úloh sestavení a vydání NuGet 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 ztrátu 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 nastavení verze se uživatelům zobrazí chyba 500 serveru.

• 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 své serverové pluginy pro sestavení 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.

• Řešení problému:

  • 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ávy 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ů v týmovém sestavení a správě verzí pomocí úkolů 'Nasazení agenta pro testy Visual Studio' a 'Spuštění funkčních testů' z katalogu úloh se momentálně používá Agents for Visual Studio 2015 Update 3 a lze je použít pouze ke spuštění testů, které byly vytvořeny v prostředí 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í:

  Nejde to nijak změnit. 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í:

  Tento problém aktuálně nemá ř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.

Podívejte se na problémy nahlášené uživateli Team Foundation Serveru 2017.

---

Návrhy a názory

Rádi uslyšíme váš názor! Na portálu Komunita vývojářů můžete navrhnout funkci a nahlásit a sledovat problém. Rady můžete získat na webu Stack Overflow.

---

Na začátek stránky