При развертывании функций в слот приложения-функции (называемый «Staging») я заметил, что на самом деле как производственный, так и Staging-слоты начинают использовать новый код. версия пакета, отмеченная в файлах * .dll, и проверка конечной точки работоспособности как в рабочей, так и в промежуточной среде после развертывания показывает, что они одинаковы.
Я не вижу упоминания об этом поведении в документации или о необходимости принимать меры для избегайте этого.
Кто-нибудь еще сталкивался с таким поведением? Есть ли способ, при котором подкачка слотов ведет себя подобным образом?
Это поведение можно наблюдать, развернув zip-файл в слот Staging с помощью этого сценария. Очевидно, вам понадобится az CLI с установленным соответствующим контекстом.
$resournceGroupName = ""
$functionAppName = ""
### Get the locaion of the zip file containing the code to deploy.
$inFile = "{0}\{1}" -f (Get-Location).Path, "FunctionApp.zip"
### Get the Kudu username and password.
$kuduUser = az webapp deployment list-publishing-profiles --resource-group $resournceGroupName --name $functionAppName --slot Staging --query "[?publishMethod=='MSDeploy'].userName" -o tsv
$kuduPass = az webapp deployment list-publishing-profiles --resource-group $resournceGroupName --name $functionAppName --slot Staging --query "[?publishMethod=='MSDeploy'].userPWD" -o tsv
### Encode the basic authentication credentials.
$creds = "{0}:{1}" -f $kuduUser, $kuduPass
$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($creds))
### Generate the URI and headers to use for the request.
$uri = "https://{0}-staging.scm.azurewebsites.net/api/zipdeploy?deployer=VSTS&message=%7B%22type%22%3A%22deployment%22%7D" -f $functionAppName
$headers = @{
Authorization = "Basic {0}" -f $encodedCreds
"Content-Disposition" = "attachment; filename=run.cmd"
}
### Deploy the functions.
$response = Invoke-WebRequest -Method Put -Uri $uri -Headers $headers -InFile $inFile -ContentType "application/zip"
$response | ConvertTo-Json -Depth 10