Team Foundation Server 2018 — informacje o wersji

Last Update: 2017-11-22

Ten artykuł zawiera informacje dotyczące najnowszej wersji serwera Team Foundation Server 2018. Kliknij przycisk pobierania.

Download the latest version of Team Foundation Server

Szczegółowe informacje na temat serwera Team Foundation Server 2018 można znaleźć na stronie Team Foundation Server Requirements and Compatibility (Wymagania i zgodność serwera Team Foundation Server).


Co nowego w programie TFS 2018 — wideo


Opinia

Chcemy poznać Twoją opinię! Możesz zgłosić problem i śledzić go w portalu społeczności deweloperów oraz uzyskać porady w witrynie Stack Overflow. Jak zawsze, jeśli masz pomysły dotyczące ustalania priorytetów różnych zagadnień, przejdź do witryny UserVoice, aby dodać swój pomysł lub oddać głos na jeden z istniejących.


Data wydania: 15 listopada 2017 r.

Podsumowanie: aktualizacje programu Team Foundation Server 2018

Do serwera Team Foundation Server 2018 dodaliśmy wiele nowych wartościowych możliwości. Niektóre najważniejsze funkcje to:

Funkcje usunięte z tej wersji


Szczegóły: nowości w tej wersji

Śledzenie elementów roboczych

Kreator tworzenia projektu w Internecie

Udoskonaliliśmy środowisko tworzenia nowego projektu zespołowego z poziomu dostępu do Internetu. Teraz ma ono większość funkcji dostępnych podczas tworzenia projektu zespołowego w kliencie programu Visual Studio. Zaletą używania interfejsu internetowego jest to, że nie trzeba mieć pasującej wersji programu Visual Studio. Różnica w przypadku korzystania z programu Visual Studio lub wersji internetowej polega na tym, że wersja internetowa nie aprowizuje raportów w usługach SSRS. Jeśli użyto wersji internetowej procesu tworzenia projektu zespołowego, można uruchomić polecenie tfsconfig w warstwie aplikacji w celu aprowizowania lub aktualizowania raportów usług SSRS. Zobacz szczegóły w części dotyczącej dodawania raportów projektu.

Menedżer szablonów procesu w Internecie

Serwer TFS 2018 umożliwia przekazywanie szablonów procesu za pośrednictwem dostępu do Internetu. Interfejs internetowy to znacznie prostsze środowisko pracy, ponieważ nie trzeba instalować odpowiedniej wersji programu Visual Studio w celu przeprowadzania interakcji z szablonami procesu. W programie Visual Studio 2017 Update 4 i jego starszych wersjach będzie nadal wyświetlane okno dialogowe Menedżer szablonów procesu, mimo że zalecamy korzystanie z interfejsu internetowego. Program Visual Studio 2017 Update 5 i nowsze wersje będą automatycznie przekierowywać Cię do Internetu.

Dostosowywanie nagłówka formularza elementu roboczego

Teraz można dostosować obszar nagłówka formularza elementu roboczego przez zastąpienie istniejących kontrolek lub ukrycie kontrolek, które nie mają zastosowania w danym procesie. Umożliwi to zastąpienie ścieżki obszaru niestandardowym polem zespołu, ukrycie iteracji w przypadku zespołów korzystających przede wszystkim z tablic Kanban oraz zastąpienie przyczyny niestandardowym polem. Pola stanu nie można ukryć ani zastąpić.

Aby uzyskać więcej informacji, zobacz dokumentację dotyczącą elementów układu internetowego i elementów kontrolek.

Formularz mobilnego elementu roboczego

Mamy kompleksowe środowisko, które obejmuje zoptymalizowany wygląd i działanie dla elementów roboczych (rysunek 1). Ułatwia ono interakcję z elementami, które są przypisane do Ciebie, i które śledzisz, odwiedzasz lub edytujesz ostatnio ze swojego telefonu.

Mobile work item query

(Rysunek 1) Zapytanie dotyczące mobilnego elementu roboczego

Oprócz atrakcyjnego wyglądu to środowisko obsługuje zoptymalizowane kontrolki dla wszystkich typów pól (Rysunek 2).

Mobile work item form

(Rysunek 2) Formularz mobilnego elementu roboczego

Dzięki nowej funkcji nawigacji w ramach urządzeń przenośnych (Rysunek 3) użytkownicy mogą nawiązywać połączenie z innymi częściami serwera TFS gotowymi do pracy w środowisku mobilnym i wracać do pełnej witryny pulpitu, gdy zajdzie potrzeba interakcji z innymi centrami.

Mobile navigation

(Rysunek 3) Nawigacja między elementami mobilnymi

Filtrowanie list prac, tablic Kanban, przebiegów i zapytań

Wszystkie nasze środowiska siatki śledzenia elementów roboczych (zapytań, list prac, tablic Kanban, list prac dotyczących przebiegów i zarządzania przypadkami testowymi) korzystają teraz z naszego wspólnego, spójnego składnika filtrowania (Rysunek 4). Poza stosowaniem filtrów słów kluczowych w wyświetlanych kolumnach i wybieraniem tagów można również filtrować według typów elementów roboczych, stanów i wartości Przypisane do, aby szybko uzyskać dostęp do szukanych elementów roboczych.

Filtering on query

(Rysunek 4) Filtrowanie zapytań

Rozwijanie w celu pokazania pustych pól na karcie Kanban

Obecnie masz opcję dodania kolejnych pól do karty, a następnie ukrycia pustych pól (Rysunek 5) w ramach ustawień tablicy, aby usunąć niepotrzebny nieporządek z tablicy. Ta funkcja miała następującą wadę: po ukryciu pustego pola jedynym sposobem zaktualizowania pola było otwarcie formularza elementu roboczego. Dzięki nowo udostępnionej opcji rozwijania na kartach Kanban możesz teraz korzystać z możliwości ukrywania pustych pól w tablicy, ale mieć opcję aktualizowania wybranego pola na karcie za pomocą pojedynczego kliknięcia. Po prostu umieść kursor nad kartą i wyszukaj skierowany w dół cudzysłów ostrokątny u dołu karty, aby zaktualizować ukryte pole.

Hidden field

(Rysunek 5) Ukryte pole na karcie Kanban

Kliknij skierowany w dół cudzysłów ostrokątny u dołu karty, aby zaktualizować pole (Rysunek 6).

Update hidden field

(Rysunek 6) Aktualizacja ukrytego pola na karcie Kanban

Rozszerzenia — blokowanie zapisywania elementu roboczego

Niestandardowe kontrolki, grupy i strony formularza elementu roboczego umożliwiają teraz blokowanie zapisywania elementu roboczego w celi zweryfikowania danych i upewnienia się, że użytkownik wypełni wszystkie wymagane pola informacji przed zapisaniem formularza elementu roboczego.

Wbudowane dodawanie funkcji do planów dostarczania

Pomysły na funkcje mogą pojawić się w każdej chwili, dlatego ułatwiliśmy dodawanie nowych funkcji bezpośrednio do planów dostarczania (Rysunek 7). Wystarczy kliknąć przycisk Nowy element wyświetlany po umieszczeniu wskaźnika w odpowiednim miejscu, wprowadzić nazwę i nacisnąć klawisz Enter. Zostanie utworzona nowa funkcja z oczekiwaną ścieżką obszaru i ścieżką iteracji.

Inline add on delivery plans

(Rysunek 7) Śródwierszowe dodawanie funkcji do planów dostarczania

Kontrola wersji

Rozwidlenia

Na serwerze TFS 2018 dodano obsługę rozwidleń usługi Git (Rysunek 8). Rozwidlenie to kopia repozytorium po stronie serwera. Dzięki rozwidleniom umożliwisz dużej grupie użytkowników współtworzenie zawartości repozytorium bez udzielania im bezpośredniego dostępu do zatwierdzania. W zamian mogą oni zatwierdzać pracę we własnym rozwidleniu repozytorium. Dzięki temu możesz przejrzeć ich zmiany w żądaniu ściągnięcia przed zaakceptowaniem tych zmian w repozytorium centralnym.

Git forks

(Rysunek 8) Rozwidlenia w usłudze Git

System plików GVFS

System plików Git Virtual File System (GVFS) jest już obsługiwany. System plików GVFS umożliwia repozytoriom Git skalowanie do milionów plików dzięki wirtualizacji i optymalizacji działania usługi Git.

Tworzenie folderu w repozytorium przez Internet

W repozytoriach Git i Kontroli wersji serwera Team Foundation można teraz tworzyć foldery w sieci Web (Rysunek 9). Funkcja ta zastępuje rozszerzenie zarządzania folderami, które zostanie poddane procesowi wycofywania.

Aby utworzyć folder, kliknij pozycję Nowy > Folder na pasku poleceń lub w menu kontekstowym:

New folder option

(Rysunek 9) Opcja Nowy folder

W przypadku repozytorium TFVC musisz podać nazwę folderu i zaewidencjonować ją. Puste foldery Git nie są dozwolone, dlatego musisz dodatkowo podać nazwę pliku, zmodyfikować go (opcjonalnie), a następnie zatwierdzić.

Ponadto rozszerzono obsługę tworzenia podfolderów w oknie dialogowym usługi Git Nowy plik (Rysunek 10), które umożliwia teraz używanie ukośników.

New file dialog

(Rysunek 10) Okno dialogowe Nowy plik

Minimapa pliku

Podczas przeglądania lub edytowania pliku można teraz wyświetlić minimapę pliku, aby szybko przejrzeć jego kod (Rysunek 11). Aby włączyć minimapę, otwórz paletę poleceń (naciskając klawisz F1 lub klikając prawym przyciskiem myszy) i wybierz pozycję Toggle Minimap (Przełącz minimapę).

File minimap

(Rysunek 11) Minimapa pliku

Dopasowywanie nawiasów

Podczas przeglądania lub edytowania pliku po lewej stronie są teraz wyświetlane wskazówki, które ułatwiają dopasowywanie nawiasów (Rysunek 12).

Bracket matching

(Rysunek 12) Dopasowywanie nawiasów

Przełączanie wyświetlania białych znaków

Podczas przeglądania lub edytowania pliku można teraz włączać i wyłączać wyświetlanie białych znaków. Wciąż pracujemy nad funkcją umożliwiającą przełączanie wyświetlania białych znaków podczas porównywania. Aby wyświetlić białe znaki (Rysunek 13), otwórz paletę poleceń (naciskając klawisz F1 lub klikając prawym przyciskiem myszy) i wybierz pozycję Przełącz wyświetlanie białych znaków, która umożliwia odróżnienie spacji od znaków tabulacji.

