Poznámka
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Komunita vývojářů | Požadavky na systém a kompatibilitu | Licenční podmínky | TFS DevOps Blog | SHA-1 hash | Nejnovější poznámky k vydání Visual Studio 2019
Poznámka:
Pokud jste na tuto stránku přešli z neanglické jazykové verze a chcete zobrazit nejaktuálnější obsah, navštivte tuto zprávu k vydání verze v angličtině. Jazyk této stránky můžete změnit kliknutím na ikonu zeměkoule v zápatí stránky a výběrem požadovaného jazyka.
V tomto článku najdete informace o Team Foundation Serveru 2018. Klikněte na tlačítko pro stažení.
Další informace o Team Foundation Serveru 2018 najdete na stránce Požadavky pro Team Foundation Server a jeho kompatibilita. Další produkty TFS 2018 si můžete stáhnout z webu visualstudio.com/downloads.
Další informace najdete na stránce o instalaci TFS.
Datum vydání: 15. listopadu 2017
Shrnutí novinek v TFS 2018
Do Team Foundation Serveru 2018 jsme přidali spoustu nových vylepšení. Mezi nejzajímavější z nich patří:
- Vylepšili jsme průvodce vytvořením projektu a správce šablon procesů na webu.
- Teď můžete přizpůsobovat záhlaví formuláře pracovní položky.
- Optimalizovali jsme mobilní verzi formuláře pracovní položky.
- Přidali jsme podporu forků Git.
- Můžete spravovat masivní úložiště Git pomocí GVFS
- Můžete zobrazovat, filtrovat a nastavovat zabezpečení značek Git.
- Do úprav webového kódu jsme přidali minimapu souboru, párování závorek a přepínání prázdných znaků.
- Provedli jsme mnoho vylepšení pull requestů.
- Máme nové vylepšené prostředí wiki.
- Přidali jsme podporu pro balíčky Maven.
- Můžete importovat a exportovat a pozastavit definice sestavení.
- Nový editor definic vydaných verzí je standardně povolen.
- Nasazení můžete provádět pomocí nasazení virtuálních počítačů.
- Vylepšili jsme sledovatelnost nahodilého testování.
- Přidali jsme dávkování testů.
- Teď si můžete zobrazit widget pro grafy pro testovací plány a testovací sady.
Co je nového v TFS 2018 – video
Sestavení XAML
Původně jsme sestavení XAML uvedli jako odebrané z verze TFS 2018 RTW a Update 1. Následkem toho ale příliš mnoho zákazníků nemohlo provést upgrade nebo muselo po dokončení upgradu žádat podporu o opětovné povolení. Ve verzi TFS 2018 Update 2 je sestavení XAML povolené, ale označené jako zastaralé. To znamená, že do sestavení XAML nebudeme nadále investovat a Microsoft Test Manager už nepodporuje použití sestavení XAML. Důrazně doporučujeme převod na jeden z novějších formátů build definice. Ve verzi TFS 2018 Update 2 se můžete nadále připojovat ke kontrolerům XAML a spouštět sestavení XAML. Další informace
Funkce odebrané ve verzi TFS 2018 RTW
- Odebrali jsme podporu centra testovacích prostředí a toků automatizovaného testování z Microsoft Test Manageru.
- Ukončili jsme rozšíření TFS pro SharePoint.
- Odebrali jsme funkci týmové místnosti.
Podrobnosti o novinkách v TFS 2018
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 v tom, že webová verze nezřizuje vaše 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ě.
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ž se v sadě Visual Studio 2017, Update 4 a starších, stále zobrazuje dialogové okno Správce šablon procesů, 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ůsobte 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í. To umožní nahradit Oblast cesty vlastním polem Tým, skrýt Iteraci, pokud se vaše týmy zaměřují více na kanban, a nahradit Důvod vlastním polem. Pole Stav skrýt ani nahradit nejde.
Tip
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 a které jste nedávno navštívili nebo upravili.
Spolu s pěkným vzhledem prostředí podporuje optimalizované ovládací prvky pro všechny typy polí (obrázek 2).
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.
Filtrování backlogů, Kanban desek, sprintů a dotazů
Všechna prostředí pro sledování pracovních položek v mřížce (dotazy, backlogy, Kanban desky, backlogy sprintů a správu testovacích případů) nyní využívají naši jednotnou a konzistentní filtrační komponentu (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.
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.
Po kliknutí na dvojitou šipku dolů v dolní části karty můžete pole aktualizovat (obrázek 6).
Rozšíření blokují ukládání pracovních položek
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 doručovacích plánů
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 plánů dodávek(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í.
Správa verzí
Vidlice
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 commitují 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ě.
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). To nahrazuje rozšíření Správa složek, které bude nyní vyřazeno z používání.
Chcete-li vytvořit složku, klikněte buď v příkazovém panelu, nebo v místní nabídce na Nová složka>.
V TFVC zadáte název složky a pak ji odevzdáte. 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.
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).
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).
Přepínání zobrazení mezer
Nyní můžete při prohlížení nebo úpravách souboru přepínat zobrazení mezer. Stále vyvíjíme funkci, která vám umožní nastavovat viditelnost prázdných znaků při porovnávání. 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 Přepnout zobrazení prázdných znaků, což vám umožní rozlišovat mezi mezerami a tabulátory.
Nastavení vypnutí webových úprav úložiště TFVC
Týmy, které používají TFVC, často využívají zásady odevzdání ve Visual Studio, aby zajistily kvalitu kódu. Vzhledem k tomu, že se zásady pro odevzdávání změn vynucují v klientovi, kód upravovaný na webu nepodléhá stejným zásadám.
Několik lidí požadovalo možnost zakázat webové úpravy, aby zabránili změnám, které obcházejí zásady kontrolních bodů. 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.
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).
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 commity 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).
Vyhledání odstraněné větve a její nové vytvoření
Když větev omylem odstraníte 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í. Vrátí všechny existující větve, které odpovídají dané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).
Pokud se najde shoda, zobrazí se, kdo to vymazal a kdy. Větev můžete také obnovit (Obrázek 18).
Obnovením větve ji znovu vytvoříte v revizi, na kterou 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 zjistit, jestli se commit dostal do všech větví s předponou „dev“, zadejte jednoduše do vyhledávacího pole „dev“ a zvolte Hledat ve větvích začínajících na: dev(Obrázek 19).
Rozsáhlejší zvýraznění pull requestů na stránce podrobností commitu
Upozornění na žádost o přijetí změn na stránce podrobností potvrzení zobrazuje relevantnější informace, abyste mohli lépe diagnostikovat (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.
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 dané složky a při filtrování podle názvu souboru zobrazuje sbalenou stromovou strukturu souboru, aby jasně zobrazoval jeho hierarchii.
Vyhledání filtru pro soubory nebo složky ve stromu potvrzení (Obrázek 21) a (Obrázek 22):
Stránka Aktualizace větví je nyní Stránka Push
Stránka Aktualizace větví má obrovskou hodnotu. Byla ale skrytá v podobě pivotu v centru Historie. Stránka s aktualizacemi větví je nyní viditelná jako centrum s názvem Push(Obrázek 23) v části Kód spolu s Committy, větvemi, značkami a žádostmi o přijetí změn. Nová adresa URL pro stránku nasazení je: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. Staré adresy URL budou i nadále fungovat.
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 lidé obtížně řeší problémy související s commity, protože zobrazení seznamu commitů zobrazovalo podrobný čas pouze po najetí myší. 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.
Zachování názvu souboru při přechodu ze souborů do sekce Commits
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 25) si můžete zobrazit všechny značky v úložišti. Pokud spravujete všechny značky jako verze, může uživatel navštívit stránku značek a získat celkový přehled všech verzí produktu.
Rozdíl mezi lehkou a anotovanou značkou snadno rozpoznáte. 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 že jste označili nesprávný commit. 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).
Varování
Značky byste měli ze vzdálených úložišť odstraňovat obezřetně.
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).
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).
Tip
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ší. Při dokončování žádosti o přijetí změn teď 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. Udělá se to za vás automaticky.
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.
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).
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).
Filtr odpovídá libovolné části cesty k souborům v žádosti o přijetí změn, takže můžete vyhledávat podle názvů složek, částečných cest, názvů souborů nebo přípon (Obrázek 33).
Další možnosti filtrování komentářů k pull requestům
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.
Zobrazit původní rozdíl komentářů ke kódu v podrobnostech pull requestu
Někdy je těžké vyznat se v komentáři k pull requestu, když se změní kód, na který komentář odkazuje (často po provedení požadované změny) (Obrázek 35).
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).
Sbalitelné komentáře k pull requestům
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).
Když skryjete komentáře (Obrázek 38), skryjete je ve stromovém zobrazení a sbalíte vlákna komentářů v zobrazení souborů:
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 nápovědným bublinám(Obrázek 39) se můžete rychle podívat na komentář, aniž byste museli zobrazovat celé vlákno.
Seznamy úloh v popisech pull requestů a komentářích
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).
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.
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.
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.
Podpora filtrování tras 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 Git push nebo Git pull žádostech uvidíte novou možnost filtrovat oznámení podle cesty ke složce (Obrázek 44).
Aktualizované e-mailové šablony pro pracovní postupy pull requestů
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 teď začíná 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 recenzenti, soubory a commity, jsou uvedeny níže v e-mailu.
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.
Aktualizované e-mailové šablony pro push oznámení
Push oznámení byla aktualizována, aby odpovídala novým e-mailovým šablonám, které jsou optimalizované tak, aby byly jasné, stručné a vyžadovaly akci (Obrázek 47). Řádek předmětu pomáhá jasně rozlišit push e-maily, identifikovat větev, úložiště a autora a shrnout počet potvrzených změn zahrnutých v pushi. 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. Specifické pro push upozornění je, že obsahují podrobnosti o úložišti, větvi, souborech a commitech, které pomáhají informovat příjemce o rozsahu změn. Hlavní výzva k akci v upozorněních na push je View Push (Zobrazit push). Tím se otevře zobrazení push pro konkrétní push, který upozornění vygeneroval.
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.
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)
- Podpora značek HTML v markdownu (Obrázek 50).
- Pohodlná změna velikosti obrázků ve složce markdownu (Obrázek 51).
- 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).
- Offline aktualizace Wiki pro pokročilé uživatele.
Tip
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).
Vytvoření stránky wiki z nefunkčního odkazu
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.
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í zastaralé. 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.
Nyní můžete skrýt odstraněné verze balíčků (Obrázek 56) od všech uživatelů kanálu. Už žádné přeškrtnuté balíčky!
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.
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ód 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ů.
Nová jednotná úloha NuGet
Zkombinovali jsme úlohu obnovení NuGetu, nástroje 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).
Tip
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 povolení 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, jestli 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áme výběrový nástroj, který vám umožní zvolit si informační kanál, a poté vygeneruje .npmrc s potřebnými přihlašovacími údaji, které využije 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).
Ú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. To zahrnuje následující:
- 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ů.
- 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 je snadno pochopitelné a použitelné.
- 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. Ztěžuje to spojování příkazů dohromady. Teď máte kontrolu nad cestou výstupního souboru.
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ů.
Nástroj pro výběr informačních kanálů VSTS/TFS
Vždy doporučujeme uložit konfigurační soubor (například NuGet.Config, .npmrc atd.) do zdrojového úložiště, aby bylo zaznamenáno, 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).
Sestavení a vydaná verze
Sestavení XAML
V TFS 2015 jsme představili webový a víceplatformový systém sestavení. Sestavení XAML nejsou podporovaná ve verzi TFS 2018 RTW ani Update 1, ale ve verzi TFS 2018 Update 2 jsme je znovu povolili. Doporučujeme vám převést svoje sestavení XAML. Pokud ještě nejste na migraci připravení a potřebujete i nadále používat sestavení XAML, upgradujte prosím na verzi TFS 2018 Update 2.
Při upgradu na verzi TFS 2018 RTW nebo Update 1:
Pokud máte v kolekci týmových projektů data sestavení XAML, zobrazí se vám upozornění na odebrání funkcí sestavení XAML.
Můžete zobrazit dokončená sestavení XAML, ale nebudete moct zařazovat do fronty nová.
V TFS 2018 neexistuje nová verze kontroleru ani agenta sestavení XAML.
Při upgradu na verzi TFS 2018 Update 2:
Pokud máte v kolekci týmových projektů data sestavení XAML, zobrazí se vám upozornění na zastarání funkcí sestavení XAML.
K úpravě definic sestavení XAML nebo zařazení nových sestavení XAML do fronty musíte použít nástroje jako Visual Studio nebo Team Explorer 2017.
Pokud potřebujete vytvořit nové agenty sestavení XAML, budete je muset nainstalovat pomocí instalačního programu agenta sestavení TFS 2015.
Tip
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.
Exportovat a importovat definice 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. Šlo o jednu z deseti nejčastějších žádostí na UserVoice.
S radostí vám oznamujeme, že máte k dispozici (Obrázek 63) a (Obrázek 64).
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" } }
Úplný příklad najdete na stránce 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á zastaralé úlohy (Obrázek 65), umístíme tyto úlohy na konec a seskupíme je do sbalitelného oddílu, který je ve výchozím nastavení 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.
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 úlohy ukáže správný směr jak z katalogu úloh, tak i existujících definic sestavení nebo vydané verze.
Umožněte přispěným sekcím řídit viditelnost oddílu
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 skupin 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 funkce byla vyvinuta a upřednostněna na základě souvisejících návrhů týkajících se proměnných pro sestavení a vydání na úrovni projektu, stejně jako 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).
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.
Tip
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 využívají vydanou verzí a nasazují se do prostředí. Rozložení a propojení prostředí odráží nastavení aktivační události definované pro jednotlivá prostředí.
Uživatelské rozhraní pro konfiguraci v rámci 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).
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 úlohy hlouběji zkoumat (Obrázek 70).
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. 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.
Vylepšený editor úloh a fází
Všechna vylepšení v novém editoru definic buildů jsou teď dostupná také v editoru definic vydání (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.
Záložky Skupiny proměnných, Uchovávání a Možnosti
Teď můžete propojit nebo zrušit propojení se skupinami proměnných (obrázek 73), nastavit zásady uchovávání informací pro jednotlivá prostředí a upravit nastavení na úrovni definice vydané verze, jako je formát čísla vydané verze, na kartě Možnosti . Prostředí můžete také uložit jako šablonu nasazení, nastavit oprávnění na úrovni prostředí a fáze opětovného řazení na kartě Úkoly .
Operace na úrovni prostředí můžete využít k ukládání jako šablon a k nastavení zabezpečení (Obrázek 74).
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.
Nasazování pomocí agenta spoléhá na stejné agenty pro 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í, jako je jediný počítač pro vývoj, kontrola kvality s více počítači a farma počítačů pro UAT a produkci. Také určují kontext zabezpečení pro vaše fyzická prostředí.
Můžete to použít na libovolném virtuálním počítači, ve kterém zaregistrujete našeho agenta. 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 budou jeho značky děděny automaticky.
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 se bude spouštět na jednotlivých počítačích, a také jak rychle nebo pomalu bude probíhat zavádění.
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).
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í build a release, a nyní jsme přepracovali stránky skupin nasazení, aby byly čistší 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í.
Pro cíl ve skupině nasazení můžete zobrazit souhrn, poslední nasazení a možnosti cíle (Obrázek 79). Můžete na cílovém objektu nastavit štítky a řídit, co se na každém cíli spouští. V následujících verzích přidáme podporu filtru pro skupiny 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).
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í verzování skupiny úloh můžete nyní vytvořit koncepty verzí skupiny úloh a současně nabízet stále stabilní verze těch nejdůležitějších konfigurací, dokud nebudete připraveni na přepnutí. Po vytvoření návrhu a několika iteracích můžete publikovat stabilní verzi a při publikování, v případě zásadní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 je tato hlavní verze ve fázi preview, zobrazí se i zpráva „vyzkoušet si to“. Pokud skupina úloh vyjde z verze Preview, definice, které ji používají, se automaticky aktualizují a posunou se podél tohoto hlavního kanálu (Obrázek 82).
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é. S importem/exportem skupiny úloh (Obrázek 83), stejně jako u definic verzí, můžete nyní exportovat jako soubor JSON a importovat tam, kam potřebujete. Povolili jsme také vnořené skupiny úloh, které se poprvé rozbalí při exportu.
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ě.
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).
Ří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 nasazovat pouze sestavení z konkrétních větví zdrojového kódu, spíše než při úspěchu jakéhokoli sestavení.
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 určit verze, které jsou nasazeny do jednotlivých prostředí, když jsou splněny podmínky spuštění nasazení (například úspěšné dokončení sestavení a vytvoření nové 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í.
Kromě toho se na stránce Shrnutí vydání(Obrázek 88) nyní otevře vyskakovací tip, který uvádí důvody pro všechna nasazení ve stavu „nespuštěno“ a navrhuje, jak nebo kdy se nasazení zahájí.
Aktivační mechanismy pro repozitáře Git jako artefaktový zdroj
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 spustit vydání, když provedete nový commit do úložiště. cs-CZ: Můžete také zadat větev v úložišti Git, pro kterou commity spustí uvolnění.
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í ve spouštěčích 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í do tohoto prostředí je spuštěno pouze v případě, že jsou všechny podmínky artefaktu úspěšně splněny.
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, která vyvolává libovolné obecné 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í.
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í Povoleno, Pokračovat při chybě, Vždy spustit a Časový limit.
Známka statusu vydání v centru kódu
Dnes, pokud chcete vědět, zda je commit nasazen do produkčního prostředí vašeho zákazníka, nejprve identifikujte sestavení, které využívá commit, a poté zkontrolujte všechna prostředí vydání, kam 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 commit nasazen do více definic verzí (s více prostředími), každá definice bude mít záznam v odznáčku, kde se pro každé prostředí zobrazuje stav (Obrázek 93). To vylepšuje sledovatelnost potvrzení kódu do nasazení.
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).
Vylepšení nabídky Build definice 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.
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í.
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).
Tip
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í:
- Už 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:
- Pomocí rozšíření SCVMM pro TFS se můžete připojit k serveru SCVMM, kde můžete vytvořit a spravovat virtuální počítače a spouštět pracovní postupy. Více podrobností najdete v části Jak provádět operace správy laboratoří v sestavení a uvolňování.
Automatizované testování:
- Už se nepodporuje:
- Pracovní postupy automatizovaného testování, které spoléhají na testovací kontrolér a testovací prostředí, jako je pracovní postup XAML pro sestavení, nasazení a testování, nebo na automatizované testy z testovacího plánu pomocí MTM, se už nepodporují.
- Doporučené alternativy:
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 explorativního testování u pracovních položek, propojení, iterací a oblastních cest
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 teď 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 zkoumání požadavků budou nyní propojeny s odkazem Testy <–> Testováno pomocí odkazu namísto odkazu Nadřazený <–> Podřízený , aby se testovací případy, které vytvoříte, automaticky přidaly do testovacích sad založených na požadavcích. Pracovní položky, které se vytvoří, aniž by se konkrétně zkoumaly jaké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).
Grafy trendů testů pro prostředí vydaných verzí a testovací běhy
Přidáváme podporu prostředí vydání ve widgetu Test Result Trend(Obrázek 99), abyste mohli sledovat stav 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í.
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řidání odkazu na existující chybu u neúspěšného testu
Při analýze výsledku testu na souhrnné stránce Build nebo Release, případně v centru Testování (Test hub), můžete nyní připojit 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.
Nahrát přílohy k testovacím běhům a testovacím výsledkům
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 testování ve Visual Studiu ve správě sestavení/vydání jsou k dispozici možnosti pro řízení toho, jak mají být testy seskupené (dávkované) pro efektivní provádění. Testy můžou být seskupené dvěma způsoby:
- Na základě počtu testů a agentů, kteří se účastní spuštění, se testy jednoduše seskupí do několika dávek specifikované velikosti.
- 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.
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).
Výsledky webového testu jsou k dispozici jako příloha výsledků testu (Obrázek 102). Toto lze stáhnout pro offline analýzu v aplikaci Visual Studio.
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.
Tip
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).
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 vzestup Slacku. 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.
Jak si stojíme?
Rádi uslyšíme 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.