Rollback Component

Use this process step to roll back a component version to the version in a snapshot or to the version that was deployed when the process began.

Tip:

Applications, components, and generic processes share some process steps. This step applies only to application processes.

For a video demo of rolling back components, see Rollback Scenarios in IBM UrbanCode™ Deploy .

In most cases, to switch to a different version of a component, you deploy the new version over the existing version. If necessary, you can run the uninstall process for the component first.

However, you can also use the Rollback Component step to automate the process of switching to a previous component version. This step has two options:

Remove Undesired Incremental Versions: This option removes versions that are not in a specified snapshot. See Rolling back to a snapshot.
Replace with Last Deployed: This option rolls back components that fail to deploy. See Uninstalling components with an application process.

Table 1. Rollback Component properties
Field	Description
Name	A name for the step. Other process steps can refer to this step by this name.
Component	Component that is used by the step; a step can affect a single component. All components that are associated with the application are available. If you want to roll back another component, add another rollback step to the process.
Limit to Tag	The user-defined resource tag that determines which resource runs the process. Only a resource with this tag, or a resource that has a parent with this tag, runs the process. See Adding tags to objects.
Rollback type	Determines the type of rollback. If you specify `Remove Undesired Incremental Versions`, the server runs the uninstall process for each version that is not in the specified snapshot. See Rolling back to a snapshot. If you specify `Replace with Last Deployed`, the server runs the specified process on the version that was installed when the process began. See Uninstalling components with an application process.
Max # of concurrent jobs	The maximum number of component processes to run at the same time. To run an unlimited number of concurrent processes, specify -1. In this field, you can use a value from another process property. UrbanCode Deploy attempts to resolve the value to an integer. If the value does not resolve to an integer, then the `-1` value is used by default. Important: The number of component processes that can run concurrently is limited by the agent, based on the hardware configuration the agent runs on.
Fail Fast	If this check box is selected, the step does not start more processes after one process fails.
Run on First Online Resource Only	Instead of being run by all agents that are mapped to the environment, the step runs only on the first online agent that the server identifies. The mechanism that is used to identify the "first" agent is database-dependent, and thus indeterminate. If no agents are online, the server skips the step and marks its status as "Not Mapped." This setting may cause the environment to become noncompliant or to provide unexpected results, because only one agent runs the process, even if many agents are mapped to the environment.
Precondition	A JavaScript 1.7 script that defines a condition that must exist before the step can run. The condition must resolve to `true` or `false`. In the script, do not use the `${p:component.myProperty}` notation. For example, to check the value of a component property in a component process, use `properties.get("myProperty") == "myValue"`. See Property scopes for information about property access.

Feedback