For a deployment, Deploy calculates the step list based on your model. If you want to add an extra step, there are several ways to do so. This topic describes how to handle a simple case by executing a remote shell command on a server.
You can specify multiple orchestrators for each deployment to achieve complex use cases.
Deploy features a modular architecture that allows you to change and extend components while maintaining a consistent system. This is a high-level overview of the system architecture:
You can disable any rule that is registered in the Deploy rule registry, including rules that are:
An orchestrator combines the steps for the individual component changes into an overall deployment workflow. This example shows how different orchestrators affect the deployment of a package containing an EAR file, a WAR file, and a datasource specification to an environment containing two JBoss Application Server server groups and one Apache Tomcat virtual host.
When preparing a deployment, Deploy must determine which steps to take for the deployment, and in what order. This happens in three phases:
Deploy is a model-driven deployment solution. Users declaratively define the artifacts and resources that they need to deploy in a package, which is a ZIP file with a deployit-manifest.xml file, and Deploy figures out how to install the components in a target environment using rules. Rules are used to teach the Deploy execution engine how to generate your deployment steps in a scalable, reusable, and maintainable way.
In Deploy, each block at the root level of a deployment plan is called a phase. If your deployment plan does not require any satellite servers, it will probably have one phase. If Deploy requires at least one satellite server to complete the deployment, the plan will contain additional phases to prepare and clean up the satellite servers.
When you set up an initial deployment or an update, you can use the Preview option to view the deployment plan that Deploy generated based on the deployment configuration. As you map deployables to containers in the deployment configuration, the Preview will update and show changes to the plan.
When you define an XML or script rule in Deploy, you use expressions or scripts to define its behavior. These are written in Jython, a combination of Python and Java.
A step is an action to be performed to accomplish a task. All steps for a particular deployment are grouped together in a steplist.
When you use the Preview option of the deployment plan, you can also see the Stitch preview for it, by using the toggle button to switch between two views. After clicking on the Stitch preview toggle, you can also browse and view Stitch invocation details.
In Deploy, an orchestrator combines the steps for individual component changes into an overall deployment or provisioning workflow. Orchestrators are also used for specifying which parts of the deployment or provisioning plan are executed sequentially or in parallel. You can combine multiple orchestrators for more complex workflows. For more information, see Combining multiple orchestrators.
The planning phase takes place when the global structure of the deployment has been determined, and Deploy needs to fill in the steps needed to deploy the application. The goal of planning is to generate a deployment plan. It uses the structured deployment generated by the orchestration phase. Plugins and rules contribute steps to the plan.
Deploy rules enable you to use XML or Jython to specify the steps that belong in a deployment plan and how the steps are configured. Several Deploy plugins include predefined rules that you can use when writing rules. For more information on rules, see Get started with rules.
A script rule adds steps and checkpoints to a plan by running a Jython script that calculates which steps and checkpoints to add.
The Deploy rules system enables you to use XML or Jython to specify the steps that belong in a deployment plan and how the steps are configured. For more information, see Get started with rules and Writing script rules.