Deployment overview and the Unified Deployment Model
This topic describes a deployment that consists of all actions needed to install, configure, and start an application on a target environment.
Unified Deployment Model (UDM)
In Deploy, deployments are modeled using the Unified Deployment Model (UDM), which consists of:
- Deployment package: An environment-independent package that contains deployable configuration items (CIs) that form a complete application.
- Environment: A group of infrastructure and middleware containers, which are deployment targets. For example, hosts, servers, clusters, and so on.
- Deployment: The process of configuring and installing a deployment package in a specific environment. Deployment results in deployeds, which describe the combination of a deployable and a container.
Deployment packages represent versions of an application. For example, the application MyWebsite could have deployment packages for version 1.0.0, 2.0.0, and so on. You can define dependencies among application versions. This ensures that when you try to deploy a specific deployment package when its dependencies are not already present in the target environment, the dependent packages will automatically be deployed, or the deployment will fail. For more information on dependencies, see Application dependencies in Deploy.
Additionally, deployment packages and all other configuration items (CIs) stored in the Deploy Repository are version-controlled. For more information, see The Deploy Repository.
UDM in the Deploy GUI
The Deploy GUI presents the main UDM concepts in the Deployment Workspace:
Deployments are defined by:
- A package containing what is to be deployed as shown in the node tree on the left.
- An environment defining where the package is to be deployed as shown in the node tree on the right.
- Configuration of the deployment that specifies customizations to the package to be deployed as shown in the node trees in the middle. The customizations can be environment-specific.
Packages and environments are made up of smaller parts:
- Packages consist of deployables, which are items that can be deployed.
- Environments consist of containers, which are items that can be deployed to.
Containers are the middleware products to which deployables are deployed. Examples of containers are an application server such as Tomcat or WebSphere, a database server, and a WebSphere node or cell.
There are two types of deployables:
- Artifacts, which are physical files such as an EAR file, a WAR file, or a folder of HTML files.
- Resource specifications, which are middleware resources that an application requires to run, such as a queue, a topic, or a datasource.
The deployment process
The deployment process consists of the following phases:
- Specification
- Delta analysis
- Orchestration
- Planning
- Execution
The process is followed when you are deploying an application, upgrading an application to a new version, downgrading an application to an older version, or undeploying an application.
Phase 1: Specification
Deploying an application starts with specification. During specification, you select the application that you want to deploy and the environment to which you want to deploy it. The deployables are then mapped to the containers in the environment. Deploy manually or automatically helps you create correct mappings.
Phase 2: Delta analysis
Given the application, environment, and mappings, Deploy can perform delta analysis. A delta is the difference between the specification and the actual state. During delta analysis, Deploy calculates what needs to be done to deploy the application by comparing the specification against the current state of the application. This comparison results in a delta specification.
Phase 3: Orchestration
Orchestration uses the delta specification to structure your deployment. For example, the order in which parts of the deployment will be executed, and which parts will be executed sequentially or in parallel. Depending on how you want the deployment to be structured, you can choose a combination of orchestrators.
Phase 4: Planning
In the planning phase, Deploy uses the orchestrated deployment to determine the final plan. The plan contains the steps to deploy the application. A step is an individual action that is taken during execution. The plugins and rules determine which steps are added to the plan. The result is the plan that can be executed to perform the deployment. For more information, see Understanding the Deploy planning phase.
Phase 5: Execution
During execution of the plan, Deploy executes the steps. After all steps have been executed successfully, the application is deployed.
Example
Assume you have a package that consists of:
- an EAR file (an artifact)
- a datasource (a resource specification)
- some configuration files (artifacts)
In this case, you want to deploy this package to an environment containing an application server and a host (both containers). The deployment could look like this:
The EAR file and the datasource are deployed to the application server and the configuration files are deployed to the host.
As you can see above, the deployment also contains smaller parts. The combination of a particular deployable and container is called a deployed. Deployeds represent the deployable on the container and contain customizations for the specific deployable and container combination.
For example, the PetClinic-ds deployed represents the datasource from the deployment package as it will be deployed to the was.Server container. You can specify a number of properties on the deployed:
For example, the deployed has a specific username and password that may be different when deploying the same datasource to another server.
After a deployment is specified and configured using the concepts above (and the what, where and customizations are known), Deploy manages the how by preparing a list of steps that need to be executed to perform the actual deployment. Each step specifies one action to take, such as copying a file, modifying a configuration file, or restarting a server.
When the deployment is started, Deploy creates a task to perform the deployment. The task is an independent process running on the Deploy server. The steps are executed sequentially and the deployment is finished successfully when all steps have been executed. If an error occurs during deployment, the deployment stops and you must manually intervene.
The result of the deployment is stored in Deploy as a deployed application and appears on the right side of the Deployment Workspace. Deployed applications are organized by environment so it is clear where each application is deployed. You can also see which parts of the deployed package are deployed to each environment member.
The final result of the sample deployment looks like this:
