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

Last Update: 22. 11. 2017

V tomto článku najdete informace týkající se nejnovější vydané verze Team Foundation Serveru 2018. Klikněte na tlačítko pro stažení.

Download the latest version of Team Foundation Server

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


Novinky ve verzi TFS 2018 – video


Zpětná vazba

Chceme znát váš názor. Na portálu Komunita vývojářů může nahlásit a sledovat problém. Rady můžete získat na webu Stack Overflow. Jako vždy, pokud máte nápady, co bychom měli upřednostnit, přejděte na UserVoice a přidejte svůj návrh nebo hlasujte pro některý z již existujících návrhů.


Datum vydání: 15. listopadu 2017

Souhrn: Aktualizace Team Foundation Serveru 2018

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

Funkce odebrané v této vydané verzi


Podrobnosti: Novinky v této verzi

Sledování pracovních položek

Průvodce vytvořením projektu na webu

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

Správce šablon procesů na webu

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

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

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

Další informace najdete v dokumentaci pro WebLayout a ovládací prvky.

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

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

Mobile work item query

(Obrázek 1) Dotaz na mobilní verzi pracovní položky

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

Mobile work item form

(Obrázek 2) Mobilní verze formuláře pracovní položky

Pomocí nové mobilní navigace (obrázek 3) mohou uživatelé přejít na libovolnou další část TFS, která je připravena pro použití v mobilních zařízeních, a zase se vrátit k plně desktopovému prostředí v případě, že potřebují pracovat s ostatními centry.

Mobile navigation

(Obrázek 3) Mobilní navigace

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

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

Filtering on query

(Obrázek 4) Filtrování dotazů

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

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

Hidden field

(Obrázek 5) Skryté pole na kartě Kanban

Po kliknutí na dvojitou šipku dolů v dolní části karty můžete pole aktualizovat (obrázek 6).

Update hidden field

(Obrázek 6) Aktualizace skrytého pole na kartě Kanban

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

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

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

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

Inline add on delivery plans

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

Správa verzí

Forky

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

Git forks

(Obrázek 8) Forky Git

GVFS

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

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

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

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

New folder option

(Obrázek 9) Možnost Nová složka

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

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

New file dialog

(Obrázek 10) Dialog Nový soubor

Minimapa souboru

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

File minimap

(Obrázek 11) Minimapa souboru

Párování závorek

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

Bracket matching

(Obrázek 12) Párování závorek

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

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

Toggle white space

(Obrázek 13) Přepínání prázdných znaků

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

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

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

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

Poznámka

Na úpravy souboru README na stránce přehledu projektu nemá tato akce vliv.

Turn off web editing

(Obrázek 14) Vypnutí webových úprav

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

Web editing not allowed dialog

(Obrázek 15) Dialog s informacemi, že webové úpravy nejsou povolené

Tuto funkci jsme vyvinuli na základě souvisejícího návrhu.

Identifikace zastaralých větví

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

Stale branches

(Obrázek 16) Zastaralé větve

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

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

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

Search for deleted branches

(Obrázek 17) Vyhledání odstraněných větví

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

Restore deleted branches

(Obrázek 18) Obnovení odstraněných větví

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

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

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

Search for a commit

(Obrázek 19) Vyhledání potvrzení

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

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

Pull request callout

(Obrázek 20) Žádost o přijetí změn – bublinový popisek

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

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

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

Find a file or folder

(Obrázek 21) Hledání souboru nebo složky

Filtered view

(Obrázek 22) Filtrované zobrazení ve stromu potvrzení

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

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

Pushes page

(Obrázek 23) Stránka Vložení

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

Commits page

(Obrázek 24) Stránka Potvrzení

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

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

Zobrazení značek Git

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

View Git tags

(Obrázek 25) Zobrazení značek Git

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

Odstranění značek Git

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

Upozornění

Značky byste měli ze vzdálených úložišť odstraňovat obezřetně.

Delete git tags

(Obrázek 26) Odstranění značek Git

Filtrování značek Git

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

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

Filter Git tags

(Obrázek 27) Filtrování značek Git

Zabezpečení značek Git

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

Git tag security

(Obrázek 28) Zabezpečení značek Git

Další informace o značkách Git si můžete přečíst na blogu Microsoft DevOps.

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

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

Complete linked work items

(Obrázek 29) Dokončení propojených pracovních položek

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

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

Reset votes setting

(Obrázek 30) Resetování nastavení hlasů

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

Reset votes in timeline

(Obrázek 31) Resetování hlasů na časové ose

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

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

Find file or folder in pull request

(Figure 32) Vyhledání souboru nebo složky v žádosti o přijetí změn

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

Find results

(Figure 33) Vyhledání výsledků

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

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

PR comment filtering

(Obrázek 34) Filtrování komentářů k žádostem o přijetí změn

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

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

View original diff

(Obrázek 35) Zobrazení původního rozdílu

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

Update badge

(Obrázek 36) Aktualizace odznáčku

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

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