Toggle white space

(Rysunek 13) Przełączanie wyświetlania białych znaków

Ustawianie wyłączania edytowania repozytoriów Kontroli wersji serwera Team Foundation w Internecie

Zespoły, które często używają Kontroli wersji serwera Team Foundation, zapewniają dobrą jakość kodu dzięki korzystaniu z zasad zaewidencjonowania w programie Visual Studio. Jednak ponieważ zasady zaewidencjonowania są wymuszane na kliencie, kod edytowany w Internecie nie podlega tym samym zasadom.

Kilka osób poprosiło o opis sposobu wyłączania edytowania w Internecie w celu zabezpieczenia przed zmianami pomijającymi zasady zaewidencjonowania. Udostępniliśmy metodę wyłączania edytowania (dodawania, usuwania, zmieniania nazw i edytowania) w Internecie dla Kontroli wersji serwera Team Foundation na podstawie projektu/repozytorium.

Aby uniemożliwić edytowanie w Internecie, ze strony Pliki przejdź do obszaru Ustawienia, a następnie Kontrola wersji (Rysunek 14). Kliknij repozytorium Kontroli wersji serwera Team Foundation w drzewie, przejdź do obszaru bazowego Opcje i usuń zaznaczenie pola wyboru Włącz edytowanie w Internecie dla tego repozytorium Kontroli wersji serwera Team Foundation. Domyślnie edytowanie w Internecie jest włączone.

Uwaga

Nie ma to wpływu na edytowanie pliku README ze strony Przegląd projektu.

Turn off web editing

(Rysunek 14) Wyłączanie edytowania w Internecie

Jeśli spróbujesz edytować projekt w sieci Web przy wyłączonej opcji edytowania w Internecie, pojawi się powiadomienie informujące o tym, że edytowanie tego typu jest niedozwolone (Rysunek 15).

Web editing not allowed dialog

(Rysunek 15) Okno dialogowe z informacją o tym, że edytowanie w Internecie jest niedozwolone

Tę funkcję opracowano na podstawie powiązanej sugestii.

Identyfikowanie starych gałęzi

Utrzymywanie repozytorium w porządku przez usuwanie niepotrzebnych gałęzi umożliwia zespołom wyszukiwanie istotnych gałęzi i ustawianie ulubionych elementów na odpowiednim poziomie szczegółowości. Jednak jeśli Twoje repozytorium zawiera wiele gałęzi, zidentyfikowanie nieaktywnych gałęzi do usunięcia może okazać się trudne. Ułatwiliśmy identyfikowanie „starych” gałęzi (gałęzi wskazujących na zatwierdzenia starsze niż 3 miesiące). Aby wyświetlić stare gałęzie, przejdź do obszaru bazowego Nieodświeżone na stronie Gałęzie (Rysunek 16).

Stale branches

(Rysunek 16) Nieodświeżone gałęzie

Wyszukiwanie usuniętej gałęzi i jej ponowne tworzenie

Jeśli gałąź zostanie przypadkowo usunięta z serwera, stwierdzenie, co się z nią stało, może okazać się trudne. Teraz możesz wyszukać usuniętą gałąź, sprawdzić, kto ją usunął, i w razie potrzeby ponownie ją utworzyć.

Aby wyszukać usuniętą gałąź, wprowadź pełną nazwę gałęzi w polu wyszukiwania gałęzi. Zostaną zwrócone wszystkie istniejące gałęzie pasujące do tego tekstu. Zobaczysz również opcję wyszukiwania dokładnego dopasowania na liście usuniętych gałęzi. Kliknij link, aby wyszukać usunięte gałęzie (Rysunek 17).

Search for deleted branches

(Rysunek 17) Wyszukiwanie usuniętych gałęzi

W przypadku znalezienia dopasowania zobaczysz informację o osobie, która usunęła gałąź, i czasie usunięcia. Można będzie również przywrócić gałąź (Rysunek 18).

Restore deleted branches

(Rysunek 18) Przywracanie usuniętych gałęzi

Przywrócenie gałęzi spowoduje jej ponowne utworzenie w obrębie zatwierdzenia, na które ostatnio wskazywała. Nie spowoduje jednak przywrócenia zasad i uprawnień.

Wyszukiwanie zatwierdzań w gałęziach rozpoczynających się prefiksem

Jeśli masz strukturę gałęzi w formacie hierarchicznym, gdzie wszystkie gałęzie mają prefiks tekstowy, ta funkcja może pomóc Ci w wyszukaniu zatwierdzenia we wszystkich gałęziach rozpoczynających się od tego prefiksu tekstowego. Jeśli na przykład chcesz zobaczyć, czy zatwierdzenie znajduje się we wszystkich gałęziach z prefiksem „dev”, po prostu wpisz w polu wyszukiwania tekst „dev” i wybierz pozycję Wyszukaj w gałęziach rozpoczynających się od „dev” (Rysunek 19).

Search for a commit

(Rysunek 19) Wyszukiwanie zatwierdzenia

Bardziej rozbudowane objaśnienia żądania ściągnięcia na stronie szczegółów zatwierdzenia

Objaśnienie żądania ściągnięcia na stronie szczegółów zatwierdzenia zawiera istotniejsze informacje ułatwiające skuteczniejsze diagnozowanie (Rysunek 20). Teraz w objaśnieniu wyświetlane jest również pierwsze żądanie ściągnięcia, które wprowadziło zatwierdzenie do dowolnej gałęzi i żądanie ściągnięcia skojarzone z gałęzią domyślną.

Pull request callout

(Rysunek 20) Objaśnienie do żądania ściągnięcia

Filtrowanie widoku drzewa w kodzie

Teraz w celu przejścia do plików nie musisz przewijać wszystkich plików, które mogły zostać zmodyfikowane przez zatwierdzenie. Widok drzewa na stronie szczegółów zatwierdzenia, żądań ściągnięcia, szczegółów zestawu na półce i szczegółów grupy zmian obsługuje teraz filtrowanie plików i folderów. Jest to inteligentny filtr, który pokazuje podrzędne pliki folderu w przypadku filtrowania według nazwy folderu oraz zwinięty widok drzewa pliku w celu wyświetlenia hierarchii plików w przypadku filtrowania według nazwy pliku.

Wyszukaj filtr plików lub folderów w drzewie zatwierdzeń (Rysunek 21) i (Rysunek 22):

Find a file or folder

(Rysunek 21) Wyszukiwanie pliku lub folderu

Filtered view

(Rysunek 22) Filtrowany widok drzewa zatwierdzeń

Strona aktualizacji gałęzi nosi teraz nazwę Wypchnięcia

Strona Aktualizacje gałęzi ma ogromną wartość. Jest ona jednak ukryta jako obszar bazowy w centrum Historia. Teraz strona aktualizacji gałęzi będzie widoczna jako centrum o nazwie Wypchnięcia (Rysunek 23) w obszarze Kod, wraz z obszarami Zatwierdzenia, Gałęzie, Tagi i Żądania ściągnięcia. Nowy adres URL strony wypchnięć: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. Stare adresy URL będą nadal działać.

Pushes page

(Rysunek 23) Strona wypchnięć

Równocześnie nazwa centrum Historia została zmieniona na Zatwierdzenia (Rysunek 24), ponieważ centrum przedstawia tylko zatwierdzenia. Otrzymaliśmy opinie wskazujące, że rozwiązywanie problemów związanych z zatwierdzeniami sprawiało użytkownikom trudność, ponieważ szczegółowy czas był pokazywany w widoku listy zatwierdzeń tylko po najechaniu kursorem. Teraz w widoku listy zatwierdzeń będzie wyświetlana data i godzina wystąpienia w formacie dd/mm/rr gg:mm. Nowy adres URL strony zatwierdzeń: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. Stare adresy URL będą nadal działać.

Commits page

(Rysunek 24) Strona zatwierdzeń

Zachowywanie nazwy pliku przy przechodzeniu od plików do zatwierdzeń

Wysłuchaliśmy opinii użytkowników, którzy informowali o tym, że podczas filtrowania katalogu w celu wyszukania określonego pliku w obszarze bazowym Pliki centrum Kod i późniejszym przejściu do obszaru bazowego Historia nazwa pliku nie była utrzymywana, jeśli zatwierdzenie spowodowało zmianę ponad 1000 plików. W wyniku użytkownicy musieli ładować więcej plików i filtrować zawartość w celu znalezienia plików, co wpływało na produktywność pracy. Deweloperzy zazwyczaj pracują w tym samym katalogu i chcą zachować używane katalogi w celu śledzenia zmian. Teraz utrzymujemy nazwę pliku podczas przenoszenia między obszarami bazowymi centrum kodu niezależnie od liczby plików zmienianych w ramach zatwierdzenia. Oznacza to, że nie musisz klikać opcji Załaduj więcej, aby odnaleźć wybrany plik.

Wyświetlanie tagów usługi Git

Wszystkie tagi w repozytorium można wyświetlić na stronie Tagi (Rysunek 25). Jeśli zarządzasz wszystkimi tagami jako wydaniami, użytkownik może odwiedzić stronę tagów i uzyskać ogólny widok wszystkich wydań produktu.

View Git tags

(Rysunek 25) Wyświetlanie tagów usługi Git

Można łatwo odróżnić tagi lekkie od tagów z adnotacjami. W tagach z adnotacjami oprócz skojarzonego zatwierdzenia przedstawiona jest osoba oznaczająca tagiem oraz data utworzenia, a tagi lekkie zawierają tylko informacje o zatwierdzeniu.

Usuwanie tagów Git

Czasami chcesz usunąć tag z repozytorium zdalnego. Przyczyną może być błąd pisowni w nazwie tagu lub oznaczenie tagiem niewłaściwego zatwierdzenia. Tagi można łatwo usuwać z interfejsu użytkownika w sieci Web, klikając menu kontekstowe tagu na stronie Tagi i wybierając polecenie Usuń tag (Rysunek 26).

Ostrzeżenie

Usuwanie tagów z repozytoriów zdalnych powinno być przeprowadzone z rozwagą.

Delete git tags

(Rysunek 26) Usuwanie tagów usługi Git

