Team Foundation Server 2018 Update 2 – zpráva k vydání verze
Komunita vývojářů | Požadavky na systém a kompatibilita | Licenční podmínky | Blog TFS DevOps | Hodnoty hash SHA-1 | | Nejnovější zpráva k vydání verze pro Visual Studio 2019
Poznámka
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 týkající se nejnovější vydané verze Team Foundation Serveru 2018. Klikněte na tlačítko pro stažení.
Další informace o Team Foundation Serveru 2018 najdete na stránce kompatibilita pro Team Foundation Server . Další produkty TFS 2018 si můžete stáhnout z webu visualstudio.com/downloads.
Od TFS 2012 a novějších verzí se podporuje přímý upgrade na Team Foundation Server 2018 Update 2. Pokud jste TFS nasadili na TFS 2010 nebo starší, musíte před upgradem na TFS 2018 Update 2 provést několik kroků. Další informace najdete v následujícím grafu a na stránce o instalaci TFS.
Důležité
Před upgradem na TFS 2018 Update 2 nemusíte upgradovat na TFS 2018 RTM.
Datum vydání 
: 7. května 2018
Nyní můžete upgradovat na TFS 2018 Update 2 a můžete se nadále připojovat ke kontrolerům XAML a spouštět sestavení XAML. Když jsme odebrali podporu sestavení XAML v sadě TFS 2018 RTW a Update 1, někteří z vás nemohli upgradovat z důvodu existence starších verzí sestavení XAML. Tuto překážku jsme odstranili. I když TFS 2018 Update 2 podporuje sestavení XAML pro vaše starší sestavení, je sestavení XAML zastaralé a nebudeme do něj již investovat. Proto velmi doporučujeme, abyste přešli na novější formát definice sestavení.
Shrnutí novinek v TFS 2018 Update 2
Do Team Foundation Serveru 2018 Update 2 jsme přidali spoustu nových vylepšení. Mezi nejzajímavější z nich patří:
- Zobrazení potvrzení sloučení žádosti o přijetí změn
- Pomoc revidujícím pomocí jmenovek žádostí o přijetí změn
- Zmínění žádosti o přijetí změn
- Oznámení komentářů žádostí o přijetí změn obsahují kontext vlákna
- Rozšiřitelnost stavu žádosti o přijetí změn
- Filtr vlastních polí a značek v oznámeních sledování pracovních položek
- Modernizované možnosti sloupce
- Přidaná podpora operátoru dotazu Není v
- Query for @MyRecentActivity and @RecentMentions
- Filtrování plánů
- Ověřování vydaných verzí
- Sestavení pomocí kontinuální integrace z GitHubu Enterprise
- Vylepšení vícefázových sestavení
- Přeskočení plánovaných sestavení, pokud se v úložišti nic nezměnilo
- Bezproblémové použití veřejných balíčků pomocí upstreamových zdrojů
- Zásady uchovávání v informačních kanálech TFS
- Filtrování při správě balíčků
- Hledání na wiki
- Odkazování pracovních položek na wiki
- Náhled obsahu při úpravě Wiki stránek
- Vložení formátovaného obsahu Wiki jako kódu HTML
- Profilové karty
- Kulaté avatary
Podrobnosti o novinkách v TFS 2018 Update 2
Podrobnosti o těchto funkcích najdete v příslušné oblasti:
Kód
Získání trvalého odkazu na kód
Při prohlížení souboru většinou vidíte verzi na vrcholu vybrané větve. Verze souboru na vrcholu se může s novými potvrzeními změnit. Když zkopírujete odkaz z tohoto zobrazení, můžou odkazy zastarat, protože adresa URL obsahuje jen název větve a nikoli hodnotu SHA potvrzení. Přepnutím zobrazení Soubor teď můžete snadno aktualizovat adresu URL tak, aby místo na větev odkazovala na potvrzení. Při stisknutí klávesy „y“ se zobrazení přepne na potvrzení na vrcholu aktuální větve. Pak můžete zkopírovat trvalé odkazy.
Obnovení nedávno odstraněného adresáře přes rozhraní API
Při čištění starých úložišť ve správě zdrojového kódu se někdy může přihodit chyba. Pokud bylo úložiště Git odstraněno během posledních 30 dnů, dá se obnovit přes rozhraní REST API. Další informace najdete v dokumentaci operací list a recover.
SSH: Podpora dalších šifer/klíčů a vyřazení zastaralých šifrování
Kvůli lepšímu zabezpečení a kompatibilitě jsme aktualizovali seznam šifer podporovaných pro SSH. V souladu se směrnicí OpenSSH jsme přidali dvě nové šifry a tři vyřadili. Vyřazené šifry budou v této verzi nadále fungovat. Budou odebrány později, jak se postupně přestanou používat.
Přidáno:
- AES128 CTR
- AES256 CTR
Vyřazeno:
- AES128
- AES192
- AES256
Zabránění přepisům a zachování výkonu pomocí nastavení úložiště
V této aktualizaci najdete dvě nová nastavení úložiště, která umožní bezproblémovou spolupráci s Gitem.
Case enforcement (Vynucení velikosti písmen) přepne server z výchozího režimu s rozlišováním malých a velkých písmen, kdy Soubor.txt a soubor.txt odkazuje na stejný soubor, do režimu podobného Windows a macOS, kdy Soubor.txt a soubor.txt jsou stejný soubor. Toto nastavení ovlivňuje soubory, složky, větve a značky. Zároveň přispěvatelům brání v nechtěném zanesení rozdílů spočívajících jen ve velikosti písmen. Vynucení velikosti písmen se doporučuje povolit, pokud většina přispěvatelů pracuje ve Windows nebo macOS.
Limit file sizes (Omezit velikost souborů) umožňuje zabránit, aby velikost nových nebo aktualizovaných souborů překročila nastavený limit. Čím větší množství velkých souborů existuje v historii úložiště Gitu, tím horší bude výkon operací klonování a načítání změn. Toto nastavení brání v nechtěném zanesení těchto souborů.
Vylepšená funkčnost filtru pro potvrzení s více než 1000 změněných souborů
Hledání souboru v potvrzeních nebo žádostech o přijetí změn, při kterých bylo změněno více než 1000 souborů, bylo neefektivní; museli jste několikrát kliknout na odkaz Načíst další, než jste našli hledaný soubor. Při filtrování obsahu ve stromovém zobrazení se teď soubor vyhledává ve všech souborech v rámci potvrzení, ne jen v prvních 1000 načtených souborech. Pokud je změněných více než 1000 souborů, má větší výkon také stránka s podrobnostmi potvrzení.
Hledání potvrzení ztracených kvůli vynucenému nasdílení změn
V Gitu můžete provést vynucené nasdílení změn a aktualizovat vzdálený odkaz, dokonce i když není nadřazeným prvkem lokálního odkazu. Kvůli tomu můžou ostatní ztratit změny a je velmi obtížné zjistit původní příčinu. V novém zobrazení nasdílených změn jsou vynucená nasdílení změn vidět, abychom vám pomohli řešit problémy spojené s chybějícími potvrzeními.
Kliknutím na značku vynuceného nasdílení změn se dostanete na odebrané potvrzení.
Příčina teď obsahuje historii
Zobrazení Blame (Příčina se skvěle hodí ke zjištění poslední osoby, která změnila řádek kódu. Někdy ale potřebujete vědět, kdo udělal předchozí změnu řádku kódu. Nejnovější vylepšení příčiny vám může pomoci – View blame prior to this commit (Zobrazit příčinu před tímto potvrzením). Jak název napovídá, umožňuje vám tato funkce vrátit se v čase k verzi souboru před verzí, která změnila konkrétní řádek, a zobrazit informace o příčině pro tuto verzi. Můžete se dál vracet v čase a prohlížet jednotlivé verze souboru, které změnily vybraný řádek kódu.
Přepnutí zalamování řádků a prázdných znaků v rozdílových zobrazeních
V rozdílovém zobrazení souborů jsou k dispozici dvě nové funkce: Toggle Word Wrap (Přepínání zalamování řádků) a Toggle White Space (Přepínání prázdných znaků). První umožňuje, aby se v rozdílovém zobrazení použilo nastavení zalamování řádků. To je zvlášť užitečné při zobrazení žádostí o přijetí změn obsahujících soubory bez častých konců řádků – dobrým příkladem jsou soubory Markdownu. Možnost přepnutí prázdných znaků oceníte, když se v řádku nebo souboru změnily jen prázdné znaky. Při přepnutí tohoto nastavení se v porovnání zobrazí a zvýrazní prázdné znaky (mezery, šipky tabulátorů apod. se nahradí tečkami).
Tato nastavení můžete spravovat tak, že v editoru žádosti o potvrzení změn nebo v rozdílovém zobrazení kliknete na ozubené kolo předvoleb editoru. V zobrazení Soubor vyberte v nabídce vyvolané kliknutím pravým tlačítkem možnost Uživatelské předvolby.
Můžete si vybrat různé funkce editoru, například Show and diff white space (Zobrazit a odlišit prázdné znaky), Enable word wrap (Povolit zalamování řádků), Enable code folding (Povolit skrývání kódu) a Show minimap (Zobrazit minimapu).
Skrývání kódu (v některých editorech označované jako „osnova“) je povolené také ve webovém zobrazení. Při povoleném skrývání kódu můžete kliknutím na znaménko minus sbalit a kliknutím na znaménko plus rozbalit sekce kódu. Na paletě příkazů F1 jsou zároveň přístupné možnosti pro skrytí různých úrovní odsazení v celém souboru, což usnadňuje čtení a revizi rozsáhlých souborů.
Sledování nasdílení změn do úložiště Gitu v sestaveních a vydaných verzích
Na stránce Pushes (Nasdílení změn) teď u potvrzení sloučení vidíte stav sestavení a vydané verze. Kliknutím na stav vedle nasdílení změn najdete konkrétní sestavení nebo vydanou verzi, jejíž je nasdílení změn součástí, takže můžete ověřit úspěšnost nebo prošetřit selhání.
Markdown vykreslený v e-mailových oznámeních
Markdown se skvěle hodí k doplnění formátování, odkazů a obrázků do popisů a komentářů žádostí o přijetí změn. V e-mailových oznámeních žádostí o přijetí změn se teď místo hrubého obsahu zobrazuje vykreslený markdown, což zlepšuje čitelnost.
Vložené obrázky se zatím nevykreslují jako vložené (zobrazují se jen jako odkazy), tento nedostatek ale máme v backlogu a vyřešíme ho v budoucnosti.
Provádění příkazů TFVC přímo z Průzkumníka Windows
Rozšíření TFVC prostředí Windows, které poskytuje zjednodušené prostředí pro správu verzí integrované do Průzkumníka souborů Windows, teď podporuje TFS 2018. Tento nástroj umožňuje pohodlný přístup k mnoha příkazům TFVC přímo z místní nabídky Průzkumníka Windows.
Tento nástroj, který byl dříve součástí nástrojů TFS Power Tools, byl vydán jako samostatný nástroj na webu Visual Studio Marketplace.
Kontrola nad tím, kdo může přispívat do žádostí o přijetí změn
Dříve mohl s žádostmi o přijetí změn pracovat každý, kdo viděl úložiště Gitu. Přidali jsme nové oprávnění s názvem Contribute to pull requests (Přispívat do žádostí o přijetí změn), které určuje přístup k vytváření a komentování těchto žádostí. Všem uživatelům a skupinám, které měly dříve oprávnění Číst, bude toto nové oprávnění standardně uděleno. Zavedení tohoto nového oprávnění poskytuje správcům flexibilitu a možnost kontroly. Pokud vyžadujete, aby skupina Čtenáři měla skutečně jen přístup ke čtení, můžete oprávnění Contribute to pull requests zakázat.
Další informace najdete v dokumentaci k rychlému startu nastavení oprávnění úložiště.
Oznámení komentářů žádostí o přijetí změn obsahují kontext vlákna
Odpovědi na komentáře žádostí o přijetí změn jsou často dost stručné a potvrzují, že změna bude nebo byla provedena. To není problém, když si tyto komentáře prohlížíte ve webovém zobrazení, pokud ale komentář čtete v e-mailovém oznámení, chybí kontext původního komentáře. Z jednoduchého „Opravím to“ nic nepoznáte.
Kdykoli teď vznikne odpověď na komentář žádosti o přijetí změn, budou e-maily s komentáři obsahovat v textu zprávy předchozí odpovědi. Účastníci vlákna tak uvidí úplný kontext komentáře přímo v doručené poště a nemusí si otevírat webové zobrazení.
Nastavení dokončení pracovních položek
Funkce pro dokončení pracovních položek při dokončení žádostí o přijetí změn teď obsahuje nové nastavení úložiště, kterým se řídí výchozí chování. Nové nastavení Remember user preferences for completing work items with pull requests (Pamatovat předvolby uživatele pro dokončování pracovních položek pomocí žádostí o přijetí změn) je standardně povolené a při dokončování budoucích žádostí o přijetí změn bude respektovat poslední stav uživatele. Pokud je toto nové nastavení zakázané, bude možnost Complete linked work items after merging (Po sloučení dokončit propojené pracovní položky) pro všechny žádosti o přijetí změn v úložišti standardně zakázaná. Při dokončování žádostí o přijetí změn se uživatelé přesto můžou rozhodnout k přechodu na propojené pracovní položky, budou tak ale muset učinit pokaždé.
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 omezené jen na integrace, které nativně poskytuje TFS. 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 TFS můžou 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. 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.
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.
V dialogovém okně vyberte ze seznamu službu, která zveřejňuje stav, a vyberte požadované možnosti zásady.
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.
Události sloučení volaných služeb žádosti o přijetí změn
Rozšíření využívající volané služby žádosti o přijetí změn teď obsahují více podrobností a možností filtrování pro události sloučení. Při každém pokusu o sloučení se tato událost aktivuje bez ohledu na úspěch nebo neúspěch sloučení. Pokud pokus o sloučení skončí neúspěšně, zobrazí se podrobnosti o příčině tohoto neúspěchu.
Vylepšené chybové zprávy pro pracovní položky dokončené pomocí žádosti o přijetí změn
Při pokusu o dokončení pracovních položek pomocí žádosti o přijetí změn je možné, že přidruženou pracovní položku nelze převést do dokončeného stavu. Určité pole může být například povinné a před přechodem stavu vyžaduje zadání od uživatele. Udělali jsme taková vylepšení, abyste byli informováni, pokud něco blokuje přechod pracovní položky, takže můžete učinit akci a provést nezbytné změny.
Zmínění žádosti o přijetí změn
Žádosti o přijetí změn teď můžete zmiňovat v komentářích žádostí a diskuzích pracovních položek. Zmiňování žádosti o přijetí změn se podobá zmiňování pracovní položky, místo mřížky # se ale používá vykřičník !.
Když chcete zmínit některou žádost o přijetí změn, zadejte !. Zobrazí se interaktivní výběr žádosti o přijetí změn ze seznamu nedávných žádostí. Zadáním klíčových slov můžete seznam návrhů filtrovat, nebo zadejte ID žádosti o přijetí změn, kterou chcete zmínit. Po zmínění se žádost o přijetí změn zobrazí na řádku s ID a úplným názvem a bude odkazovat na stránku s podrobnostmi žádosti o přijetí změn.
Pomoc revidujícím pomocí jmenovek žádostí o přijetí změn
Někdy je důležité revidujícím sdělit dodatečné informace k žádosti o přijetí změn. Žádost o přijetí změn může být v rozpracovaném stavu nebo se jedná o opravu hotfix pro nadcházející vydanou verzi, takže k názvu můžete připojit například text [ROZPRACOVÁNO] nebo [NESLUČOVAT]. Jmenovky teď umožňují označit žádosti o přijetí změn dodatečnými informacemi, které lze použít ke sdělení důležitých podrobností a organizaci žádostí o přijetí změn.
Komentáře žádostí o přijetí změn sledují přejmenované soubory
Někdy dojde k přejmenování nebo přesunutí souborů, zatímco je žádost o přijetí změn aktivní. Pokud byly dříve u těchto přejmenovaných souborů komentáře, při posledním zobrazení kódu se tyto komentáře nezobrazily. Sledování komentářů jsme teď vylepšili tak, že se přejmenování sledují a zobrazují se komentáře u posledních verzí přejmenovaných nebo přesunutých souborů.
Zobrazení potvrzení sloučení žádosti o přijetí změn
Rozdílová zobrazení žádostí o přijetí změn skvěle zvýrazňují změny zanesené do zdrojové větve. Změny v cílové větvi ale můžou způsobit, že rozdílové zobrazení vypadá jinak, než očekáváte. Teď je dostupný nový příkaz, který zobrazí rozdíl „náhledového“ potvrzení sloučení žádosti o přijetí změn – View merge commit (Zobrazit potvrzení sloučení). Toto potvrzení sloučení se vytvoří kvůli kontrole konfliktů při sloučení a použití se sestavením žádosti o potvrzení změn. Znázorňuje, jak bude potvrzení sloučení vypadat, až se žádost o přijetí změn dokončí. Pokud cílová větev obsahuje změny nepromítnuté do rozdílu, může být rozdíl potvrzení sloučení užitečný k zobrazení posledních změn ve zdrojové i cílové větvi.
Další příkaz, který je užitečný ve spojení s příkazem View merge commit, je Restart merge (Restartovat sloučení) dostupný ve stejné nabídce příkazů. Pokud se cílová větev od prvotního vytvoření žádosti o přijetí změn změnila, při spuštění tohoto příkazu se vytvoří nové náhledové potvrzení sloučení a rozdílové zobrazení potvrzení sloučení se aktualizuje.
Nedávno použití revidující
Pokud si necháváte kód často revidovat stejnými osobami, bude přidání revidujících snadnější. Při přidávání revidujících do žádosti o přijetí změn se při umístění fokusu do pole pro zadání revidujících automaticky zobrazí seznam nedávno přidaných revidujících, takže je nemusíte hledat podle jména. Vyberte je, jako byste to udělali s jakýmkoli jiným revidujícím.
Zobrazení zbývajících kritérií zásad pro automatické dokončování žádostí o přijetí změn
Automatické dokončování je užitečná funkce pro týmy, které používají zásady pro větve, při použití nepovinných zásad ale nemusí být jasné, co přesně blokuje dokončení žádosti o přijetí změn. Když teď pro žádost o přijetí změn nastavíte automatické dokončování, je v poli popisku zřetelně uvedený přesný seznam kritérií zásad, které blokují dokončení. Při plnění jednotlivých požadavků ubývají z tohoto seznamu položky, dokud nezbudou žádné požadavky, a žádost o přijetí změn se sloučí.
Matematické diskuze v žádostech o přijetí změn
Potřebujete do komentářů žádostí o přijetí změn začlenit rovnici nebo matematický výraz? Do komentářů teď můžete začlenit funkce LaTeX, a to pomocí vložených nebo blokových komentářů. Další informace najdete v seznamu podporovaných funkcí.
Návrhy žádostí o přijetí změn pro forky
Kdykoli se v úložišti aktualizuje tématická větev, zobrazí se pro tuto tématickou větev „návrh“ na vytvoření nové žádosti o přijetí změn. To je velmi užitečné pro vytváření nových žádostí o přijetí změn a tuto funkci teď můžou použít také ti, kteří pracují v úložišti s vytvořeným forkem. Když aktualizujete nějakou větev ve forku, při příští návštěvě centra Kód této větve nebo upstreamového úložiště uvidíte návrh na vytvoření žádosti o přijetí změn. Při výběru odkazu Vytvořit žádost o získání dat přejdete do prostředí pro vytvoření žádosti o přijetí změn s předvybranou zdrojovou a cílovou větví a úložištěm.
Filtry cest pro zásady žádosti o přijetí změn
Jediné úložiště bude často obsahovat kód, který je sestavený několika kanály kontinuální integrace pro účely ověření sestavení a provedení testů. Integrované zásady sestavení teď podporují možnost filtrování cesty usnadňující konfiguraci několika sestavení žádosti o přijetí změn, které mohou být vyžadovány a automaticky aktivovány pro jednotlivé žádosti o přijetí změn. Podle potřeby stačí určit cestu, která se má vyžadovat pro jednotlivá sestavení, a nastavit možnosti aktivace a požadavků.
U zásad stavu jsou kromě možností filtrování sestavení dostupné také možnosti filtrování cesty. U libovolných vlastních zásad nebo zásad jiných výrobců tak půjde nakonfigurovat vynucení zásad pro konkrétní cesty.
Práce
Klávesové zkratky na formuláři pracovní položky
Pomocí klávesových zkratek můžete přiřadit pracovní položku sami sobě (Alt+I), přejít na diskuzi (Ctrl+Alt+D) a zkopírovat odkaz na pracovní položku (Shift+Alt+C). Pokud chcete zobrazit úplný seznam nových zkratek, zadejte otazník („?“) v otevřeném formuláři pracovní položky nebo se podívejte do tabulky níže.
Modernizované možnosti sloupce
Dialog Možnosti sloupce sloužící ke konfiguraci sloupců mřížky pracovní položky v centrech Backlog, Dotazy a Test, byl aktualizován na nový panelový design. Hledáním můžete najít pole, přetažením přeuspořádat sloupce nebo odebrat sloupce, které už nepotřebujete.
Informace o tom, kdo naposledy spustil dotaz
S rozrůstáním projektové stromové struktury Sdílené dotazy může být obtížné určit, zda se dotaz už nepoužívá a může se odstranit. Abychom vám pomohli se správou sdílených dotazů, přidali jsme do rozhraní REST API dotazu dvě nová metadata, a sice autora posledního spuštění a datum posledního spuštění, abyste mohli napsat čisticí skripty pro odstranění zastaralých dotazů.
Odstranění značek HTML v mřížkách pracovních položek
Na základě zpětné vazby od zákazníků jsme chování víceřádkových textových polí v zobrazeních výsledků dotazů na pracovní položky na webu, v Excelu a integrovaném vývojovém prostředí Visual Studio aktualizovali odebráním formátování HTML. Víceřádková textová pole se po přidání ve formě sloupce do dotazu teď budou zobrazovat jako prostý text. Zde je příklad funkce s kódem HTML v popisu.
V minulosti se výsledky dotazu zobrazily podobně jako <div><b><u>Customer Value</u>....
Přidaná podpora operátoru dotazu Není v
Pole, která podporují operátor dotazu „V“, teď podporují operátor „Není v“. Můžete psát dotazy na položky, které „nejsou v“ seznamu ID, „nejsou v“ seznamu stavů a podobně, aniž byste museli vytvářet spoustu vnořených klauzulí „Nebo“.
Dotaz pro @MyRecentActivity a @RecentMentions
Zavedli jsme dvě nová makra dotazů pro pole ID, abychom vám pomohli najít pracovní položky, které pro vás můžou být důležité. Pomocí @RecentMentions můžete zjistit, o jakých položkách jste se zmínili za posledních 30 dnů, nebo se podívejte na pracovní položky, které jste nedávno zobrazili nebo upravili pomocí @MyRecentActivity.
Filtr vlastních polí a značek v oznámeních sledování pracovních položek
Oznámení se teď dají definovat pomocí podmínek u vlastních polí a značek, a to nejen při jejich změně, ale i při nabytí určitých hodnot. To umožňuje nastavit pro pracovní položky robustnější sadu oznámení.
Podpora zmínek na stránce Mé pracovní položky
Na stránku Mé pracovní položky jsme přidali nový oddíl Mentioned (Zmíněno). Uvnitř tohoto oddílu si můžete prohlédnout pracovní položky, které byly zmíněny během posledních 30 dnů. Díky tomuto novému zobrazení můžete rychle učinit akci u položek, které vyžadují vaši pozornost, a mít přehled o konverzacích, které jsou pro vás důležité.
Stejný pivot je dostupný také v mobilním prostředí, takže mobilní a desktopová aplikace jsou konzistentní.
Filtrování plánů
Rozšíření Delivery Plans (Plány dodávek) teď využívá naši společnou filtrovací komponentu a je konzistentní s prostředím pro filtrování mřížek pracovních položek a panelů. Tento filtrovací ovládací prvek poskytuje lepší použitelnost a jednotné rozhraní všem členům vašeho týmu.
Aktualizovaná navigace mezi plány
Mnozí s vás se starají o konkrétní plány nebo sady plánů a pro rychlý přístup k obsahu používají oblíbené položky. Za prvé jsme aktualizovali centrum Plans (Plány), takže přejdete na naposledy navštívený plán místo na stránku adresáře. Za druhé – když tam budete – se můžete pomocí oblíbených položek rychle přepnout na jiný plán nebo pomocí popisu cesty přejít zpět na stránku adresáře.
Rozbalení/sbalení požadavků nebo lidí na panelu úkolů
Jedním kliknutím teď můžete rozbalit nebo sbalit všechny položky na panelu úkolů sprintu.
Udělení oprávnění bypassrule konkrétním uživatelům
Při migraci pracovních položek z jiného zdroje chtějí organizace často zachovat všechny původní vlastnosti pracovní položky. Můžete například chtít vytvořit chybu, která si zachovává původní hodnoty data vytvoření a autora ze systému, odkud pochází.
Rozhraní API pro aktualizaci pracovní položky obsahuje příznak bypassrule, který to umožňuje. Identita, která učinila tuto žádost rozhraní API, musela být dříve členem skupiny Správci kolekcí projektů. Na úroveň projektu jsme přidali oprávnění, které umožňuje spuštění tohoto rozhraní API s příznakem bypassrule.
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, abyste migrovali svoje 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 budete muset použít VS 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.
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.
Vylepšení vícefázových sestavení
Fáze jste mohli používat k organizaci kroků sestavení a cílení různých agentů pomocí různých požadavků pro jednotlivé fáze. Do fází sestavení jsme přidali několik funkcí, které vám teď umožňují:
Určit jinou frontu agenta pro každou fázi. To znamená, že například můžete:
- Spustit jednu fázi sestavení na agentovi macOS a jinou fázi na agentovi Windows. Dobrý příklad toho, jak užitečné to může být, najdete v tomto videu Connect(); 2017: CI/CD DevOps Pipeline for mobile apps and services (Kanál CI/CD DevOps pro mobilní aplikace a služby).
- Spustit kroky sestavení ve fondu agentů sestavení a testovací kroky ve fondu testovacích agentů.
Urychlit testy jejich souběžným spuštěním. Jakákoli fáze, u které je nakonfigurovaná souběžnost „Multi-agent“ (Více agentů) a obsahuje úlohu VSTest, teď automaticky umožní souběžné provádění testů v rámci nakonfigurovaného počtu agentů.
Povolit nebo zakázat skriptům přístup k jednotlivým fázím tokenu OAuth. To například znamená, že teď můžete povolit spuštění skriptů ve fázi sestavení a umožnit tak komunikaci s VSTS přes rozhraní REST API, a ve stejné definici sestavení blokovat spuštění skriptů ve fázi testování.
Spustit fázi jen za určitých podmínek. Fázi můžete nakonfigurovat například tak, aby se spustila jen při úspěchu předchozích fází nebo jen při sestavování kódu v hlavní větvi.
Další informace najdete na stránce Fáze při správě sestavení a vydaných verzí.
Přeskočení plánovaných sestavení, pokud se v úložišti nic nezměnilo
Vyhověli jsme vašim četným žádostem a nově můžete zadat, aby se naplánované sestavení nespustilo, pokud se v kódu nic nezměnilo. Toto chování můžete ovládat pomocí možnosti v plánu. Ve výchozím nastavení nebude nové sestavení naplánováno, pokud proběhlo poslední naplánované sestavení (ze stejného plánu) a do úložiště nebyly vráceny žádné další změny.
Sestavení pomocí kontinuální integrace z GitHubu Enterprise
Pokud ke správě verzí používáte GitHub Enterprise, využijete teď lepší integraci pro sestavení kontinuální integrace (CI). Dříve jste byli omezeni na dotazování změn kódu pomocí konektoru Externí Git, který mohl zvýšit zatížení vašich serverů a způsobit prodlevy před aktivací sestavení. Díky oficiální podpoře GitHubu Enterprise se teď týmová sestavení CI aktivují okamžitě. Připojení lze navíc nakonfigurovat pomocí různých metod ověřování, jako jsou LDAP nebo předdefinované účty.
Soubory zabezpečení lze stahovat do počítačů agentů během sestavování nebo vydávání
Nová úloha Stáhnout soubor zabezpečení podporuje stahování zašifrovaných souborů (do počítačů agentů) z knihovny Soubory zabezpečení VSTS. Po stažení se soubor zašifruje a uloží na disk agenta. Když se sestavení nebo vydání dokončí, odstraní se tento soubor z agenta. Při sestavování nebo vydávání verzí tak můžete používat citlivé soubory, například certifikáty nebo privátní klíče, které jsou jinak bezpečně zašifrované a uložené ve VSTS. Další informace najdete v dokumentaci k souborům zabezpečení.
Zřizovací profily Apple lze instalovat z úložišť zdrojového kódu
Úloha Nainstalovat zřizovací profil Apple už podporuje instalaci zřizovacích profilů (do počítačů agentů), které jsou uložené v knihovně Soubory zabezpečení VSTS. Xcode používá zřizovací profily k podepsání a zabalení aplikací Apple určených pro iOS, macOS, tvOS a watchOS. Zřizovací profily teď lze instalovat z úložišť zdrojového kódu. I když se kvůli lepšímu zabezpečení těchto souborů doporučuje používat knihovna Soubory zabezpečení, řeší toto vylepšení zřizovací profily, které už jsou uložené ve správě zdrojového kódu.
Vysledování zdrojových kódů GitHubu k sestavením pomocí značek sestavení
Sestavení z GitHubu nebo GitHubu Enterprise už odkazují na příslušné potvrzení. Stejně důležitá je ale možnost vysledovat potvrzení k sestavením, která sestavilo. Teď je to možné, když v TFS povolíte označování zdrojového kódu. Při výběru úložiště GitHubu v definici sestavení můžete vybrat typy sestavení, která chcete označit, a formát značek.
Značky sestavení se pak objeví v úložišti GitHubu nebo GitHubu Enterprise.
Během sestavování nebo vydávání lze nainstalovat konkrétní sady JDK (Java Development Kit)
Při sestavování určitých projektů Java se mohou vyžadovat konkrétní sady JDK, které ale v počítačích agentů nemusí být dostupné. Projekty mohou například vyžadovat starší nebo odlišné verze sad JDK od IBM, Oraclu nebo z oblasti Open Source. Úloha Instalační program nástrojů Java stáhne a nainstaluje sadu JDK, kterou projekt potřebuje během sestavování nebo vydávání. Po dobu sestavování nebo vydávání se příslušným způsobem nastaví proměnná prostředí JAVA_HOME. Pomocí sdílené složky, úložiště zdrojového kódu nebo Azure Blob Storage lze Instalačnímu programu nástrojů Java zpřístupnit konkrétní sady JDK.
Vylepšená konfigurace sestavení Xcode
Úloha Xcode byla aktualizována o novou hlavní verzi (4.*), která zlepšuje konfiguraci sestavování, testování a balení Xcode. Pokud má váš projekt Xcode jediné sdílené schéma, použije se automaticky. Byla přidána další vložená nápověda. Zastaralé funkce, jako je balení xcrun, byly z vlastností úlohy Xcode odebrány. Kvůli použití této nejnovější verze 4.* úlohy Xcode se existující definice sestavení a verzí musí upravit. Pokud v nových definicích potřebujete zastaralé funkce předchozí verze úlohy Xcode, můžete v definici tuto verzi vybrat.
Ověřování vydaných verzí
Nedílnou součástí kanálů DevOps je nepřetržité monitorování. Ověření toho, že je aplikace ve vydané verzi po nasazení v pořádku, je stejně důležité jako úspěch procesu nasazení. Podniky využívají různé nástroje pro automatické zjišťování stavu aplikace v produkci a evidenci incidentů hlášených zákazníky. Až doteď museli schvalující před povýšením vydané verze ručně monitorovat stav aplikací ze všech systémů. Správa vydaných verzí teď ale podporuje integraci nepřetržitého monitorování do kanálů verze. Můžete tak zajistit, aby se systém opakovaně dotazoval na všechny signály stavu aplikace, dokud všechny z nich nebudou současně v pořádku, než bude pokračovat ve vydání verze.
Začnete tím, že v definici verze definujete ověření před nasazením nebo po nasazení. Každé ověření dokáže monitorovat jeden nebo více signálů stavu odpovídajících systému monitorování aplikace. Pro „výstrahy monitorování Azure (Application Insights)“ a „Pracovní položky“ jsou dostupná předdefinovaná ověření. Díky flexibilitě, kterou nabízí funkce Azure, můžete zajistit integraci s jinými systémy.
Při provádění začne Vydaná verze vzorkovat všechna ověření a shromažďovat signály stavu, které od nich pocházejí. Opakuje vzorkování po intervalech, dokud signály shromážděné ze všech ověření ve stejném intervalu nejsou úspěšné.
Prvotní vzorky ze systémů monitorování nemusejí být přesné, protože pro nové nasazení nemusí být k dispozici dostatek informací. Možnost „Delay before evaluation“ (Prodleva před vyhodnocením) zajišťuje, aby Vydaná verze během tohoto intervalu nepokračovala, i když jsou všechny vzorky úspěšné.
Během vzorkování ověření se nevyužívají žádní agenti ani kanály. Další informace najdete v dokumentaci ověřování vydané verze.
Selektivní nasazení na základě artefaktu, který aktivuje vydanou verzi
Do definice verze lze přidat několik zdrojů artefaktů a nakonfigurovat je k aktivaci vydané verze. Nová vydaná verze se vytvoří, když je pro některý z těchto zdrojů dostupné nové sestavení. Stejný proces nasazení se provádí bez ohledu na to, který zdroj vydanou verzi aktivoval. Proces nasazení teď můžete přizpůsobit na základě aktivačního zdroje. U automaticky aktivovaných vydaných verzí je teď proměnná vydané verze Release.TriggeringArtifact.Alias vyplněna a identifikuje zdroj artefaktu, který vydanou verzi aktivoval. V podmínkách úloh, podmínkách fází a parametrech úloh to lze využít k dynamické úpravě procesu. Například když potřebujete nasadit jen artefakty, které se změnily v rámci různých prostředí.
Správa zabezpečení konkrétní entity
Když byly v minulosti při zabezpečení na základě rolí nastaveny role zabezpečeného přístupu, byly pro skupiny nasazení, skupiny proměnných, fronty agentů a koncové body služby nastaveny pro uživatele nebo skupinu na úrovni centra. U konkrétní entity teď můžete dědičnost zapnout a vypnout a nakonfigurovat zabezpečení tak, jak potřebujete.
Schválení několika prostředí
Správa schválení je teď u vydaných verzí jednodušší. U kanálů, které mají stejného schvalujícího pro několik souběžně nasazovaných prostředí, se schvalující momentálně musí zabývat každým schválením zvlášť. Díky této funkci teď můžete dokončit několik nevyřízených schválení najednou.
Rozšiřitelnost šablony vydané verze
Šablony vydané verze umožňují vytvořit základ, s kterým můžete při definování procesu vydané verze začít. V minulosti jste mohli do svého účtu nahrát nové šablony, teď ale autoři můžou zahrnout šablony vydané verze do svých rozšíření. Podívejte se na příklad v úložišti GitHubu.
Podmíněné úlohy a fáze vydané verze
Podobně jako u podmíněných úloh sestavení teď můžete úlohu nebo fázi spustit jen při splnění určitých podmínek. To vám pomůže při modelování scénářů vrácení zpět.
Pokud předdefinované podmínky nevyhovují vašim potřebám nebo pokud potřebujete podrobnější kontrolu nad tím, kdy má se úloha nebo fáze spustit, můžete si určit vlastní podmínky. Podmínku můžete vyjádřit jako vnořenou sadu funkcí. Agent vyhodnocuje nejvíce vnořenou funkci a postupuje směrem ven. Konečný výsledek je logická hodnota, která určuje, jestli se má úloha spustit.
Historie žádostí pro koncové body služby
Koncové body služby umožňují připojení k externím a vzdáleným službám za účelem spouštění úloh pro sestavení nebo nasazení. Koncové body se konfigurují v rozsahu projektu a sdílejí mezi několika definicemi sestavení a verze. Vlastníci koncových bodů služby teď můžou využít konsolidované zobrazení sestavení a nasazení používajících koncový bod, což pomůže ke zlepšení auditování a zásad správného řízení.
Výchozí vlastnosti typů artefaktů Gitu a GitHubu teď lze upravovat
Výchozí vlastnosti typů artefaktů Gitu a GitHubu teď můžete upravovat dokonce i potom, co byl na artefakt vytvořen odkaz. To je užitečné zvláště v situacích, kdy se větev stabilní verze artefaktu změnila a budoucí vydané verze průběžného doručování by pomocí této větve měly získat novější verzi tohoto artefaktu.
Ruční hromadné nasazení prostředí ze zobrazení verzí
Teď můžete ručně aktivovat akci Nasadit do několika prostředí vydané verze najednou. Díky tomu můžete ve vydané verzi vybrat několik prostředí s neúspěšnými konfiguracemi nebo nasazeními a znovu je nasadit do všech těchto prostředí v jedné operaci.
Podpora kanálu Jenkins s několika větvemi a propojování úloh uspořádaných do složek
Využívání projektů z Jenkins je teď ještě lepší.
Za prvé teď můžete pro zdroje artefaktů v definici verze využívat projekty kanálu Jenkins s několika větvemi.
Za druhé, zatímco dříve jste mohli propojovat projekty Jenkins jako artefakty jen z kořenové složky serveru Jenkins, teď můžete využívat projekty Jenkins uspořádané do složek. V seznamu zdrojů, ze kterých vyberete projekt, který se má využít jako zdroj artefaktu, uvidíte seznam projektů Jenkins spolu s cestami ke složkám.
Centrum Dockeru nebo Azure Container Registry jako zdroj artefaktu
Tato funkce umožňuje, aby vydané verze používaly image uložené v registru centra Dockeru nebo Azure Container Registry (ACR). Jedná se o první krok směrem k podpoře scénářů, jako je vydávání nových změn po oblastech pomocí funkce geografické replikace ACR nebo nasazení do prostředí (například produkčního) z registru kontejneru, který obsahuje image jen pro produkční prostředí.
V prostředí +Přidat artefakt v definici verze teď můžete centrum Dockeru nebo ACR nakonfigurovat jako artefakt první třídy. Prozatím se vydaná verze musí aktivovat ručně nebo jiným artefaktem, brzy ale přidáme aktivační událost vycházející z nasdílení změn nové image do registru.
Výchozí verze artefaktu
Při propojování artefaktu správy verzí s definicí verze existuje v současnosti několik možností výchozí verze. Můžete nakonfigurovat, aby se z výchozí větve vybralo konkrétní potvzení/sada změn nebo jednoduše nejnovější verze. Normálně nakonfigurujete, aby se vybrala nejnovější verze, zvláště to ale oceníte v některých prostředích, kde se pro všechna budoucí průběžná nasazování musí určit zlatá verze artefaktu.
Vylepšení větve aktivačních událostí verze
Teď můžete nakonfigurovat filtr aktivačních událostí verze na základě výchozí větve určené v definici sestavení. To je zvláště užitečné, pokud se výchozí větev sestavení mění s každým sprintem a filtr aktivačních událostí verze se musí pro všechny definice verze aktualizovat. Teď stačí, když v definici sestavení změníte výchozí větev, a ve všech definicích verze se tato větev použije automaticky. Pokud například váš tým vytváří větve verze pro každou datovou část verze sprintu, její aktualizací v definici sestavení odkážete na novou větev verze sprintu a tato verze si ji vybere automaticky.
Aktivační událost verze pro artefakt správy balíčků
U artefaktu Správa balíčků v definici verze teď můžete nastavit aktivační událost, takže se nová verze vytvoří automaticky při publikování nové verze balíčku. Další informace najdete v dokumentaci aktivačních událostí ve správě vydaných verzí.
Určení oboru skupiny proměnných pro konkrétní prostředí
Když byla v minulosti do definice verze přidána skupina proměnných, byly obsažené proměnné dostupné všem prostředím v této verzi. Teď máte místo toho možnost určit obor skupiny proměnných pro konkrétní prostředí. To je zpřístupní pro jedno prostředí, ale nikoli pro jiná prostředí ve stejné verzi. To oceníte, pokud používáte externí službu (například e-mailovou službu SMTP), která se mezi prostředími liší.
Automatické vydání z Azure Container Registry nebo centra Dockeru
Při nasazování kontejnerizovaných aplikací se změny image kontejneru nejprve nasdílí do registru kontejneru. Po nasdílení změn lze tuto image kontejneru nasadit na Web App for Containers nebo cluster Kubernetes. Teď můžete zapnout automatické vytváření vydaných verzí při aktualizacích imagí uložených v centru Dockeru nebo Azure Container Registry tím, že je přidáte do zdroje artefaktu.
Určení výchozí verze artefaktů Jenkins
Když se automaticky aktivuje vydaná verze s několika artefakty, vyberou se pro všechny artefakty výchozí verze uložené v definici verze. Artefakty Jenkins v minulosti neobsahovaly nastavení výchozí verze, proto jste u vydané verze používající Jenkins nemohli nastavit aktivační událost průběžného nasazování jako sekundární artefakt.
Teď můžete určit výchozí verzi artefaktů Jenkins s možnostmi, které už znáte:
- Latest (Nejnovější)
- Specify at the time of release creation (Určit při vytváření vydané verze)
- Specific version (Konkrétní verze)
Získání ověřování vydaných verzí z rozšíření
Ověřování vydaných verzí umožňují přidat do kanálů verze schválení na základě informací. Před nebo po nasazení se shromažďuje sada signálů stavu, pomocí kterých se určí, jestli vydaná verze má nebo nemá povýšit do další fáze. K dispozici je sada předdefinovaných ověřování, přičemž jako prostředek pro integraci s jinými službami se dosud doporučovalo používat „Vyvolat funkci Azure“. Tento postup teď zjednodušujeme integrací s jinými službami a ověřování se dají přidávat přes rozšíření na marketplace. Teď můžete přispívat vlastními úlohami ověřování a poskytnout autorům definic verze vylepšené prostředí pro konfiguraci tohoto ověřování.
Přečtěte si další informace o vytváření úloh ověřování.
Škálování nasazení do virtuálních počítačů pomocí skupin nasazení
Skupiny nasazení, které umožňují robustní, okamžité nasazení do více počítačů, jsou teď obecně dostupné. Pomocí skupin nasazení můžete orchestrovat nasazení na více serverů a provádět kumulativní aktualizace a současně zajistit vysokou dostupnost celé aplikace. Nasazovat také můžete na servery místně, do virtuálních počítačů v Azure nebo do libovolných cloudů a získat kompletní sledovanost nasazených verzí artefaktů až na úroveň serveru.
Funkce nasazení na základě agenta spoléhá na stejné agenty sestavení a nasazení, jako jsou již k dispozici. Ve fázi skupiny nasazení můžete na cílových počítačích využít celý katalog úloh. Z hlediska rozšiřitelnosti můžete také pro programový přístup využít u skupin nasazení a cílů rozhraní REST API.
Balíček
Bezproblémové použití veřejných balíčků pomocí upstreamových zdrojů
Nyní jsou k dispozici upstreamové zdroje pro nuget.org a npmjs.com. K výhodám patří možnost správy balíčků uložených z upstreamových zdrojů (vyjmutí ze seznamu, vyřazení, zrušení publikování, odstranění atd.), stejně jako garantované uložení všech upstreamových balíčků, které používáte.
Zásady uchovávání v informačních kanálech TFS
Informační kanály balíčků TFS doteď neposkytovaly žádný způsob automatického čištění starších nepoužívaných verzí balíčků. Uživatelům, kteří často publikují balíčky, to mohlo způsobit pomalejší dotazy na informační kanály ve Správci balíčků NuGet a jiných klientech, dokud nebyly ručně odstraněny některé verze.
U informačních kanálů TFS jsme teď povolili zásady uchovávání. Zásady uchovávání automaticky odstraní při dosažení prahové hodnoty nejstarší verzi balíčku. Balíčky přesunuté do zobrazení jsou trvale zachovány, což vám poskytne možnost ochránit verze, které se používají v produkci nebo v rámci celé organizace.
Zásady uchovávání povolíte tak, že při úpravě informačního kanálu zadáte hodnotu do pole Maximum number of versions per package (Maximální počet verzí na balíček) v oddílu Retention policies (Zásady uchovávání).
Filtrování při správě balíčků
Stránka Packages (Balíčky) byla aktualizována a používá standardní rozložení stránky, ovládací prvek panelu příkazů a nový standardní panel filtrů.
Sdílení balíčků pomocí oznámení
V komunitě Open Source se v souboru README úložiště často používá oznámení, které odkazuje na nejnovější verzi balíčku. Oznámení pro balíčky teď můžete vytvářet v informačních kanálech. Jednoduše zaškrtněte možnost Enable package badges (Povolit oznámení balíčků) v nastavení informačního kanálu, vyberte balíček a pak klikněte na Create badge (Vytvořit oznámení). Můžete zkopírovat přímo adresu URL oznámení nebo předem vygenerovaný Markdown, který zpětně odkazuje na oznámení na stránce s podrobnostmi balíčku.
Předchozí verze balíčku teď mají formu celostránkového seznamu
Dostali jsme spoustu zpětné vazby k aktualizovanému prostředí správy balíčků, ve kterém jsme seznam předchozích verzí balíčku přesunuli do výběru popisu cesty na stránce s podrobnostmi balíčku. Přidali jsme nový oddíl Versions (Verze), který zobrazuje další informace o předchozích verzích a usnadňuje kopírování čísla verze nebo získání odkazu na starou verzi.
Zobrazení kvality verze balíčku v seznamu balíčků
V seznamu balíčků teď můžete vidět zobrazení jednotlivých verzí balíčků a rychle tak určit jejich kvalitu. Další informace najdete v dokumentaci zobrazení verzí. ) další informace najdete v dokumentaci.
Podpora ověřených informačních kanálů Gulp, Yarn a dalších
Úloha npm dnes bezproblémově funguje s ověřenými informačními kanály npm (v Package Management (Správa balíčků) nebo externími registry jako npm Enterprise a Artifactory), ale až doteď bylo obtížné použít spouštěč úloh jako Gulp nebo alternativního klienta jako Yarn, pokud tato úloha nepodporovala také ověřené informační kanály. Přidali jsme novou úlohu sestavení Ověření npm, která přidá přihlašovací údaje do souboru .npmrc, aby následné úlohy mohly úspěšně používat ověřené informační kanály.
Výchozí oprávnění informačního kanálu balíčku teď obsahuje skupinu Správci projektů
Při vytváření informačního kanálu byl minulosti jeho autor nastaven jako jediný vlastník, což ve velkých organizacích mohlo způsobit problémy se správou, když tento uživatel přešel do jiného týmu nebo odešel z organizace. Abychom tento kritický prvek odstranili, při vytváření informačního kanálu se teď pomocí kontextu aktuálního projektu uživatele získá skupina Správci projektů a nastaví se jako další vlastník tohoto informačního kanálu. Pomocí dialogu pro nastavení informačního kanálu můžete tuto skupinu odebrat a dále oprávnění informačního kanálu přizpůsobit.
Recyklace a obnovení balíčků
Odstraněním nepoužívaných balíčků můžete zachovat přehlednost seznamu balíčků, někdy ale můžete balíček odstranit omylem. Odstraněné balíčky teď můžete obnovit z koše. Odstraněné balíčky zůstávají v koši po dobu 30 dnů, takže máte dostatek času k jejich případnému obnovení.
Odkazy na balíčky odkudkoli
Ačkoli jste v minulosti mohli sdílet adresu URL balíčku nalezeného v centru Packages (Balíčky), často se obtížně používala, protože jste do této adresy URL potřebovali zahrnout projekt, který se mohl nebo nemusel vztahovat na ty, kteří tento odkaz používali. V této aktualizaci teď můžete sdílet balíčky pomocí adresy URL, která automaticky vybere projekt, ke kterému má příjemce přístup.
Formát adresy URL je: 'https://< TFSserverURL>/_packaging?feed=feed>&< package=<package>&version=version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package'
Všechny parametry kromě< TFSserverURL> jsou volitelné, ale pokud zadáte balíček, musíte zadat typ protokolu.Test
Úloha Visual Studio Test nepotřebuje úplnou sadu Visual Studio
Úloha Visual Studio Test v sestavení/vydané verzi vyžaduje ke spuštění testů Visual Studio na agentovi. Místo instalace sady Visual Studio ke spouštění testů v produkčním prostředí nebo k pouhé distribuci testů na několik agentů použijte novou úlohu Instalační program testovací platformy Visual Studio. Tato úloha opatří testovací platformu z webu nuget.org a přidá ji do mezipaměti nástrojů. Tato úloha instalačního programu splní požadavek na vstest a následná úloha Visual Studio Test v definici poběží bez nutnosti instalace plné verze sady Visual Studio na agentovi.
Úlohu instalačního programu přidejte do definice z katalogu úloh.
Následnou úlohu Visual Studio Test nakonfigurujte tak, aby používala součásti opatřené instalačním programem.
Poznámka
Omezení: Balíček Test Platform na NuGetu momentálně nepodporuje spouštění programových testů uživatelského rozhraní. Umožnění podpory programových testů uživatelského rozhraní máme v backlogu. Balíček Test Platform na NuGetu je multiplatformní, ale úloha VSTest momentálně nepodporuje spouštění testů .NET Core. Ke spouštění testů .NET Core použijte úlohu „dot net“.
Úlohy Spustit funkční testy a Nasadit testovacího agenta jsou teď zastaralé
Loni jsme začali se sjednocením agentů mezi sestavením, vydanou verzí a testem. Cílem bylo vyřešení různých problematických míst spojených s použitím úloh Nasadit testovacího agenta a Spustit funkční testy založených na WinRM. Zároveň tak můžete úlohu Visual Studio Test (VSTest) použít pro všechny potřeby testování, mezi které patří:
- Testování částí
- Funkční testy (související/nesouvisející s uživatelským rozhraním)
- Testy založené na MSTest
- Testy založené na rozhraních jiných výrobců
- Specifikace testů založené na sestavení nebo spouštění testů pomocí testovacího plánu/sady testů
- Spuštění testu na jednom agentovi a distribuce testů na několik agentů
Sjednocení agentů rovněž správcům umožňuje spravovat všechny počítače použité pro CI/CD jednotným způsobem.
Kvůli této funkci jsme dodali několik zásadních prvků, mezi které patří:
- Agenty lze nakonfigurovat pro testování uživatelského rozhraní.
- Instalační program testovací platformy sady Visual Studio umožňuje spuštění úlohy VSTest bez předem nainstalované sady Visual Studio.
- Definice sestavení a verze lze vytvořit s několika fázemi a možností použití různých front agentů pro jednotlivé fáze.
- Automatizované testovací případy lze spustit z centra Test pomocí úlohy VSTest.
Vzhledem k výše uvedenému jsme připraveni k vyřazení těchto dvou úloh. I když existující definice, ve kterých se tyto vyřazené úlohy používají, budou nadále fungovat, doporučujeme přejít na použití úlohy VSTest a využít tak výhod kontinuálních vylepšení.
Filtrování rozsáhlých výsledků testů
Prostředky testů se časem rozrůstají a u velkých aplikací se můžou snadno vyšplhat až na tisíce testů. Týmy hledají lepší způsoby procházení rozsáhlých sad výsledků testů, aby při identifikaci selhání testů, přidružení původní příčiny nebo změně vlastnictví problémů byly produktivní. Za tímto účelem jsme na kartu Testy v oblasti Sestavení a verze přidali tři nové filtry, a sice Název testu, Kontejner (knihovny DLL) a Vlastník (vlastník kontejneru).
Stávající filtr Výsledek teď také umožňuje filtrování více výsledků. Různá kritéria filtrů mají kumulativní povahu. Když chcete jako uživatel zobrazit výstupy testů u právě provedené změny, získáte relevantní výsledky použitím filtru Kontejner (název knihovny DLL), Vlastník (vlastník knihovny DLL) nebo Název testu, případně všech tří.
Identifikace nespolehlivých testů
Testy jsou někdy nespolehlivé – jsou neúspěšné v jednom běhu a úspěšné v jiném, aniž dojde ke změně. Nespolehlivé testy jsou frustrující a podkopávají důvěru v efektivitu testů – způsobují selhání, která se mají ignorovat, a chyby, které mají projít. V této aktualizaci jsme nasadili první část řešení, které vám pomůže se s nespolehlivými testy vypořádat. Úlohu Visual Studio Test teď můžete nakonfigurovat tak, aby se neúspěšné testy opakovaly. Ve výsledcích testů pak poznáte, které testy nejprve selhaly a při opakování byly úspěšné. Podpora opakování testů založených na datech a seřazených testů bude přidána později.
Při konfiguraci úlohy Visual Studio Test lze určit maximální počet pokusů o opakování neúspěšných testů a procentuální prahovou hodnotu selhání (testy se zopakují, pokud například selhalo méně než 20 % všech testů), aby nedošlo k opakování testů v případě rozsáhlých chyb.
Na kartě Testy v oblasti Sestavení a verze můžete filtrováním výsledků testů, jejichž Výsledek je „Předáno při opětovném spuštění“, odhalit testy, které se při běhu chovaly nespolehlivě. V současnosti se zobrazí poslední pokus každého testu, který byl při opakování úspěšný. Také souhrnné zobrazení je upravené a v oblasti Celkem testů se zobrazuje „Předáno při opětovném spuštění (n/m)“, kde n je počet testů, které byly při opakování úspěšné, a m je celkový počet úspěšných testů. Hierarchické zobrazení všech pokusů chystáme v několika příštích sprintech.
Vylepšení náhledu a podpora různých typů protokolů generovaných úlohou Visual Studio Test
Úlohu VSTest jsme vylepšili tak, aby publikovala protokoly generované různými druhy protokolovacích výpisů, které u neúspěšných testů odpovídají standardnímu výstupu a standardní chybě. Zdokonalili jsme rovněž náhled, který podporuje zobrazení textových formátů a formátů souborů protokolu a umožňuje v nich vyhledávat.
Wiki
Hledání na wiki
Přímo při práci s kódem a pracovními položkami můžete hledat oblíbené Wiki stránky podle názvu nebo obsahu. Více se o hledání na Wiki dočtete na blogu Microsoft DevOps.
Tisk Wiki stránek
Wiki se dá použít pro různý obsah. Někdy může být užitečné si vytisknout obsah z Wiki a přečíst si ho ve volném čase, doplnit komentáře perem na papír nebo se podělit o papírovou kopii s těmi, kdo nejsou členy projektu VSTS. Teď můžete jednoduše kliknout na místní nabídku stránky a vybrat Print page (Vytisknout stránku).
Poznámka
Tato funkce momentálně není podporovaná ve Firefoxu.
Snadné přispívání na Wiki stránky pomocí klávesových zkratek
Časté akce související s úpravou a prohlížením Wiki teď můžete provádět pomocí klávesových zkratek ještě rychleji.
Při prohlížení stránky můžete přidat, upravit nebo vytvořit podstránku, například:
Při úpravě stránky ji můžete rychle uložit, uložit a zavřít nebo jen zavřít.
Můžete je využít navíc ke standardním klávesovým zkratkám pro úpravy, například Ctrl+B pro tučný text, Ctrl+I pro kurzívu, Ctrl+K pro rukopis atd. Další informace najdete v úplném seznamu klávesových zkratek.
Vykreslení formátování Markdownu v úložišti kódu
V úložištích kódu teď můžete vytvářet formátované soubory README.MD. Vykreslování Markdownu souborů MD v úložištích kódu teď podporuje značky HTML, blokové citace, emoji, změnu velikosti obrázků s matematické vzorce. Vykreslování Markdownu ve Wiki a souborech MD v kódu je rovnocenné.
Wiki podporuje matematické vzorce
Pokud vaše aplikace využívá matematické vzorce a rovnice, můžete je teď vložit do Wiki pomocí formátu LaTeX.
Odkazování pracovních položek na Wiki
Na Wiki stránkách teď můžete na pracovní položky odkazovat tak, že stisknutím klávesy # zobrazíte seznam naposledy použitých pracovních položek a pak vyberete požadovanou pracovní položku. To oceníte především při psaní zpráv k vydání verze, námětů, specifikací nebo jiných stránek, které vyžadují odkaz na pracovní položku.
Propojování pracovních položek a Wiki stránek
Pracovní položku teď můžete propojit s Wiki a naopak. Pracovní položky můžete s Wiki propojit při vytváření stránek s námětem, zpráv k vydání verze a při plánování obsahu. To vám pomůže sledovat pracovní položky přidružené k wiki stránce a ověřit, jaké procento stránky s námětem je hotové.
Propojené pracovní položky se pak zobrazí na Wiki stránce.
Odkaz na Wiki stránku můžete z pracovní položky přidat pomocí nového typu odkazu „Wiki page“ (Wiki stránka).
Uložení Wiki stránky pomocí Ctrl+S
Zjistili jsme, že chcete rychlejší a snadnější způsob uložení wiki stránky. Jednoduchým stisknutím klávesové zkratky Ctrl+S teď můžete stránku uložit s výchozí revizní zprávou a pokračovat v úpravách. Pokud byste chtěli přidat vlastní revizní zprávu, klikněte na dvojitou šipku vedle tlačítka Uložit.
Vložení formátovaného obsahu Wiki jako kódu HTML
Ze všech aplikací založených na prohlížeči, jako jsou Confluence, OneNote, SharePoint a MediaWiki, teď můžete do editoru Markdownu Wiki vložit formátovaný text. Tuto funkci ocení každý, kdo vytvořil formátovaný obsah (například komplexní tabulky) a chce je zobrazit ve Wiki. Jednoduše obsah zkopírujte a vložte jako kód HTML.
Přesunutí stránky ve Wiki pomocí klávesnice
Ve Wiki uživatelé nemohli v minulosti změnit pořadí nebo nadřazenost stránek pomocí klávesnice, což postihlo ty, kteří dávají přednost operacím pomocí klávesnice. Pomocí klávesových zkratek Ctrl+šipka nahoru nebo Ctrl+šipka dolů teď můžete stránky přeuspořádat. Kliknutím na Přesunout stránku v místní nabídce stránky můžete také vybrat novou nadřazenou stránku, pod kterou se má přesunout.
Zvýraznění filtrovaného textu
Při filtrování navigačního podokna ve Wiki se zobrazí celá hierarchie stránek. Pokud například filtrujete stránku s názvem „panel“, zobrazí se ve filtrovaném navigačním podokně také všechny nadřazené stránky. To může být matoucí, protože ve filtrované sadě výsledků se zobrazují stránky, které nemají název „panel“. Při filtrování obsahu ve Wiki se teď zvýrazní hledaný text, takže budete mít přehled o tom, které názvy jsou a nejsou filtrované.
Podobného chování si můžete všimnout také ve všech navigačních podoknech s kódem. Příkladem je navigační okno souborů v žádostech o přijetí změn, potvrzeních, sadách změn a sadách odložených změn.
Náhled obsahu při úpravě Wiki stránek
Víme, že při úpravě obsahu uživatelé téměř vždy několikrát zobrazí Náhled Wiki stránky. Při úpravě každé stránky uživatelé v průměru 1 až 2krát kliknou na Náhled. Kvůli tomu je úprava stránky pomalá a ne zrovna příjemná. Pro ty, kteří Markdown neznají, může být navíc časově náročná. Při úpravě stránky teď vidíte její náhled.
Obecné
Profilové karty
TFS obsahuje několik oblastí, kde se zobrazují informace přidružené ke konkrétní osobě, mimo jiné například žádosti o přijetí změn vytvořené nějakou osobou a pracovní položky přiřazené nějaké osobě. O samotné osobě ale máte omezené informace k tomu, abyste získali úplný kontext. Existující profilovou kartu nahrazuje v TFS nová profilová karta. Aktualizovaná profilová karta vám umožní komunikovat a lépe poznat uživatele ve vašem účtu TFS. Díky integraci s výchozím klientem e-mailu a rychlých zpráv můžou uživatelé služby Active Directory posílat zprávy a chatovat přímo z profilové karty. Uživatelé služby Active Directory také na profilové kartě uvidí organizační hierarchii. Profilové karty lze aktivovat na domovské stránce projektu v oddílu členů týmu, správy verzí, pracovních položek a Wiki, a to kliknutím na ikonu kontaktní karty, profilový obrázek nebo jména uživatelů v komentářích.
Kulaté avatary
Kulaté avatary jsou zde! Všechny profilové obrázky ve službě se teď zobrazují nikoli ve čtvercové, ale v kruhové podobě. Jako příklad uvádíme skutečnou žádost o přijetí změn pro tuto změnu (všimněte si kulatých, ne čtvercových avatarů).
Značky projektu
Projekty teď můžete doplnit o důležitá klíčová slova (značky). Správci můžou značky snadno přidávat a odstraňovat přímo na domovské stránce projektu, což uživatelům umožní rychle zjistit účel a rozsah projektu. Máme naplánované ještě lepší využití značek projektu, proto čekejte na další novinky.
Přeuspořádání skupin oblíbených položek
Skupiny na stránce účtu Oblíbené položky teď můžete přeuspořádat pomocí šipek nahoru a dolů v záhlaví jednotlivých skupin.
Názory a návrhy
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.