Hide comments

(Obrázek 37) Skrytí komentářů

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

Collapsed comments

(Obrázek 38) Sbalené komentáře

Sbalené komentáře můžete snadno rozbalit kliknutím na ikonu na okraji a potom je snadno dalším kliknutím zase sbalit. Díky popisům (Obrázek 39) se můžete rychle podívat na komentář, aniž byste museli zobrazovat celé vlákno.

Collapsed comment tooltip

(Obrázek 39) Popis sbaleného komentáře

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

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

Task list toolbar

(Obrázek 40) Panel nástrojů Seznam úkolů

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

Task list

(Obrázek 41) Seznam úkolů

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

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

Like pull request comments

(Obrázek 42) Lajkování komentářů k žádostem o přijetí změn

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

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

Cancel auto-complete dialog

(Obrázek 43) Dialogové okno zrušení automatického dokončování

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

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

Path filtering for notifications

(Obrázek 44) Filtrování cesty u oznámení

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

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

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

Improved email template

(Obrázek 45) Vylepšená e-mailová šablona

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

Email call-to-action

(Obrázek 46) E-mailová výzva k akci

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

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

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

Push template

(Obrázek 47) Šablona pro vložení

Wiki

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

Wiki page

(Obrázek 48) Stránka wiki žádosti o přijetí změn

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

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

Title wiki

(Obrázek 49) Wiki názvu žádosti o přijetí změn

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

Wiki HTML tags

(Obrázek 50) Značky HTML wiki žádosti o přijetí změn

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

Image resize

(Obrázek 51) Změna velikosti obrázku žádosti o přijetí změn

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

Wiki menu

(Obrázek 52) Nabídka wiki žádosti o přijetí změn

Přečtěte si další informace o tom, jak začít s wiki.

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

Wiki revert button

(Obrázek 53) Tlačítko pro vrácení wiki žádosti o přijetí změn zpět

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

Create wiki page

(Obrázek 54) Wikistránka vytvoření žádosti o přijetí změn

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

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

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

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

Správa balíčků

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

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

Package URL

(Obrázek 55) Adresa URL balíčku žádosti o přijetí změn

Už žádné přeškrtávání balíčků! Na základě tohoto návrhu UserVoice jsme přidali funkci, která vám umožňuje skrýt odstraněné verze balíčků (Obrázek 56) ze zobrazení všech uživatelů informačního kanálu.

Hide deleted packages

(Obrázek 56) Skrytí odstraněných balíčků

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

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

Last pushed column

(Obrázek 57) Sloupec Naposledy vloženo

Balíčky Maven

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

Maven packages

(Obrázek 58) Balíčky Maven

Nová jednotná úloha NuGet

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

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

Nuget task

(Obrázek 59) Úloha NuGet

Přečtěte si více o použití nejnovějšího balíčku NuGet ve vašem buildu na blogu Microsoft DevOps.

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

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

Aktualizace úlohy sestavení npm

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

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

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

dotnet task

(Obrázek 60) Úloha dotnet

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

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

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

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

Práce mimo účet nebo kolekci

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

Feeds to use

(Obrázek 61) Informační kanál, který se má použít

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

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

Feed picker

(Obrázek 62) Výběr informačního kanálu

Sestavení a vydaná verze

Odebrání podpory sestavení XAML

V TFS 2015 jsme představili webový a víceplatformový systém sestavení. V TFS 2018 se jedná o jediný model, který podporujeme. Sestavení XAML se v TFS 2018 nepodporují. Doporučujeme, abyste migrovali svoje sestavení XAML. Pokud ještě nejste na migraci připraveni a potřebujete i nadále používat sestavení XAML, neměli byste upgradovat na TFS 2018.

Při upgradu na TFS 2018:

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

  • V TFS 2018 si budete moci zobrazit celá sestavení XAML, ale nebudete moci zařazovat do fronty nová.

  • TFS 2018 neobsahuje žádnou novou verzi kontroleru ani agenta sestavení XAML a není možné nakonfigurovat starší verzi kontroleru nebo agenta sestavení XAML, aby fungovala s TFS 2018.

Vysvětlení našeho plánu pro vyřazení sestavení XAML najdete v blogovém příspěvku Rozvoj funkcí pro automatizaci sestavení TFS/Team Services.

Export a import definic sestavení

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

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

Export build definition

(Obrázek 63) Export definice sestavení

Import build definition

(Obrázek 64) Import definice sestavení

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

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

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

Celý příklad najdete tady: https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

Tip

Tuto funkci můžete využít k nabízení a sdílení stejné vlastní šablony ve všech svých týmových projektech.

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

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

"deprecated": true

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

Deprecated task badge

(Obrázek 65) Odznáček vyřazené úlohy

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

Deprecated task description

(Obrázek 66) Popis vyřazené úlohy

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

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

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

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

Podpora skupiny proměnných

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

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

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

Secure files library

(Obrázek 67) Knihovna zabezpečených souborů

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

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

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

