Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dzięki tej aktualizacji ułatwiliśmy uwierzytelnianie usługi Azure Artifacts za pomocą innych popularnych menedżerów pakietów. Więcej szczegółów na temat rzeczywistej implementacji można znaleźć poniżej.
Funkcje
Azure Boards
- dodaj filtr "Nadrzędny element roboczy" do tablicy zadań i listy prac przebiegu
- Ulepszanie środowiska obsługi błędów — wymagane pola dotyczące usterki/zadania
Azure Pipelines
- Podgląd agentów zestawu skalowania
- Ubuntu 20.04 w wersji zapoznawczej dla hostowanych pul usługi Azure Pipelines
- Obsługa pakietów GitHub w potokach YAML
Azure Artifacts
- Powiadomienia dotyczące wyłączonych źródeł nadrzędnych
- Wyrażenia licencji i osadzone licencje
- Uproszczone zadania uwierzytelniania
Azure Boards
Dodaj filtr „Nadrzędny element roboczy” do tablicy zadań i rejestru sprintu
Dodaliśmy nowy filtr zarówno do tablicy Sprintu, jak i listy prac Sprintu. Dzięki temu można filtrować elementy backlogu na poziomie wymagań (pierwsza kolumna po lewej stronie) według ich rodzica. Na przykład na poniższym zrzucie ekranu odfiltrowaliśmy widok tak, aby pokazywał tylko historyjki użytkownika, w których element nadrzędny jest "Moja duża funkcja".
Ulepszanie środowiska obsługi błędów — wymagane pola dotyczące usterki/zadania
Dawniej na tablicy Kanban, jeśli element roboczy został przesunięty z jednej kolumny do drugiej, gdzie zmiana statusu wyzwalała reguły pól, karta była wyświetlana z czerwonym komunikatem o błędzie, który wymuszał otwarcie elementu roboczego, aby zrozumieć główną przyczynę. Podczas sprintu 170 ulepszyliśmy doświadczenie, dzięki czemu można teraz kliknąć czerwony komunikat o błędzie, aby wyświetlić szczegóły błędu bez konieczności otwierania samego elementu roboczego.
Azure Pipelines
Podgląd agentów skalowalnego zestawu
Wyświetlamy przegląd nowej funkcji nazywanej agentami zestawu skalującego, która łączy wygodę i elastyczną pojemność agentów hostowanych przez firmę Microsoft z kontrolą i elastycznością agentów hostowanych samodzielnie. Ta wersja zapoznawcza umożliwia teraz zarządzanie agentami zgodnie ze specyfikacją, całkowicie zautomatyzowaną w ramach subskrypcji platformy Azure. Warto rozważyć użycie agentów zestawu skalowania zamiast agentów hostowanych przez firmę Microsoft lub własnych agentów w następujących przypadkach:
- potrzebujesz więcej pamięci, więcej procesora, więcej miejsca do magazynowania lub więcej operacji we/wy niż oferujemy w natywnych agentach hostowanych przez firmę Microsoft
- Nie chcesz zezwalać na wyświetlanie listy wielu adresów IP w zaporze firmowej w celu umożliwienia agentom hostowanym przez firmę Microsoft komunikowania się z serwerami
- potrzebują więcej agentów hostowanych przez firmę Microsoft, niż możemy zapewnić, aby spełnić Twoje potrzeby na dużą skalę
- musi mieć możliwość partycjonowania zadań równoległych hostowanych przez firmę Microsoft do poszczególnych projektów lub zespołów w organizacji
- Nie chcesz uruchamiać dedykowanych agentów przez cały czas, ale zamiast tego chcesz usunąć aprowizację maszyn agentów, które nie są aktywnie wykorzystywane.
Aby użyć agentów zestawu skalowania, najpierw utworzysz zestaw skalowania maszyn wirtualnych w ramach subskrypcji platformy Azure, a następnie utworzysz pulę agentów w usłudze Azure Pipelines, aby wskazać ten zestaw skalowania. Usługa Azure Pipelines automatycznie skaluje tę pulę na podstawie liczby oczekujących zadań i liczby bezczynnych maszyn, które mają być obsługiwane przez cały czas. Usługa Azure Pipelines zainstaluje również agenta na tych maszynach wirtualnych. Aby uzyskać więcej informacji, zobacz Agenci zestawu skalowania. Podczas wyświetlania podglądu funkcji dołącz swoją opinię na stronie dokumentacji.
System Ubuntu 20.04 w wersji zapoznawczej dla pul hostowanych usługi Azure Pipelines
Obraz Ubuntu 20.04 jest teraz dostępny w wersji zapoznawczej w hostowanych pulach usługi Azure Pipelines. Aby użyć tego obrazu, zaktualizuj plik YAML, aby uwzględnić plik vmImage: "ubuntu-20.04". Pamiętaj, że etykieta obrazu ubuntu-latest będzie nadal odnosić się do ubuntu-18.04, dopóki ubuntu-20.04 nie zakończy swojej wersji zapoznawczej w późniejszym czasie w tym roku.
Pamiętaj, że ponieważ obraz ubuntu 20.04 jest w wersji zapoznawczej, obecnie nie obsługuje wszystkich narzędzi dostępnych w systemie ubuntu-18.04. Dowiedz się więcej
Obsługa pakietów GitHub w potokach YAML
Niedawno wprowadziliśmy nowy typ zasobów o nazwie pakiety , który umożliwia korzystanie z pakietów NuGet i npm z usługi GitHub jako zasobu w potokach YAML. W ramach tego zasobu można teraz określić typ pakietu (NuGet lub npm), który ma być używany z usługi GitHub. Możesz również włączyć automatyczne wyzwalacze potoku po wydaniu nowej wersji pakietu. Obecnie obsługa jest dostępna tylko w przypadku korzystania z pakietów z usługi GitHub, ale planujemy rozszerzyć obsługę korzystania z pakietów z innych repozytoriów pakietów, takich jak NuGet, npm, AzureArtifacts i wiele innych. Aby uzyskać szczegółowe informacje, zapoznaj się z poniższym przykładem:
resources:
packages:
- package: myPackageAlias # alias for the package resource
type: Npm # type of the package NuGet/npm
connection: GitHubConn # GitHub service connection of type PAT
name: nugetTest/nodeapp # <Repository>/<Name of the package>
version: 1.0.9 # Version of the package to consume; Optional; Defaults to latest
trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers
Uwaga: Obecnie pakiety GitHub obsługują tylko uwierzytelnianie oparte na pat, co oznacza, że połączenie usługi GitHub w zasobie pakietu powinno być typu PAT. Gdy to ograniczenie zostanie zniesione, zapewnimy obsługę innych typów uwierzytelniania.
Domyślnie pakiety nie są automatycznie pobierane w zadaniach, dlatego wprowadziliśmy getPackage makro, które umożliwia korzystanie z pakietu zdefiniowanego w zasobie. Aby uzyskać szczegółowe informacje, zapoznaj się z poniższym przykładem:
- job: job1
pool: default
steps:
- getPackage: myPackageAlias # Alias of the package resource
Azure Artifacts
Powiadomienia dotyczące wyłączonych źródeł nadrzędnych
Interfejs internetowy usługi Azure Artifacts teraz powiadamia, gdy co najmniej jedno źródło nadrzędne kanału nie działa. Źródła nadrzędne umożliwiają wskazanie kanału informacyjnego (Kanał informacyjny A) do innego źródła danych (Kanał informacyjny B) i umożliwienie konsumentom kanału informacyjnego A uzyskiwania dostępu do pakietów z kanału informacyjnego B bez konieczności nawiązywania bezpośredniego połączenia z nim. Aby uzyskać więcej informacji o źródłach nadrzędnych, zobacz dokumentację usługi Azure Artifacts. Źródła nadrzędne mogą nie działać, jeśli są wyłączone w źródle, na przykład jeśli źródło danych B zostało usunięte w trybie dyskretnym, klienci nie będą mogli pobierać z niego pakietów za pośrednictwem kanału informacyjnego A. W przeszłości taka sytuacja może wystąpić bez ostrzeżenia i prowadzić do trudnych do zdiagnozowania problemów operacyjnych, takich jak nagłe przerwy kompilacji z powodu brakujących zależności (tj. pakietów źródłowych z kanału informacyjnego B w powyższym przykładzie). Teraz usługa Azure Artifacts wyświetli ostrzeżenie, gdy występują problemy z dowolnymi nadrzędnymi źródłami kanałów informacyjnych. Gdy problem istnieje, na stronie szczegółów kanału informacyjnego usługi Azure Artifacts zostanie wyświetlony baner (czerwona strzałka poniżej).
Kliknięcie linku na banerze spowoduje otwarcie strony, która pokazuje status każdego źródła nadrzędnego twojego kanału. Oprócz informacji o każdym źródle nadrzędnym dla bieżącego kanału informacyjnego można zobaczyć bieżący stan w kolumnie "Ostatnia synchronizacja". Źródła nadrzędne, które działają prawidłowo, będą wyświetlać zielony znak zaznaczenia wraz z ostatnim potwierdzeniem kondycji źródła. Źródła nadrzędne, które są uszkodzone, będą pokazywać czerwony X przy czasie, o której zostały sprawdzone. Źródła nadrzędne oczekujące na weryfikację będą wyświetlać niebieską ikonę informacji.
Po kliknięciu czasu ostatniej synchronizacji dla niedziałającego źródła nadrzędnego zostanie otwarte okno dialogowe zawierające więcej szczegółów na temat głównej przyczyny problemu (jeśli jest dostępna). Na przykład na poniższej ilustracji źródło nadrzędne nie działa, ponieważ kanał docelowy został usunięty. Okno dialogowe zawiera również link do dziennika inspekcji, aby ułatwić zrozumienie, kto ostatnio wprowadził istotne zmiany. Linki do ustawień uprawnień i dokumentacji usługi Azure Artifacts mogą również służyć do badania głównej przyczyny.
Wyrażenia licencyjne i wbudowane licencje
Teraz możesz zobaczyć szczegóły informacji o licencji pakietów NuGet przechowywanych w usłudze Azure Artifacts podczas przeglądania pakietów w programie Visual Studio. Dotyczy to licencji reprezentowanych przy użyciu wyrażeń licencji lub osadzonych licencji. Teraz możesz wyświetlić link do informacji o licencji na stronie szczegółów pakietu programu Visual Studio (czerwona strzałka na poniższej ilustracji).
Kliknięcie linku spowoduje przejście do strony internetowej, na której można wyświetlić szczegóły licencji. To doświadczenie jest takie samo w przypadku wyrażeń licencji i licencji osadzonych, więc można zobaczyć szczegóły licencji pakietów przechowywanych w usłudze Azure Artifacts w jednym miejscu (dla pakietów, które określają informacje o licencji i są wspierane przez program Visual Studio).
Uproszczone zadania uwierzytelniania
Teraz możesz uwierzytelniać się za pomocą popularnych menedżerów pakietów w Azure Pipelines, korzystając z lekkich zadań uwierzytelniania. Obejmuje to narzędzia NuGet, npm, PIP, Twine i Maven. Wcześniej można było uwierzytelnić się za pomocą tych menedżerów pakietów przy użyciu zadań, które udostępniały dużą ilość funkcji, w tym możliwość publikowania i pobierania pakietów. Jednakże wymagało to użycia tych zadań dla wszystkich działań, które współpracowały z menedżerami pakietów. Jeśli masz własne skrypty do uruchamiania na potrzeby wykonywania zadań, takich jak publikowanie lub pobieranie pakietów, nie można ich używać w potoku. Teraz możesz używać skryptów własnego projektu w potoku YAML i wykonywać uwierzytelnianie przy użyciu tych nowych uproszczonych zadań. Przykład użycia narzędzia npm:
Użycie polecenia "ci" i "publish" na tej ilustracji jest dowolne. Można użyć dowolnych poleceń obsługiwanych przez usługę Azure Pipelines YAML. Dzięki temu można mieć pełną kontrolę nad wywoływaniem poleceń i ułatwia użycie wspólnych skryptów w konfiguracji potoku. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją zadania uwierzytelniania dla NuGet, npm, PIP, Twinei Maven.
Dalsze kroki
Uwaga / Notatka
Te funkcje będą wdrażane w ciągu najbliższych dwóch do trzech tygodni.
Przejdź do usługi Azure DevOps i przyjrzyj się.
Jak przekazać opinię
Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.
Możesz również uzyskać porady i odpowiedzi na pytania społeczności w witrynie Stack Overflow.
Dzięki,
Aaron Hallberg