Skip to main content
Version: Early Access

Deploy System Architecture

With Deploy modular architecture you can change and extend components while maintaining a consistent system.

This is a high-level overview of the system architecture:

[deploy arch diagram]

The Deploy core​

Deploy's central component is called the core. It contains the following functionality:

  • The Unified Deployment Engine, which determines what is required to perform a deployment
  • Storage and retrieval of deployment packages
  • Execution and storage of deployment tasks
  • Security
  • Reporting

The Deploy core is accessed using a REST service. Deploy includes two REST service clients:

  • An HTML5 graphical user interface (GUI) that runs in a supported browser
  • A command-line interface (CLI) that interprets Jython.

Deploy plugins​

A plugin is a separately-maintained, modular component that extends the core architecture to interact with specific middleware, enabling you to customize a deployment plan for your environment. Plugins enable you to:

  • Maintain a core that remains independent of the middleware to which it connects.
  • Extend existing Deploy plugins to customize Deploy for your environment.
  • Develop custom plugins to extend Deploy and seamlessly integrate with Deploy's core functionality.
  • Create new Deploy plugins from scratch.

A plugin integrates with the core using a well-defined interface that enables the core to invoke the plugin when needed. Plugins respond by performing the defined actions. Plugins can define the following:

  • Deployable - Configuration Items (CIs) that are part of a package and can be deployed
  • Container - CIs that are part of an environment and can be deployed to
  • Deployed - CIs that are a result of the deployment of a deployable CI to a container CI
  • A recipe describing how to deploy deployable CIs to container CIs
  • Validation rules to validate CIs or properties of CIs

Startup behavior​

When the Deployit server starts, it scans the classpath for valid plugins and loads each plugin, readying it for interaction with the Deployit core. Once the Deployit core has loaded the plugins, it will not pick up any modified plugins or new ones you create.

Runtime behavior​

At runtime, multiple plugins will be active at the same time. It is up to the Deploy core to integrate the various plugins and ensure they work together to perform deployments. There is a well-defined process (described below) that invokes all plugins involved in a deployment and turns their contributions into one consistent deployment plan. The execution of the deployment plan is handled by the Deploy core.

Deployment stages in Deploy​

Deploy and plugins work together to perform a deployment in stages, ensuring that the deployment package is properly deployed and configured in the environment. Stages include:

  • Specification: Creates a deployment specification that defines which deployables (deployment package members) are to be deployed to which containers (environment members) and how they should be configured.

  • Delta Analysis: Analyzes the differences between the deployment specification and the current state of the middleware. Creates a delta specification that lists changes to the current middleware state and the state that will result from the execution of the deployment specification. The deltas represent one of the following operations needed on the deployed items:

    • CREATE: Deploying an item for the first time
    • MODIFY: Upgrading an item
    • DESTROY: Undeploying an item
    • NOOP: No change to an item

  • Orchestration: Splits the delta specification into independent sub-specifications that can be planned and executed in isolation. Creates a deployment plan containing nested subplans.

  • Planning: Adds steps to each subplan that, when executed, perform the actions needed to execute the actual deployment.

  • Execution: Executes the complete deployment plan.

Deployments and plugins​

The following diagram depicts how a plugin is involved in a deployment:

Deployment

The transitions in this diagram that are represented with a:

  • Puzzle piece icon are those that interact with the plugins.
  • Deploy logo are those that are handled by the Deploy core.

Specification and Planning stage details​

The following sections detail how the core and plugins interact during the Specification and planning stages of a deployment.

Specification stage details​

In the Specification stage, the details for deployment to be executed are specified including selecting the deployment package and members and mapping each package member to the environment members to which they will be deployed.

Specifying CIs​

The Deploy plugin defines which CIs the Deploy core can use to create deployments. When a plugin is loaded into the core, Deploy scans the plugin for CIs and adds these to its CI registry. Based on the CI information in the plugin, Deploy will categorize each CI as either a:

  • Deployable CI which defines the what of the deployment or
  • Container CI which defines the where of the deployment
Specifying relationships​

While the deployable CI represents the passive resource or artifact, the deployed CI represents the active version of the deployable CI when it has been deployed in a container. By defining deployed CIs, the plugin indicates which combinations of deployable and container are supported.

Configuration​

Each deployed CI represents a combination of a deployable CI and a container CI. It is important to note that one deployable CI can be deployed to multiple container CIs. For example, an EAR file can be deployed to two application servers. In a deployment, this is modeled as multiple deployed CIs.

You may want to configure a deployable CI differently depending on the container CI or environment to which it is deployed. This can be done by configuring the properties of the deployed CI differently.

Configuration of deployed CIs is handled in the Deploy core. You perform this task either using the GUI or the CLI. A Deploy plugin can influence this process by providing default values for its properties.

Result​

The result of the Specification stage is a deployment specification that describes which deployable CIs are mapped to which container CIs with the needed configuration.

Planning stage details​

In the Planning stage, the deployment specification and the subplans that were created in the Orchestration stage are processed. During this stage, the Deploy core performs the following procedure:

  1. Preprocessing
  2. Contributor processing
  3. Postprocessing

During each part of this procedure, the Deploy plugin is invoked to add required deployment steps to the subplan.

Preprocessing​

Preprocessing allows the plugin to contribute steps to the very beginning of the plan. During preprocessing, all preprocessors defined in the plugin are invoked in turn. Each preprocessor has full access to the delta specification. As such, the preprocessor can contribute steps based on the entire deployment. Examples of such steps are sending an email before starting the deployment or performing "pre-flight" checks on CIs in that deployment.

Deployed CI processing​

Deployed CIs contain both the data and the behavior to make a deployment happen. Each deployed CI that is part of the deployment can contribute steps to ensure that it is correctly deployed or configured.

Steps in a deployment plan must be specified in the correct order for the deployment to succeed, and the order of these steps must be coordinated among an unknown number of plugins. To achieve this, Deploy weaves all of the separate resulting steps from all the plugins together by looking at the order property (a number) they specify.

For example, suppose you have a container CI representing a WebSphere Application Server (WAS) called WasServer. This CI contains the data describing a WAS server (such as host, application directory, and so on) as well as the behavior to manage it. During a deployment to this server, the WasServer CI contributes steps with order 10 to stop the server. Also, it would contribute steps with order 90 to restart it. In the same deployment, a deployable CI called WasEar (representing a WAS EAR file) contributes steps to install itself with order 40. The resulting plan would weave the installation of the EAR file (40) in between the stop (10) and start (90) steps.

This mechanism allows steps (behavior) to be packaged together with the CIs that contribute them. Also, CIs defined by separate plugins can work together to produce a well-ordered plan.

Default step orders​

Deploy uses the following default orders:

StepDefault order
PRE_FLIGHT0
STOP_ARTIFACTS10
STOP_CONTAINERS20
UNDEPLOY_ARTIFACTS30
DESTROY_RESOURCES40
CREATE_RESOURCES60
DEPLOY_ARTIFACTS70
START_CONTAINERS80
START_ARTIFACTS90
POST_FLIGHT100

To review the order values of the steps in a plan, set up the deployment, preview the plan, and then check the server log. The step order value appears at the beginning of each step in the log.

To change the order of steps in a plan, you can customize Deploy's behavior by:

Postprocessing​

Postprocessing is similar to preprocessing, but it allows a plugin to add one or more steps to the very end of a plan. A postprocessor could, for example, add a step to send an email after the deployment is complete.

Result​

The Planning stage results in a deployment plan that contains all steps required to perform the deployment. The deployment plan is ready to be executed.