Defining Application Deployments
Application deployments are the core strength of CDA. This topic explains the deployment model and how the CDA entities relate.
This page includes the following:
Deployment Model
With Automic Continuous Delivery Automation, you can easily configure and manage the entities that make up the deployment process. The following illustration depicts the dependencies among entities:
CDA Core Entities
The following table provides brief descriptions of the core entities of the deployment model and links to the topics that deal with them:
| Entity | Short Description | Topic | |
|---|---|---|---|
| WHAT to deploy |
Application & Components |
An Application is the main container of the deployment model and typically consists of multiple Components. As an example, your Application may consist of two Components, a web application and a database component. Each Application Component uses a specific technology such as Apache Tomcat or a Microsoft SQL database. The Application entity also includes component-related Workflows to install, upgrade, or remove Application Components. |
|
| Package |
A Package is an instance (a version, a revision, a tag, …) of an Application that defines the content which you want to deploy. Here you define if you want to deploy the entire Application or simply a few specific Components. |
Deployment Packages | |
| HOW to deploy | Workflow |
Workflows are used to carry out physical deployments. A workflow describes all necessary steps for a deployment of your Application. As your Application consists of different Components, the top level of the Workflow (Application Workflow) represents your Application architecture and Component Workflows are used to deploy the individual Components. You can quickly define your Component Workflow with predefined Actions. |
Workflows |
| Deployment Profile |
A Deployment Profile links an Application to one specific Environment. Typically it is an intersection between the Application Components and the Environment Deployment Targets. For example, Tomcat application components are mapped to the Tomcat deployment target. The Deployment Profile is used during the deployment execution and defines where to deploy. |
Deployment Profiles | |
| Login object | Login Objects store account credentials that are used by agents on nodes. Account credentials can be related to single nodes or can be shared between a set of nodes (for example, shared account). | Login Objects and Account Credentials | |
| WHERE to deploy | Environment |
An Environment consists of Deployment Targets which represent your endpoints. Different Environments are used for different phases in the software delivery cycle, for example, Development, QA, Staging, Production. An Environment is typically set up once and used by several Applications. |
Environments |
| Deployment Target |
A Deployment Target is an endpoint where you deploy your Application Components. All endpoint-related parameters (for example, port numbers, IP addresses, and directories) are typically related to the Deployment Target and can be configured there. The execution itself is handled by the assigned operating system agent. |
Deployment Targets |
Design your deployments in the following order:
- Creating Applications
- Creating Components
- Creating Workflows
- Creating Login Objects
- Creating Environments
- Creating Deployment Targets
- Creating Deployment Profiles
- Creating Packages. This should be the last step, as Packages are the only entity that requires creation for each release and version of the Application.