Team Foundation Server 2018 RC1 — informacje o wersji

Last Update: 2017-09-25

Ten artykuł zawiera informacje dotyczące najnowszej wersji serwera Team Foundation Server 2018 RC1. 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).


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: 30 sierpnia 2017 r.

Podsumowanie: aktualizacje serwera Team Server Foundation na serwerze TFS 2018 RC1

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

Podsumowanie: nowości w tej wersji

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, które są dostępne 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.

Formularz mobilnego elementu roboczego

Oferujemy pełne, kompleksowe środowisko ze zoptymalizowanym wyglądem i sposobem działania elementów roboczych (Rysunek 1), które zapewnia prosty sposób interakcji z elementami przypisanymi do Ciebie albo ostatnio odwiedzonymi bądź edytowanymi przy użyciu telefonu.

Mobile work item query

(Rysunek 1) Zapytanie o mobilny element roboczy

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 mobilna

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

Kontrola wersji

Rozwidlenia

Na serwerze TFS 2018 dodano obsługę rozwidleń usługi Git (Rysunek 7). 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 (Rysunek 7). Dzięki temu możesz przejrzeć ich zmiany w żądaniu ściągnięcia przed zaakceptowaniem tych zmian w repozytorium centralnym.

Git forks

(Rysunek 7) Rozwidlenia usługi Git

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 8). 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 8) Wyłączanie edytowania w Internecie

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

Web editing not allowed dialog

(Rysunek 9) Edytowanie w Internecie niedozwolone (okno dialogowe)

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 Stare na stronie Gałęzie (Rysunek 10).

Stale branches

(Rysunek 10) Stare 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 11).

Search for deleted branches

(Rysunek 11) 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 12).

Restore deleted branches

(Rysunek 12) 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 13).

Search for a commit

(Rysunek 13) 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 przedstawia istotniejsze informacje ułatwiające skuteczniejsze diagnozowanie (Rysunek 14). 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 14) Objaśnienie żą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 przedstawienia hierarchii plików w przypadku filtrowania według nazwy pliku.

Wyszukaj filtr plików lub folderów w drzewie zatwierdzeń (Rysunek 15) i (Rysunek 16):

Find a file or folder

(Rysunek 15) Wyszukiwanie pliku lub folderu

Filtered view

(Rysunek 16) 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 17) w obszarze Kod, wraz z obszarami Zatwierdzenia, Gałęzie, Tagi i Żądania ściągnięcia. Nowy adres URL strony wypchnięć to: <tfsserverurl>/<projectname>/_git/<reponame>/pushes. Stare adresy URL będą nadal działać.

Pushes page

(Rysunek 17) Strona wypchnięć

Równocześnie nazwa centrum Historia została teraz zmieniona na Zatwierdzenia (Rysunek 18), 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ń to: <tfsserverurl>/<projectname>/_git/<reponame>/commits. Stare adresy URL będą nadal działać.

Commits page

(Rysunek 18) 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 19). 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 19) Wyświetlanie tagów usługi Git

W tym miejscu można łatwo odróżnić tagi lekkie od tagów z adnotacjami, ponieważ 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 internetowego interfejsu użytkownika, klikając menu kontekstowe tagu na stronie Tagi i wybierając polecenie Usuń tag (Rysunek 20).

Uwaga: usuwanie tagów z repozytoriów zdalnych powinno być przeprowadzone z rozwagą.

Delete git tags

(Rysunek 20) 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 tagów 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 21).

Filter Git tags

(Rysunek 21) 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. Można przyznać użytkownikom uprawnienia do usuwania tagów lub zarządzania nimi w tym interfejsie (Rysunek 22).

Git tag security

(Rysunek 22) 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. Teraz po ukończeniu żądania ściągnięcia będziesz mieć opcję automatycznego ukończenia połączonych elementów roboczych po pomyślnym zakończeniu scalania żądania ściągnięcia (Rysunek 23). 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 23) 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 24). Nowe ustawienie jest opcją zasad Wymagaj minimalnej liczby recenzentów.