Pozastavení definic sestavení

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

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

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

Další informace o cílech a využití najdete na stránce úložiště úloh VSTS.

Nový editor definic vydané verze

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

Vizualizace kanálu

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

Pipeline

(Obrázek 68) Kanál vydaných verzí

Uživatelské rozhraní pro konfiguraci v kontextu

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

Release configuration

(Obrázek 69) Konfigurace vydané verze

Začínáme se šablonami nasazení

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

Deployment templates

(Obrázek 70) Šablony nasazení

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

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

Simplified management of variables

(Obrázek 71) Zjednodušená správa proměnných

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

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

Task editor

(Obrázek 72) Editor úloh

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

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

Variable groups

(Obrázek 73) Skupiny proměnných

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

Environment menu

(Obrázek 74) Nabídka prostředí

Další informace najdete v dokumentaci pro editor definic vydané verze.

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

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

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

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

Deployment groups

(Obrázek 75) Skupiny nasazení

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

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

Configure deployment groups

(Obrázek 76) Konfigurace skupin nasazení

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

Deployment group progress

(Obrázek 77) Průběh skupiny nasazení

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

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

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

Deployment groups UI

(Obrázek 78) Uživatelské rozhraní skupin nasazení

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

Deployment groups UI tags

(Obrázek 79) Značky uživatelského rozhraní skupin nasazení

Odkazy na skupinu úloh

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

Task group references

(Obrázek 80) Odkazy na skupinu úloh

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

Správa verzí skupiny úloh

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

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

Save as draft

(Obrázek 81) Uložení skupiny úloh jako konceptu

Publish task group as preview

(Obrázek 82) Publikování skupiny úloh jako verze Preview

Import a export skupiny úloh

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

Export task group

(Obrázek 83) Export skupiny úloh

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

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

Multi configuration of agentless tasks

(Obrázek 84) Více konfigurací úloh bez využití agentů

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

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

Manual intervention task

(Obrázek 85) Úloha ručního zásahu

Manual intevention pending dialog

(Obrázek 86) Dialog ručního zásahu čekajícího na vyřízení

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

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

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

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

Deployment conditions dialog

(Obrázek 87) Dialog podmínek nasazení

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

Release summary tip

(Obrázek 88) Tip k souhrnu vydané verze

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

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

Release triggers

(Obrázek 89) Aktivační události vydané verze

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

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

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

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

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

Branch filters

(Obrázek 90) Filtry větví

Vylepšení úloh na straně serveru

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

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

REST API task

(Obrázek 91) Úloha rozhraní REST API

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

Task control options

(Obrázek 92) Možnosti ovládání úloh

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

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

Release status badge

(Obrázek 93) Odznáček stavu vydané verze

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

Deployment options dialog

(Obrázek 94) Dialog možností nasazení

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

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

Add artifact

(Obrázek 95) Přidání artefaktu

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

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

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

Revert release definition

(Obrázek 96) Vrácení definice vydané verze zpět

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

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

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

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

Release notifications

(Obrázek 97) Oznámení o vydané verzi

Další informace najdete v příspěvku o správě oznámení o vydaných verzích.

Testování

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

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

Níže najdete dopad upgradu na TFS 2018:

Centrum testovacích prostředí:
  • Nadále se nepodporuje:
    • Testovací kontroléry není možné zaregistrovat v TFS za účelem vytváření a správy testovacích prostředí.
    • Všechny existující testovací kontroléry zaregistrované v TFS přejdou do režimu offline a existující testovací prostředí se zobrazí jako nepřipravené.
  • Doporučená alternativa:
Automatizované testování:
Manuální testování:
  • Všechny scénáře manuálního testování jsou stále plně podporovány. Přestože v TFS 2018 můžete manuální testování spustit pomocí MTM, nemůžete manuální testování spouštět pomocí testovacích prostředí.
  • Pro všechny scénáře manuálního testování důrazně doporučujeme používat centrum testování ve webové verzi TFS.

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

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

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

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

Test case filters

(Obrázek 98) Filtry testovacích případů

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

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

Test trend chart

(Obrázek 99) Graf trendu testu

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

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

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

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

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

Dávkování testů

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

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

Test batching

(Obrázek 100) Dávkování testů

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

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

Test selection

(Obrázek 101) Výběr testu

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

Test summary

(Obrázek 102) Souhrn testu

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

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

Příklad toho, jak to můžete použít společně se zátěžovým testem, najdete v průvodci zátěžovým testem aplikace v cloudu pomocí sady Visual Studio a VSTS.

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

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

Chart widget

(Obrázek 103) Widget pro vytváření grafů

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

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

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

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

Poznámka

Pokud upgradujete na TFS 2018 z předchozí verze nakonfigurované pro integraci s SharePointem, budete muset integraci s SharePointem po upgradu vypnout, jinak se vaše weby SharePointu TFS nepodaří načíst.

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

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

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

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


Na začátek stránky