Udostępnij za pośrednictwem

Ulepszenia yaML w usłudze Azure Pipelines — aktualizacja przebiegu 142

  • Artykuł

W aktualizacji Przebiegu 142 usługi Azure DevOps wprowadzono kilka ulepszeń języka YAML, takich jak dodawanie niestandardowych liczników do kompilacji, określanie gałęzi do kompilowania żądań ściągnięcia i używanie szablonów wbudowanych. Włączyliśmy również nową nawigację dla wszystkich użytkowników, wprowadziliśmy motyw ciemny i ulepszyliśmy środowisko łączenia i załączników w Azure Boards.

Zapoznaj się z poniższą listą Funkcji , aby uzyskać więcej informacji.

Funkcje

Ogólne:

Azure Boards:

Azure Repos:

Azure Pipelines:

Azure Test Plans:

Azure Artifacts:

Wiki:

Administracja:

Ogólne

Nowa nawigacja jest włączona dla wszystkich użytkowników

Włączyliśmy nową nawigację dla wszystkich użytkowników. Jest to ważny kamień milowy w zakresie wdrażania naszego nowego projektu produktu. Chociaż przenosimy wszystkich do nowego modelu nawigacji w tej wersji, użytkownicy nadal będą mogli zrezygnować ze starej nawigacji do 16 stycznia 2019 r. Możesz zrezygnować, wybierając pozycję Funkcje w wersji zapoznawczej z menu poniżej awatara w prawym górnym rogu każdej strony.

Aby uzyskać więcej informacji, zobacz wpis w blogu Dotyczącym aktualizacji nawigacji .

Motyw ciemny

Jednym z naszych wieloletnich żądań funkcji było zaoferowanie ciemnego motywu. Z przyjemnością poinformujemy Cię, że jest to teraz dostępne w ramach nowej nawigacji. Motyw ciemny można włączyć, wybierając pozycję Motyw z menu poniżej awatara w prawym górnym rogu każdej strony.

Motyw ciemny

Azure Boards

Organizowanie materiałów referencyjnych z bogatszymi załącznikami elementów roboczych

Dołączanie plików do elementów roboczych umożliwia zespołowi scentralizowanie materiałów referencyjnych, dzięki czemu są one zawsze blisko, gdy ich potrzebujesz. Teraz łatwiej jest dodać nowy załącznik, przeciągając i upuszczając plik w dowolnym miejscu w formularzu elementu roboczego. Możesz kontynuować wyświetlanie załączników jako listy lub przełączyć się do widoku siatki, aby wyświetlić podgląd miniatur. Kliknij dwukrotnie plik, aby otworzyć podgląd i przejść przez nie, aby szybko znaleźć potrzebne informacje.

Załączniki elementów roboczych

Zarządzanie zależnościami przez łączenie elementów roboczych w organizacjach

Łączenie powiązanej lub zależnej pracy zapewnia szerszy kontekst do śledzenia pracy i ułatwia zarządzanie zależnościami z innymi zespołami. Dzięki linkom do pracy zdalnej możesz śledzić pracę w organizacjach w firmie. Wystarczy skopiować adres URL istniejącego elementu roboczego, przejść do innego elementu roboczego i utworzyć link przy użyciu jednego z trzech nowych typów linków: Zużywa z, Tworzy dla i Powiązane zdalnego. Zobacz dokumentację łączenia elementów roboczych, aby uzyskać więcej informacji na temat możliwości śledzenia w Azure Boards.

Uwaga

Uprawnienia są przestrzegane w obu organizacjach usługi Azure DevOps, które muszą być wspierane przez tę samą dzierżawę Azure AD.

Link zdalny

Gdy zaczniesz zarządzać kilkoma zależnościami, użyj nowego pola Liczba linków zdalnych w zapytaniach , aby wyświetlić listę elementów roboczych, które mają zależności zdalne w projekcie, lub rozważyć zainstalowanie rozszerzenia Tracker zależności . To rozszerzenie, które zostało utworzone przez grupę systemu Windows w firmie Microsoft w celu zaspokojenia ich potrzeb w zakresie skalowania, opiera się na zdalnych linkach, aby wyświetlić bogatą hierarchię i graficzną reprezentację zależności.

Wcześniej nie można otworzyć elementu roboczego ze strony wyników wyszukiwania, jeśli okienko podglądu elementu roboczego zostało wyłączone. Utrudniłoby to zagłębienie się w wyniki wyszukiwania. Teraz możesz kliknąć tytuł elementu roboczego, aby otworzyć elementy robocze w modalnym oknie. Ta funkcja została priorytetowa w usłudze UserVoice.