Filtrowanie tagów usługi Git

W starych repozytoriach liczba tagów może zwiększyć się znacznie wraz z upływem czasu; niektóre repozytoria mogą również zawierać tagi utworzone w hierarchiach, co może utrudnić wyszukiwanie tagów.

Jeśli na stronie Tagi nie można znaleźć szukanego tagu, można po prostu wyszukać nazwę tagu przy użyciu filtru w górnej części strony Tagi (Rysunek 27).

Filter Git tags

(Rysunek 27) Filtrowanie tagów usługi Git

Zabezpieczenia tagów usługi Git

Teraz można udzielać użytkownikom repozytorium szczegółowych uprawnień, które umożliwią zarządzanie tagami. Użytkownikom można przyznać uprawnienia do usuwania tagów lub zarządzania nimi w tym interfejsie (Rysunek 28).

Git tag security

(Rysunek 28) Zabezpieczenia tagów usługi Git

Przeczytaj więcej na temat tagów usługi Git w blogu dotyczącym metodyki Microsoft DevOps.

Automatyczne kończenie elementów roboczych podczas kończenia żądań ściągnięcia

Jeśli połączysz elementy robocze z żądaniami ściągnięcia, utrzymywanie aktualnych danych stanie się o wiele prostsze. Obecnie po ukończeniu żądania ściągnięcia dostępna będzie opcja automatycznego ukończenia połączonych elementów roboczych po pomyślnym scaleniu żądania ściągnięcia (Rysunek 29). Jeśli używasz zasad i ustawisz automatyczne kończenie żądań ściągnięcia, zobaczysz tę samą opcję. Nie będzie trzeba już pamiętać o ponownym przechodzeniu do elementów roboczych w celu zaktualizowania ich stanu po ukończeniu żądania ściągnięcia. Ta czynność zostanie wykonana automatycznie.

Complete linked work items

(Rysunek 29) Kończenie połączonych elementów roboczych

Resetowanie głosów w przypadku wypychania/nowej iteracji

Zespoły, które wolą bardziej rygorystyczne przepływy pracy zatwierdzania w żądaniu ściągnięcia, mogą teraz wyrazić zgodę na resetowanie głosów w przypadku wypychania nowych zmian (Rysunek 30). Nowe ustawienie jest opcją zasad Wymagaj minimalnej liczby recenzentów.

Reset votes setting

(Rysunek 30) Resetowanie ustawienia głosów

Ustawienie tej opcji spowoduje, że wszystkie głosy wszystkich recenzentów będą resetowane zawsze po zaktualizowaniu źródłowej gałęzi żądania ściągnięcia. Po włączeniu tej opcji wpis zostanie zarejestrowany na osi czasu żądania ściągnięcia za każdym razem, gdy głosy zostaną zresetowane (Rysunek 31).

Reset votes in timeline

(Rysunek 31) Resetowanie głosów na osi czasu

Filtrowanie drzewa żądań ściągnięcia według nazwy pliku

Znalezienie określonego pliku w żądaniu ściągnięcia jest łatwiejsze niż kiedykolwiek. Nowe pole filtru w widoku Pliki umożliwia użytkownikom odfiltrowywanie listy plików w widoku drzewa (Rysunek 32).

Find file or folder in pull request

(Rysunek 32) Wyszukiwanie pliku lub folderu w żądaniu ściągnięcia

Filtr dopasowuje wartość do dowolnej części ścieżki plików w żądaniu ściągnięcia, dlatego możesz wyszukiwać według nazwy folderu, częściowych ścieżek, nazw plików lub rozszerzeń (Rysunek 33).

Find results

(Rysunek 33) Wyszukiwanie wyników

Więcej opcji filtrowania komentarzy do żądania ściągnięcia

Komentarze w przeglądzie żądania ściągnięcia i w widoku plików mają teraz te same opcje (Rysunek 34). Możesz również odfiltrować dyskusje tak, aby wyświetlić tylko te, w których bierzesz udział.

PR comment filtering

(Rysunek 34) Filtrowanie komentarzy do żądania ściągnięcia

Wyświetlanie różnic oryginału dla komentarzy dotyczących kodu w szczegółach żądania ściągnięcia

Czasami trudno jest zrozumieć komentarz do żądania ściągnięcia po zmianie kodu, do którego ten komentarz się odwołuje (przypadki wielokrotnego wprowadzenia żądanych zmian) (Rysunek 35).

View original diff

(Rysunek 35) Wyświetlanie różnic oryginału

Obecnie w takiej sytuacji zobaczysz wskaźnik z liczbą aktualizacji, który można kliknąć, aby sprawdzić, jak wyglądał kod w momencie utworzenia komentarza (Rysunek 36).

Update badge

(Rysunek 36) Wskaźnik aktualizacji

Zwijane komentarze do żądania ściągnięcia

Przegląd kodu to krytyczna część pracy z żądaniem ściągnięcia, więc dodaliśmy nowe funkcje, które ułatwiają recenzentom skoncentrowanie się na kodzie. Recenzenci kodu mogą łatwo ukrywać komentarze, aby nie przeszkadzały podczas przeglądania nowego kodu po raz pierwszy (Rysunek 37).

Hide comments

(Rysunek 37) Ukrywanie komentarzy

Ukrywanie komentarzy (Rysunek 38) polega na schowaniu ich w widoku drzewa i zwinięciu wątków komentarzy w widoku plików:

Collapsed comments

(Rysunek 38) Zwinięte komentarze

Jeśli komentarze zostały zwinięte, można je łatwo rozszerzyć, klikając ikonę na marginesie, a następnie ponownie zwinąć kolejnym kliknięciem. Etykietki narzędzi (Rysunek 39) ułatwiają podejrzenie komentarza bez wyświetlania całego wątku.

Collapsed comment tooltip

(Rysunek 39) Etykietka narzędzia zwiniętego komentarza

Listy zadań w opisach żądania ściągnięcia i komentarzach do niego

W przypadku przygotowywania żądania ściągnięcia lub dodawania komentarzy masz czasami krótką listę rzeczy do śledzenia, ale potem kończy się na edytowaniu tekstu lub dodawaniu wielu komentarzy. Lekkie listy zadań to dobry sposób śledzenia postępu na liście zadań do wykonania jako twórca lub recenzent żądania ściągnięcia w opisie lub jednym, skonsolidowanym komentarzu. Kliknij pasek narzędzi języka znaczników Markdown, aby rozpocząć pracę lub zastosować formatowanie do zaznaczonego tekstu (Rysunek 40).

Task list toolbar

(Rysunek 40) Pasek narzędzi listy zadań

Po dodaniu listy zadań (Rysunek 41) możesz po prostu zaznaczyć pola, aby oznaczyć elementy jako ukończone. Te informacje są wyrażane i przechowywane w komentarzu jako elementy [ ] i [x] w języku znaczników Markdown. Aby uzyskać więcej informacji, zobacz Markdown guidance (Wskazówki dotyczące znaczników markdown).

Task list

(Rysunek 41) Lista zadań

Możliwość polubienia komentarzy w żądaniach ściągnięcia

Pokaż zainteresowanie komentarzem do żądania ściągnięcia za pomocą pojedynczego kliknięcia przycisku polubienia (Rysunek 42). Możesz wyświetlić listę wszystkich osób, które polubiły komentarz, ustawiając kursor na przycisku.

Like pull request comments

(Rysunek 42) Oznaczanie komentarza do żądania ściągnięcia jako polubionego

Udoskonalony przepływ pracy w przypadku zatwierdzania z sugestiami

Użycie opcji automatycznego ukończenia (Rysunek 43) żądań ściągnięcia to świetny sposób poprawienia wydajności pracy, ale nie należy skracać żadnych aktywnych dyskusji z recenzentami kodu. W celu usprawnienia tych dyskusji głos Zatwierdź z sugestiami będzie teraz powodować wyświetlenie monitu, gdy żądanie ściągnięcia zostanie ustawione na automatyczne ukończenie. Użytkownik będzie mieć opcję anulowania automatycznego ukończenia, tak aby można było zapoznać się z jego opinią, lub utrzymania ustawienia automatycznego ukończenia i zezwolenia na automatyczne ukończenie żądania ściągnięcia po spełnieniu warunków wszystkich zasad.

Cancel auto-complete dialog

(Rysunek 43) Okno dialogowe anulowania automatycznego ukończenia

Obsługa filtrowania ścieżek na potrzeby powiadomień usługi Git

Zamiast otrzymywać powiadomienia dla wszystkich folderów w repozytorium, można teraz wybrać opcję otrzymywania powiadomień, gdy członkowie zespołu tworzą żądania ściągnięcia lub wypychają kod tylko w istotnych dla Ciebie folderach. Podczas tworzenia niestandardowych subskrypcji powiadomień e-mail dla żądania ściągnięcia usługi Git lub wypchnięcia usługi Git zobaczysz nową opcję filtrowania tych powiadomień według ścieżki folderu (Rysunek 44).

Path filtering for notifications

(Rysunek 44) Filtrowanie ścieżek według powiadomień

Zaktualizowane szablony wiadomości e-mail na potrzeby przepływów pracy żądań ściągnięcia

Alerty e-mail dotyczące żądań ściągnięcia zostały odświeżone — są teraz bardziej czytelne i zwięzłe oraz umożliwiają przeprowadzenie akcji (Rysunek 45). Wiersz tematu będzie rozpoczynać się od tytułu żądania ściągnięcia, a informacje pomocnicze, takie jak nazwa i identyfikator repozytorium, zostaną przeniesione na koniec. Do tematu dodaliśmy nazwę autora, co ułatwi stosowanie reguł i filtrów w oparciu o informacje o osobie, która utworzyła żądanie ściągnięcia.

Treść alertów e-mail ma odświeżony szablon: najpierw przedstawiane jest podsumowanie przyczyn wysłania alertu, a następnie podawane są metadane o krytycznym znaczeniu (tytuł, nazwy gałęzi i opis) oraz główny przycisk wezwania do akcji. Dodatkowe szczegóły, takie jak recenzenci, pliki i zatwierdzenia, są uwzględniane w dalszej części wiadomości e-mail.

Improved email template

(Rysunek 45) Udoskonalony szablon wiadomości e-mail

