Create a Deployment Model

How to create a deployment model in RapidDeploy

A Deployment Model in RapidDeploy is called the Project Orchestration. This is a series of target neutral step that can run on any target server. A model can consist of multiple sub models. You access the Orchestration canvas by going to ‘Menu’ -> ‘Resources’ -> ‘Projects’ -> [Selected Project]. The orchestration Map canvas tab is the default tab when you edit a project.

Orchestration Map Canvas

The Orchestration map canvas, showing configured failure branches, target specific tasks and a conditional.

1. The Orchestration Canvas


On the Project Orchestration tab, the Orchestration map will start with a start and finish task, and one failure branch. This is the defaut position.

Click to enlarge

2. Adding tasks to the canvas


A new task can be added by highlighting the ‘Start‘ task, and clicking ‘Add Task‘.

A dialog box will be presented, with a list of available tasks. The tasks in the list will depend on which plugins are installed. Hundreds of tasks are available out of the box.

Select the required task, and click ‘Add‘ in the top right hand corner of the dialog. You might need to scroll to see it.

Click to enlarge

3. Adding Target Specific tasks to the canvas


Ideally, the same set of task actions should run on every target where this orchestration is run. However, we have to recognise that not all targets are exactly the same and some tasks should be run on a subset of targts. For this scenario we have the ‘Target Specific‘ orchestration entry.

A new target specific orchestration entry can be added by clicking the ‘Add Target Specific‘ button.

Once the target specific task is added, you add individual targets by highlighting the ‘Target Specific‘ entry in the orchestration and on the right hand task dialog, clicking the grey ‘Add Target‘ button.

Note you can only add targets that alread exist, having been created on the ‘ Targets ‘ tab.

For each branch created, you can add any tasks that will be specific to that target.

Click to enlarge

4. Adding Conditionals and loops


Conditionals and loops are meant to create simple ‘code’ constructs between tasks to allow you to orchestrate the relationship between tasks more efficiently. If you have more complex code for specific actions, that cannot be accomplished in the set of existing tasks, then add a ‘Script Code Runner’ task and enter your bash, shell, perl, ruby or python code directly into it.

A new conditional or loop task can be added by opening the red ‘Conditionals and Loops‘ button.

Highlight the point in the orchestration before the conditional or loop you want to add, and then click on the conditional or loop task you want to add in the drop-list.

Once you’ve added the conditional or loop, you can add other tasks to it. You can also nest conditionals inside loops.

Typically the conditional will act on a boolean from a previous task in the task flow. In the shown case the ‘Check File Attributes‘ task returns a check against a file to ensure it exists and is a directory. The outputParameter from this task is ${checkResult}, which we enter as the conditionParameter in the ‘If Task

Most tasks produce one or more output parameters, which can be defined as ${parameter-name}, and can be consumed in any field in any task later in the task flow.

Click to enlarge

5. Adding Failure Branches

On the Project Orchestration tab, the Orchestration map will start with one failure branch. This is the defaut setting. All tasks with ‘failOnError‘ set to true will, by default, subscribe to this failure branch, which simply fails the job.

Any task can add a new failure branch, or subscribe to any other failure branch.

You can choose an existing failure branch, or add a new one by selecting the task and choosing from the drop-down in the ‘Failure branch‘ field or clicking the ‘+‘ button. You can add any tasks to the failure branch in order to accomplish the required cleanup.

See the Rollback How-To for more information.

Click to enlarge

6. Data Dictionary

Target specfic values are injected into the model at deployment time using ‘Data Dictionary‘ parameters. These parameters are written as @@VALUE@@.

The screen shot to the right shows a task with several configured data dictionary values. These will be set to different values depending on the target that the model is being deployed to.

Data Dictionary values are scoped values that can be set at Project, Target and Job scopes.

  • Project Scope – Any Data Dictionary values set at project scope are used by all targets, unless overridden by the target scope.
  • Target Scope – Overrides Data Dictionary values at the project scope for a particular target.
  • Job Scope – Overrides Data Dictionary values at the project and target scopes. Can be set when a job is called via the web services interface. User is prompted to enter Job Scoped Data Dictionary values in the UI if the value is empty at the Project and Target scope. This is called ‘Late Property Injection’.

If you specify a Data Dictionary parameter and save the project, the new parameter will be discovered and added to the project scope.

Click to enlarge

7. Project Scope

This panel shows the Project scoped data dictionary values. These values will be used unless overridden at the target or job scopes.

Click to enlarge

8. Target Scope

This panel shows the Target scoped data dictinary values. The colour coding makes it is easy to see which values are overridden, and which are inherited.

The red ‘Empty’ indicates the value is empty at both scopes. We call this ‘Late Property Injection‘. The user is prompted to enter these values at deployment time, although they can elect to leave them blank.

Click to enlarge