Azure Repos

Autorzy rozszerzeń mogą wykonywać zapytania dotyczące kontekstu bieżącego repozytorium

Jednym z wyzwań dla autora rozszerzenia kontroli wersji jest uzyskanie kontekstu repozytorium wyświetlanego użytkownikowi, takiego jak nazwa, identyfikator i adres URL. Aby to ułatwić, dodaliśmy usługę VersionControlRepositoryService jako usługę dostępną do rozszerzenia. Dzięki temu autor rozszerzenia może wysyłać zapytania o informacje o bieżącym kontekście repozytorium Git w interfejsie użytkownika sieci Web. Obecnie ma jedną metodę getCurrentGitRepository().

  • Jeśli wybrano repozytorium Git, obiekt GitRepository jest zwracany z podstawowymi danymi dotyczącymi repozytorium (nazwa, identyfikator i adres URL)
  • Jeśli wybrano repozytorium TFVC lub usługa będzie uzyskiwana poza stronami Azure Repos, zostanie zwrócona wartość null.

Oto przykładowe rozszerzenie , które korzysta z tej usługi.

Azure Pipelines

Dodawanie niestandardowych liczników kompilacji do kompilacji

Liczniki kompilacji umożliwiają unikatowe kompilacje liczb i etykiet. Wcześniej można było użyć specjalnej zmiennej $(rev:r), aby to osiągnąć. Teraz możesz zdefiniować własne zmienne licznika w definicji kompilacji, które są automatycznie zwiększane za każdym razem, gdy uruchamiasz kompilację. Można to zrobić na karcie zmiennych definicji. Ta nowa funkcja zapewnia większą moc w następujący sposób:

  • Możesz zdefiniować niestandardowy licznik i ustawić jego wartość inicjacji. Na przykład możesz uruchomić licznik o godzinie 100. $(rev:r) zawsze zaczyna się od 0.
  • Możesz użyć własnej logiki niestandardowej, aby zresetować licznik. Wartość $(rev:r) jest powiązana z generowaniem numerów kompilacji i jest automatycznie resetowana za każdym razem, gdy w numerze kompilacji znajduje się nowy prefiks.
  • Można zdefiniować wiele liczników na definicję.
  • Możesz wykonać zapytanie o wartość licznika poza kompilacją. Na przykład można policzyć liczbę kompilacji, które zostały uruchomione od ostatniego resetowania przy użyciu licznika.

Aby uzyskać więcej informacji na temat liczników kompilacji, zobacz dokumentację dotyczącą zmiennych zdefiniowanych przez użytkownika .

Używanie języka YAML do określania gałęzi do kompilowania dla żądań ściągnięcia

Potoki YAML mogą określać, które gałęzie mają być kompilowanie żądań ściągnięcia (żądania ściągnięcia). Możesz wybrać gałęzie do uwzględnienia i wykluczenia. Ta możliwość była wcześniej dostępna w internetowym interfejsie użytkownika. Przeniesienie go do pliku YAML staje się częścią przepływu pracy konfiguracji jako kodu.

Przykład użycia wyzwalaczy żądania ściągnięcia może wyglądać następująco:

pr:
  branches:
    include:
    - features/*
    exclude:
    - features/experimental/*
  paths:
    include:
    - **/*.cs

steps:
- script: echo My PR build!

Używanie wyrażeń szablonu YAML w tekście

Szablony YAML to zaawansowany sposób ponownego użycia części potoków. Oprócz faktoringu wspólnego kodu wyrażenia szablonu umożliwiają zmianę wartości i kontrolowanie, co zawiera kod YAML. Do tej pory wyrażenie szablonu musiało zajmować całą wartość w wyrażeniu YAML. Ten przykład zadziała, ponieważ wyrażenie jest całą wartością właściwości rozwiązania .

- task: msbuild@1
  inputs:
    solution: ${{ parameters.solution }}

Teraz złagodziliśmy ograniczenie i zezwoliliśmy na szablony wbudowane, jak pokazano w poniższym przykładzie.

- script: echo The solution file is ${{ parameters.solution }}

Ulepszanie rozwiązywania problemów przy użyciu dziennika inicjowania potoku

Po uruchomieniu potoku usługa Azure Pipelines musi upewnić się, że definicja potoku jest poprawna, zdecydować, jakie zadania mają być zaplanowane, żądać agentów do uruchamiania zadań i nie tylko. Do tej pory ten proces był całkowicie nieprzezroczysły, więc gdy coś poszło nie tak, klient prawie nie mógł rozwiązać problemu. Wprowadzamy nowy rodzaj dziennika o nazwie dziennik inicjowania potoku, który sprawia, że te szczegóły są widoczne. Aby uzyskać dostęp do dziennika inicjowania potoku, wybierz opcję Pobierz wszystkie dzienniki w ukończonej kompilacji.

