Deploy concepts

This topic provides information about the Deploy concepts for using Deploy.

Deploy is an application release automation (ARA) tool that deploys applications to environments (for example, development, test, QA, and production) while managing configuration values that are specific to each environment. Deploy is designed to make the process of deploying applications faster, easier, and more reliable. You provide the components that make up your application, and Deploy does the rest.

Deploy is based on these key concepts:

• Configuration items (CIs): A configuration item (CI) is a generic term that describes all objects that you can manage in Deploy.
• Applications: The software that will be deployed in a target system
• Deployables: An artifact such as a file, a folder, or a resource specification that you can add to a deployment package and that contains placeholders for environment-specific values
• Deployment packages: The collection of deployables that make up a specific version of your application
• Environments: A collection of infrastructure (servers, containers, cloud infrastructure, and so on) where elements of your packages can be deployed
• Mappings: The task of identifying where each deployment package should be deployed
• Deployments: The task of mapping a specific deployment package to the containers in a target environment and running the resulting deployment plan
• Deployment plans: The steps that are needed to deploy a package to a target environment
• Deployed items: A deployable that has been deployed to a container and contains environment-specific values

Interacting with Deploy

You can interact with Deploy in the following ways:

• Deploy GUI: The Deploy graphical user interface (GUI) is an HTML5 based web-application running in a browser.
• Deploy Command Line Interface (Deploy CLI): The Deploy CLI is a Jython application that you can access remotely and use to perform administrative tasks or to automate Deploy tasks.
• XL Command Line Interface (XL CLI): The XL CLI is part of the DevOps as Code feature set, and is separate from the Deploy CLI. The XL CLI is a lightweight command line interface that enables developers to use text-based artifacts to interact with our DevOps products without using the GUIs.

Security

Deploy has a role-based access control scheme that ensures the security of your middleware and deployments. The security mechanism is based on the concepts of roles and permissions. For more information, see Overview of security in Deploy.

A role is a functional group of principals (security users or groups) that can be authenticated and assigned rights over resources in Deploy. These rights can be either:

• Global: the rights apply to all of Deploy, such as permission to log in.
• Relevant to a particular configuration item (CI) or set of CIs. Example: the permission to read specific CIs in the repository.

The security system uses the same permissions when the system is accessed with the GUI or the CLI.

note

In Deploy, user principals are not case-sensitive.

Plugins

A plugin is a self-contained piece of functionality that adds capabilities to the Deploy system. A plugin is packaged in a JAR or XLDP file and installed in Deploy's plugins directory. Plugins can contain:

• Functionality to connect to specific middleware
• Host connection methods
• Custom importers

For more information, see Install or remove Deploy plugins.

Configuration items

Applications, middleware, environments, and deployments are all represented in Deploy as CIs. A CI has a type that determines what information it contains, and what it can be used for.

All Deploy CIs have an id property that is a unique identifier. The id determines the place of the CI in the library.

Example: A CI of type udm.DeploymentPackage represents a deployment package. It has properties containing the version number. This CI has child CIs for the artifacts and resource specifications it contains and has a link to a parent CI of type udm.Application. This indicates which application the package is a part of.

Directories

A directory is a CI used for grouping other CIs. Directories exist directly below the root nodes in the library and may be nested. Directories are also used to group security settings.

Example: You can create directories called Administrative, Web, and Financial under Applications in the library to group the available applications in these categories.

Embedded CIs

Embedded CIs are CIs that are part of another CI and can be used to model additional settings and configuration for the parent CI. Embedded CI types are identified by their source deployable type and their container (or parent) type.

Embedded CIs, like regular CIs, have a type and properties and are stored in the repository. Unlike regular CIs, they are not individually compared in the delta analysis phase of a deployment. If an embedded CI is changed, this will be represented as a MODIFY delta on the parent CI.

Type system

Deploy features a configurable type system that you can use to modify and add types of CI types. For more information, see Working with configuration items. You can extend your installation of Deploy with new types or change existing types. Types defined in this manner are referred to as synthetic types. The type system is configured using XML files called synthetic.xml. All files containing synthetic types are read when the Deploy server starts and are available in the system afterward.

Synthetic types are first-class citizens in Deploy and can be used in the same way that the built-in types are used. These types can be included in deployment packages, used to specify your middleware topology, and used to define and execute deployments. Synthetic types can also be edited in the Deploy GUI, including new types and added properties.

