Udostępnij przez

Zarządzane pule DevOps dla platformy Azure DevOps (wersja podglądowa)

Z przyjemnością informujemy o wersji zapoznawczej zarządzanych pul DevOps, które zostały zaprojektowane, aby pomóc zespołom deweloperskim i inżynieryjnym platformy szybko konfigurować i zarządzać niestandardowymi pulami DevOps.

Ponadto ulepszyliśmy interfejsy API szacowania użycia miernika dla usługi GitHub Advanced Security, zapewniając nowe możliwości, które ułatwiają identyfikowanie użytkowników.

Sprawdź notatki o wydaniu, aby uzyskać szczegóły.

GitHub Advanced Security dla usługi Azure DevOps

Azure Pipelines

GitHub Advanced Security dla usługi Azure DevOps

Interfejs API użycia miernika zaawansowanego zabezpieczeń zwraca teraz tożsamości użytkowników

Aby ułatwić identyfikowanie użytkowników usługi Advanced Security, interfejsy API szacowania użycia miernika zwracają teraz tożsamość usługi Azure DevOps każdego użytkownika, w tym ich nazwę wyświetlaną, identyfikator CUID, identyfikator e-mail i deskryptor tożsamości. Ta funkcja jest dostępna na poziomach organizacji, projektu i repozytorium. Aby użyć tego nowego punktu końcowego, składnia jest podobna do istniejących punktów końcowych interfejsu API użycia miernika, dołączając /details do punktu końcowego:

  • Na poziomie organizacji: GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • Na poziomie projektu: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • Na poziomie repozytorium: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

Skanowanie kodu usługi GitHub Advanced Security dla projektów C# i Java bez kompilacji

Skanowanie kodu przy użyciu języka CodeQL obejmuje uruchamianie zapytań w bazach danych reprezentujących kod w repozytorium dla jednego języka. W przypadku skompilowanych języków, takich jak C/C++, C#, Go, Java i Swift, zwykle wymaga to najpierw utworzenia kodu.

Jednak codeQL, aparat analizy statycznej za usługą GitHub Advanced Security dla usługi Azure DevOps, może teraz skanować projekty języka C# i Java bez konieczności kompilacji. Gdy tryb kompilacji ma wartość "none", baza danych CodeQL jest generowana bezpośrednio z bazy kodu, pomijając krok kompilacji.

W przypadku wszystkich skompilowanych języków domyślny tryb kompilacji to "ręczne". Jednak w przypadku języków C# i Java można zmienić tryb kompilacji na "none".

Tryb kompilacji można skonfigurować podczas instalacji AdvancedSecurity-Codeql-Init@1. Aby uzyskać szczegółowe instrukcje dotyczące konfigurowania skanowania kodu w usłudze GitHub Advanced Security za pomocą usługi Azure DevOps, zobacz Konfigurowanie skanowania kodu

Rozwaga:

  • Jeśli wybrano "none" i użyto języka innego niż obsługiwane języki skompilowane C# lub Java, zadanie potoku może nie działać zgodnie z oczekiwaniami.

  • Tryb kompilacji "none" działa obecnie w połączeniu z innymi językami interpretowanymi (np. JavaScript, Python, Ruby).

  • Prawidłowy przykład: C# i JavaScript z trybem kompilacji ustawionym na "none". (JavaScript w języku interpretowanym)

  • Nieprawidłowy przykład: C#, JavaScript i Swift z trybem kompilacji ustawionym na wartość "none" (swift nie jest obsługiwana w trybie kompilacji "none").

Zrzut ekranu AdvancedSecurity-Codeql.

Azure Pipelines

Zarządzane pule DevOps (wersja zapoznawcza)

Zespoły inżynieryjne osiągają doskonałość, gdy mogą skupić się na pisaniu kodu, aby rozwijać aplikacje i usługi dla swoich użytkowników. Jednak w praktyce znaczna ilość czasu jest często poświęcana na zarządzanie innymi zadaniami, takimi jak utrzymywanie infrastruktury DevOps.