Domyślne przechowywanie potoków YAML

Pracujemy nad sposobem konfigurowania zasad przechowywania dla potoków YAML przez użytkowników. Dopóki ta nowa funkcja nie będzie dostępna, zwiększyliśmy domyślne przechowywanie dla wszystkich kompilacji YAML do 30 dni, ponieważ wielu użytkowników chce zachować swoje kompilacje dłużej niż w poprzednim 10-dniowym domyślnym przechowywaniu. Usunęliśmy kartę przechowywania w edytorze dla potoków YAML, dopóki nowy model nie zostanie na miejscu.

Tworzenie na platformach Linux/ARM i Windows 32-bitowych

Usługa Azure Pipelines open source, międzyplatformowy agent zawsze był obsługiwany w 64-bitowych systemach Windows, macOS i Linux. Ten przebieg wprowadzamy dwie nowe obsługiwane platformy: Linux/ARM i Windows/32-bitowe. Te nowe platformy umożliwiają tworzenie na mniej popularnych, ale nie mniej ważnych platformach, takich jak Raspberry Pi, maszyna z systemem Linux/ARM.

Klonowanie grup zmiennych

Dodaliśmy obsługę klonowania grup zmiennych. Zawsze, gdy chcesz replikować grupę zmiennych i po prostu zaktualizować kilka zmiennych, nie musisz przechodzić przez żmudny proces dodawania zmiennych jeden po drugim. Teraz możesz szybko utworzyć kopię grupy zmiennych, odpowiednio zaktualizować wartości i zapisać ją jako nową grupę zmiennych.

Klonowanie grupy zmiennych

Uwaga

Wartości zmiennych tajnych nie są kopiowane podczas klonowania grupy zmiennych. Należy zaktualizować zaszyfrowane zmienne, a następnie zapisać sklonowaną grupę zmiennych.

Zobacz zatwierdzenia i elementy robocze dla wszystkich połączonych źródeł

Kontynuując nasze zaangażowanie w kierunku lepszej możliwości śledzenia, z przyjemnością ogłaszamy, że klienci mogą teraz zobaczyć szczegóły zatwierdzenia i elementów roboczych dla wszystkich artefaktów połączonych z potokiem. Domyślnie zatwierdzenie i element roboczy są porównywane z ostatnim wdrożeniem na tym samym etapie. Jednak w razie potrzeby można porównać je z innymi poprzednimi wdrożeniami.

Połączone źródła

Uruchamianie z pakietu obsługiwanego we wdrożeniach Azure App Service

Wersja zadania Azure App Service Deploy (4.*) obsługuje teraz funkcję RunFromPackage (wcześniej o nazwie RunFromZip).

App Service obsługuje wiele różnych technik wdrażania plików, takich jak msdeploy (aka WebDeploy), git, ARM i nie tylko. Jednak wszystkie te techniki mają ograniczenie. Pliki są wdrażane w folderze wwwroot (w szczególności d:\home\site\wwwroot), a środowisko uruchomieniowe uruchamia pliki stamtąd.

W przypadku uruchamiania z pakietu nie ma już kroku wdrażania, który kopiuje poszczególne pliki do katalogu wwwroot. Zamiast tego wystarczy wskazać plik zip, a plik zip jest instalowany w katalogu wwwroot jako system plików tylko do odczytu. Ma to kilka korzyści:

  • Zmniejsza ryzyko problemów z blokowaniem kopiowania plików.
  • Można wdrożyć w aplikacji produkcyjnej (przy ponownym uruchomieniu).
  • Możesz mieć pewność, że pliki są uruchomione w aplikacji.
  • Poprawia wydajność wdrożeń Azure App Service.
  • Może skrócić czasy zimnego uruchamiania, szczególnie w przypadku funkcji Języka JavaScript z dużymi drzewami pakietów npm.

Wdrażanie kontenerów systemu Linux za pomocą zadania Wdrażanie serwera aplikacji

Wersja 4.* zadania Azure App Service Deploy obsługuje teraz wdrażanie własnego kontenera niestandardowego w Azure Functions w systemie Linux.

