Skip to content

Commit 95845c9

Browse files
authored
Removing dynamic configuration from the post to reevaluate and provide a better solution (#243)
1 parent b97d1de commit 95845c9

File tree

1 file changed

+1
-52
lines changed

1 file changed

+1
-52
lines changed

blog/2025-07-01-safe-deployment-of-versioned-workflows/2025-07-01-safe-deployment-of-versioned-workflows.md

Lines changed: 1 addition & 52 deletions
Original file line numberDiff line numberDiff line change
@@ -201,57 +201,6 @@ This change finalizes the safe rollout of the new versioned workflow. At each st
201201

202202
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.
203203

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-
func MyWorkflow(ctx workflow.Context) error {
225-
// The call of the dynamic configuration client is safe for the workflow execution
226-
// because it's not saved in the history events.
227-
changeIDExecVersion, err := dcClient.GetIntValue("changeId", map[string]interface{
228-
"region": region,
229-
})
230-
if err != nil {
231-
// Error handling must be non-deterministic
232-
}
233-
234-
// When GetVersion is executed for the first time, changeIDExecVersion will be returned
235-
version := workflow.GetVersion(ctx, "MyChange", workflow.DefaultVersion, 1, workflow.ExecuteWithVersion(changeIDExecVersion))
236-
237-
if version == workflow.DefaultVersion {
238-
return workflow.ExecuteActivity(ctx, FooActivity).Get(ctx, nil)
239-
}
240-
241-
return workflow.ExecuteActivity(ctx, BarActivity).Get(ctx, nil)
242-
}
243-
244-
245-
```
246-
247-
#### Step 2
248-
249-
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-
255204
## Conclusion
256205

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

Comments
 (0)