Zpráva k vydání verze Team Foundation Serveru 2018 RC1

Last Update: 25. 9. 2017

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

Stáhnout nejnovější verzi Team Foundation Serveru

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


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í: 30. srpna 2017

Shrnutí: Aktualizace Team Foundation Serveru v TFS 2018 RC1

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

Souhrn: Novinky v této verzi

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. Prostředí 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.

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

Máme plně funkční a kompletní prostředí, které zahrnuje optimalizovaný vzhled a chování pracovních položek (obrázek 1) a poskytuje snadný způsob, jak můžete z telefonu pracovat s položkami, které máte přiřazené, které sledujete nebo které jste navštívili, případně které jste naposledy upravili.

Dotaz na mobilní verzi pracovní položky

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

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

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

Mobilní navigace

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

Filtrování dotazů

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

Skryté pole

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

Aktualizace skrytého pole

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

Správa verzí

Forky

TFS 2018 přidává podporu forků Git (obrázek 7). 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ě (obrázek 7). 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ě.

Forky Git

(Obrázek 7) Forky Git

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 potom na Správa verzí (obrázek 8). 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.

Vypnutí webových úprav

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

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

Dialogové okno s oznámením, že webové úpravy nejsou povoleny

(Obrázek 9) Dialogové okno s oznámením, že webové úpravy nejsou povoleny

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

Zastaralé větve

(Obrázek 10) 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 11).

Vyhledávání odstraněných větví

(Obrázek 11) Vyhledává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 12).

Obnovení odstraněných větví

(Obrázek 12) 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 například zobrazit, zda se potvrzení promítlo u všech větví s prefixem „dev“, zadejte jednoduše do vyhledávacího pole „dev“ a vyberte Hledat ve větvích začínajících: dev (obrázek 13).

Vyhledání potvrzení

(Obrázek 13) 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 14). 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.

Bublinový popisek žádosti o přijetí změn

(Obrázek 14) Bublinový popisek žádosti o přijetí změn

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 15) a (obrázek 16):

Vyhledání souboru nebo složky

(Obrázek 15) Vyhledání souboru nebo složky

Filtrované zobrazení

(Obrázek 16) 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. Nyní bude stránka aktualizací větví viditelná jako centrum s názvem Vložení (obrázek 17) v části Kód spolu s Potvrzeními, Větvemi, Značkami a Žádostmi o přijetí změn. Nová adresa URL stránky vložení je: <tfsserverurl>/<projectname>/_git/<reponame>/pushes. Staré adresy URL budou i nadále fungovat.

Stránka Vložení

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

Současně se centrum Historie přejmenovává na Potvrzení (obrázek 18), 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 stránky potvrzení je: <tfsserverurl>/<projectname>/_git/<reponame>/commits. Staré adresy URL budou i nadále fungovat.

Stránka Potvrzení

(Obrázek 18) 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ž 1 000 souborů. Kvůli tomu museli uživatelé načítat více souborů a filtrovat obsah, aby našli požadovaný soubor. To mělo vliv na produktivitu. Vývojáři běžně pracují ve stejném adresáři a při sledování změn se chtějí držet adresářů, v nichž pracují. Nyní se název souboru při přechodu mezi pivoty centra Kód zachová bez ohledu na počet souborů, které byly v potvrzení změněny. To znamená, že při hledání požadovaného souboru už nemusíte klikat na Načíst další.

Zobrazení značek Git

Na stránce Značky (obrázek 19) 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.

Zobrazení značek Git

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

Rozdíl mezi zjednodušenou a anotovanou značkou tady poznáte na první pohled, protože 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 20).

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

Odstranění značek Git

(Obrázek 20) 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ček 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 21).

Filtrování značek Git

(Obrázek 21) 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 22).

Zabezpečení značek Git

(Obrázek 22) 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ší. Nyní 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 23). 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.

Dokončení propojených pracovních položek

(Obrázek 23) 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, mohou nyní vyjádřit výslovný souhlas a resetovat hlasy při vložení nových změn (obrázek 24). Toto nové nastavení představuje možnost v rámci zásad, které vyžadují minimální počet revidujících.

Nastavení resetování hlasů

(Obrázek 24) Nastavení resetování 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 25).