Reset votes setting

(Rysunek 24) Ustawienie resetowania 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. Na osi czasu żądania ściągnięcia wpis zostanie zarejestrowany za każdym razem, gdy głosy zostaną zresetowane w wyniku działania tej opcji (Rysunek 25).

Reset votes in timeline

(Rysunek 25) 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 26).

Find file or folder in pull request

(Rysunek 26) 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 27).

Find results

(Rysunek 27) 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 28). Możesz również odfiltrować dyskusje tak, aby wyświetlić tylko te, w których bierzesz udział.

PR comment filtering

(Rysunek 28) 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 tym jak kod, do którego się odwołuje się, został zmieniony (wiele razy, gdy żądana zmiana została wprowadzona) (Rysunek 29).

View original diff

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

W takim przypadku zobaczysz teraz wskaźnik z liczbą aktualizacji, który można kliknąć, aby sprawdzić, jak wyglądał kod w momencie utworzenia komentarza (Rysunek 30).

Update badge

(Rysunek 30) 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 31).

Hide comments

(Rysunek 31) Ukrywanie komentarzy

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

Collapsed comments

(Rysunek 32) 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 33) ułatwiają podejrzenie komentarza bez wyświetlania całego wątku.

Collapsed comment tooltip

(Rysunek 33) 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 zaznaczonego tekstu (Rysunek 34).

Task list toolbar

(Rysunek 34) Pasek narzędzi listy zadań

Po dodaniu listy zadań (Rysunek 35) 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 35) Lista zadań

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

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

Like pull request comments

(Rysunek 36) Polubione komentarze do żądania ściągnięcia

Udoskonalony przepływ pracy w przypadku zatwierdzania z sugestiami

Użycie opcji automatycznego ukończenia (Rysunek 37) 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 37) Okno dialogowe anulowania automatycznego koń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 38).

Path filtering for notifications

(Rysunek 38) Filtrowanie ścieżek na potrzeby powiadomień

Doskonałe 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 i są teraz czytelne i zwarte oraz umożliwiają przeprowadzanie akcji (Rysunek 39). 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 39) Udoskonalony szablon wiadomości e-mail

W przypadku większości alertów wezwanie do akcji (Rysunek 40) 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 40) Wezwanie do akcji w wiadomości e-mail

Rozszerzalność stanu żądania ściągnięcia

Korzystanie z zasad gałęzi może być świetnym sposobem poprawienia jakości kodu. Te zasady zostały jednak ograniczone do integracji udostępnianych w sposób natywny przez usługi VSTS. Dzięki nowemu interfejsowi API stanu żądania ściągnięcia i odpowiednim zasadom gałęzi usługi innych firm mogą brać udział w przepływie pracy żądania ściągnięcia, tak jak natywne funkcje usług VSTS.

Gdy usługa publikuje informację w interfejsie API stanu dla żądania ściągnięcia, natychmiast pojawia się ona w widoku Szczegóły żądania ściągnięcia w nowej sekcji Stan (Rysunek 41). Sekcja stanu przedstawia opis i tworzy link do adresu URL podanego przez usługę. Są również obsługiwane wpisy stanu i menu akcji (...), które można rozszerzyć o nowe akcje do dodania z poziomu rozszerzeń internetowych.

PR status section

(Rysunek 41) Żądanie ściągnięcia — sekcja stanu

Sam stan nie blokuje ukończenia żądania ściągnięcia — w tym miejscu rozpoczyna się działanie zasad. Po opublikowaniu stanu żądania ściągnięcia można skonfigurować zasady. W środowisku pracy z zasadami gałęzi nowe zasady są dostępne dla opcji Wymagaj zatwierdzenia od usług zewnętrznych. Wybierz pozycję + Dodaj usługę, aby rozpocząć proces (Rysunek 42).

