Skip to content

Latest commit

 

History

History
71 lines (46 loc) · 1.97 KB

File metadata and controls

71 lines (46 loc) · 1.97 KB

Worker-Level Versioning Sample

This sample demonstrates worker-level versioning, where each worker deployment is associated with a single version string.

What it shows

  • The worker uses UseVersioning(...) with MatchStrategy = Strict to pin itself to a single version and reject orchestration instances stamped with a different version.
  • The client uses UseDefaultVersion() to stamp every new orchestration instance with the same version automatically.
  • The orchestration reads context.Version to see what version it was scheduled with.
  • To "upgrade," you redeploy the worker with a new implementation and change the version string.

Prerequisites

Running the Sample

1. Start the DTS emulator

docker run --name durabletask-emulator -d -p 8080:8080 -e ASPNETCORE_URLS=http://+:8080 mcr.microsoft.com/dts/dts-emulator:latest

2. Set the connection string

export DURABLE_TASK_SCHEDULER_CONNECTION_STRING="Endpoint=http://localhost:8080;TaskHub=default;Authentication=None"

PowerShell:

$env:DURABLE_TASK_SCHEDULER_CONNECTION_STRING = "Endpoint=http://localhost:8080;TaskHub=default;Authentication=None"

3. Run with version 1.0 (default)

dotnet run

4. Simulate a deployment upgrade to version 2.0

Bash:

WORKER_VERSION=2.0 dotnet run

PowerShell:

$env:WORKER_VERSION = "2.0"; dotnet run

5. Clean up

docker rm -f durabletask-emulator

When to use this approach

Worker-level versioning is the simplest model. Use it when:

  • You deploy one version of your orchestration logic at a time
  • You want a straightforward rolling upgrade story
  • You don't need multiple versions of the same orchestration active simultaneously

For running multiple versions of the same orchestration in one worker, see the EternalOrchestrationVersionMigrationSample.