Dela via

Inställning för att inaktivera skapandet av TFVC-lagringsplatser

  • Artikel

Med den här uppdateringen introducerar vi en ny inställning för att inaktivera skapandet av TFVC-lagringsplatser. Den här ändringen fokuserar på nya projekt samtidigt som du ser till att dina befintliga TFVC-lagringsplatser inte påverkas.

Dessutom är vi glada över att kunna meddela att i Azure Pipelines är en ny REST API-slutpunkt tillgänglig för att begära OIDC-token! Detta gör det möjligt för uppgiftsutvecklare att generera idTokens för Entra-ID-autentisering, vilket förbättrar säkerheten och användarvänligheten.

Slutligen kan du bara ta bort områdes- och iterationssökvägar i Azure Boards om de inte längre är associerade med några arbetsobjekt. Den här förbättringen förhindrar störningar och säkerställer att teamen behåller åtkomsten till sina styrelser och kvarvarande uppgifter.

Mer information finns i viktig information.

GitHub Advanced Security för Azure DevOps

Azure Boards:

Azure-lagringsplatser

Azure-pipelines

Azure Test Plans:

GitHub Advanced Security för Azure DevOps

Dokumentation om API för säkerhetsöversikt är nu tillgänglig

Dokumentation för API:et som driver fliken Översikt över avancerad säkerhet är nu tillgänglig. Använd slutpunkten /{organization}/_apis/reporting/summary/alerts för att visa en sammanfattning av aviseringskritiskhet för alla Avancerade säkerhetsaktiverade lagringsplatser. Se till att din ADO PAT har behörigheten vso.advsec , vilket ger möjlighet att läsa aviseringar, resultatinstanser och analysresultatinstanser.

Azure-tavlor

Ändra för att ta bort sökvägar för område och iteration

Det kan vara störande att ta bort ett område eller en iterationssökväg. Det kan flytta arbetsobjekt till en ny sökväg och kan leda till att team förlorar åtkomst till sina tavlor och kvarvarande uppgifter. Trots varningar och uppmaningar tas sökvägar ibland bort utan att helt förstå konsekvenserna. För att åtgärda detta har vi ändrat beteendet: Sökvägar för område och iteration kan nu bara tas bort om de inte längre används av några arbetsobjekt.

Skärmbilder av borttagningsområdet.

Azure-lagringsplatser

Ny inställning för att inaktivera skapandet av TFVC-lagringsplatser

Under de senaste åren har inga nya funktioner lagts till i Team Foundation Version Control (TFVC) eftersom Git har blivit det föredragna versionskontrollsystemet i Azure Repos. Alla de senaste förbättringarna av säkerhet, prestanda och tillgänglighet har gjorts uteslutande för Git-lagringsplatser, vilket leder till en kontinuerlig minskning av TFVC-användningen. Medan vissa fortfarande förlitar sig på TFVC och vi inte tänker ta bort den här funktionsuppsättningen, planerar vi att gradvis fasa ut TFVC för nya projekt och organisationer, samt för projekt som för närvarande inte använder TFVC.

Som en del av den här övergången introducerar vi en ny inställning för "Inaktivera skapande av TFVC-lagringsplatser", vilket bara påverkar skapandet av nya TFVC-lagringsplatser och inte påverkar befintliga.

Gif to demo Inaktivera skapandet av TFVC-lagringsplatser.

Azure-pipelines

Få åtkomst till Azure Service Bus från pipelines med hjälp av Microsoft Entra-ID-autentisering

Nu kan du använda Microsoft Entra ID-autentisering för att få åtkomst till Azure Service Bus från Azure Pipelines. På så sätt kan du dra nytta av arbetsbelastningsidentitetsfederationen för att ta bort hantering av hemligheter och Azure RBAC för detaljerad åtkomstkontroll.

Identiteter som har åtkomst till Azure Service Bus måste beviljas en av de inbyggda Azure-rollerna för Azure Service Bus på servicebussen som nås.

PublishToAzureServiceBus@2 uppgift

De nya PublishToAzureServiceBus@2 uppgifterna kan konfigureras med hjälp av en Azure-tjänstanslutning. Skapa en Azure-tjänstanslutning och fyll i serviceBusQueueName egenskaperna och serviceBusNamespace för den nya uppgiften:

