You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: blog/2025-07-01-safe-deployment-of-versioned-workflows/2025-07-01-safe-deployment-of-versioned-workflows.md
+1-52Lines changed: 1 addition & 52 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -201,57 +201,6 @@ This change finalizes the safe rollout of the new versioned workflow. At each st
201
201
202
202
The previous deployment flow for versioned workflows included only Steps 0, 2, and 3\. Therefore, a direct upgrade from Step 0 to Step 2 (skipping Step 1\) was not safe due to the inability to perform a safe rollback. The new functions enabled customers to have Step 1, thereby making the deployment process safe.
203
203
204
-
### Deployment with Dynamic Configuration
205
-
206
-
Using the new options adds an extra step, which can lead to increased deployment time. If your service has a dynamic configuration, you can integrate it with the new functions to eliminate this problem and maintain the same number of deployments.
207
-
208
-
The solution combines the code changes from [Step 1](#step-1) and [Step 2](#step-2) into a single code change. Step 2 becomes a change in Dynamic Configuration rather than a new version deployment. Therefore, in this case, the deployment will include the following steps:
209
-
210
-
#### Step 1
211
-
212
-
This Step 1 is similar to the original [Step 1](#step-1) but introduces the retrieval of a value from the Dynamic Configuration. To achieve forward and backward compatibility of the change, the Dynamic Configuration must have the value of the minimum support version \-`workflow.DefaultVersion` at this step.
213
-
214
-
```go
215
-
216
-
var (
217
-
// Get dynamic config client during app initialization
218
-
dcClient, _ = dynamicConfig.NewClient()
219
-
region = getRegion()
220
-
)
221
-
222
-
// Git tag: v0.2
223
-
// MyWorkflow supports: workflow.DefaultVersion and 1
224
-
funcMyWorkflow(ctxworkflow.Context) error {
225
-
// The call of the dynamic configuration client is safe for the workflow execution
Once all v0.2 workers are replaced by v0.1 workers, you need to change the Dynamic Configuration value to the next version (in this case, 1). This will activate the new logic for new workflow executions. To roll back from Step 2 to Step 1, simply revert the dynamic configuration value.
250
-
251
-
#### Safety
252
-
253
-
The new options do not alter the logic of replaying, so dynamically changing the value will not cause non-deterministic errors during the replay of old or new workflow executions; therefore, it is safe to change the value. Only the minimum and maximum supported versions are used during replay, indicating which versions the code supports.
254
-
255
204
## Conclusion
256
205
257
-
The new options introduced into `GetVersion` address gaps in the Versioning logic that previously led to failed workflow executions. This enhancement improves the safety of deploying versioned workflows, allowing for the separation of code changes from the activation of new logic, making the deployment process more predictable. This extension of `GetVersion` is a significant improvement that opens the way for future optimizations.
206
+
The new options introduced into `GetVersion` address gaps in the Versioning logic that previously led to failed workflow executions. This enhancement improves the safety of deploying versioned workflows, allowing for the separation of code changes from the activation of new logic, making the deployment process more predictable. This extension of `GetVersion` is a significant improvement that opens the way for future optimizations.
0 commit comments