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
- Přístup ke službě Azure Service Bus z Pipelines pomocí ověřování Microsoft Entra ID
- Kanály a úlohy naplní proměnné pro přizpůsobení ověřování federace identit úloh
- Opakování pro úlohy serveru
- Úlohy, které používají verzi Node Runneru pro ukončení životnosti ke spuštění upozornění
- DockerCompose0 používá Docker Compose v2 v režimu kompatibility v1.
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.
Azure Repos
Nové nastavení pro zakázání vytváření úložišť TFVC
V posledních letech nebyly do 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, a využívání TFVC tak postupně klesá. I když někteří TFVC stále používají a my se tuto sadu funkcí nechystáme odebrat, plánujeme TFVC postupně vyřadit pro nové projekty a organizace a také pro projekty, které TFVC aktuálně nepoužívají.
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ě.
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í.
Ú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 však neřeší všechny problémy s kompatibilitou. Viz Migrace na Compose V2. 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.
Můžete také získat rady a své otázky zodpovězené komunitou ve službě Stack Overflow.
Díky,
Silviu Andrica