Resetování hlasů na časové ose

(Obrázek 25) 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 26).

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

(Obrázek 26) 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 27).

Výsledky hledání

(Obrázek 27) Výsledky hledání

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í nyní komentáře stejné možnosti (Obrázek 28). Můžete si také vyfiltrovat jenom diskuze, do kterých jste se zapojili.

Filtrování komentářů k žádostem o přijetí změn

(Obrázek 28) 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 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 29).

Zobrazení původního rozdílu

(Obrázek 29) 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 30).

Odznáček aktualizace

(Obrázek 30) Odznáček aktualizace

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. Kontroloři si mohou komentáře jednoduše skrýt, aby je při první revizi nového kódu nerušily (Obrázek 31).

Skrytí komentářů

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

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

Sbalené komentáře

(Obrázek 32) 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 33) se můžete rychle podívat na komentář, aniž byste museli zobrazovat celé vlákno.

Popis sbaleného komentáře

(Obrázek 33) 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 34).

Panel nástrojů Seznam úloh

(Obrázek 34) Panel nástrojů Seznam úloh

Po přidání seznamu úloh (Obrázek 35) 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.

Seznam úloh

(Obrázek 35) Seznam úloh

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

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

Lajkování komentářů k žádostem o přijetí změn

(Obrázek 36) 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 37) 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ří kód kontrolují. 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.

Dialogové okno Zrušit automatické dokončování

(Obrázek 37) Dialogové okno Zrušit automatické 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 38).

Filtrování cesty u oznámení

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

Skvělé 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 39). Řá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.

Vylepšená e-mailová šablona

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

U většiny upozornění výzva k akci (Obrázek 40) 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.

E-mailová výzva k akci

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

Rozšiřitelnost stavu žádosti o přijetí změn

Používáním zásad větví můžete výrazně vylepšit kvalitu svého kódu. Tyto zásady jsou ale omezeny jenom na integrace, které nativně poskytuje VSTS. Pomocí nového rozhraní API stavu žádosti o přijetí změn a odpovídajících zásad větví se stejně jako nativní funkce VSTS mohou do pracovního postupu žádosti o přijetí změn zapojit i služby třetích stran.

Když služba zveřejní žádost o přijetí změn v rozhraní API stavu, zobrazí se žádost okamžitě v zobrazení podrobností žádosti o přijetí změn v novém oddílu Stav (Obrázek 41). V oddílu stavu se zobrazí popis a vytvoří se odkaz na adresu URL, kterou služba poskytla. Položky stavu také podporují nabídku akce (...), kterou je možné rozšířit o nové akce přidávané webovými rozšířeními.

Oddíl stavu žádosti o přijetí změn

(Obrázek 41) Oddíl stavu žádosti o přijetí změn

Stav samotný neblokuje dokončování žádosti o přijetí změn – to mají na starost zásady. Jakmile se zveřejní stav žádosti o přijetí změn, je možné nakonfigurovat zásady. V prostředí zásad větví je nová zásada, která vyžaduje schválení od externích služeb. Výběrem možnosti + Přidat službu zahajte proces (Obrázek 42).

Přidání nové zásady

(Obrázek 42) Žádost o přijetí změn – přidání nové zásady

V dialogovém okně vyberte ze seznamu službu, která zveřejňuje stav, a vyberte požadované možnosti zásady (Obrázek 43).

Nastavení zásady stavu

(Obrázek 43) Žádost o přijetí změn – nastavení zásady stavu

Jakmile je zásada aktivní, stav se zobrazí podle potřeby v oddílu Zásady v části Povinné nebo Nepovinné a vynutí se dokončení žádosti o přijetí změn (podle potřeby).

Další informace o rozhraní API stavu najdete v dokumentaci a ukázkách, kde si toto rozhraní můžete také vyzkoušet.

Wiki

Každý projekt teď podporuje vlastní wiki (Obrázek 44). 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.

Stránka wiki

(Obrázek 44) Žádost o přijetí změn – wikistránka

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 45) Wiki názvu

    (Obrázek 45) Žádost o přijetí změn – wiki názvu

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

Značky HTML wiki

(Obrázek 46) Žádost o přijetí změn –značky HTML wiki

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

