Sdílet prostřednictvím


Nastavení pro zakázání vytváření úložišť TFVC

V této aktualizaci zavádíme nové nastavení pro zakázání vytváření úložišť TFVC. Tato změna se zaměřuje na nové projekty a zároveň zajišťuje, aby vaše stávající úložiště TFVC zůstala nedotčená.

Kromě toho s radostí oznamujeme, že v Azure Pipelines je k dispozici nový koncový bod rozhraní REST API pro vyžádání tokenů OIDC! To umožňuje vývojářům úloh generovat idTokens pro ověřování Entra ID, zvýšit zabezpečení a snadné použití.

Nakonec se v Azure Boards dají cesty k oblasti a iteraci odstranit jenom v případě, že už nejsou přidružené k žádným pracovním položkám. Toto vylepšení brání přerušení a zajišťuje, aby týmy zachovaly přístup ke svým panelům a backlogům.

Podrobnosti najdete v poznámkách k verzi.

Pokročilé zabezpečení GitHubu pro Azure DevOps

Azure Boards:

Azure Repos

Azure Pipelines

Azure Test Plans:

Pokročilé zabezpečení GitHubu pro Azure DevOps

K dispozici je teď dokumentace k rozhraní API přehledu zabezpečení.

K dispozici je teď dokumentace k rozhraní API, které využívá kartu Rizika přehledu rozšířeného zabezpečení. Pomocí koncového bodu /{organization}/_apis/reporting/summary/alerts zobrazíte souhrn závažnosti výstrah ve všech úložištích s podporou rozšířeného zabezpečení. Ujistěte se, že vaše služba ADO PAT má vso.advsec oprávnění, která uděluje možnost číst výstrahy, instance výsledků a instance výsledků analýzy.

Azure Boards

Změna pro odstraňování oblastí a iteračních cest

Odstranění oblasti nebo cesty iterace může být rušivé. Může přesunout pracovní položky na novou cestu a může způsobit, že týmy ztratí přístup ke svým panelům a backlogům. I přes upozornění a výzvy se cesty někdy odstraní, aniž by plně porozuměly důsledkům. Abychom to vyřešili, změnili jsme chování: Cesty oblasti a iterace se teď dají odstranit jenom v případě, že už nejsou používány žádnými pracovními položkami.

Snímky obrazovky oblasti odstranění

Azure Repos

Nové nastavení pro zakázání vytváření úložišť TFVC

V posledních letech nebyly do Správa verzí Team Foundation (TFVC) přidány žádné nové funkce, protože Git se stal upřednostňovaným systémem správy verzí v Azure Repos. Všechna nedávná vylepšení zabezpečení, výkonu a přístupnosti byla provedena výhradně v úložištích Git, což vede k průběžnému poklesu využití TFVC. I když někteří stále spoléhají na TFVC a my tuto sadu funkcí nechceme odebrat, plánujeme TFVC postupně vyřadit pro nové projekty a organizace a také pro projekty, které aktuálně nepoužívají TFVC.

V rámci tohoto přechodu zavádíme nové nastavení "Zakázat vytváření úložišť TFVC", které ovlivní jenom vytváření nových úložišť TFVC a nebude mít vliv na stávající úložiště.

Gif pro ukázku Zakázání vytváření úložišť TFVC

Azure Pipelines

Přístup ke službě Azure Service Bus z Pipelines pomocí ověřování Microsoft Entra ID

Teď můžete použít ověřování Microsoft Entra ID pro přístup ke službě Azure Service Bus z Azure Pipelines. Díky tomu můžete využít federování identit úloh k odebrání správy tajných kódů a Azure RBAC pro jemně odstupňované řízení přístupu.

Identitám, které přistupují ke službě Azure Service Bus, je potřeba udělit jednu z předdefinovaných rolí Azure pro Službu Azure Service Bus v přístupné službě Service Bus.

PublishToAzureServiceBus@2 úkol

Nové úlohy PublishToAzureServiceBus@2 je možné nakonfigurovat pomocí připojení služby Azure. Vytvořte připojení služby Azure a naplňte serviceBusQueueName vlastnosti serviceBusNamespace nové úlohy:

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

Vlastní úlohy serveru (bez agenta), které používají ServiceBus provádění, můžou určovat připojení služby Azure jako EndpointId a vynechat ConnectionString. Viz Vytváření úloh serveru.

Kanály a úlohy naplní proměnné pro přizpůsobení ověřování federace identit úloh

Koncový bod rozhraní REST API pro vyžádání tokenů OIDC je nyní k dispozici v System.OidcRequestUri proměnné kanálu. Vývojáři úloh mohou tuto proměnnou využít k vygenerování idTokenu pro ověřování pomocí Entra ID.

Pokud k nasazení do Azure používáte úlohy Marketplace nebo vlastní úlohy, mějte na paměti, že tyto úlohy ještě nemusí podporovat federaci identit úloh. Doporučujeme vývojářům, aby povolili federaci identit úloh, aby zlepšili bezpečnostní opatření.

Snímek obrazovky se spolupráci oidc