W przypadku większości alertów wezwanie do akcji (Rysunek 46) będzie dotyczyć wyświetlenia żądania ściągnięcia w Internecie. Jeśli jednak otrzymasz powiadomienie związane z określonym komentarzem, wezwanie do akcji będzie łączyć się bezpośrednio z tym komentarzem, co ułatwi wyszukanie kodu i poprzedniej rozmowy dla danego kontekstu.

Email call-to-action

(Rysunek 46) Wezwanie do akcji w wiadomości e-mail

Zaktualizowane szablony wiadomości e-mail dla powiadomień wypychanych

Zaktualizowano powiadomienia wypychane, aby dopasować je do nowych szablonów wiadomości e-mail, które są teraz bardziej czytelne i zwięzłe oraz umożliwiają wykonanie akcji (Rysunek 47). Wiersz tematu pomaga wyraźnie odróżnić wypychane wiadomości e-mail oraz wskazać gałąź, repozytorium i autora. Ponadto zawiera on podsumowanie liczby zatwierdzeń zawartych w wypychaniu. Zmiany te ułatwiają również tworzenie reguł i filtrów, które pomagają zarządzać powiadomieniami e-mail.

W treści wiadomości e-mail, spójnej z treścią innych wiadomości, podkreślono, kto i dlaczego wysłał tę wiadomość e-mail, oraz szczegółowo opisano, co się stało. W przypadku alertów wypychanych dołączane są szczegółowe informacje o repozytorium, gałęzi, plikach i zatwierdzeniach, co pomaga poinformować adresatów o zakresie zmian. W przypadku alertów wypychanych główne wezwanie do działania to Wyświetl wypchnięcie. Powoduje ono otwarcie widoku wypchnięć dla wypchnięcia, które wygenerowało alert.

Push template

(Rysunek 47) Szablon wypchnięcia

Wiki

Każdy projekt obsługuje obecnie własną witrynę typu Wiki (Rysunek 48). Teraz możesz łatwo pisać strony, które pomogą członkom zespołu zrozumieć projekt, używać go i współtworzyć jego zawartość.

Wiki page

(Rysunek 48) Strona Wiki żądania ściągnięcia

Oto niektóre kluczowe funkcje nowej witryny Wiki:

Title wiki

(Rysunek 49) Tytuł strony Wiki żądania ściągnięcia

  • Obsługa tagów HTML w języku znaczników markdown (Rysunek 50).

Wiki HTML tags

(Rysunek 50) Znaczniki HTML strony żądania ściągnięcia

  • Wygodna zmiana rozmiaru obrazów w folderze kodu markdown (Rysunek 51).

Image resize

(Rysunek 51) Zmienianie rozmiaru obrazu żądania ściągnięcia

  • Zaawansowane okienko zarządzania stronami, w którym można zmieniać kolejność i elementy nadrzędne stron, a także zarządzać stronami.
  • Możliwość filtrowania stron według tytułu w dużych witrynach typu Wiki (Rysunek 52).

Wiki menu

(Rysunek 52) Menu strony Wiki żądania ściągnięcia

Dowiedz się więcej na temat rozpoczynania pracy z witryną Wiki.

  • Jeśli coraz częściej używasz witryny Wiki, prawdopodobnie w pewnym momencie zapiszesz niezamierzone zmiany. Teraz możesz przywrócić wersję strony typu Wiki, przechodząc do szczegółów zmian i klikając przycisk Przywróć (Rysunek 53).

Wiki revert button

(Rysunek 53) Przycisk Przywróć na stronie Wiki żądania ściągnięcia

podczas tworzenia stron Wiki zaobserwowaliśmy wzorzec, gdzie w spisie treści na stronie Wiki uwzględnione są nieistniejące linki (Rysunek 54). Użytkownicy będą klikali te linki, próbując utworzyć rzeczywistą stronę. Poprzednio ten scenariusz był obsługiwany przez wyświetlenie ostrzeżenia o tym, że link został przerwany lub że strona nie istnieje. Teraz obsługujemy ten scenariusz jako główny w przypadku witryny Wiki, umożliwiając Ci w zamian tworzenie stron.

Create wiki page

(Rysunek 54) Tworzenie strony Wiki żądania ściągnięcia

Tworzenie linku do strony docelowej typu Wiki