Add new policy

(Rysunek 42) Żądanie ściągnięcia — dodawanie nowych zasad

W oknie dialogowym wybierz usługę, która publikuje stan z listy i ustaw żądane opcje zasad (Rysunek 43).

Set status policy

(Rysunek 43) Żądanie ściągnięcia — ustawianie zasad stanu

Po uaktywnieniu zasad stan zostanie wyświetlony w sekcji Zasady odpowiedniego obszaru: Wymagane lub Opcjonalne, a ukończenie żądania ściągnięcia zostanie wymuszone we właściwy sposób.

Aby dowiedzieć się więcej na temat interfejsu API stanu i go wypróbować, zobacz dokumentację i przykłady.

Wiki

Każdy projekt obsługuje obecnie własną witrynę Wiki (Rysunek 44). 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 44) Żądanie ściągnięcia — strona Wiki

Oto niektóre kluczowe funkcje nowej witryny Wiki:

  • Uproszczone środowisko edytowania korzystające ze składni języka znaczników markdown.
  • Nowa strona pozwala określić tytuł i dodać zawartość. (Rysunek 45) Title wiki

    (Rysunek 45) Żądanie ściągnięcia — tytuł w witrynie Wiki

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

Wiki HTML tags

(Rysunek 46) Żądanie ściągnięcia — tagi HTML w witrynie Wiki

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

Image resize

(Rysunek 47) Żądanie ściągnięcia — zmiana rozmiaru obrazu

  • 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 Wiki (Rysunek 48).

Wiki menu

(Rysunek 48) Żądanie ściągnięcia — menu witryny Wiki

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ć poprawkę do strony typu Wiki, przechodząc do szczegółów poprawki i klikając przycisk Przywróć (Rysunek 49).

Wiki revert button

(Rysunek 49) Żądanie ściągnięcia — przycisk przywracania w witrynie Wiki

Tworzenie strony Wiki na podstawie przerwanego linku — podczas tworzenia stron Wiki zaobserwowaliśmy wzorzec, w którym użytkownicy tworzą spis treści na stronie Wiki, która zawiera nieistniejące linki (Rysunek 50). Następnie klikają oni te linki w celu utworzenia rzeczywistych stron. W poprzednim środowisku pracy 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 50) Żądanie ściągnięcia — tworzenie strony Wiki

Zakończyliśmy obsługę rozszerzenia Wiki w witrynie Marketplace. Jeśli jesteś istniejącym użytkownikiem rozszerzenia Wiki, możesz migrować strony typu wiki do nowej witryny Wiki za pomocą tego narzędzia migracji. Dowiedz się więcej na temat 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 (Rysunek 50). Format to: <tfsserverurl>/<project|team>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package.

Package URL

(Rysunek 51) Żądanie ściągnięcia — adres URL pakietu

Można teraz ukrywać usunięte wersje pakietów wszystkich (Rysunek 52) użytkowników kanału informacyjnego (nie będzie już przekreślanych pakietów!) w odpowiedzi na tę sugestię w witrynie UserVoice.

Hide deleted packages

(Rysunek 52) 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 53), w której znajdują się daty w czytelnej postaci, dzięki czemu można łatwo wyszukiwać ostatnio zaktualizowane pakiety.

Last pushed column

(Rysunek 53) Kolumna Ostatnie wypchnięcie

Pakiety Maven

Rozpoczęliśmy obsługę hostowania artefaktów Maven na serwerze TFS 2018 (Rysunek 54). 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 54) 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 55).

Nuget task

(Rysunek 55) Zadanie NuGet

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

dotnet task

(Rysunek 56) 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 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 57). 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 57) 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 58).

Feed picker

(Rysunek 58) Selektor 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 ten wpis w blogu.

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ą ogłaszamy, że teraz jest to możliwe (Rysunek 59) i (Rysunek 60).

