Each time you commit a node or workflow, DataWorks saves a new version. On the Versions tab, view the commit history, compare versions side-by-side, and roll back to any previous version.
The workflow version procedure is the same as the node version procedure described here.
Prerequisites
Before you begin, ensure that you have:
-
Access to the DataWorks console
-
A node that has been committed at least once
View version history
-
Log on to the DataWorks console. In the top navigation bar, select the desired region. In the left-side navigation pane, choose Data Development and Governance > Data Development. Select the workspace from the drop-down list and click Go to Data Development.
-
On the DataStudio page, find the node in the left-side navigation pane and double-click its name. The configuration tab opens.
-
In the right-side navigation pane, click the Versions tab. The Versions tab shows the commit history for the node. The following table describes the key columns.
Column Description Change Type Create: the first commit of the node. Change: any subsequent commit. Status Yes: committed to the development environment; no deployment package created; not yet deployed to production. Not Deployed: committed and a deployment package exists, but the node is waiting to be deployed. Deployed: deployed to the production environment. Actions View: inspect the code and scheduling settings for that version. Compare: compare the version with the saved version, or select two versions and click Compare Versions. Roll Back: restore the node to this version. 
Compare versions
Two entry points are available for comparing versions.
Method 1 — Versions tab
On the configuration tab, click the Versions tab in the right-side navigation pane. Select any two versions and click Compare Versions.
Only two versions can be compared at a time.
Method 2 — Deploy page
On the configuration tab, click Deploy in the toolbar. On the Create Deploy Task page, find the version to deploy and click Compare in the Actions column. This compares the selected version against the currently deployed version in the production environment.
Roll back a node
Rolling back overwrites the current version of the node. After the rollback, commit the node again to make the changes take effect.
On the Versions tab, find the version to restore and click Roll Back in the Actions column.
Scheduling parameters reference
When you click View or Compare for a version, the panel shows the scheduling configuration captured in that version snapshot. The following tables describe the parameters.
Identity and ownership
| Parameter | Description |
|---|---|
| appId | ID of the DataWorks workspace the node belongs to. View it on the Workspace Management page. |
| createUser | ID of the user who created the node. |
| createTime | Timestamp when the node was created. |
| lastModifyUser | ID of the user who last modified the node. |
| lastModifyTime | Timestamp of the most recent modification. |
| owner | Owner ID of the node. View it in the General section of the Properties tab. For more information, see Configure basic properties. |
Scheduling behavior
| Parameter | Description | Valid values |
|---|---|---|
| startRightNow | When auto triggered node instances are generated after deployment. | 0: next day after deployment. 1: immediately after deployment. For more information, see Configure immediate instance generation for a task. |
| cycleType | Scheduling frequency type. | 0: daily, weekly, monthly, or yearly. 1, 2, or 3: minute or hourly. |
| cronExpress | CRON expression that defines the scheduling policy. | — |
| startEffectDate | Start of the period during which scheduling takes effect. | — |
| endEffectDate | End of the period during which scheduling takes effect. For more information, see Configure time properties. | — |
| isStop | Whether scheduling is suspended. | 0: scheduling runs normally. 1: scheduling is suspended. |
| reRunAble | Rerun policy for the node. | 0: rerun only after failure. 1: rerun regardless of result. 2: rerun not allowed. |
| taskRerunTime | The number of times the node is rerun. | — |
| taskRerunInterval | Interval between automatic reruns. Unit: milliseconds. | — |
Dependencies
| Parameter | Description | Valid values |
|---|---|---|
| dependentTypeList | Cross-cycle scheduling dependency type. | 0: no dependency. 1: one or more specified nodes. 2: level-1 descendant nodes. 3: the current node. For more information, see Configure cross-cycle scheduling dependencies. |
| dependentDataNode | IDs of nodes specified as cross-cycle dependencies. Valid only when dependentTypeList is 1. | — |
| isAutoParse | Whether automatic parsing is enabled to resolve scheduling dependencies. | 1: enabled. 0: disabled. For more information, see Configure same-cycle scheduling dependencies. |
| input / inputList | Input configurations for the node, including dependency resolution method (parseType: 0 = automatic parsing, 1 = manual, 2 = data lineage). For more information, see Scheduling dependency configuration guide. | — |
| output / outputList | Output configurations for the node. | — |
| inputContextList / outputContextList | Context-based input and output parameter configurations. For more information, see Configure input and output parameters. | — |
Resource and additional configuration
| Parameter | Description |
|---|---|
| resgroupId | ID of the resource group used to run the node. For more information, see Configure the resource property. |
| extConfig | Additional node configurations in JSON format. Contains ignoreBranchConditionSkip (whether the dry-run property from the previous cycle applies to the current cycle; true: the dry-run property from the previous cycle is used; false: the dry-run property from the previous cycle is not used; see Passing of the dry-run attribute of an ancestor node) and alisaTaskKillTimeout (timeout period in hours). |
| tags | Reserved parameters. |