Model hostingu systemu Linux dla Azure Functions opiera się na kontenerach platformy Docker, co zapewnia większą elastyczność w zakresie tworzenia pakietów i korzystania z zależności specyficznych dla aplikacji. Funkcje w systemie Linux mogą być hostowane w 2 różnych trybach:

  1. Wbudowany obraz kontenera: Wprowadzasz kod aplikacji funkcji, a platforma Azure udostępnia kontener (wbudowany tryb obrazu) i zarządza nim, więc nie jest wymagana żadna wiedza związana z platformą Docker. Jest to obsługiwane w istniejącej wersji zadania App Service Deploy.
  2. Niestandardowy obraz kontenera: Ulepszyliśmy zadanie App Service Deploy w celu obsługi wdrażania niestandardowych obrazów kontenerów w Azure Functions w systemie Linux. Jeśli funkcje wymagają określonej wersji językowej lub wymagają określonej zależności lub konfiguracji, która nie jest podana na wbudowanym obrazie, możesz utworzyć i wdrożyć obraz niestandardowy w funkcji platformy Azure w systemie Linux przy użyciu usługi Azure Pipelines.

Azure Test Plans

Klient modułu uruchamiającego testy testowe platformy Azure do uruchamiania testów ręcznych dla aplikacji klasycznych

Teraz możesz użyć klienta modułu uruchamiającego testy testowe platformy Azure (ATR) do uruchamiania testów ręcznych dla aplikacji klasycznych. Pomoże to przejść z programu Microsoft Test Manager do Azure Test Plans. Zapoznaj się z naszymi wskazówkami tutaj. Za pomocą klienta usługi ATR można uruchamiać testy ręczne i rejestrować wyniki testów dla każdego kroku testu. Masz również możliwości zbierania danych, takie jak zrzut ekranu, dziennik akcji obrazu i nagrywanie wideo audio. Jeśli podczas testowania wystąpi problem, użyj modułu uruchamiającego testy, aby utworzyć usterkę z krokami testu, zrzutami ekranu i komentarzami automatycznie uwzględninymi w usterce.

Usługa ATR wymaga jednorazowego pobrania i zainstalowania modułu uruchamiającego. Wybierz pozycję Uruchom dla aplikacji klasycznej , jak pokazano poniżej.

Moduł uruchamiający testy platformy Azure

Instalowanie modułu uruchamiającego testy platformy Azure

Azure Artifacts

Publiczna wersja zapoznawcza artefaktów potoku

Udostępniamy publiczną wersję zapoznawcza potoku Artifacts , nowy wysoce skalowalny typ artefaktu zaprojektowany do użycia z usługą Azure Pipelines. Pipeline Artifacts jest oparta na tej samej technologii używanej przez niedawno ogłoszoną funkcję universal packages i może znacznie skrócić czas przechowywania danych wyjściowych kompilacji dla dużych kompilacji klasy korporacyjnej.

Witryna Wiki

Publikowanie kodu jako strony typu wiki z uprawnieniami współtworzenia

Wcześniej tylko użytkownicy z uprawnieniami do tworzenia repozytorium Git mogli publikować kod jako witrynę typu wiki. Sprawiło to, że administratorzy repozytorium lub twórcy stanowili wąskie gardło dla wszystkich żądań publikowania plików markdown hostowanych w repozytoriach Git jako stron typu wiki. Teraz możesz opublikować kod jako witrynę typu wiki , jeśli masz tylko uprawnienie Współtworzenie w repozytorium kodu.

Administracja

Wymuś cap

W lutym 2017 r. ogłosiliśmy obsługę zasad dostępu warunkowego usługi Azure Active Directory, ale istniało ograniczenie, że alternatywne mechanizmy uwierzytelniania, takie jak osobiste tokeny dostępu, nie będą wymuszać cap. Z przyjemnością ogłaszamy, że wypełniliśmy tę lukę, a usługa Azure DevOps będzie teraz honorować zasady ogrodzenia adresów IP cap podczas korzystania z pat, kluczy SSH, poświadczeń uwierzytelniania alternatywnego i protokołu OAuth. Administratorzy nie muszą nic robić, aby korzystać z tej funkcji. Zostanie ona automatycznie zastosowana do wszystkich istniejących zasad.

Następne kroki

Uwaga

Te funkcje zostaną wprowadzane w ciągu najbliższych dwóch do trzech tygodni.

Przeczytaj o nowych funkcjach poniżej i przejdź do usługi Azure DevOps, aby wypróbować je samodzielnie.

Przejdź do usługi Azure DevOps

Jak przekazać opinię

Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu opinii, aby zgłosić problem lub przekazać sugestię.

Utwórz sugestię

Możesz również uzyskać porady i pytania, na które odpowiada społeczność w witrynie Stack Overflow.

Dzięki,

Aaron Bjork