Azure App Service是否存在随代码在槽位间迁移的唯一标识？

Great question—this is a common pain point when transitioning from the old Cloud Service model to App Service (including Functions), since the behavior of deployment identifiers shifted significantly. Let’s break this down clearly:

No Native Slot-Migratable deploymentId in App Service #

First, to directly answer your question: App Service does not have a built-in deploymentId that moves with your code when swapping slots. As you noticed, the current deploymentId property is tied to the slot itself, not the code running in it:

• For production slots, it’s just the service name
• For non-production slots, it’s formatted as [ServiceName]__<hex-string>

When you swap slots, the code moves between slots, but each slot retains its own deploymentId because this identifier belongs to the slot resource, not the deployed code package. This is a deliberate design difference from Cloud Services, where DeploymentId was linked to the deployment package itself.

Workarounds for a Code-Bound Unique Identifier #

If you need a unique ID that travels with your code across slot swaps, here are practical solutions:

• Inject a custom deployment identifier during CI/CD
  Add a unique value (like a Git commit hash, CI build ID, or timestamp-based UUID) to your application’s configuration during deployment. For example:

  • Set it as an app setting (make sure the "Deployment Slot Setting" toggle is off if you want it to swap with the code)
  • Embed it directly into your application’s code or a config file during the build process

  This value will be tied to your code package, so it moves with the code whenever you swap slots.

• Use the deployment history’s unique ID
  Every code deployment to App Service gets a unique ID in the deployment history. You can retrieve this ID via the Azure CLI with:

  az webapp deployment list --name <your-app-name> --resource-group <your-rg-name>
  

  Capture this ID during deployment and store it in your app (e.g., as an environment variable or config value). Since this ID is linked to the specific code package, it will stay with the code through slot swaps.

• Leverage Git commit hashes
  If you’re deploying directly from Git, the commit hash is a natural unique identifier for your code version. Inject this hash into your app during the build process (many CI/CD tools like GitHub Actions, Azure DevOps Pipelines make this easy). This hash is inherently tied to your code, so it will migrate with the code across slots.

Key Takeaway #

App Service’s native deploymentId is slot-specific, not code-specific—but you can easily implement a custom code-bound identifier using CI/CD tooling or deployment metadata. This gives you the same behavior you relied on with Cloud Services’ DeploymentId.

内容的提问来源于stack exchange，提问作者danatcofo