Export build definition

(Rysunek 59) Eksportowanie definicji kompilacji

Import build definition

(Rysunek 60) 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 61), 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 61) 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 62). 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 62) 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. 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 63) ogólnego przeznaczenia.

Secure files library

(Rysunek 63) Biblioteka bezpiecznych 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:

Nowy edytor definicji wydania

Domyślne wyrażanie zgody na uczestnictwo: w edytorze definicji wydania dla wszystkich użytkowników domyślnie została wybrana opcja wyrażania zgody na uczestnictwo. Ty i odpowiedni administratorzy serwera TFS nadal będziecie mieć możliwość wyłączenia tej opcji przez przejście do opcji Funkcje w wersji zapoznawczej w menu Twojego profilu. Zobacz część dotyczącą funkcji w wersji zapoznawczej, aby uzyskać więcej informacji.

Kontynuując naszą podróż mającą na celu odświeżenie środowisk kompilacji i wydań, po wprowadzeniu nowego edytora definicji kompilacji zmieniliśmy teraz obraz naszego edytora definicji wydań, aby zwiększyć czytelność i intuicyjność środowiska, naprawiliśmy niektóre problematyczne punkty i dodaliśmy nowe możliwości. Jedną z najbardziej zaawansowanych funkcji nowego edytora jest to, że może ułatwić tworzenie mentalnego modelu lub wizualizowania sposobu rozwoju wdrożeń w środowiskach. Oprócz tego ustawienia zatwierdzeń, środowiska i wdrażania są teraz kontekstowe i można je łatwo skonfigurować (Rysunek 65).

Wizualizacja potoku

Potok (Rysunek 64) 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 64) Potok wydania

Kontekstowy interfejs użytkownika konfiguracji

Artefakty, wyzwalacze wersji, zatwierdzenia przed 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 65).

Release configuration

(Rysunek 65) Konfiguracja wydania

Wprowadzenie do szablonów wdrożenia

Lista szablonów (wbudowanych i niestandardowych) jest wyświetlana podczas tworzenia nowego środowiska w celu ułatwienia rozpoczynania pracy (Rysunek 66).

Deployment templates

(Rysunek 66) Szablony wdrożenia

Ulepszony edytor zadań i faz

Wszystkie rozszerzenia w nowym edytorze definicji kompilacji są teraz również dostępne w edytorze definicji wydania (Rysunek 67). 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 67) Edytor zadań

Karty Grupy zmiennych, Przechowywanie i Opcje

Można teraz podłączyć/odłączyć elementy od grup zmiennych (Rysunek 68), ustawić zasady przechowywania dla poszczególnych środowisk i zmodyfikować ustawienia na poziomie definicji wydania, takie jak 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 68) Grupy zmiennych

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

Environment menu

(Rysunek 69) Menu środowiska

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żeń (Rysunek 70) 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 70) 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żeń (Rysunek 71). 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 71) Konfigurowanie grup wdrożeń

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

Deployment group progress

(Rysunek 72) Postęp grupy wdrożenia

Ta funkcja jest teraz zintegrowaną częścią usługi Release Management. Do jej używania nie są wymagane żadne dodatkowe licencje.

Odwołania do grupy zadań

Grupy zadań umożliwiają definiowanie zestawu zadań, który można dodać do definicji kompilacji lub wydania. 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 73).

Task group references

(Rysunek 73) 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ą stabilną wersję (Rysunek 74).

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ń zakończy się, używające jej definicje zostaną automatycznie zaktualizowane przez przejście przez kanał główny (Rysunek 75).

Save as draft

(Rysunek 74) Zapisywanie grupy zadań jako wersji roboczej

Publish task group as preview

(Rysunek 75) 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 76), podobnie jak w przypadku definicji wydań, teraz możesz 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 76) 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 77) możesz teraz uruchomić ten sam zestaw zadań w fazie w ramach wielu konfiguracji uruchamianych równolegle.