Witryna typu Wiki obsługuje teraz tworzenie linków do sekcji docelowych znajdujących się na jednej stronie lub na kilku stronach, co jest bardzo przydatne podczas tworzenia spisu treści. Przy użyciu następującej składni można odwoływać się do nagłówka tej samej lub innej strony:

  • Ta sama strona:[text to display](#section-name)
  • Inna strona:[text to display](/page-name#section-name)

Zakończyliśmy obsługę rozszerzenia Wiki w witrynie Marketplace. Jeśli jesteś istniejącym użytkownikiem rozszerzenia Wiki, możesz migrować strony do nowej witryny Wiki za pomocą tego narzędzia migracji. Dowiedz się więcej na temat sposobu migrowania istniejących stron typu Wiki do nowej witryny Wiki.

Zarządzanie pakietami

Aktualizacje środowiska zarządzania pakietami

Adresy URL pakietów współpracują teraz z nazwą i wersją pakietu, zamiast korzystać z identyfikatorów GUID. Ułatwia to ręczne tworzenie adresów URL pakietów (Rysunek 55). Format: \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package.

Package URL

(Rysunek 55) Adres URL pakietu żądania ściągnięcia

W odpowiedzi na tę sugestię w witrynie UserVoice można teraz ukrywać usunięte wersje pakietów (Rysunek 56) przed wszystkimi użytkownikami kanału informacyjnego (koniec z przekreślonymi pakietami).

Hide deleted packages

(Rysunek 56) Ukrywanie usuniętych pakietów

Każdą akcję, którą można było wykonać na stronie szczegółów, teraz można wybrać z menu kontekstowego na liście pakietów.

Lista pakietów zawiera nową kolumnę Ostatnie wypchnięcie (Rysunek 57), w której znajdują się daty w czytelnej postaci, dzięki czemu można łatwo wyszukiwać ostatnio zaktualizowane pakiety.

Last pushed column

(Rysunek 57) Kolumna Ostatnie wypchnięcie

Pakiety Maven

Rozpoczęliśmy obsługę hostowania artefaktów Maven na serwerze TFS 2018 (Rysunek 58). Artefakty Maven umożliwiają deweloperom języka Java łatwe udostępnianie kodu i składników. Zapoznaj się z naszym przewodnikiem z wprowadzeniem, aby uzyskać informacje na temat sposobu udostępniania artefaktów Maven za pomocą funkcji zarządzania pakietami.

Maven packages

(Rysunek 58) Pakiety Maven

Nowe ujednolicone zadanie NuGet

Połączyliśmy zadania NuGet Restore, NuGet Packager i NuGet Publisher w ramach jednego, ujednoliconego zadania kompilacji NuGet, aby lepiej dopasować je do biblioteki zadań kompilacji; nowe zadanie domyślnie używa rozwiązania NuGet 4.0.0. W związku z tym wycofaliśmy z użytku stare zadania i zalecamy w wolnym czasie przejście do nowego zadania NuGet. Ta zmiana pokrywa się z falą udoskonaleń przedstawionych poniżej, do których będziesz uzyskiwać dostęp tylko za pośrednictwem połączonego zadania.

W ramach tej pracy wydaliśmy również nowe zadanie NuGet Tool Installer, które kontroluje dostępną wersję pakietu NuGet dostępną w ścieżce PATH i używaną przez nowe zadanie NuGet. Dlatego w celu użycia nowszej wersji pakietu NuGet wystarczy dodać zadanie NuGet Tool Installer na początku kompilacji (Rysunek 59).

Nuget task

(Rysunek 59) Zadanie NuGet

Przeczytaj więcej na temat korzystania z najnowszego rozwiązania NuGet w swojej kompilacji na blogu Microsoft DevOps.

Opcja zezwalania na pomijanie duplikatów w rozwiązaniu NuGet

Wielu klientów rozwiązania NuGet informowało nas, że generują oni zestaw pakietów, z których tylko niektóre mogły mieć aktualizacje (i w związku z tym zaktualizowane numery wersji). Nowe zadanie kompilacji NuGet ma nową opcję Zezwalaj na pomijanie duplikatów, która umożliwi kontynuowanie zadania w przypadku próby wypchnięcia pakietów do kanału informacyjnego usług VSTS/serwera TFS, jeśli wersja jest już używana.

Aktualizacje zadania kompilacji npm

Bez względu na to, czy kompilujesz projekt npm w systemie Windows lub Linux, czy też na komputerze Mac, nowe zadanie kompilacji NPM będzie działać bezproblemowo. Zmieniliśmy również organizację zadania tak, aby ułatwić instalację npm i publikowanie npm . W przypadku instalacji i publikowania uprościliśmy pozyskiwanie poświadczeń, tak aby poświadczenia dla rejestrów wymienionych w pliku .npmrc Twojego projektu mogły być bezpiecznie przechowywane w punkcie końcowym usługi. Alternatywnie — jeśli używasz kanału informacyjnego usług VSTS/serwera TFS oferujemy selektor, który umożliwia wybranie kanału informacyjnego, a następnie wygenerowanie pliku .npmrc z wymaganymi poświadczeniami, które są używane przez agenta kompilacji.

Rozwiązanie Maven obsługuje teraz uwierzytelnione kanały informacyjne

Inaczej niż w przypadku rozwiązań NuGet i npm, zadanie kompilacji Maven nie współpracowało wcześniej z uwierzytelnionymi kanałami informacyjnymi. Zaktualizowaliśmy zadanie Maven, aby można było łatwo pracować z kanałami informacyjnymi usług VSTS/serwera TFS (Rysunek 60).

dotnet task

(Rysunek 60) Zadanie dotnet

Zadanie dotnet obsługuje uwierzytelnione kanały informacyjne i projekty internetowe

W następnej wersji głównej zadania dotnet (2.x) uwzględniono wiele wniosków pochodzących z opinii użytkowników oraz usunięto zestaw usterek śledzonych od pewnego czasu.

  1. Po pierwsze zadanie dotnet obsługuje teraz uwierzytelnione źródła pakietów, takie jak funkcja zarządzania pakietami, więc nie trzeba już używać zadania NuGet w celu przywrócenia pakietów z prywatnych źródeł pakietów.
  2. Zachowanie pola Ścieżka do projektów zostało zmienione w wersji 2.0 zadania. W poprzednich wersjach zadania, jeśli nie znaleziono plików projektu pasujących do wybranego wzorca, zadanie rejestrowało ostrzeżenie i kończyło się powodzeniem. W takich scenariuszach czasami może być trudno zrozumieć, dlaczego kompilacja zakończyła się powodzeniem, ale zależności nie zostały przywrócone. Obecnie zadanie będzie kończyć się niepowodzeniem, jeśli pliki projektu pasujące do określonego wzorca nie zostaną znalezione. To zachowanie jest zgodne z zachowaniem innych zadań oraz łatwe do zrozumienia i stosowania.
  3. W poprzednich wersjach polecenia publikowania zadania zadanie modyfikowało ścieżkę wyjściową, umieszczając wszystkie pliki w folderze, który otrzymywał nazwę zgodną z nazwą pliku projektu, nawet po przekazaniu jawnej ścieżki wyjściowej. Utrudniało to łączenie poleceń w ramach łańcucha. Teraz masz kontrolę nad wyjściową ścieżką pliku.

Wydaliśmy również nowe zadanie dotnet Tool Installer, które kontroluje dostępną wersję dotnet dostępną w ścieżce PATH i używaną przez nowe zadanie dotnet. Dlatego w celu użycia nowszej wersji rozwiązania dotnet wystarczy dodać zadanie dotnet Tool Installer na początku kompilacji.

Praca poza kontem/kolekcją

Obecnie możesz łatwiej pracować z kanałami informacyjnymi (Rysunek 61) spoza serwera TFS lub konta usług VSTS bez względu na to, czy są to kanały informacyjne zarządzania pakietami na innym koncie usług VSTS, czy też kanały informacyjne inne niż powiązane z funkcją zarządzania pakietami, takie jak NuGet.org/npmjs.com, Artifactory lub MyGet (Rysunek 60). Dedykowane typy punktu końcowego usługi dla rozwiązań NuGet i npm ułatwiają wprowadzanie poprawnych poświadczeń i umożliwianie bezproblemowego działania zadań kompilacji w ramach operacji pobierania pakietów i wypychania pakietów.

Feeds to use

(Rysunek 61) Kanał informacyjny do użycia

Selektor kanału informacyjnego w przypadku kanałów informacyjnych usług VSTS/serwera TFS

Zawsze zalecamy zewidencjowanie pliku konfiguracji (np. NuGet.Config, npmrc itp.), dzięki czemu repozytorium źródłowe będzie zawierać rekord miejsca, z którego pochodzą pakiety. Otrzymaliśmy jednak informacje o grupie scenariuszy, dla której nie jest to idealne rozwiązanie. Dodaliśmy więc nową opcję używania pakietów usług VSTS / serwera TFS, która pozwala na wybranie kanału informacyjnego i automatyczne generowanie pliku konfiguracji do użycia podczas danego kroku kompilacji (Rysunek 62).

Feed picker

(Rysunek 62) Wybór kanału informacyjnego

Kompilowanie i wydawanie

Usuwanie obsługi kompilacji XAML

Na serwerze TFS 2015 wprowadziliśmy internetowy, międzyplatformowy system kompilacji. Na serwerze TFS 2018 jest to jedyny obsługiwany model. Kompilacje XAML nie są obsługiwane w przypadku serwera TFS 2018. Zachęcamy Cię do migracji kompilacji XAML. Jeśli chcesz przygotować się do migracji i musisz kontynuować korzystanie z kompilacji XAML, nie uaktualniaj serwera do wersji TFS 2018.

W przypadku uaktualniania serwera do wersji TFS 2018:

  • Jeśli masz dane kompilacji XAML w kolekcji projektów zespołowych, otrzymasz ostrzeżenie dotyczące usuwania funkcji kompilacji XAML.

  • Na serwerze TFS 2018 można będzie wyświetlić ukończone kompilacje XAML, ale nowych nie będzie można dodawać do kolejki.

  • Na serwerze TFS 2018 nie ma agenta ani kontrolera kompilacji XAML i nie można skonfigurować starszej wersji agenta ani kontrolera kompilacji XAML do pracy z serwerem TFS 2018.

Aby uzyskać informacje na temat naszego planu wycofywania kompilacji XAML, zobacz wpisy na blogu dotyczące rozwijających się możliwości automatyzacji kompilacji usług TFS/Team Services.

Eksportowanie i importowanie definicji kompilacji

Definicje kompilacji są implementowane wewnętrznie jako pliki JSON, dzięki czemu możesz widzieć szczegóły zmian w historii pliku. Możesz już klonować i tworzyć szablony na podstawie definicji kompilacji, ale wielu użytkowników chciało tworzyć kopię logiki kompilacji elementu konfiguracji i ponownie używać jej w innym projekcie zespołowym. Było to jedno z 10 najpopularniejszych żądań w witrynie UserVoice.

Z przyjemnością informujemy, że teraz jest to możliwe (Rysunek 63) i (Rysunek 64)!

Export build definition

(Rysunek 63) Eksportowanie definicji kompilacji

Import build definition

(Rysunek 64) Importowanie definicji kompilacji

Rozszerzenia z szablonami kompilacji

Szablony kompilacji umożliwiają tworzenie planu bazowego dla użytkowników, którzy chcą rozpocząć definiowanie procesu kompilacji. Obecnie niektóre z nich są dostępne jako wbudowane. Nowe szablony można było przekazywać do konta, ale twórcy rozszerzeń nigdy nie mogli uwzględniać nowych szablonów jako części rozszerzenia. Obecnie możesz uwzględniać szablony kompilacji w swoich rozszerzeniach. Na przykład:

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

Pełen przykład można znaleźć pod adresem https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

Porada

Ta opcja umożliwia oferowanie i udostępnianie tego samego szablonu niestandardowego we wszystkich projektach zespołowych.

Oznaczanie zadania jako przestarzałego

Obecnie można oznaczyć zadanie jako przestarzałe w rozszerzeniu. Aby działało to prawidłowo, należy dodać do najnowszej wersji zadania następującą zmienną:

"deprecated": true

Gdy użytkownik wyszukuje przestarzałe zadania (Rysunek 65), wypychamy je na koniec i grupujemy w zwijanej sekcji, która domyślnie jest zwinięta. Jeśli definicja już używa przestarzałego zadania, pokazujemy wskaźnik zadania przestarzałego, aby zachęcić użytkowników do przełączenia się do zadania, które je zastępuje.

Deprecated task badge

(Rysunek 65) Wskaźnik zadania przestarzałego

Aby pomóc użytkownikom dowiedzieć się więcej na temat zadania zastępczego, wspomnij o nim w opisie zadania (Rysunek 66). Opis następnie skieruje użytkowników zadania we właściwym kierunku z wykazu zadań i istniejących definicji kompilacji/wydań.

Deprecated task description

(Rysunek 66) Opis zadania przestarzałego

Kontrola widoczności sekcji za pośrednictwem sekcji kompilacji dodanych przez współautorów

Poprzednio w przypadku korzystania z rozszerzenia zawierającego zadania kompilacji i sekcji podsumowania kompilacji użytkownik widział sekcję podsumowania kompilacji, nawet jeśli nie korzystał z zadania kompilacji w danej kompilacji. Teraz można wybrać opcję ukrycia lub pokazania tej sekcji na stronie podsumowania kompilacji, dodając następujący wiersz w kodzie rozszerzenia i ustawiając wartość na true lub false:

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

Przejrzyj przykład uwzględniony w repozytorium vsts-extension-samples firmy Microsoft.

Obsługa grupy zmiennych

Grupy zmiennych były dostępne do użycia w definicjach wersji, a teraz są gotowe do użycia także w definicjach kompilacji.Grupy zmiennych były dostępne do użycia w definicjach wersji, a teraz są gotowe do użycia także w definicjach kompilacji. Dowiedz się więcej na temat tworzenia grupy zmiennych. Ta funkcja została opracowana i oznaczona jako priorytetowa w oparciu o powiązane sugestie dotyczące zmiennych kompilacji/wydania na poziomie projektu i grup zmiennych w definicjach kompilacji.

Praca z bezpiecznymi plikami, takimi jak certyfikaty firmy Apple

Dodaliśmy bibliotekę bezpiecznych plików (Rysunek 67) ogólnego przeznaczenia.

Secure files library

(Rysunek 67) Zabezpieczanie biblioteki plików

W bibliotece bezpiecznych plików można przechowywać pliki, takie jak certyfikaty podpisywania, profile aprowizacji firmy Apple, pliki magazynu kluczy systemu Android i klucze SSH, na serwerze bez konieczności zatwierdzania ich w repozytorium źródłowym.

Zawartość bezpiecznych plików jest szyfrowana i może być używana tylko podczas procesów wydawania lub kompilacji przez odwołanie się do nich z zadania. Bezpieczne pliki są udostępniane w wielu definicjach kompilacji i wydawania w projekcie zespołowym na podstawie ustawień zabezpieczeń. Bezpieczne pliki są zgodne z modelem zabezpieczeń biblioteki.

Dodaliśmy także niektóre zadania firmy Apple, które korzystają z tej nowej funkcji:

Wstrzymywanie definicji kompilacji

Definicje kompilacji można teraz wstrzymać lub wyłączyć. Jeśli planujesz zmienić definicję kompilacji i chcesz uniknąć kolejkowania nowych kompilacji w czasie wprowadzania zmian, po prostu wyłącz definicję kompilacji. Podobnie w przypadku uaktualniania maszyn z zainstalowanym agentem możesz wybrać opcję wstrzymania definicji kompilacji. Dzięki temu nowe żądania kompilacji będą akceptowane przez usługę VSTS, ale do momentu wznowienia definicji będą one przechowywane w kolejce bez uruchamiania.

Obsługa walidacji danych wejściowych zadań

Zadania polegające na wpisywaniu parametrów w definicjach kompilacji mogą być podatne na błędy. Dzięki walidacji danych wejściowych zadań autorzy zadań mogą mieć pewność, że podano odpowiednie wartości. Wyrażenia walidacyjne są zgodne ze znaną składnią wyrażeń używaną do określania warunków zadań. Oprócz ogólnych funkcji obsługiwanych przez warunki zadań mogą one korzystać z dowolnych z obsługiwanych funkcji, w tym adresów URL, protokołu IPV4, poczty e-mail, zakresu numerów, algorytmu sha1, długości lub dopasowania.

Więcej informacji o przeznaczeniu i używaniu tej funkcji można znaleźć na stronie repozytorium zadań usługi VSTS.

Nowy edytor definicji wydania

W ramach starań na rzecz odświeżenia środowisk kompilowania i wydawania przeprojektowaliśmy edytor definicji wersji, aby zwiększyć intuicyjność jego obsługi i usunąć niektóre problemy oraz dodać nowe możliwości. Działanie jednej z najbardziej zaawansowanych funkcji nowego edytora polega na ułatwianiu wizualizacji sposobu rozwoju wdrożeń w środowiskach. Oprócz tego ustawienia zatwierdzeń, właściwości środowiska i ustawienia wdrażania są teraz kontekstowe i można je łatwo skonfigurować.

Wizualizacja potoku

Potok (Rysunek 68) w edytorze zawiera graficzne przedstawienie przyszłego postępu wdrożeń w wydaniu. Artefakty będą używane przez wydanie i wdrażane w tych środowiskach. Układ i łączenie środowisk odzwierciedla ustawienia wyzwalacza zdefiniowane dla każdego środowiska.

Pipeline

(Rysunek 68) Potok wydania

Kontekstowy interfejs użytkownika konfiguracji

Artefakty, wyzwalacze wersji, zatwierdzenia przed wdrożeniem i po wdrożeniu, właściwości środowiska i ustawienia wdrożenia są teraz dostępne jako kontekstowe i można je łatwo konfigurować (Rysunek 69).

Release configuration

(Rysunek 69) Konfiguracja wydania

Wprowadzenie do szablonów wdrożenia

Wszystkie wbudowane szablony wdrożenia zawierają parametry procesu, które ułatwiają użytkownikom rozpoczęcie pracy. Mogą oni podać najważniejsze parametry bez konieczności dogłębnego analizowania zadań (Rysunek 70).

Deployment templates

(Rysunek 70) Szablony wdrożenia

Uproszczone zarządzanie zmiennymi wydania i zmiennymi środowiskowymi

Widok Lista pozwala szybko dodawać zmienne wydania lub zmienne środowiskowe, a widok Siatka — porównywać zmienne z różnych zakresów i równocześnie je edytować (Rysunek 71). Ponadto przy użyciu filtru i wyszukiwania słów kluczowych można zarządzać zestawem używanych zmiennych w obu widokach.

Simplified management of variables

(Rysunek 71) Uproszczone zarządzanie zmiennymi

Ulepszony edytor zadań i faz

Wszystkie rozszerzenia w nowym edytorze definicji kompilacji są teraz również dostępne w edytorze definicji wydania (Rysunek 72). Można wyszukiwać zadania i dodawać je przy użyciu przycisku Dodaj lub opcji przeciągania i upuszczania. Można zmieniać kolejność zadań lub je klonować za pomocą opcji przeciągania i upuszczania.

Task editor

(Rysunek 72) Edytor zadań

Karty Grupy zmiennych, Przechowywanie i Opcje

Można teraz podłączyć/odłączyć elementy od grup zmiennych (Rysunek 73), ustawić zasady przechowywania dla poszczególnych środowisk i zmodyfikować ustawienia na poziomie definicji wydania (np. format numeru wydania) na karcie Opcje. Można również zapisać środowisko jako szablon wdrożenia, ustawić uprawnienia na poziomie środowiska i zmienić kolejność faz na karcie Zadania.

Variable groups

(Rysunek 73) Grupy zmiennych

Użyj operacji na poziomie środowiska w celu zapisania jako szablonu i ustawienia zabezpieczeń (Rysunek 74).

Environment menu

(Rysunek 74) Menu środowiska

Aby uzyskać więcej informacji, zobacz dokumentację edytora definicji wydania.

Wdrażanie maszyn wirtualnych przy użyciu grup wdrożenia

Usługa Release Management obsługuje teraz niezawodną, wbudowaną funkcję wdrożenia wielu maszyn. Obecne można organizować wdrożenia na wielu maszynach i przeprowadzać aktualizacje stopniowe przy jednoczesnym zapewnieniu wysokiej dostępności w całej aplikacji.

Możliwość wdrażania na podstawie agenta zależy od tych samych agentów wdrożenia i kompilacji. Jednak w przeciwieństwie do bieżącego podejścia, w przypadku którego agenci kompilacji i wdrażania są instalowani w zestawie serwerów proxy w puli agentów i obsługują wdrażanie na docelowych serwerach zdalnych, agent jest instalowany bezpośrednio na każdym z serwerów docelowych i obsługiwane jest wdrażanie stopniowe na tych serwerach. Na maszynach docelowych możesz użyć pełnego wykazu zadań.

Grupa wdrożenia (Rysunek 75) to logiczna grupa celów (maszyn) z agentami zainstalowanymi na każdym z nich. Grupy wdrożeń reprezentują środowiska fizyczne, np. Dev dla jednego wystąpienia, QA dla wielu maszyn i farma maszyny na potrzeby testowania akceptacyjnego przez użytkowników/produkcji. Określają one również kontekst zabezpieczeń środowisk fizycznych.

Deployment groups

(Rysunek 75) Grupy wdrożeń

Tej opcji można używać w przypadku każdej maszyny wirtualnej używanej do rejestrowania naszego agenta. Ponadto bardzo uprościliśmy proces rejestrowania na platformie Azure dzięki obsłudze rozszerzenia maszyny wirtualnej platformy Azure, które automatycznie instaluje agenta po uruchomieniu maszyny wirtualnej. Tagi będą automatycznie dziedziczone przez maszynę wirtualną platformy Azure po jej zarejestrowaniu.

Po utworzeniu grupy wdrożenia możesz po prostu skonfigurować operacje do wykonania w danej grupie wdrożenia (Rysunek 76). Możesz kontrolować procesy uruchamiane na maszynach przy użyciu tagów oraz sprawdzać jak szybko lub wolno następuje wprowadzanie.

Configure deployment groups

(Rysunek 76) Konfigurowanie grup wdrożeń

Po uruchomieniu wdrożenia dzienniki przedstawiają postęp w całej docelowej grupie maszyn (Rysunek 77).

Deployment group progress

(Rysunek 77) Postęp grupy wdrożeń

Ta funkcja jest teraz zintegrowaną częścią usługi Release Management. Żadne dodatkowe licencje nie są wymagane.

Ulepszony interfejs użytkownika grup wdrożeń

W ramach starań na rzecz odświeżenia środowisk kompilowania i wydawania przeprojektowaliśmy strony grup wdrożeń pod kątem zwiększenia przejrzystości oraz intuicyjności ich obsługi (Rysunek 78). Na stronie docelowej można wyświetlić kondycję elementów docelowych w grupie wdrożenia. Można również zarządzać zabezpieczeniami konkretnej grupy wdrożenia oraz ustawić uprawnienia domyślne w różnych grupach wdrożeń.

Deployment groups UI

(Rysunek 78) Interfejs użytkownika grup wdrożeń

Można wyświetlić podsumowanie, ostatnie wdrożenia i możliwości elementu docelowego w grupie wdrożenia (Rysunek 79). Dla poszczególnych elementów docelowych można ustawić tagi i kontrolować, co jest na nich uruchamiane. W kolejnych wydaniach dodamy obsługę filtrowania grup wdrożeń.

Deployment groups UI tags

(Rysunek 79) Tagi interfejsu użytkownika grup wdrożeń

Odwołania do grupy zadań

Grupy zadań umożliwiają definiowanie zestawu zadań, który można dodać do definicji kompilacji lub wydania (Rysunek 80). Jest to przydatne, jeśli należy użyć tego samego grupowania zadań w wielu kompilacjach lub wydaniach. Aby ułatwić śledzenie użytkowników grupy zadań, masz teraz wgląd w definicje kompilacji, definicje wydań i grupy zadań, które odwołują się do danej grupy zadań (Rysunek 79).

Task group references

(Rysunek 80) Odwołania do grupy zadań

Jeśli podejmiesz próbę usunięcia grupy zadań, która nadal ma odwołania do siebie, otrzymasz od nas ostrzeżenie i link do tej strony.

Przechowywanie wersji grupy zadań

Wprowadzanie zmian do grup zadań można uznać za ryzykowne, ponieważ zmiana obowiązuje we wszystkich definicjach, które używają grupy zadań. Dzięki funkcji przechowywania wersji grupy zadań możesz teraz tworzyć wersje grupy zadań i przeglądać je, jednocześnie zapewniając stabilne wersje najważniejszych definicji, dopóki wszystko będzie gotowe do przełączenia. Po opracowaniu niektórych wersji próbnych i iteracji można opublikować stabilną wersję, a następnie — podczas publikowania — jeśli zmiany mają krytyczne znaczenie, można opublikować grupę zadań jako wersję zapoznawczą (nowej wersję główną). Alternatywnie można opublikować ją bezpośrednio jako zaktualizowaną wersję stabilną (Rysunek 81).

Gdy nowa wersja główna (lub wersja zapoznawcza) grupy zadań zostanie udostępniona, edytor definicji poinformuję Cię, że istnieje nowa wersja. Jeśli ta wersja główna będzie wersją zapoznawczą, zobaczysz nawet komunikat o możliwości jej wypróbowania. Gdy okres obowiązywania wersji zapoznawczej grupy zadań się zakończy, używające jej definicje zostaną automatycznie zaktualizowane przez przejście przez kanał główny (Rysunek 82).

Save as draft

(Rysunek 81) Zapisywanie grupy zadań jako wersji roboczej

Publish task group as preview

(Rysunek 82) Publikowanie grupy zadań jako wersji zapoznawczej

Importowanie i eksportowanie grupy zadań

Mimo że grupy zadań mogły być ponownie używane w ramach projektu, wiemy, że ponownie tworzenie grupy zadań w projektach i na kontach może stanowić problem. Dzięki funkcji importowania/eksportowania grupy zadań (Rysunek 83), podobnie jak w przypadku definicji wydań, można teraz wyeksportować ją jako plik JSON, a następnie zaimportować do wybranej lokalizacji. Włączyliśmy również zagnieżdżone grupy zadań, które podczas eksportowania są najpierw rozwijane.

Export task group

(Rysunek 83) Eksportowanie grupy zadań

Obsługa wielu konfiguracji w przypadku zadań po stronie serwera (bez agentów)

Dzięki określeniu mnożników zmiennych dla zadań po stronie serwera (bez agentów) (Rysunek 84) możesz teraz uruchomić ten sam zestaw zadań w fazie w ramach wielu konfiguracji uruchamianych równolegle.

Multi configuration of agentless tasks

(Rysunek 84) Wiele konfiguracji zadań bez agentów

Obsługa zmiennych w zadaniu interwencji ręcznej

Zadanie Interwencja ręczna (Rysunek 85) obsługuje teraz używanie zmiennych w tekście instrukcji widocznym dla użytkowników po uruchomieniu zadania w momencie, gdy użytkownik będzie mógł wznowić wykonywanie procesu wydania lub go odrzucić. Można uwzględnić wszystkie zmienne zdefiniowane i dostępne w wydaniu, a wartości będą używane w powiadomieniach oraz w wiadomościach e-mail wysyłanych do użytkowników (Rysunek 86).

Manual intervention task

(Rysunek 85) Zadanie interwencji ręcznej

Manual intevention pending dialog

(Rysunek 86) Okno dialogowe oczekującej interwencji ręcznej

Kontrolowanie wydań do środowiska w oparciu o gałąź źródłową

Można skonfigurować definicję wydania w celu automatycznego wyzwolenia wdrożenia podczas tworzenia nowego wydania, przeważnie po pomyślnym zakończeniu kompilacji źródła. Możesz jednak wdrażać tylko kompilacje z określonego źródła, a nie po pomyślnym zakończeniu dowolnej kompilacji.

Możesz na przykład wdrażać wszystkie kompilacje w środowiskach tworzenia i testowania, ale tylko określone kompilacje w środowisku produkcyjnym. Wcześniej w tym celu należało obsługiwać dwa potoki wydań: jeden dla środowisk tworzenia i testowania i drugi dla środowiska produkcyjnego.

Usługa Release Management obsługuje teraz użycie filtrów artefaktów dla każdego środowiska. Oznacza to, że możesz określić wersje, które zostaną wdrożone w każdym środowisku po spełnieniu warunków wyzwalacza wdrożenia (takich jak zakończenie kompilacji powodzeniem i tworzenie nowego wydania). W sekcji Wyzwalacz okna dialogowego środowiska Warunki wdrożenia (Rysunek 87) wybierz warunki artefaktu, takie jak gałąź źródłowa i tagi dla kompilacji, które wyzwolą nowe wdrożenie w tym środowisku.

Deployment conditions dialog

(Rysunek 87) Okno dialogowe Warunki wdrażania

Ponadto strona Podsumowanie wydania (Rysunek 88) zawiera teraz wyskakującą poradę, która wskazuje przyczynę „nieuruchomienia” wdrożeń oraz sugeruje sposób lub czas rozpoczęcia wdrożenia.

Release summary tip

(Rysunek 88) Porada Podsumowanie wydania

Wyzwalacze wydań dla repozytoriów Git jako źródło artefaktów

Usługa Release Management obsługuje teraz konfigurowanie wyzwalacza ciągłego wdrażania (Rysunek 89) dla repozytoriów Git połączonych z definicją wydania w dowolnym projekcie zespołowym w obrębie tego samego konta. Umożliwia to automatyczne wyzwalanie wydania po przeprowadzeniu nowego zatwierdzenia w repozytorium. Można również określić gałąź w repozytorium Git, którego zatwierdzenia wyzwolą wydanie.

Release triggers

(Rysunek 89) Wyzwalacze wydania

Wyzwalacze wydania: ciągłe wdrażanie zmian wypychanych do repozytorium Git

Usługa Release Management zawsze oferowała możliwość konfigurowania ciągłego wdrażania po zakończeniu kompilacji. Obecnie można jednak również konfigurować ciągłe wdrażanie operacji wypychania Git. Oznacza to, że można łączyć repozytoria GitHub i Team Foundation Git jako źródła artefaktów w definicji wersji. Następnie wyzwalacz wydaje automatycznie aplikacje, takie jak Node.JS i PHP, które nie zostały wygenerowane na podstawie kompilacji i dlatego nie potrzebują akcji kompilacji w przypadku ciągłego wdrażania.

Filtry gałęzi w wyzwalaczach środowiska

W nowym edytorze definicji wydania można podać warunki artefaktu dla określonego środowiska. Warunki te zapewniają bardziej szczegółową kontrolę nad artefaktami, które powinny zostać wdrożone w danym środowisku. Na przykład warto zagwarantować, aby tylko kompilacje generowane z gałęzi głównej były wdrażane w środowisku produkcyjnym. Filtr ten należy ustawić dla wszystkich artefaktów, które prawdopodobnie powinny spełniać te kryteria.

Dla każdego artefaktu połączonego z definicją wydania można również dodać wiele filtrów (Rysunek 90). Wdrożenie zostanie wyzwolone w środowisku tylko po spełnieniu wszystkich warunków dotyczących artefaktów.

Branch filters

(Rysunek 90) Filtry gałęzi

Rozszerzenia zadań po stronie serwera

Wprowadziliśmy dwa ulepszenia zadań po stronie serwera (zadań uruchamianych w fazie serwera).

Dodaliśmy nowe zadanie, które może służyć do wywołania dowolnego ogólnego interfejsu API REST protokołu HTTP (Rysunek 91) jako część potoku zautomatyzowanego. Może ono na przykład służyć do wywoływania określonego przetwarzania przy użyciu funkcji platformy Azure i oczekiwania na jego ukończenie.

REST API task

(Rysunek 91) Zadanie interfejsu API REST

Do wszystkich zadań po stronie serwera dodaliśmy również sekcję Opcje kontroli (Rysunek 92). Zachowanie zadania obejmuje teraz ustawianie opcji Włączone, Kontynuuj przy błędzie, Zawsze uruchamiaj i Limit czasu.

Task control options

(Rysunek 92) Opcje kontroli zadań

Wskaźnik stanu wydania w centrum kodu

Obecnie jeśli chcesz dowiedzieć się, czy zatwierdzenie jest wdrażane w środowisku produkcyjnym klienta, musisz najpierw zidentyfikować kompilację, która wykorzystuje zatwierdzenie, a następnie sprawdzić wszystkie środowiska wydania, w których wdrożono tę kompilację. Teraz jest to znacznie łatwiejsze dzięki integracji ze stanem wdrożenia we wskaźniki stanu centrum kodu w celu wyświetlenia listy środowisk, w których wdrożono dany kod. Stan każdego wdrożenia jest publikowany w najnowszym zatwierdzeniu, które było częścią wdrożenia. Jeśli zatwierdzenie zostało wdrożone w wielu definicjach wydania (w wielu środowiskach), każde z nich ma wpis we wskaźniku z pokazanym stanem dla każdego środowiska (Rysunek 93). Zwiększa to możliwość śledzenia zatwierdzenia kodu we wdrożeniach.

Release status badge

(Rysunek 93) Wskaźnik stanu zlecenia

Domyślnie podczas tworzenia definicji wydania stan wdrożenia jest publikowany dla wszystkich środowisk. Można jednak selektywnie wskazać środowiska, w których stan wdrożenia powinien być wyświetlany we wskaźniku stanu (np. w celu pokazania tylko środowisk produkcyjnych) (Rysunek 94).

Deployment options dialog

(Rysunek 94) Okno dialogowe Opcje wdrażania

Rozszerzenia menu definicji kompilacji na potrzeby dodawania artefaktów

Podczas dodawania artefaktów kompilacji do definicji wydania można teraz wyświetlać definicje z informacjami o organizacji folderów i upraszczać wybieranie żądanej definicji (Rysunek 95). Ułatwia to odróżnienie definicji kompilacji o tej samej nazwie, ale w różnych folderach.

Add artifact

(Rysunek 95) Dodawanie artefaktów

Lista definicji jest filtrowana na podstawie tych, które zawierają termin z filtru.

Przywracanie starszej wersji definicji wydania

Obecnie w przypadku zaktualizowania definicji wydania nie można bezpośrednio przywrócić jej do poprzedniej wersji. Jedynym sposobem jest sprawdzenie historii definicji w celu wyszukania zmian, a następnie ręczne edytowanie definicji wydania. Korzystając z funkcji przywracania definicji (Rysunek 96), można teraz wybrać i przywrócić dowolną starszą wersję definicji wydania na karcie Historia definicji wydania.

Revert release definition

(Rysunek 96) Przywracanie definicji wersji

Spersonalizowane powiadomienia o wydaniach

Powiadomienia o wydaniach są teraz zintegrowane z ustawieniami powiadomień usługi VSTS. Osoby zarządzające wydaniami są automatycznie powiadamiane o oczekujących działaniach (zatwierdzeniach lub interwencjach ręcznych) i ważnych awariach wdrażania. Można wyłączyć te powiadomienia, przechodząc do ustawień powiadomień w obszarze menu profilu i wyłączając opcję Subskrypcje wydania. Można również zasubskrybować dodatkowe powiadomienia, tworząc niestandardowe subskrypcje. Administratorzy mogą kontrolować subskrypcje zespołów i grup za pomocą ustawień powiadomień w obszarach Zespół i Konto.

Autorzy definicji wydań już nie muszą wysyłać wiadomości e-mail z prośbami o zatwierdzenie i ukończenie wdrożenia.

Jest to szczególnie przydatne w przypadku dużych kont, obejmujących wiele osób zainteresowanych wydaniem (oprócz osoby zatwierdzającej, twórcy wydania i właściciela środowiska), które prawdopodobnie chcą być powiadamiane(Rysunek 97).

Release notifications

(Rysunek 97) Powiadomienia o wersji

Aby uzyskać więcej informacji, zobacz wpis dotyczący zarządzania powiadomieniami o wydaniach.

Testowanie

Rezygnacja z obsługi Centrum laboratoryjnego i zautomatyzowanych przepływów testowania w programie Microsoft Test Manager

Ze względu na rozwój funkcji zarządzania kompilacjami i wydaniami kompilacje XAML nie są już obsługiwane na serwerze TFS 2018. W konsekwencji aktualizujemy obsługę programu Microsoft Test Manager (MTM) z użyciem serwera TFS. Używanie Centrum testów/Centrum laboratoryjnego w programie MTM na potrzeby testowania automatycznego nie jest już obsługiwane na serwerze TFS od wersji TFS 2018. Jeśli użytkownik nie jest gotowy do migracji z kompilacji XAML i Centrum laboratoryjnego, nie powinien uaktualniać serwera do wersji TFS 2018.

Zobacz wpływ uaktualnienia do programu TFS 2018 poniżej:

Centrum laboratoryjne:
Testowanie automatyczne:
Testowanie ręczne:
  • Wszystkie scenariusze testowania ręcznego będą nadal w pełni obsługiwane. Testy ręczne można uruchamiać w programie MTM przy użyciu serwera TFS 2018, ale środowisk laboratoryjnych nie można używać na potrzeby uruchamiania testów ręcznych.
  • W przypadku wszystkich scenariuszy testowania ręcznego zdecydowanie zalecamy używanie Centrum testów w przypadku uzyskiwania dostępu do Internetu dla serwera TFS.

Udoskonalenia możliwości śledzenia testowania eksploracyjnego dla ścieżek obszarów, iteracji i linków elementów roboczych

Na podstawie opinii otrzymanych od zespołów zajmujących się testowaniem eksploracyjnym poprawiamy linki umożliwiające śledzenie podczas zgłaszania usterek, zadań i przypadków testowych z poziomu rozszerzenia Test i opinie. Usterki i zadania utworzone podczas eksplorowania wymagań będą teraz tworzone przy użyciu tej samej ścieżki obszaru i iteracji, co wymaganie, zamiast ustawień domyślnych zespołu. Przypadki testowe utworzone podczas eksplorowania wymagania będą teraz łączone przy użyciu linku Testy <-> Przetestowane przez zamiast linku Nadrzędne <-> Podrzędne, dlatego tworzone przypadki testowe będą automatycznie dodawane do zestawu testów opartego na wymaganiach. Ponadto elementy robocze utworzone podczas czynności innych niż eksplorowanie wymagań będą zgłaszane w domyślnej iteracji zespołu zamiast bieżącej iteracji, tak aby żadne nowe elementy robocze nie były uwzględniane w bieżącej iteracji po ukończeniu planowania przebiegu.

Filtry elementów roboczych Przypadek testowy w zestawach i planach testów w Centrum testów

Oprócz filtrów dostępnych w polach Test, takich jak Wynik, Konfiguracja i Tester, można teraz filtrować według pól elementu roboczego Przypadek testowy, takich jak Tytuł, Stan i Przypisane do (Rysunek 98).

Test case filters

(Rysunek 98) Filtry przypadków testowych

Wykresy trendu testów w środowiskach wydania i uruchomieniach testów

Dodajemy obsługę środowisk wydania w widżecie Trend wyników testów (Rysunek 99), dzięki czemu można śledzić stan środowisk testowych na pulpitach nawigacyjnych usług VSTS. Podobnie jak w przypadku wyników testów w obszarze Kompilacja, można teraz tworzyć wykresy trendu przedstawiające współczynnik testów z wynikiem pozytywnym, liczbę całkowitą, testy zakończonych powodzeniem i niepowodzeniem oraz czas trwania dla środowisk wydania. Można również filtrować wykresy określonego uruchomienia testu w środowisku przy użyciu filtra tytułu uruchomienia testu.

Test trend chart

(Rysunek 99) Wykres trendu testu

Obsługa formatowania kodu w języku znaczników markdown dla komentarzy do uruchomienia testu i wyniku testu

Dodajemy obsługę formatowania komentarzy do uruchomienia testu i wyniku testu z użyciem składni języka znaczników markdown. Ta funkcja umożliwia tworzenie tekstu sformatowanego lub szybkich linków do adresów URL w komentarzach. Komentarze do wyniku testu można aktualizować na stronie Podsumowanie wyników w obszarze Aktualizowanie analizy, a komentarze do uruchomienia testu — na stronie Podsumowanie uruchomienia przy użyciu opcji aktualizacji komentarzy w centrum Test.

Podczas analizowania wyników testów w na stronie podsumowania Kompilacja lub Wydanie lub w centrum Test można teraz skojarzyć istniejącą usterkę z testem zakończonym wynikiem negatywnym. Jest to pomocne w sytuacji, gdy test kończy się wynikiem negatywnym ze znanego powodu, dla którego zgłoszono już usterkę.

Przekazywanie załączników do uruchomień testów i wyników testów

Do uruchomień testów lub wyników testów można teraz dołączać dodatkowe informacje, takie jak zrzuty ekranu i pliki dziennika. Dotąd było to możliwe tylko za pomocą klienta programu Microsoft Test Manager (MTM), co zmuszało do przełączania kontekstu między centrum Test usług VSTS/serwera TFS a klientem programu MTM.

Przetwarzanie wsadowe testów

W zadaniu testowym programu Visual Studio w obszarze zarządzania kompilowaniem/wydawaniem dostępne są opcje umożliwiające sterowanie grupowaniem (przetwarzaniem wsadowym) testów pod kątem zapewnienia ich wydajnego wykonywania. Testy można pogrupować na dwa sposoby:

  1. Na podstawie liczby testów i agentów uczestniczących w ich uruchomieniu — czyli po prostu grupowanie testów na partie o określonym rozmiarze.
  2. Na podstawie czasu wykonywania testów w przeszłości — poszczególne partie testów są tworzone tak, aby ich czas wykonywania był w przybliżeniu taki sam (Rysunek 100). Testy o krótkim czasie wykonywania są umieszczane w jednej partii, a testy trwające dłużej mogą należeć do oddzielnej partii. Opcji tej można użyć razem z ustawieniem etapu obejmującego wielu agentów, aby maksymalnie skrócić łączny czas testu.

Test batching

(Rysunek 100) Przetwarzanie wsadowe testów

Uruchamianie testów internetowych przy użyciu zadania VSTest

Za pomocą zadania testowego programu Visual Studio można uruchamiać testy internetowe, znane także jako internetowe testy wydajności, w potoku CI/CD. W tym celu można wskazać, które testy mają zostać uruchomione, w danych wejściowych zestawu zadania. Po wybraniu planu testu lub zestawu testów w zadaniu można również uruchomić dowolny element roboczy przypadku testowego ze „skojarzoną automatyzacją” połączoną z testem internetowym (Rysunek 101).

Test selection

(Rysunek 101) Wybieranie testów

Wyniki testu internetowego będą dostępne jako załącznik do wyniku testu (Rysunek 102). Można go pobrać w programie Visual Studio w celu przeprowadzenia analizy offline.

Test summary

(Rysunek 102) Podsumowanie testu

Dostępność tej funkcji zależy od zmian na platformie testowej programu Visual Studio. Wymagane jest zainstalowanie programu Visual Studio 2017 Update 4 na agencie kompilacji/wydania. Nie można uruchamiać testów internetowych za pomocą wcześniejszych wersji programu Visual Studio.

Testy internetowe można również uruchamiać przy użyciu zadania Uruchom test funkcjonalny. Dostępność tej funkcji zależy od zmian w programie Test Agent, który zostanie udostępniony razem z programem Visual Studio 2017 Update 5.

W artykule Load test your app in the cloud using Visual Studio and VSTS quickstart (Szybki start: test obciążenia aplikacji w chmurze przy użyciu programu Visual Studio i usługi VSTS) przedstawiono przykładowe użycie tych możliwości w połączeniu z testowaniem obciążenia.

Widżet wykresów dla planów testów i zestawów testów

Wykresy planów testów i zestawów testów utworzone w centrum Test można było wcześniej przypinać do pulpitu nawigacyjnego. Dodaliśmy widżet, który umożliwia tworzenie wykresów planów testów i zestawów testów z poziomu wykazu widżetów na pulpicie nawigacyjnym. Można tworzyć wykresy przedstawiające stan tworzenia testów lub stan wykonywania testów. Ponadto widżet ten pozwala tworzyć większe wykresy, co umożliwia wyświetlanie dodatkowych danych (Rysunek 103).

Chart widget

(Rysunek 103) Element widget wykresu

Obsługa zrzutów ekranu i adnotacji w aplikacjach klasycznych podczas przeprowadzania testów ręcznych w przeglądarce Chrome

Wprowadzamy obsługę jednej z najbardziej oczekiwanych funkcji testowania ręcznego — przechwytywanie zrzutów ekranu aplikacji klasycznych z poziomu modułu uruchamiającego testy internetowe w centrum Test. Do tej pory przechwytywanie zrzutów ekranu aplikacji klasycznych wymagało użycia modułu uruchamiającego testy w programie Microsoft Test Manager. Aby korzystać z tej funkcji, musisz zainstalować rozszerzenie Test & Feedback. Wprowadzamy obsługę przeglądarki Chrome. Obsługa programu Firefox będzie dostępna wkrótce.

Rezygnacja z obsługi rozszerzenia TFS dla programu SharePoint

Serwer TFS 2018 ani jego nowsze wersje nie będą obsługiwać rozszerzenia TFS dla programu SharePoint. Ponadto ekrany używane do konfigurowania integracji między serwerem TFS i serwerem programu SharePoint zostały usunięte z konsoli administracyjnej serwera Team Foundation.

Uwaga

Jeśli uaktualniasz poprzednią wersję serwera TFS, zintegrowaną z programem SharePoint, do wersji 2018, musisz wyłączyć integrację z programem SharePoint po uaktualnieniu. W przeciwnym razie załadowanie witryn programu TFS SharePoint nie powiedzie się.

Utworzyliśmy rozwiązanie, które umożliwia wyłączenie integracji na serwerze programu SharePoint. Aby uzyskać więcej informacji, zobacz wpis na temat planów dotyczących integracji serwera TFS i programu SharePoint.

Rezygnacja z pokoi zespołów

Praca nowoczesnych zespołów deweloperów w dużym stopniu zależy od współpracy. Ludzie chcą mieć miejsce (i potrzebują go) do monitorowania aktywności (powiadomienia) i rozmawiania o niej (czat). Kilka lat temu zidentyfikowaliśmy ten trend i rozpoczęliśmy kompilowanie pokoju zespołu w celu obsługi takich scenariuszy. Od tego czasu na rynku pojawiło się więcej rozwiązań obsługujących współpracę. Głównie była to rozwijająca się aplikacja Slack. I niedawno anons dotyczący aplikacji Microsoft Teams.

Ze względu na dostępność tylu dobrych rozwiązań skutecznie integrowanych z serwerem TFS i usługami Visual Studio Team Services w styczniu ogłosiliśmy plany usunięcia naszej funkcji pokoju zespołu z serwera TFS 2018 oraz usług Visual Studio Team Services.


Początek strony