RapidDeploy Glossary of Terms

• Task

  A task is a unit of work which is executed on a target server. RapidDeploy contains over 200 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. Running existing assets

• Orchestration

  An orchestration contains a set of tasks which are executed, in order, for a specific project deployment. Orchestrations are environment neutral, but may be dynamically populated with environment specific values at runtime.

• Job

  A job is an invocation of an orchestration on a target server. See Deployment Request for a description of the deployment Job Type

• Composite Deployment

  A composite deployment is a set of jobs run together as a batch, for example, this may include a DB configuration job and a WebSphere deployment job and Tomcat deployment job which together make up a complete enterprise application.

• Project

  A project defines the orchestration, build stores and logging directories.  It also contains the logical environment definition files containing the applications and/or configuration data required for the orchestration. A project may be situated on a standard filesystem, or be under version control. A project may be used to deploy configuration, deployment artifacts such as ear files or schemas, or both.

  Multiple projects may contain definitions for the same target environment, allowing users to configure different “views” of that target environment for each project. This means a shared JEE cluster for example may take on many different attributes depending on project and version deployed to it. For example it might be used for testing stream 1 of an application with one set of configuration (from project 1) in the morning, and stream 2 of the same application (from project 2) with a different set of configuration (perhaps an additional Data Source) in the afternoon.

  A project’s configuration will also change over time as code evolves. RapidDeploy stores each built version of the project (either code, configuration or both) over time and these may be rolled in and out of the target environment at will, perhaps changing the deployed version into a test environment many times in the same day.

• 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. A created package is stored in a projects Build Store.

• Build Store

  A build store contains the project packages which are deployed to the target servers and used in a job.  The RapidDeploy build stores contain the packages, the build store location being defined on the project panel.  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.  The orchestration is then read to find out the working directory and that directory is used to expand the package to as a transient working area. The finalization task of the orchestration cleans up the files in this working directory or it can be set to leave the files for trouble shooting purposes. Local and remote build stores should not be held in a version control system.

• Snapshot

  A moment in time shapshot of a technologies configuration, 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.

• Server

  In most common use, server is a physical computer (a computer hardware system) dedicated to running one or more services (as a host),to serve the needs of users of the other computers on the network. Depending on the computing service that it offers it could be a database server, file server, mail server, application server, web server or other. In RapidDeploy terms, a server may further defined as a deployment target, which may contain one or more environments for one or more technologies.

• Environment

  A physical container of components which may include some or all of the following (non exhaustive list): A binary software installation (possible distributed across multiple nodes); a naming (directory) service; a remote procedure call (RPC) mechanism; a time service; an authentication service; a distributed file system (DFS); an administration service;  a number of ditributed node level administration services. The components, taken together and distributed across multiple nodes, form a container and framework for one or more server runtimes. Examples of Environments defined in RapidDeploy would be an IBM WebSphere ND Cell, a WebLogic Domain, a WebSphere MQ Queue Manager, and an Oracle Database or RAC installation. A RapidDeploy Environment is one discreet sub-level component of a RapidDeploy server and contains one or more RapidDeploy instances.

  A logical environment may also define an end to end set of componets or interrelated systems, such as a web server, application server and database that together form a organizational core business area, function, or service. RapidDeploy can deploy an entire environment by the use of deployment plans. Thus, numerous logical end-to-end environment components may reside in a single  physical environment. For example a WebSphere cell may contain many unrelated clusters that each form part of a different logical end-to-end environment.

  RapidDeploy can deploy whole logical enbvironments using deployment plans or just a single component (in the above example a cluster in WebSphere) with deployment requests as well as whole physical environments (a WebSphere cell migration, for example)

• Instance

  An instance as defined in RapidDeploy is one discreet sub-level component of an environment. Some examples would be a cluster or standalone application server and all of its unique configuration and other assets (such as deployed code, logs etc) in a WebSphere Cell or WebLogic domain. For an Oracle Database it would be a schema within a database or RAC environment. A RapidDeploy instance typically contains one or more RapidDeploy applications.

• Application

  An application as defined in RapidDeploy is one discreet sub-level component of an instance. Some examples would be an Ear file that may be deployed to one or more WebSphere or WebLogic clusters or standalone servers. For an Oracle schema it would be the DDL and possibly reference data defining the schema. A WebSphere MQ application might contain security data and MQSC files.

• Deployment Request

  Deployment of 1 project orchestration onto one defined environment. It may consist of deployable artifacts (for example ear/war/jar files) and/or all or some of the configuration required to define that component (such as application bindings, WebSphere cluster configuration, Jms providers, Jdbc providers, DataSources, Virtual hosts, Work manager configs etc). This can be used to completely rebuild the cluster on each deployment or just a part of it (such as Jdbc connectivity). A deployment request may deploy just the artifacts (with bindings information), just the configuration, or both.

• Deployment Plan

  A set of deployment requests from 1 or more projects that typically will define one end-to-end logical environment, interleaved as required with human tasks.
  For example,  in a very simple case the projects might be:
  An Apache project with httpd.conf and static content;
  A webSphere project with 1 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 environment.
  So the deployment plan in this case might have 3 deployment requests, each selecting a version from the available builds of its project and the target physical environment for each (A webSphere Cluster in a cell, an Oracle DB schema in an oracle instance , an http.conf file in an apache installation)

  Deployment plans are managed by the Environment manager Role
  Deployment plans allow requests to be batched together and have dependencies on each other.
  Allows checkpoints on completion of a set of batched requests

• Route To Live Plan

  A collection of deployment plans and human tasks forming a long running workflow. Workflow of deployment plans on a route to live, typically encompassing at least one test environment, one pre-production environment, one production environment.
  Human tasks for checkpoints, input of Change Records, Checking Approval state of Change Records prior to production deployments, scheduling, Backout steps. Version lock deployment plans entering the workflow to prevent version changes.

  Controlled by the Release Manager role.

• Environments and shared infrastructure

  - A logical end to end environment might consist of phsical infrastructure such as web servers, a WebSphere cell and a database instance
  - Many different Deployment plans can be deployed to this physical infrastructure concurrently. They may be
  completely unrelated. They may queue. Each Request will run independetly of any other.

  For example WebSphere cells:

  Might have Payments Development/Test cell forming part of 50 payments end-to-end dev environments with 50 JVMS. Those 50 JVM’s might be from 10 payments projects, each with 5 parallel development streams. There may be deployments to each JVM happening in parallel throughout the day. All of the JVMs are in constant use.

  Similarly for the Database instance with 50 schemas and the Apache instance with 50 httpd.conf files.