Udostępnij za pośrednictwem

Zarządzane pule DevOps dla usługi Azure DevOps (wersja zapoznawcza)

  • Artykuł

Z przyjemnością informujemy o wersji zapoznawczej zarządzanych pul DevOps zaprojektowanych w celu szybkiego konfigurowania niestandardowych pul devOps i zespołów inżynierów platformy i zarządzania nimi.

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.

Zapoznaj się z informacjami o wersji, aby uzyskać szczegółowe informacje.

Usługa GitHub Advanced Security dla usługi Azure DevOps

Azure Pipelines

Usługa 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 opcję "none" , a język inny niż obsługiwany obsługiwany języki 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 wartość "none". (JavaScript w interpretowanym języku)

  • 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 przedstawiający plik AdvancedSecurity-Codeql.

Azure Pipelines

Zarządzane pule DevOps (wersja zapoznawcza)

Zespoły inżynieryjne excel, gdy mogą skupić się na pisaniu kodu w celu tworzenia aplikacji i usług 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ę zapoznawcza zarządzanych pul DevOps (MDP), nową funkcję usługi Azure DevOps zaprojektowaną w celu ułatwienia zespołom inżynierów programistycznych i zespołom inżynierów platformy wdrażania niestandardowych pul DevOps dostosowanych do ich unikatowych potrzeb. Protokół MDP łączy elastyczność agentów zestawu skalowania z łatwością konserwacji skojarzonej z agentami hostowanymi przez firmę Microsoft, umożliwiając zespołom ustanawianie spójności i najlepszych rozwiązań przy jednoczesnej optymalizacji wydajności, zabezpieczeń, zgodności i wydajnoś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 spędzony na zarządzaniu 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 pomocą 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 jednej 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 wymaganiami 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 węzłaJS jako moduł uruchamiający, teraz używa teraz środowiska NodeJS 20. Autorzy rozszerzeń zadań powinni zaktualizować swoje zadania, aby używały węzła 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 kompilacji

Aby zwiększyć bezpieczeństwo potoku, wprowadzamy nowe uprawnienie, Create build pipeline, na poziomie potokó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żliwiło to wszystkim użytkownikom tworzenie potoków w celu edytowania potoków, których nie utworzyli. Zapobieganie temu było czasochłonne.

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

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

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

Uwaga

Uprawnienie Edytowanie potoku kompilacji nie uniemożliwia innym osobom edytowania potoku YAML; chroni tylko właściwości potoku przed edycją.

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

Wyłączna kontrola blokady na poziomie etapu

Niektóre przypadki użycia wymagają potoku, aby uzyskać dostęp 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 jedno uruchomienie potoku powinno uzyskać 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 osiągnięcie tego celu wymaga użycia zasobu serwera proxy, takiego jak środowisko, i umieszczenie w tym środowisku kontroli wyłącznych blokad. 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śl 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 etapu. 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 potoku

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 potoku 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ł uruchamiany do ukończenia.

Na przykład potok może obejmować etapy tworzenia, testowania, wdrażania w środowisku przejściowym 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 tym przebiegu dodamy obsługę ręcznie wyzwalanych etapów potoku YAML. Aby użyć tej funkcji, należy dodać trigger: manual właściwość 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 środowisko jest 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. Uruchomienie potoku kończy się, gdy do wykonania pozostały tylko etapy wyzwalane ręcznie.

Następne kroki

Uwaga

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