Změna velikosti obrázku

(Obrázek 47) Žádost o přijetí změn – změna velikosti obrázku

  • Výkoný panel pro správu stránky, který 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 48).

Nabídka wiki

(Obrázek 48) Žádost o přijetí změn – nabídka wiki

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. Nyní můžete vrátit revizi wikistránky tak, že přejdete na podrobnosti revize a kliknete na tlačítko Vrátit (Obrázek 49).

Tlačítko pro vrácení wiki

(Obrázek 49) Žádost o přijetí změn – tlačítko pro vrácení wiki

Vytvoření wikistránky z poškozeného odkazu. Při vytváření wiki jsme vypozorovali, že lidé často nejdřív vytvoří na wikistránce obsah, který obsahuje neexistující odkazy (Obrázek 50). Potom kliknou na tyto odkazy a vytvoří skutečné stránky. Dříve jsme v takové situaci 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.

Vytvoření wikistránky

(Obrázek 50) Žádost o přijetí změn – vytvoření wikistránky

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 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 51). Formát je: <tfsserverurl>/<project|team>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package.

Adresa URL balíčku

(Obrázek 51) Žádost o přijetí změn – adresa URL balíčku

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

Skrytí odstraněných balíčků

(Obrázek 52) 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 53) s čitelnějším datem, abyste mohli snadno vyhledat naposledy aktualizované balíčky.

Sloupec Naposledy vloženo

(Obrázek 53) Sloupec Naposledy vloženo

Balíčky Maven

Spustili jsme podporu hostování artefaktů Maven v TFS 2018 (Obrázek 54)! 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ů.

Balíčky Maven

(Obrázek 54) 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 55).

Úloha NuGet

(Obrázek 55) Úloha NuGet

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

Úloha dotnet

(Obrázek 56) Ú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 mimo server TFS nebo účet VSTS je nyní snazší, a to bez ohledu na to, zda 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 57). 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ů.

Informační kanály k použití

(Obrázek 57) Informační kanál k použití

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

Výběr informačního kanálu

(Obrázek 58) 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í plánu vyřazení sestavení XAML najdete v tomto příspěvku blogu.

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 nyní je vám k dispozici (Obrázek 59) a (Obrázek 60)!

Export definice sestavení

(Obrázek 59) Export definice sestavení

Import definice sestavení

(Obrázek 60) 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 61, 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.

Odznáček vyřazené úlohy

(Obrázek 61) 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 62). 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.

Popis vyřazené úlohy

(Obrázek 62) 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 63).

Knihovna zabezpečených souborů

(Obrázek 63) 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í:

Nový editor definic vydané verze

Výchozí výslovný souhlas: Nový editor definic vydané verze je standardně pro všechny povolen. Vaši správci TFS budou i nadále mít možnost tuto funkci vypnout tak, že v nabídce profilu přejdou na možnost Funkce ve verzi Preview. Další podrobnosti viz Funkce ve verzi Preview.

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

Vizualizace kanálu

Kanál (Obrázek 64) 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í.

Kanál

(Obrázek 64) Kanál vydané verze

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ď zasazeny do kontextu a dají se snadno konfigurovat (Obrázek 65).

Konfigurace vydané verze

(Obrázek 65) Konfigurace vydané verze

Začínáme se šablonami nasazení

Při vytváření prostředí se zobrazí seznam šablon (dodávaných i vlastních), abyste mohli snadno začít (Obrázek 66).

Šablony nasazení

(Obrázek 66) Šablony nasazení

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

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

Editor úloh

(Obrázek 67) Editor úloh

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

Na kartě Možnosti nyní můžete vytvořit propojení se skupinami proměnných (a také ho zrušit) (Obrázek 68), 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í.

Skupiny proměnných

(Obrázek 68) 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 69).

Nabídka prostředí

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

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

Skupiny nasazení

(Obrázek 70) 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 71). 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í.

Konfigurace skupin nasazení

(Obrázek 71) 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 72).

Průběh ve skupině nasazení

(Obrázek 72) Průběh ve skupině nasazení

Tato funkce nyní tvoří nedílnou součást Release Managementu. K jejímu použití se nevyžadují žádné další licence.

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. 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 nyní možnost zobrazit si definice sestavení a vydaných verzí a skupiny úloh, které odkazují na vaši skupinu úloh (Obrázek 73).

