| - |
== Application Process Steps ==
|
+ |
= Application Process Steps =
|
| - |
= Rollback Component =
|
+ |
=== Rollback Component ===
|
| |
This step has two use cases: You can deploy the version of that component which was deployed prior to running the current process ("Replace with last deployed"), or you can remove any versions not specified in the current deployment (such as for incremental components deployed using snapshots). Most people just use the former option, as incremental components are relatively uncommon - suppose a deployment fails and you want the process to be an atomic action. You'd use "replace with last deployed" to put the previous version of the component back on the target environment before the process finished. |
|
This step has two use cases: You can deploy the version of that component which was deployed prior to running the current process ("Replace with last deployed"), or you can remove any versions not specified in the current deployment (such as for incremental components deployed using snapshots). Most people just use the former option, as incremental components are relatively uncommon - suppose a deployment fails and you want the process to be an atomic action. You'd use "replace with last deployed" to put the previous version of the component back on the target environment before the process finished. |
| - |
= Apply Configuration =
|
+ |
=== Apply Configuration ===
|
| |
This will run a process which does not take a component version to simply apply configuration. This is intended to support deployments which don't use artifacts, but are just adjusting system configuration or property files or something. This compares the current configuration inventory on the resource with whatever configuration has been provided to the process, and only executes if there is a difference found. (This matches the "Configuration Deployment" component process type.) |
|
This will run a process which does not take a component version to simply apply configuration. This is intended to support deployments which don't use artifacts, but are just adjusting system configuration or property files or something. This compares the current configuration inventory on the resource with whatever configuration has been provided to the process, and only executes if there is a difference found. (This matches the "Configuration Deployment" component process type.) |
| |
This lets you take different paths from the switch step based on the value of some property. You enter a property name (without the ${p: ... }) in the step itself, and then on each arrow coming out of the switch, you can set a value or tell it to be "Default". When the step executes, it gets the value of the property and determines which paths to go down. If no arrows with values entered are a match, it will take any "Default" arrows. |
|
This lets you take different paths from the switch step based on the value of some property. You enter a property name (without the ${p: ... }) in the step itself, and then on each arrow coming out of the switch, you can set a value or tell it to be "Default". When the step executes, it gets the value of the property and determines which paths to go down. If no arrows with values entered are a match, it will take any "Default" arrows. |
| |
Gives a bit more control over our implicit joining behavior in workflows. When you use a join step, it will not pass the join until all arrows leading into the Join are valid (prior steps must have succeeded for success arrows, or must have failed for failure arrows, and all steps must have actually executed.) |
|
Gives a bit more control over our implicit joining behavior in workflows. When you use a join step, it will not pass the join until all arrows leading into the Join are valid (prior steps must have succeeded for success arrows, or must have failed for failure arrows, and all steps must have actually executed.) |
| - |
= Acquire and Release Lock =
|
+ |
=== Acquire and Release Lock ===
|
| |
You can use locks to control concurrent deployments. When an "acquire lock" step is executed, it will attempt to get a lock on a global string value. If any other processes have also acquired that lock, this step will have to wait until those processes release it. So, you can have a lock which enforces that a component can only be deployed to one resource at a time, and you might use ${p:component.name} as the lock value. Or, you can make sure only one process can run on a resource at a time, and you'd use ${p:resource.name} for that. (But, all processes you want to restrict concurrency on would have to acquire the same lock). Locks are released automatically when a process is finished, but you can also use the "Release Lock" to manually release the lock prior to process completion. |
|
You can use locks to control concurrent deployments. When an "acquire lock" step is executed, it will attempt to get a lock on a global string value. If any other processes have also acquired that lock, this step will have to wait until those processes release it. So, you can have a lock which enforces that a component can only be deployed to one resource at a time, and you might use ${p:component.name} as the lock value. Or, you can make sure only one process can run on a resource at a time, and you'd use ${p:resource.name} for that. (But, all processes you want to restrict concurrency on would have to acquire the same lock). Locks are released automatically when a process is finished, but you can also use the "Release Lock" to manually release the lock prior to process completion. |