- task: PublishToAzureServiceBus@2
  inputs:
    azureSubscription: my-azure-service-connection
    serviceBusQueueName: my-service-bus-queue
    serviceBusNamespace: my-service-bus-namespace
    useDataContractSerializer: false
    messageBody: |
      {
        "foo": "bar"
      }
Serveruppgifter

Anpassade serveruppgifter (agentlösa) som använder ServiceBus körning kan ange en Azure-tjänstanslutning som EndpointId och utelämna ConnectionString. Se Redigering av serveraktivitet.

Pipelines och uppgifter fyller i variabler för att anpassa autentisering för arbetsbelastningsidentitetsfederation

REST API-slutpunkten för att begära OIDC-token är nu tillgänglig i System.OidcRequestUri pipelinevariabeln. Uppgiftsutvecklare kan använda den här variabeln för att generera en idToken för autentisering med Entra-ID.

Om du använder Marketplace-uppgifter eller anpassade uppgifter för att distribuera till Azure bör du vara medveten om att dessa uppgifter kanske inte stöder arbetsbelastningsidentitetsfederation ännu. Vi rekommenderar uppgiftsutvecklare att aktivera arbetsbelastningsidentitetsfederation för att förbättra säkerhetsåtgärderna.

Skärmbild av oidc-samarbete.

Uppgifter som tar in indata connectedService:AzureRM i task.json kan uppdateras för att stödja arbetsbelastningsidentitetsfederation genom att följa dessa steg:

  • Använd rest-API:et för Oidctoken för att begära en idToken (pil 1 i diagrammet ovan).
  • Byt idToken mot en åtkomsttoken med hjälp av det federerade autentiseringsflödet i OAuth-API:et och ange idToken som client_assertion (pilarna 2 & 4 i diagrammet ovan);
    eller:
  • För uppgifter som fungerar som omslutning runt ett verktyg som utför själva autentiseringen använder du verktygens autentiseringsmetod för att ange den federerade token.

Node-uppgifter kan använda det vanliga npm-paketet azure-pipelines-tasks-artifacts-common för att hämta idToken. Se kodexemplet för implementeringsinformation.

Begära en ny idToken

Pipelinevariabeln System.OidcRequestUri och AZURESUBSCRIPTION_SERVICE_CONNECTION_ID miljövariabeln som exponeras i aktiviteterna och AzurePowerShell@5 gör det möjligt för pipelineförfattare att autentisera AzureCLI@2 från sitt eget skript:

PowerShell Az
- task: AzurePowerShell@5
  inputs:
    azureSubscription: 'my-azure-subscription'
    scriptType: inlineScript
    inline: |        
      # Request fresh idToken
      Invoke-RestMethod -Headers @{
                        Authorization  = "Bearer $(System.AccessToken)"
                        'Content-Type' = 'application/json'
                      } `
                      -Uri "${env:SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${env:AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}" `
                      -Method Post `
                      | Select-Object -ExpandProperty oidcToken
                      | Set-Variable idToken

    # Fetch current context
    $azContext = Get-AzContext

    # Start new Az session
    Connect-AzAccount -ApplicationId $azContext.Account.Id `
                      -TenantId $azContext.Tenant.Id `
                      -SubscriptionId $azContext.Subscription.Id `
                      -FederatedToken $idToken
Azure CLI
- task: AzureCLI@2
  inputs:
    addSpnToEnvironment: true
    azureSubscription: 'my-azure-subscription'
    scriptType: bash
    scriptLocation: inlineScript
    inlineScript: |
      # Request fresh idToken
      OIDC_REQUEST_URL="${SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}"
      ARM_OIDC_TOKEN=$(curl -s -H "Content-Length: 0" -H "Content-Type: application/json" -H "Authorization: Bearer $(System.AccessToken)" -X POST $OIDC_REQUEST_URL | jq -r '.oidcToken')

      # Save subscription context
      ARM_SUBSCRIPTION_ID=$(az account show --query id -o tsv)

      # New az-cli session
      az login --service-principal -u $servicePrincipalId --tenant $tenantId --allow-no-subscriptions --federated-token $ARM_OIDC_TOKEN
      az account set --subscription $ARM_SUBSCRIPTION_ID

Återförsök för serveruppgifter

Serveruppgifter som anropar externa system, till exempel AzureFunction eller InvokeRESTAPI, kan ibland misslyckas på grund av tillfälliga fel som överbelastning av beräkningsresurser. Tidigare skulle sådana fel göra att hela jobbet, och eventuellt pipelinen, misslyckas.

