Search before asking

• I had searched in the DSIP and found no similar DSIP.

Motivation

Current Workflow Issues

Operational Process:

1. Development Process: For development workflows, the following steps must be executed: 1. Return to the workflow list -> 2. Deploy the workflow -> 3. Run the workflow -> 4. Check the runtime logs.
2. Modification Process: Adjusting workflow content is more complex: 1. Return to the workflow list -> 2. Undeploy the workflow -> 3. Enter workflow editing -> 4. Return to the workflow -> 5. Deploy the workflow -> 6. Run the workflow -> 7. Check the runtime logs.

Technical/Design Factors:

1. The workflow lacks a development state. While this simplifies logic and reduces bugs, it shifts complexity to the user.
2. The design prioritizes production stability, requiring users to be more cautious when making adjustments.

Desired：

Operational Process Optimization: Introduce a dedicated development workflow, separate from the production workflow (which can only be deployed from the development environment and cannot be created directly).

1. Development Workflow Process: Only requires: 1. Modify workflow content -> 2. Run the workflow -> 3. Check the runtime logs.
2. Deployment Process: Publish a development workflow to the production workflow (overwriting if previously deployed).

Technical/Design Optimization:

1. Development and production workflows are stored in separate tables with completely independent data.
2. Development workflows lack a deployment state, allowing debugging. Running workflows and task instances are isolated from production.
3. During deployment, the current version of the workflow is copied to the production workflow record, with an association logged (for subsequent overwrites).

Design Detail

1. The workflow adds a label field to mark more information, such as whether it is a development or production workflow, which can also be customized

2. The workflow operation adds an overwrite (replace) operation: click and select the workflow to overwrite the non-online state (can be across projects)，It supports the comparison of differences between two nodes, the coverage is for the entire workflow.

3. The workflow supports label filtering

Compatibility, Deprecation, and Migration Plan

There is a compatibility issue. This table is needed. Data migration needs to be considered. Complement processing is required in init-job.

Test Plan

Old version workflow runs stock data upgrade verification
Functional testing
UT and E2E modification test

Code of Conduct

• I agree to follow this project's Code of Conduct