Dela via

Hanterade DevOps-pooler för Azure DevOps (förhandsversion)

  • Artikel

Vi är glada över att kunna presentera förhandsversionen av Hanterade DevOps-pooler som är utformade för att hjälpa utvecklings- och plattformstekniker att snabbt konfigurera och hantera anpassade DevOps-pooler.

Dessutom har vi förbättrat API:erna för beräkning av mätaranvändning för GitHub Advanced Security, vilket ger nya funktioner som hjälper dig att identifiera användare.

Mer information finns i viktig information.

GitHub Advanced Security för Azure DevOps

Azure-pipelines

GitHub Advanced Security för Azure DevOps

API för avancerad säkerhetsmätare returnerar nu användaridentiteter

För att hjälpa dig att identifiera dina avancerade säkerhetsanvändare returnerar API:erna för uppskattning av mätaranvändning nu varje användares Azure DevOps-identitet, inklusive deras visningsnamn, CUID, e-postidentifierare och identitetsbeskrivning. Den här funktionen är tillgänglig på organisations-, projekt- och lagringsplatsnivå. Om du vill använda den här nya slutpunkten liknar syntaxen de befintliga API-slutpunkterna för mätaranvändning och lägger /details till slutpunkten:

  • På organisationsnivå: GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • På projektnivå: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • På lagringsplatsnivå: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

GitHub Advanced Security-kodsökning för C#- och Java-projekt utan byggen

Kodgenomsökning med CodeQL innebär att köra frågor på databaser som representerar koden på lagringsplatsen för ett enda språk. För kompilerade språk som C/C++, C#, Go, Java och Swift kräver detta vanligtvis att koden skapas först.

CodeQL, den statiska analysmotorn bakom GitHub Advanced Security för Azure DevOps, kan nu skanna C#- och Java-projekt utan att behöva en version. När byggläget är inställt på "none" genereras CodeQL-databasen direkt från kodbasen och kringgår byggsteget.

För alla kompilerade språk är standardläget för bygget "manuellt". Men för C# och Java kan du ändra byggläget till "ingen".

Du kan konfigurera byggläget under installationen av AdvancedSecurity-Codeql-Init@1. Detaljerade anvisningar om hur du konfigurerar kodgenomsökning i GitHub Advanced Security med Azure DevOps finns i Konfigurera kodgenomsökning

Hänsyn:

  • Om "ingen" har valts och ett annat språk än det språk som stöds är C# eller Java kanske pipelineaktiviteten inte fungerar som förväntat.

  • Byggläget "none" fungerar för närvarande tillsammans med andra tolkade språk (t.ex. JavaScript, Python, Ruby).

  • Giltigt exempel: C# och JavaScript med byggläge inställt på "ingen". (JavaScript på ett tolkat språk)

  • Ogiltigt exempel: C#, JavaScript och Swift med byggläget inställt på "none" (Swift stöds inte i byggläget "none").

Skärmbild av AdvancedSecurity-Codeql.

Azure-pipelines

Hanterade DevOps-pooler (förhandsversion)

Teknikteamen utmärker sig när de kan fokusera på att skriva kod för att utveckla program och tjänster för sina användare. I praktiken ägnas dock ofta mycket tid åt att hantera andra uppgifter, till exempel att underhålla DevOps-infrastrukturen.

Vi är glada över att kunna presentera den offentliga förhandsversionen av Managed DevOps Pools (MDP), en ny Azure DevOps-funktion som är utformad för att hjälpa utvecklings- och plattformstekniker att distribuera anpassade DevOps-pooler som är skräddarsydda för deras unika behov. MDP kombinerar flexibiliteten hos skalningsuppsättningsagenter med det enkla underhåll som är associerat med Microsoft-värdbaserade agenter, vilket gör det möjligt för team att upprätta konsekvens och bästa praxis samtidigt som prestanda, säkerhet, efterlevnad och kostnadseffektivitet optimeras.

Viktiga fördelar med Hanterade DevOps-pooler är:

  • Värdhanterad för din räkning: MDP hanteras och hanteras av Microsoft, där de virtuella datorerna driver agenterna som skapats och underhålls i Microsoft-ägda Azure-prenumerationer.
  • Tid som ägnas åt hantering: MDP minskar avsevärt den tid som används för att hantera agenter, särskilt de som baseras på lokal infrastruktur eller manuellt underhållna system.
  • Specifika pooler: På grund av hur enkelt nya pooler kan skapas kan organisationer enkelt skapa flera teamspecifika eller arbetsbelastningsspecifika pooler.
  • DevOps-fakturering: MDP hjälper till att optimera ett teams DevOps-faktura genom många funktioner. Det gör det enkelt för team att hitta en optimal balans mellan en pools QoS/prestanda och kostnad.
  • Skalbar: MDP skalar till 1 000-talet agenter i en enda pool.