Multi configuration of agentless tasks

(Rysunek 77) Wiele konfiguracji zadań bez agenta

Obsługa zmiennych w zadaniu interwencji ręcznej

Zadanie Interwencja ręczna (Rysunek 78) 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 79).

Manual intervention task

(Rysunek 78) Zadanie Interwencja ręczna

Manual intevention pending dialog

(Rysunek 79) 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 80) 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 80) Okno dialogowe warunków wdrożenia

Ponadto strona Podsumowanie wydania (Rysunek 81) 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 81) Porada w podsumowaniu 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 82) 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 82) 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.

Rozszerzenia zadań po stronie serwera

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

Dodaliśmy nowe zadanie, który może służyć do wywołania dowolnego ogólnego interfejsu API REST protokołu HTTP (Rysunek 83) 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 83) Zadanie interfejsu API REST

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

Task control options

(Rysunek 84) Opcje kontroli zadania

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 85). Zwiększa to możliwość śledzenia zatwierdzenia kodu we wdrożeniach.

Release status badge

(Rysunek 85) Wskaźnik stanu wydania

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

Deployment options dialog

(Rysunek 86) Okno dialogowe opcji wdrożenia

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 87). Ułatwia to odróżnienie definicji kompilacji o tej samej nazwie, ale w różnych folderach.

Add artifact

(Rysunek 87) Dodawanie artefaktu

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. Teraz korzystając z funkcji przywracania definicji (Rysunek 88), można wybrać i przywrócić dowolną starszą wersję definicji wydania na karcie Historia definicji wydania.

Revert release definition

(Rysunek 88) Przywracanie definicji wydania

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.

Uaktualnienie do serwera TFS 2018 ma wpływ na następujące elementy:

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żesz teraz filtrować według pól elementu roboczego Przypadek testowy, takich jak Tytuł, Stan i Przypisane do (Rysunek 89).

Test case filters

(Rysunek 89) 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 90), 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 90) Wykres trendu testów

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

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.

W przyszłości nie będziemy obsługiwać integracji między serwerami i będziemy przeprowadzać integrację przy użyciu publicznych interfejsów API i platform rozszerzalności.

Jeśli uaktualniasz serwer przy użyciu skonfigurowanej integracji serwera TFS/programu SharePoint, oferujemy Ci rozwiązanie umożliwiające „uaktualnienie odchodzące ” od integracji między serwerami. Witryny programu TFS SharePoint będą nadal wyświetlane po uaktualnieniu, ale funkcje integracji zostaną wyłączone. Aby uzyskać więcej informacji oraz instrukcje, przejdź tutaj.

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.


Znane problemy

Usługa importu bazy danych TFS nie obsługuje wersji RC

Usługa importu bazy danych TFS dla usługi Visual Studio Team Services nie obsługuje operacji importowania z wersji RC serwera TFS. Jeśli planujesz importowanie bazy danych kolekcji do usługi Team Services za pomocą tej usługi, pamiętaj, aby nie uaktualniać produkcyjnej bazy danych do tej wersji RC. W przypadku uaktualnienia trzeba będzie poczekać i uaktualnić tę wersję do wersji RTW lub przywrócić kopię zapasową bazy danych z poprzedniej wersji serwera TFS w celu przeprowadzenia importu.

Zadanie programu Visual Studio Test w wersji 1 w konfiguracji kompilacji/wydania nie może uruchomić testów przy użyciu programu Visual Studio 2017 Update 3

Zadanie programu Visual Studio Test w wersji 1 w konfiguracji kompilacji/wydania nie może uruchomić testów przy użyciu programu Visual Studio 2017 Update 3. Zadanie kończy się następującym błędem: „Nie można określić lokalizacji pliku vstest.console.exe”. Obejście to użycie wersji 2 zadania programu Visual Studio Test.