Z przyjemnością ogłaszamy publiczną wersję zapoznawczą zarządzanych pul DevOps (MDP), nową funkcję usługi Azure DevOps zaprojektowaną w celu ułatwienia zespołom programistów i inżynierów platformy wdrażania niestandardowych pul DevOps dostosowanych do ich unikatowych potrzeb. MDP łączy elastyczność agentów Scale Set z łatwością konserwacji, jaką zapewniają agenci hostowani przez Microsoft, umożliwiając zespołom ustanawianie spójności i najlepszych praktyk przy jednoczesnej optymalizacji wydajności, zabezpieczeń, zgodności i efektywności kosztowej.

Najważniejsze zalety zarządzanych pul DevOps obejmują:

  • Hostowane w Twoim imieniu: Protokół MDP jest hostowany i zarządzany przez firmę Microsoft, a maszyny wirtualne obsługują agentów utworzone i obsługiwane w ramach subskrypcji platformy Azure należących do firmy Microsoft.
  • Czas spędzony w zarządzaniu: Protokół MDP znacznie skraca czas poświęcany na zarządzanie agentami, szczególnie na podstawie infrastruktury lokalnej lub ręcznie obsługiwanych systemów.
  • Określone pule: Ze względu na łatwość tworzenia nowych pul organizacje mogą łatwo tworzyć wiele pul specyficznych dla zespołu lub pul specyficznych dla obciążenia.
  • Rozliczenia metodyki DevOps: Protokół MDP pomaga zoptymalizować rachunek za metodykę DevOps zespołu za pośrednictwem wielu funkcji. Ułatwia zespołom znalezienie optymalnej równowagi między funkcją QoS/wydajnością puli a kosztami.
  • Skalowalne: Protokół MDP skaluje do 1000 agentów w pojedynczej puli.

Zespoły mogą tworzyć pule z obrazami szybkiego startu, które zawierają to samo oprogramowanie obecne w agentach hostowanych przez firmę Microsoft lub obrazy utworzone przez zespół z warunkami wstępnymi, które są unikatowe dla ich scenariusza.

Dowiedz się więcej o zarządzanych pulach DevOps, czytając nasz wpis w blogu lub jego dokumentację.

Zadania usługi Azure Pipelines używają węzła 20

Większość zadań potoku używa węzła jako modułu uruchamiającego. Zadanie usługi Azure Pipelines, które używa NodeJS jako środowiska uruchomieniowego, teraz korzysta z NodeJS 20. Autorzy rozszerzeń zadań powinni zaktualizować swoje zadania, aby używały Node 20. Aby uzyskać wskazówki dotyczące uaktualniania, zobacz How can I upgrade my custom task to the latest Node? (Jak mogę uaktualnić zadanie niestandardowe do najnowszej wersji środowiska Node?).

Uprawnienie do tworzenia potoku kompilacyjnego

Aby zwiększyć bezpieczeństwo rur, wprowadzamy nowe uprawnienie, Create build pipeline, na poziomie pipeline'ów.

Zrzut ekranu przedstawiający uprawnienie do tworzenia potoku kompilacji.

Edit build pipeline Wcześniej wymagane było uprawnienie do tworzenia lub edytowania potoku. Stwarzało to zagrożenie bezpieczeństwa, ponieważ umożliwiało to wszystkim użytkownikom, którzy mogli tworzyć potoki, również edytowanie potoków, których nie utworzyli. Zapobieganie temu było czasochłonne.

Aby ulepszyć doświadczenie korzystania z potoku bez naruszania zabezpieczeń, wszyscy użytkownicy i grupy posiadające uprawnienie Edit build pipeline, otrzymają również uprawnienie Create build pipeline.

Po utworzeniu potoku jego twórca otrzymuje Edit build pipeline uprawnienie.

W celu zwiększenia bezpieczeństwa procesu możesz usunąć uprawnienie z grup użytkowników, takich jak Współautorzy i Czytelnicy. Zapewnia to, że domyślnie tylko twórca pipeline'u może go edytować.

Uwaga / Notatka

Uprawnienie Edytowanie potoku kompilacji nie blokuje innym osobom edytowania potoku YAML, a jedynie zabezpiecza właściwości potoku przed edycją.

W przypadku nowych projektów użytkownicy i grupy z Edit build pipeline uprawnieniami będą również mieli Create build pipeline uprawnienia. Może to ulec zmianie w przyszłości.

Wyłączna kontrola blokady na poziomie etapu

