Task

A task is a unit of work which is executed on a target 'Server'. The tool contains hundreds of tasks and adding new plugins will typically add more tasks. These tasks are OS level tasks (such as CHMOD, MKDIR, COPY) and technology specific tasks (such as INSTALL PRODUCT, START SERVER, FEDERATE NODE). Existing scripts can be leveraged in a task or new tasks can be written in Java by implementing a simple API. Tasks are chained together in a project 'Orchestration'.

Orchestration

An orchestration contains a set of 'Tasks' which are executed as defined in the Orchestration designer, for a specific project deployment. Orchestrations are target neutral, but may be dynamically populated with target specific 'Data Dictionary' values at runtime. The orchestration defines 'how' we perform our deployment.

Project

A project defines the 'Orchestration', 'Build Store', 'Resources' and logging directories. It also contains the logical target definition 'Data Dictionary' values at 'Project' and 'Target' scope.

Data Dictionary

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

Package

A package is the payload that contains the configuration and/or applications to be installed / configured / deployed. A package is created by compressing the project directory and including any internal or external 'Resources' from a RapidDeploy 'Resource'. A created package is stored as a unique 'Version' in a projects 'Build Store'.

Build Store

A 'Build Store' contains the versioned project deployment packages which are deployed to the target servers and used in a job. The build stores contain the packages, the 'Build Store' location being defined on the project panel by the artifact repository plugin. The remote server build store is where the 'Package', 'Orchestration' and log settings file are copied to, this remote build store is defined on the server panel.

Snapshot

A moment in time snapshot of an 'Installation', which can be used to compare against another snapshot to work out configuration drift. In some cases a snapshot can also be used as a golden source template for other environments.

Infrastructure

The 'Infrastructure' panel defines the list of 'Servers' and their associated 'Installations'. Infrastructure defines 'where' we can deploy to.

Server

In MidVision terms, a server may be defined as a a logical name for one or more identical physical hosts, which may each contain one or more 'Installations' for one or more technologies. On the server panel you define how to connect to the target either using SSH or an Agent. You also define the IP address(es) that make up this server definition or integrate with a cloud provider via one of the cloud plugins.

Installation

A RapidDeploy 'Installation' is one discreet sub-level of a 'Server' and represents something installed on a server such as a web server, application server, set of files, set of scripts or a database.

Configuration

An configuration as defined in the tool is one discrete sub-level component of an 'Installation'. It allows us to define different configurations for the same installation. For example an 'Installation' might be a script on a set of 'servers'. We define different configurations for each different invocation of that script, with perhaps different environment variables or command line arguments.

Project Target

A 'Project Target' defines where a project 'Orchestration' can be run. A 'Project Target' is a 'Configuration' for a specific 'Installation' on a specific 'Server'. You can define target specific data dictionary values on a target which will be used in any invocation of the server orchestration on this 'Project Target', overriding those data dictianary parameters set at project scope.

Environment

An 'Environment' is a collection of 'Installations'. Each 'Installation' can belong to just one 'Environment'. Out of the box RapidDeploy comes with three pre-defined 'Environments': Development, Test and Production. Further 'Environments' can be added by the user.

A logical end to end 'Environment' might consist of physical infrastructure such as web servers, a WebSphere cell and a database instance. Adding the development installations for each of these components to an 'Environment' creates a logical grouping. We might call it WebSphere-Development. Equally we can create further goupings for WebSphere-Test and WebSphere-Production. In RapidDeploy we can further assign roles, resources, and approval groups to these 'environments' to enable us to control access to them, and we can report on actions taken against specific 'Environments'.

Job Request

Deployment of one Project 'Package' at a specific 'Version' onto one defined Project 'Target' and then running the 'Orchestration'. The package may consist of deployable artifacts (for example script, database or jar files) defined as project 'Resources' and/or all or some of the configuration required to configure those resources (such as script environment variables or arguments, database parameters or java properties etc) defined as literals in the orchestration or as 'Data Dictionary' values.

Pipeline

A set of 'Job Requests' from one or more 'Projects' that typically will define one end-to-end delivery pipeline at a specific version of each of the component projects, interleaved as required with automatic or human tasks. For example, in a very simple case the projects in a job plan might be:

• An Apache project with httpd.conf and static content
• A webSphere project with one EAR file and the cluster and Database Provider definitions to build and maintain the cluster
• A Database project with schema and reference data definitions

Together these components define a simple end-to-end web application. These components may be deployed to a development, test and production 'Environment' following a pipeline with interleaved pipeline steps and approval gates.

Pipeline Step

An action between a set of Project/Targets. These may be manual, automatic, event driven, depend on the output of a REST call or of another type. The step action will need to be fulfilled before the pipeline moves on to the next set of project/targets.

Job Plan

A set of 'Pipelines' that run sequentially or in parallel.

Resource

The RapidDeploy 'Resource' defines a site wide 'Resources' that can be consumed by projects. The resources typically added to the RapidDeploy 'Resource' could be binary installers, scripts, jar files, ear files etc. They can be sourced dynamically using differnet protocols or tools, such as http, https, local file or folder, remote SCP file or folder, Nexus, Maven, Artifactory, Team Foundation Server, Git, Subversion etc.

Project Resources

'Resources', included in the versioned 'Deployment Packages' for a 'Project' can be thought of as the 'things' deployed to our Infrastructure.