Deployment packages

To deploy an application with Deploy, you must supply a file called a deployment package, or a DAR package. A deployment package contains deployables, which are the physical files (artifacts) and resource specifications (datasources, topics, queues, etc.) that define a specific version of your application.

DAR packages do not contain deployment commands or scripts. Deploy automatically generates a deployment plan that contains all of the deployment steps that are necessary.

DAR packages are designed to be environment-independent so that artifacts can be used from development to production. Artifacts and resources in the package can contain customization points such as placeholders in configuration files or resource attributes. Deploy will replace these customization points with environment-specific values during deployment. The values are defined in dictionaries.

A DAR package is a ZIP file that contains application files and a manifest file that describes the package content and any resource specifications that are needed. You can create DAR packages in the Deploy interface, or you can use a plugin to automatically build packages as part of your delivery pipeline. Deploy offers a variety of plugins for tools such as Maven, Jenkins, Team Foundation Server (TFS), and others.

You can use command line tools such as zip, the Java jar utility, the Maven jar plugin, or the Ant jar task to prepare DAR packages.

Deployables

Deployables are configuration items (CIs) that can be deployed to a container and are part of a deployment package. The two types of deployables: artifacts (example: EAR files) and specifications (example: a datasource).

Artifacts

Artifacts are files containing application resources such as code or images. These are examples of artifacts:

• A WAR file
• An EAR file
• A folder containing static content such as HTML pages or images

An artifact has a property called checksum that can be overridden during or after import. If it is not specified, Deploy will calculate a SHA-1 sum of the binary content of the artifact, which is used during deployments to determine if the artifact's binary content has changed or not.

Resource specifications

Resource specifications are specifications of middleware resources required for an application to run. These are examples of resources:

• A datasource
• A queue or topic
• A connection factory

Deployeds

Deployeds are CIs that represent deployable CIs in their deployed form on the target container. The deployed CI specifies settings that are relevant for the CI on the container.

Examples:

• A wls.Ear deployable is deployed to a wls.Server container, resulting in a wls.EarModule deployed.

• A wls.DataSourceSpec is deployed to a wls.Server container, resulting in a wls.DataSource deployed. The wls.DataSource is configured with the database username and password that are required to connect to the database from this particular server.

Deployeds go through the following lifecycle:

• The deployed is created on a target container for the first time in an initial deployment
• The deployed is upgraded to a new version in an upgrade deployment
• The deployed is removed from the target container when it is undeployed

Composite packages

Composite packages are deployment packages that have other deployment packages as members. A composite packages can be used to compose a release of an application that consists of components delivered by separate teams.

Composite packages can not be imported. They are created inside Deploy using other packages that are in the Deploy repository. You can create composite packages that contain other composite packages.

Deploying a composite package is the same as deploying a regular package.

note

Deploy has a composite package orchestrator that ensures the deployment is carried out according to the ordering of the composite package members.

Dictionaries

A dictionary is a CI that contains environment-specific entries for placeholder resolution. Entries can be added in the GUI or using the CLI. The deployment package remains environment-independent and can be deployed unchanged to multiple environments. For more information, see Create a dictionary.

A dictionary value can refer to another dictionary entry. This is accomplished by using the {{..}} placeholder syntax.

Example:

Key	Value
APPNAME	Deploy
MESSAGE	Welcome to {{APPNAME}}!

The value from the key MESSAGE will be "Welcome to Deploy!". Placeholders can refer to keys from any dictionary in the same environment.

If a dictionary is associated with an environment, by default, the values from the dictionary are applied to all deployments targeting the environment. You can restrict the dictionary values to deployments to specific containers within the environment or to deployments of specific applications to the environment. These restrictions can be specified on the dictionary's Restrictions tab. A deployment must meet all restrictions for the dictionary values to be applied.

note

An unrestricted dictionary cannot refer to entries in a restricted dictionary.

Dictionaries are evaluated in the order in which they appear in the GUI. The first dictionary that defines a value for a placeholder is the one that Deploy uses for that placeholder.

Dictionaries can also be used to store sensitive information by using encrypted entries. In this case all contained values are encrypted by Deploy. When a value from an encrypted entry is used in a CI property or placeholder, the Deploy CLI and GUI will only show the encrypted values. After the value is used in a deployment, it is decrypted and can be used by Deploy and the plugins. For security reasons, the value of an encrypted entry will be blank when used in a CI property that is not password enabled.