Úlohy, které v task.json zadávají connectedService:AzureRM vstup, je možné aktualizovat tak, aby podporovaly federaci identit úloh pomocí následujícího postupu:

  • Pomocí rozhraní REST API Oidctoken si vyžádáte idToken (šipka 1 ve výše uvedeném diagramu).
  • Exchange idToken pro přístupový token pomocí federovaného toku přihlašovacích údajů rozhraní OAuth API, který určuje idToken jako client_assertion (šipky 2 a 4 ve výše uvedeném diagramu);
    nebo:
  • Pro úlohy, které fungují jako obálka kolem nástroje, který provádí samotné ověřování, použijte metodu ověřování nástrojů k určení federovaného tokenu.

Úlohy uzlů můžou k získání idTokenu použít balíček azure-pipelines-tasks-artifacts-common npm. Podrobnosti implementace najdete v příkladu kódu.

Vyžádání nového idTokenu

Proměnná System.OidcRequestUri kanálu a AZURESUBSCRIPTION_SERVICE_CONNECTION_ID proměnná prostředí vystavená v AzureCLI@2 úlohách a AzurePowerShell@5 umožňuje autorům kanálů ověřovat se z vlastního skriptu:

Modul Az PowerShellu
- 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

Opakování pro úlohy serveru

Úlohy serveru, které volají externí systémy, například AzureFunction nebo InvokeRESTAPI, můžou občas selhat kvůli přechodným chybám, jako je vyčerpání výpočetních prostředků. Tato selhání dříve způsobila selhání celé úlohy a potenciálně selhání kanálu.

Abychom zlepšili odolnost proti přechodným chybám, zavedli jsme podporu retryCountOnTaskFailure vlastnosti v úlohách serveru. Předpokládejme, že máte v kanálu následující kód YAML:

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

Pokud https://api.fabrikamfiber.com dojde k přechodné chybě, Azure Pipelines požadavek zopakuje až třikrát (počáteční pokus plus dvě opakování určené retryCountOnTaskFailure). Každé opakování zahrnuje rostoucí dobu čekání. Maximální povolený počet opakování je 10.

Není retryCountOnTaskFailure k dispozici pro ManualValidation úkol a další úkoly, které nezahrnují volání externího systému.

Úlohy, které používají verzi Node Runneru pro ukončení životnosti ke spuštění upozornění

Úlohy kanálu, které se spoléhají na verzi uzlu, se už nezachovají , začnou dostávat upozornění:

Verze úlohy TaskName je závislá na verzi <version> uzlu (10), která je konec životnosti. Požádejte vlastníka rozšíření o aktualizovanou verzi úlohy. Správci úloh by měli zkontrolovat pokyny k upgradu uzlu: https://aka.ms/node-runner-guidance

Pokud chcete tato upozornění potlačit, můžete nastavit prostředí nebo proměnnou kanálu na úrovni kanálu (úlohy) nebo úlohy. Příklad:

variables:
  AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false

DockerCompose@0 používá Docker Compose v2 v režimu kompatibility v1.

Docker Compose v1 dosáhne konce životnosti a bude odebrán z hostovaných agentů 24. července 2024. Aktualizovali jsme DockerCompose@0 úlohu tak, aby používala Docker Compose v2 v režimu kompatibility v1, pokud v agentu není k dispozici Docker Compose v1.

Režim kompatibility ale neřeší všechny problémy s kompatibilitou. Viz Migrace na vytvoření verze 2. Někteří uživatelé budou potřebovat více času na aktualizaci svých projektů Docker Compose pro kompatibilitu Docker Compose v2. V těchto případech postupujte podle těchto pokynů a použijte úlohu DockerComposeV0 s docker-compose v1.

POZNÁMKA: Tato příručka je založená na samostatné dokumentaci k instalaci aplikace Compose.

Použití docker-compose v1 ve Windows

Přidejte do kanálu krok PowerShellu, který stáhne docker-Compose v1.29.2 a použije ho s úlohou DockerComposeV0 ve 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

Použití docker-compose v1 v Linuxu

Přidejte do kanálu krok Bash, který stáhne Docker-Compose v1.29.2 a použije ho s úlohou DockerComposeV0 v Linuxu:

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

Rozšíření Testování a Zpětná vazba v manifestu V3

S radostí oznamujeme novou aktualizaci rozšíření Azure DevOps Test and Feedback. Tento upgrade přepíná naši implementaci z manifestu verze 2 na verzi 3 v souladu s plánem vyřazení Společnosti Google pro Manifest V2.

I když základní funkce rozšíření zůstávají beze změny, tato aktualizace zlepšuje zabezpečení a výkon. Aktualizované rozšíření se postupně zavede do prohlížečů Chrome i Edge v nadcházejících týdnech. Před rozšířením zavedení na základě výsledků budeme monitorovat výkon a zpětnou vazbu, abychom zajistili hladký přechod.

Další podrobnosti najdete v našem nedávném blogovém příspěvku o této aktualizaci. Rozšíření Testování a zpětná vazba v manifestu V3

Další kroky

Poznámka:

Tyto funkce se budou zavádět během následujících dvou až tří týdnů.

Přejděte na Azure DevOps a podívejte se na ně.

Jak poskytnout zpětnou vazbu

Rádi bychom slyšeli, co si o těchto funkcích myslíte. Pomocí nabídky nápovědy můžete nahlásit problém nebo poskytnout návrh.

Vytvoření návrhu

Můžete také získat rady a své otázky zodpovězené komunitou ve službě Stack Overflow.

Díky,

Silviu Andrica