För att förbättra motståndskraften mot tillfälliga fel har vi infört stöd för retryCountOnTaskFailure egenskapen i serveruppgifter. Anta att du har följande YAML-kod i pipelinen:

- stage: deploy
  jobs:
  - job:
    pool: server
    steps:
    - task: AzureFunction@1
      retryCountOnTaskFailure: 2
      inputs:
        function: 'https://api.fabrikamfiber.com'
        key: $(functionKey)
        method: 'POST'
        waitForCompletion: 'false'

Om https://api.fabrikamfiber.com det uppstår ett tillfälligt fel försöker Azure Pipelines begäran igen upp till tre gånger (det första försöket plus två återförsök som anges av retryCountOnTaskFailure). Varje återförsök innehåller en ökande väntetid. Det maximala antalet återförsök som tillåts är 10.

retryCountOnTaskFailure Är inte tillgängligt för uppgiften ManualValidation och andra uppgifter som inte omfattar externa systemanrop.

Uppgifter som använder en end-of-life Node runner-version för att köra avge varningar

Pipelineuppgifter som förlitar sig på en nodversion som inte längre underhålls börjar ta emot varningar:

Uppgiftsversionen TaskName <version> är beroende av en Node-version (10) som är slutpunkt. Kontakta tilläggsägaren om du vill ha en uppdaterad version av uppgiften. Uppgiftsunderhållare bör gå igenom vägledningen för noduppgradering: https://aka.ms/node-runner-guidance

Om du vill ignorera dessa varningar kan du ange en miljö- eller pipelinevariabel på antingen pipeline-nivån (jobbet) eller aktivitetsnivån. Till exempel:

variables:
  AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false

DockerCompose@0 använder Docker Compose v2 i v1-kompatibilitetsläge

Docker Compose v1 når sin livslängd och tas bort från värdbaserade agenter 24 juli 2024. Vi har uppdaterat DockerCompose@0 uppgift för att använda Docker Compose v2 i v1-kompatibilitetsläge om Docker Compose v1 inte är tillgängligt på agenten.

Kompatibilitetsläget löser dock inte alla kompatibilitetsproblem. Se Migrera till Skriv V2. Vissa användare behöver mer tid för att uppdatera sina Docker Compose-projekt för Docker Compose v2-kompatibilitet. I sådana fall följer du de här anvisningarna för att använda DockerComposeV0-aktiviteten med docker-compose v1.

Obs! Den här guiden baseras på fristående dokumentation om Install Compose

Använda docker-compose v1 i Windows

Lägg till powershell-steget i pipelinen för att ladda ned docker-Compose v1.29.2 och använd det med aktiviteten DockerComposeV0 i Windows:

variables:
    dockerComposePath: C:\docker-compose

steps:
- powershell: |
    mkdir -f $(dockerComposePath)
    # GitHub now requires TLS1.2. In PowerShell, run the following
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: '**/docker-compose.yml'
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)\docker-compose.exe

Använda docker-compose v1 på Linux

Lägg till bash-steget i pipelinen för att ladda ned Docker-Compose v1.29.2 och använd det med Aktiviteten DockerComposeV0 i Linux:

variables:
    dockerComposePath: /tmp/docker-compose

steps:
- bash: |
    sudo mkdir $(dockerComposePath)
    sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
    sudo chmod 755 $(dockerComposePath)/docker-compose
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)/docker-compose

Azure Test Plans

Test- och feedbacktillägg i Manifest V3

Vi är glada över att kunna presentera en ny uppdatering av Azure DevOps Test and Feedback-tillägget! Den här uppgraderingen övergår vår implementering från Manifest version 2 till version 3, i linje med Googles utfasningsschema för Manifest V2.

Även om tilläggets kärnfunktioner förblir oförändrade, förbättrar den här uppdateringen säkerhet och prestanda. Det uppdaterade tillägget distribueras gradvis till både Chrome- och Edge-webbläsare under de kommande veckorna. Vi övervakar prestanda och feedback för att säkerställa en smidig övergång innan vi utökar distributionen baserat på resultaten.

Mer information finns i vårt senaste blogginlägg om den här uppdateringen. Test- och feedbacktillägg i Manifest V3

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