Containers

Containers are CIs that deployable CIs can be deployed to. Containers are grouped together in an environment. Examples of containers are: a host, WebSphere server, or WebLogic cluster.

Environments

An environment is a grouping of infrastructure items, such as hosts, servers, clusters, and so on. Environments can contain any combination of infrastructure items that are used in your scenario. An environment is used as the target of a deployment, allowing deployables to be mapped to members of the environment.

In Deploy you can define cloud environments, which are environments containing members that run on a cloud platform. Cloud environments are defined in specific plugins (example: Deploy AWS plugin ). For more information, see the cloud platform specific manuals.

Application deployment

The process of deploying an application installs a particular application version, represented by a deployment package, on an environment. Deploy copies all necessary files and makes all configuration changes to the target middleware that are required for the application to run.

Automated deployment plans

With Deploy, you are not required to create deployment scripts or workflows. When a deployment is created in Deploy, a deployment plan is created automatically. This plan contains all of the necessary steps to deploy a specific version of an application to a target environment.

Deploy also generates deployment plans when a deployed application is upgraded to a new version, downgraded to an old version, or removed from an environment (called undeploying).

When the deployment is performed, Deploy executes the deployment plan steps in the required order. Deploy compares the deployed application to the one that you want to deploy and generates a plan that only contains the steps that are required, improving the efficiency of application updates.

Deploy offers automated rollback functionality at every stage of the deployment.

For more information about the features that you can use to configure the deployment plan, see Preparing your application for Deploy.

Plan optimization

During planning, Deploy tries to simplify and optimize the plan. The simplifications and optimizations are performed after the ordinary planning phase.

Simplification is needed to remove intermediate plans that are not necessary. Optimization is performed to split large step plans into smaller plans. This provides a better overview of how many steps there are, and decreases the amount of network traffic needed to transfer the task state during execution.

Simplification can be switched on and off by switching the optimizePlan property of the deployed application from the Deployment Properties option. Turning this property off disables the simplification, but not the splitting of large plans.

• Simplification removes intermediate plans and does not remove steps. Example: If a parallel plan contains only one sub plan, the intermediate parallel plan is removed because there will not be anything running in parallel.
• Deploy scans all step plans and if any step plan contains more than 30 steps, it will be split up into serial plans that contain all steps from a specified order group.
• After splitting the step by order, the plan is scanned again for step plans that contain more than 100 steps. Those plans will be split into serial plans containing 100 steps each.

Parallel deployment

Deploy can run specific parts of the deployment plan in parallel. Deploy selects which parts of the plan will be executed in parallel during orchestration. By default, no plan will be executed in parallel. You can enable parallel execution by selecting an orchestrator that supports parallel execution.

Force Redeploy

At times you may want to just redeploy an already deployed application by merging and overriding the content without doing the delta analysis or cleanup. Such situations arise when you want to simply destroy/uninstall the existing deployed (application) and install the application again.

Select the Force Redeploy property (check box) of the deployed application from the Deployment Properties dialog box and do the deployment in such situations.

Note: The Force Redeploy feature is not supported for plugins that are used to deploy WAR type deployables—Tomcat and JEE plugins, for example.

Rollback

Deploy supports customized rollbacks of deployments that revert changes made by a failed deployment to the exact state before the deployment was started. Rollbacks are triggered manually via the GUI or CLI when a task is active and not yet archived. Changes to deployeds and dictionaries are also rolled back.

Undeploying an application

The process of undeploying an application removes a deployed application from an environment. Deploy stops the application and undeploys all its components from the target middleware.

Upgrading an application

The process of upgrading an application replaces an application deployed to an environment with another version of the same application. When performing an upgrade, deployeds can be inherited from the initial deployment. Deploy recognizes which artifacts in the deployment package have changed and deploys only the changed artifacts.

Control tasks

Control tasks are actions that you can perform on middleware or middleware resources. For example, a control task can start or stop an Apache web server.

A control task is defined on a particular CI type and can be executed on a specific instance of that type. When you invoke a control task, Deploy starts a task that executes the steps associated with the control task.

You can define control tasks in Java, XML, or by using scripts.

For more information, see Using control tasks in Deploy.