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

---

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|

---

---

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 team foundation serveru.

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í agility
• Vylepšení řídicích panelů a widgetů
• Vylepšení úložiště 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áci nad kódem

Podrobnosti najdete v tématu Hledání v celém kódu.

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

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

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

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

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.

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

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.

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) . Stačí jednoduše zrušit 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.

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 většina uživatelů 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í.

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

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

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

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.

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

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

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

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 z rozevíracího seznamu 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 Členové týmu byl aktualizován, aby usnadňoval přidání dalších členů týmu (obrázek 18) .

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.

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

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.

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.

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

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. V zobrazení Soubory teď můžete přesně vidět, co se změnilo při každém odeslání nového kódu do žádosti o přijetí změn. 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.

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.

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.

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

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ší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 s komentářem na řádku 13 (obrázek 27) :

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

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 k ochraně svých 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í sestavení, aby mohli 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) .

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

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

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

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, jestli se potvrzené změny promítly do sestavení 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 žá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í, žádost o přijetí změn, která ho vytvořila). Pokud vaše změny dosáhly hlavní verzi, objeví se odkaz na větev potvrzující, že změny byly zahrnuty.

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 celý obsah těchto velkých souborů jednoduše kliknutím na soubor v ú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ěr neúplných řádků.

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

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

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

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

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.

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

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

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.

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.

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

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

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

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

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

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

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

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

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

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.

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

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.

Některou 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).

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

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

Další podrobnosti najdete v dokumentaci k [aliasu 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ž 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) .

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 tak, aby spouštěla skripty SQL pro Azure SQL Database. Skripty můžou být ve formě souboru nebo vložené v úloze.

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

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.

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

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 a počkat, až se zásada spustí a sníží úložiště využívané výsledky testů, aby byl upgrade TFS rychlejší. Po instalaci sady TFS, ale před upgradem instance sady TFS můžete k vyčištění výsledků testů použít TFSConfig.exe nástroj . 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 konfigurace zásad uchovávání testů najdete v tématu Uchovávání dat výsledků testů s Team Foundation Serverem 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é 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 testování.

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

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

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

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

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

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

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

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

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.

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.

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.

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

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.

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

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.

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

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.

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.

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í průzkumného testování, 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, že se chyby se nezobrazují v backlozích ani na panelech nebo že se chyby 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ě.

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

• V rámci rozšíření (Obrázek 82): Vyhledejte pracovní položku z relace XT a pak ji přidružte k probíhající relaci.

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.

Záznam obrazovky jako video: Pomocí rozšíření 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 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í.

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

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

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

Relace průzkumného testování: Zobrazení neprozkoumaných pracovních položek

Kromě toho, že je možné v zobrazení posledních relací průzkumného testování zobrazit všechny podrobnosti o prozkoumaných pracovních položkách s filtrem na všechny/vlastní relace v daném časovém rozsahu, 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žka 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.

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.

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

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.

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.

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.

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 rychlost průchodu lze přejít na kartu Testy a prozkoumat testy, které v daném prostředí selhaly.

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.

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

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.

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

Spuštění

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.

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

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

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 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 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 Serveru výběrem možnosti zapnutí nové navigace. Je třeba upozornit, že se tím navigace povolí 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.

Správa

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.

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

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

---

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

• 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 oznamující, že atribut LayoutMode není deklarovaný.

• 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ů nedojde k ověření úkolů sestavení 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í:

  • Možnost 1: Klikněte na uzel Všechna upozornění a nastavte zobrazení filtru 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.

  • Možnost 2: 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ů 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 ke 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.

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

---

Návrhy a názory

Chceme znát 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.

---

Začátek stránky