Odkazy na skupinu úloh

(Obrázek 73) 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 74).

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

Uložení jako konceptu

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

Publikování skupiny úloh jako Preview

(Obrázek 75) Publikování skupiny úloh jako 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 76) (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 skupiny úloh

(Obrázek 76) 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 77) teď můžete spustit stejnou sadu úloh ve fázi pro více konfigurací, které běží paralelně.

Více konfigurací úloh bez agenta

(Obrázek 77) Více konfigurací úloh bez agenta

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

Úloha Ruční zásah (Obrázek 78) 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 79).

Úloha Ruční zásah

(Obrázek 78) Úloha Ruční zásah

Dialogové okno s oznámením, že se čeká na ruční zásah

(Obrázek 79) Dialogové okno s oznámením, že se čeká na ruční zásah

Ří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í procedura v dialogovém okně prostředí Podmínky nasazení (Obrázek 80) vyberte podmínky artefaktů, například zdrojovou větev a značky pro sestavení, které aktivují nové nasazení do daného prostředí.

Dialogové okno Podmínky nasazení

(Obrázek 80) Dialogové okno Podmínky nasazení

Kromě toho se teď na stránce souhrnu vydané verze (Obrázek 81) 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.

Tip na stránce souhrnu vydané verze

(Obrázek 81) Tip na stránce souhrnu vydané verze

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

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

Aktivační procedury vydané verze

(Obrázek 82) Aktivační procedury 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í.

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

Úloha rozhraní REST API

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

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

Možnosti ovládání úlohy

(Obrázek 84) Možnosti ovládání úlohy

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 85). To vylepšuje sledovatelnost potvrzení kódu do nasazení.

Odznáček se stavem vydané verze

(Obrázek 85) Odznáček se stavem 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 86).

Dialogové okno možností nasazení

(Obrázek 86) Dialogové okno 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, což vám usnadní volbu požadované definice (Obrázek 87). Díky tomu snadněji rozlišíte stejný název definice sestavení, ale v různých složkách.

Přidání artefaktu

(Obrázek 87) 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. Nyní můžete pomocí funkce Původní definice (Obrázek 88) zvolit na kartě Historie definice vydané verze kteroukoli starší verzi definice a vrátit se k ní.

Původní definice vydané verze

(Obrázek 88) Původní definice vydané verze

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.

Upgrade na TFS 2018 bude mít vliv na následující funkce:

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

Filtry testovacích případů

(Obrázek 89) 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 90), 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í.

Graf trendu testů

(Obrázek 90) Graf trendu testů

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.

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.

Od teď už nebudeme podporovat integraci server-to-server a integraci budeme provádět pomocí veřejných rozhraní API a rozšiřujících architektur.

Pokud upgradujete server pomocí nakonfigurované integrace TFS/SharePoint, poskytujeme vám řešení pro jiný způsob upgradu bez integrace server-to-server. Vaše weby TFS SharePoint se budou po upgradu stále zobrazovat, ale funkce integrace nebudou dostupné. Další podrobnosti a pokyny najdete tady.

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.


Známé problémy

Služba TFS Database Import Service nepodporuje verze RC

Služba TFS Database Import Service pro službu Visual Studio Team Services nepodporuje importy z RC verzí TFS. Pokud máte v plánu importovat svou databázi kolekce do služby Team Services pomocí této služby, je důležité, abyste svou produkční databázi neupgradovali na tuto verzi RC. Pokud upgrade provedete, budete muset počkat a provést upgrade na verzi RTW této vydané verze nebo obnovit zálohu své databáze z předchozí verze TFS, abyste databázi mohli importovat.

Úloha Visual Studio Test v1 v sestavení nebo vydané verzi nemůže spouštět testy pomocí sady Visual Studio 2017 Update 3

Úloha Visual Studio Test v1 v sestavení nebo vydané verzi nemůže spouštět testy pomocí sady Visual Studio 2017 Update 3. Úloha se nezdaří s chybovou zprávou Nejde zjistit umístění souboru vstest.console.exe. Alternativním řešením je použití verze 2 úlohy Visual Studio Test.