Niektóre przypadki użycia wymagają kanału przetwarzania do uzyskania dostępu do określonego zasobu tylko raz w danym momencie. Aby zapewnić obsługę tego przypadku, mamy kontrolę blokady na wyłączność.

Podobna sytuacja występuje, gdy tylko jeden przebieg potoku może mieć dostęp do etapu w dowolnym momencie. Jeśli na przykład masz etap, który jest wdrażany w grupie zasobów platformy Azure, możesz uniemożliwić jednoczesne aktualizowanie tej samej grupy zasobów przez wiele przebiegów potoku. Obecnie, aby to osiągnąć, konieczne jest użycie zasobu proxy, takiego jak środowisko, oraz umieszczenie kontroli blokad wyłącznych w tym środowisku. Takie podejście może być czasochłonne, zwiększać złożoność i zwiększać nakłady pracy konserwacyjne.

W tym przebiegu wprowadzamy obsługę określania wyłącznej blokady na poziomie etapu. Jeśli masz etap z identyfikatorem i określisz jego lockBehavior właściwość, blokada zostanie automatycznie utworzona dla tego etapu. Zachowanie sequential pozostaje spójne zarówno dla blokad na poziomie zasobów, jak i na poziomie etapów. Jednak zachowanie różni się runLatest ponieważ anuluje runLatest tylko kompilacje dla tej samej gałęzi, a nie dla wszystkich gałęzi potoku.

Informacje o szablonie w uruchomieniach przepływu

Zaktualizowaliśmy przebiegi potoków — pobierz interfejs API REST z informacjami o szablonach rozszerzonych i uwzględnionych w przebiegu potoku.

Rozważmy na przykład następujący kod potoku YAML:

extends:
  template: template-stages.yml@templates
  parameters:
    stages:
    - stage: deploy
      jobs:
      - job:
        steps:
        - template: template-step.yml

Nowy interfejs API REST ma następujące nowe właściwości:

"yamlDetails":
    {
        "extendedTemplates":
        [
            {
                "yamlFile": "template-stages.yml",
                "repoAlias": "templates"
            }
        ],
        "includedTemplates":
        [
            {
                "yamlFile": "template-step.yml",
                "repoAlias": "templates"
            }
        ],
        "rootYamlFile":
        {
            "ref": "refs/heads/main",
            "yamlFile": "azure-pipelines.yml",
            "repoAlias": "self"
        },
        "expandedYamlUrl": "https://dev.azure.com/fabrikamfiber/161cfeeb-d9fd-395c-917b-fec46db44fbb/_apis/build/builds/39224/logs/1"
    }

Etapy rurociągu YAML wyzwalane ręcznie

Często otrzymujemy żądania dotyczące ręcznie wyzwalanych etapów potoku YAML. Są one przydatne, gdy potrzebujesz ujednoliconego potoku, ale nie zawsze chcesz, aby był doprowadzany do końca.

Na przykład pipeline może obejmować etapy tworzenia, testowania, wdrażania w środowisku testowym i wdrażania w środowisku produkcyjnym. Możesz chcieć, aby wszystkie etapy działały automatycznie z wyjątkiem wdrożenia produkcyjnego, które wolisz wyzwalać ręcznie, gdy wszystko będzie gotowe.

W tej iteracji dodamy obsługę ręcznie wyzwalanych etapów potoku YAML. Aby użyć tej funkcji, trzeba dodać trigger: manual atrybut do etapu.

Rozważmy następujący przykład potoku YAML:

stages:
- stage: stage_WUS1
  displayName: Deploy WUS1
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''     
- stage: stage_WUS2
  displayName: Deploy WUS2
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''

Po uruchomieniu tego potoku wrażenia są następujące:

Zrzut ekranu przedstawiający etapy potoku YAML wyzwalane ręcznie.

Etapy wyzwalane ręcznie nie mają zależności i mogą być uruchamiane w dowolnym momencie. Przebieg potoku kończy się, gdy do zrealizowania pozostają tylko etapy wyzwalane ręcznie.

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

Przejdź do usługi Azure DevOps

Jak przekazać opinię

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

Utwórz sugestię

Możesz również uzyskać porady i odpowiedzi na pytania społeczności w witrynie Stack Overflow.

Dzięki

Silviu Andrica

  • Last updated on