Project Orchestration

The orchestration file is located in the project root directory and by default is called midvision-deploy-orchestration.xml. It may be edited through the RapidDeploy GUI on the project Orchestration tab. The orchestration defines the task steps to run on the target servers. You can select tasks from a palette of base tasks and additional plugin-dependent tasks. Each task will normally define all of the configuration required to perform the task, in the form of fields known as task parameters. Most tasks also support one or more outputParameter fields. These typically contain the outputs from the task or true/false results.

outputParameters may be used as inputs in any fields of any subsequent tasks in the task flow.

The task steps are usually, but not always, target neutral. Configuration differences between targets are specified using Data Dictionary values.

As well as the standard tasks, there are some special tasks listed below:

• Select 'Conditionals and Loops' to add basic programming constructs into your orchestration such as 'If', 'While' and 'ForEach' statements.
• Select 'Add Target Specific' to add tasks that run only on the specified target(s), for example to check a change management tool in a production target only.
• Select 'Add RD Job Task' to add a 'Linked Deployment' which enables the current task flow to callback into RapidDeploy to invoke another job on this or a different target, either as a synchronous (wait) or asynchronous (parallel) call. For example, in between application stop/start on the current target, call out synchronously to a Database deploy project to make changes to a database.

Project Data Dictionary

The dictionary file is located in the project root directory and is called 'data-dictionary.xml'. It may be edited through the RapidDeploy GUI on the project 'Orchestration' -> 'Data Dictionary' tab.

Data dictionary parameters are key/value pairs of the following form:

@@DATA_DICTIONARY_KEY@@ Data-Dictionary-Value

The Data Dictionary defines the differences between one target and another target. The (target specific) dictionary values are injected into the deployment orchestration at deployment time.

Project, Target and Job scopes are supported.

• 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'.

Project Deployable Resources

The projects deployable resources can be stored locally under the project root directory, or pulled in at package time from an external resource library location. They tend to be target neutral resources such as scripts, Ear files, Jar files etc. Typically they represent the 'payload' of the job and are often the output of a continuous integration or build process.

Targets

A 'Target' is defined as a 'Server' and one of its contained 'Installations'. A project can define many deployment targets. For example a project might define several development, test, UAT and production targets, each of which can be deployed to independently or as part of a release 'Pipeline'. Each deployment target can override the Data Dictionary values discovered and set at Project scope.

You can click on the 'Server' and 'Installation' links on the 'Targets' list panel to go to the Server or Installation definition respectively.

Deployment Package

The deployment package is a point in time, zipped copy of the project root directory that is stored outside SCM, normally on the filesystem or in an artifact repository such as Maven. It will also contain any external resources as required by the project (see above). The package will be named according to the label in the Scm repository. This package contains all of the configuration and artifacts to completely build (from scratch) and/or update ALL of the target that this package relates to.

This package can be created the RapidDeploy application itself using the Projects Package Wizard or through a Job Plan by selecting 'NEW VERSION' on the version selector. In the latter case, a new package is created in the project as the first step each time the pipeline is invoked, and used for all subsequent targets in the pipeline for this project.

Simple Case

In its simplest form, the deployment process allows you to select a project defining your set of version locked components, a target installation and a point-in-time deployment package (version of components, configuration or both) and execute them.

This performs the following actions:

• Copy the package to the target server on which the installation resides (or deployment manager if it resides on multiple servers such as a WebSphere Cell)
• Unpack the package in the temporary location
• Use the dictionary file to replace any placeholders in the orchestration file and any other configuration files (to make them target specific) if necessary
• Run through the tasks in the orchestration file in turn to perform the individual deployment tasks
• Logging is streamed back to the RapidDeploy UI in real-time for monitoring and debugging purposes.

Linked Deployments

RapidDeploy supports calling one or more downstream project jobs from a currently running job, either synchronously or asynchronously by using the 'Linked Deployment' task, which makes a Rest Web Services call back to the RapidDeploy framework server. This task can invoke any target on any project. This method can therefore be used to create dependencies between project targets (such as in a route to live scenario) or between projects (such as where deploying multiple components to create a complete target environment).

Job Plan

You can combine projects, targets and deployment package versions into a job plan, which is a higher level construct above the project level, enabling dependencies between project jobs to be created. The jobs plan is composed of pipelines, steps and jobs. Pipelines are based on steps and every step can have multiple parallel jobs. This means that within each pipeline jobs and be executed serially and/or in parallel, depending on which configuration is set. Additionally every pipeline can be scheduled to run at any time and steps auto executed or manually triggered. Dependencies can be set up between deployments and Human task steps can be introduced so that you can for example deploy all web servers in parallel, wait for them all to complete and then deploy the web application, perhaps requiring a human task after the web application has deployed to confirm success or order a backout.

Additionally, a pipeline step may make a REST call to any external service and wait (poll) for a specific success or failure response. A pipeline step may also call another pipeline, either synchronously or asynchronously.