Teams kan skapa pooler med snabbstartsbilder som innehåller samma programvara som finns i Microsofts värdbaserade agenter eller med bilder som teamet har skapat med förutsättningar som är unika för deras scenario.

Läs mer om Hanterade DevOps-pooler genom att läsa vårt blogginlägg eller dess dokumentation.

Azure Pipelines-uppgifter använder Node 20

De flesta pipelineaktiviteter använder Node som löpare. Azure Pipelines-uppgift som använder NodeJS som löpare använder nu Alla NodeJS 20. Författare av aktivitetstillägg bör uppdatera sina uppgifter så att de använder Node 20. Information om hur du uppgraderar finns i Hur uppgraderar jag min anpassade uppgift till den senaste noden?.

Skapa behörighet för bygg-pipeline

För att öka pipelinesäkerheten introducerar vi en ny behörighet, Create build pipeline, på pipelinenivå.

Skärmbild av behörigheten skapa byggpipeline.

Tidigare krävdes behörigheten Edit build pipeline för att skapa eller redigera en pipeline. Detta utgjorde en säkerhetsrisk eftersom det gjorde det möjligt för alla användare med möjligheten att skapa pipelines att även redigera pipelines som de inte skapade. Det var tidskrävande att förhindra detta.

För att förbättra din pipelineupplevelse utan att äventyra säkerheten får alla användare och grupper med Edit build pipeline behörigheten nu även behörigheten Create build pipeline .

När en pipeline skapas beviljas dess skapare behörigheten Edit build pipeline .

För förbättrad pipelinesäkerhet kan du välja att ta bort behörigheten Edit build pipeline från användargrupper som Deltagare och Läsare. Detta säkerställer att endast pipelinens skapare som standard kan redigera den.

Kommentar

Behörigheten Redigera byggpipeline hindrar inte andra från att redigera en YAML-pipeline. Den skyddar endast pipelinens egenskaper från att redigeras.

För nya projekt har användare och grupper med Edit build pipeline behörigheten också behörigheten Create build pipeline . Detta kan komma att ändras i framtiden.

Exklusiv låskontroll på stegnivå

Vissa användningsfall kräver en pipeline för att få åtkomst till en specifik resurs endast en gång vid en viss tidpunkt. För att stödja det här fallet har vi kontrollen Exklusivt lås .

En liknande situation uppstår när endast en pipelinekörning ska komma åt ett stadium när som helst. Om du till exempel har en fas som distribueras till en Azure-resursgrupp kanske du vill förhindra att flera pipelinekörningar uppdaterar samma resursgrupp samtidigt. För närvarande krävs det att du använder en proxyresurs, till exempel en miljö, och att den exklusiva låskontrollen placeras i den miljön. Den här metoden kan vara tidskrävande, öka komplexiteten och öka underhållsinsatserna.

I den här sprinten introducerar vi stöd för att ange det exklusiva låset på stegnivå. Om du har en fas med ett ID och anger dess lockBehavior egenskap skapas automatiskt ett lås för den fasen. Beteendet sequential förblir konsekvent för både lås på resursnivå och nivånivå. Beteendet runLatest skiljer sig dock åt, eftersom det bara avbryter runLatest byggen för samma gren, inte för alla grenar i pipelinen.

Mallinformation i pipelinekörningar

Vi har uppdaterat Pipelines Runs – Hämta REST API med information om de mallar som utökas och ingår i en pipelinekörning.

Anta till exempel att du har följande YAML-pipelinekod:

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

Det nya REST-API:et har följande nya egenskaper:

"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"
    }

Manuellt utlösta YAML-pipelinesteg

Vi får ofta förfrågningar om manuellt utlösta YAML-pipelinesteg. Dessa är användbara när du vill ha en enhetlig pipeline men inte alltid vill att den ska köras.

Din pipeline kan till exempel innehålla steg för att skapa, testa, distribuera till en mellanlagringsmiljö och distribuera till produktion. Du kanske vill att alla steg ska köras automatiskt förutom produktionsdistributionen, som du föredrar att utlösa manuellt när du är klar.

Med den här sprinten lägger vi till stöd för manuellt utlösta YAML-pipelinesteg. Om du vill använda den här funktionen måste du lägga till egenskapen i trigger: manual en fas.

Överväg följande YAML-pipelineexempel:

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'''

När du kör den här pipelinen är upplevelsen följande:

Skärmbild av manuellt utlösta YAML-pipelinesteg.

Manuellt utlösta steg har inga beroenden och kan köras när som helst. Pipelinekörningen slutförs när det bara finns manuellt utlösta steg kvar att köra.

Nästa steg

Kommentar

Dessa funktioner kommer att distribueras under de kommande två till tre veckorna.

Gå över till Azure DevOps och ta en titt.

Gå till Azure DevOps

Så här ger du feedback

Vi vill gärna höra vad du tycker om de här funktionerna. Använd hjälpmenyn för att rapportera ett problem eller ge ett förslag.

Ge ett förslag

Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.

Tack,

Silviu Andrica