30 docs tagged with "package"

To deploy an application with Deploy, you must supply a deployment package. It contains the files (artifacts) and middleware resources that Deploy can deploy to a target environment.

Artifacts are the physical files that make up a specific version of an application. For example, an application binary, configuration files, or web content. When adding an artifact to a deployment package, you can either:

In Deploy, you can define dependencies among different versions of different applications. When you set up the deployment of an application, Deploy automatically includes the correct versions of other applications that it depends on. You define dependencies at the deployment package level.

In Deploy, you can define dependencies among different versions of different applications. When you set up the deployment of an application, Deploy automatically includes the correct versions of other dependent applications. Application dependencies work with other Deploy features such as staging, satellites, rollbacks, updates, and undeployment. You define dependencies at the deployment package level.

There are specific characteristics about how Deploy handles archive artifacts (such as ZIP files) and folders. In Deploy's Unified Deployment Model (UDM) type hierarchy, there are two base types for deployable artifacts:

You can create a package retention policy (policy.PackageRetentionPolicy) that retains the deployment packages based on the configured regular expression. Deployed packages are never removed by the package retention policy. If a deployed package is part of the packages identified for removal, then it will be skipped, with no impact on other packages.

This topic describes how to fetch artifacts from a Maven repository. You can access artifacts stored in a Maven repository using the fileUri property of Deploy artifacts. To use this feature, you must configure the Maven repositories that Deploy will search for artifacts.

Creating a Deploy package via Ant is possible using the jar task.

To enable continuous integration, Deploy can work with Jenkins CI server through the Jenkins Deploy plugin. The plugin supports:

To enable continuous deployment, the Deploy Maven plugin enables you to integrate Deploy with the Maven build system. For more information, see Deploy Maven plugin.

You can use the command line to create a deployment package (DAR file) that can be imported into Deploy. This example packages an application called PetClinic that consists of an EAR file and a resource specification.

To complete this tutorial, you must have your Deploy infrastructure and environment defined, and have added or imported an application to Deploy. For more information, see Connect Deploy to your infrastructure, Create an environment in Deploy, and Import a package instructions.

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.

The manifest file included in a deployment package (DAR file) describes the contents of the archive for Deploy. When importing a package, the manifest is used to construct CIs in Deploy's repository based on the contents of the imported package. The format is based on XML.

The Deploy database is called the repository. It stores all configuration items (CIs), binary files - such as deployment packages, and Deploy security configuration - such as user accounts and rights. By default, Deploy uses an internal database that stores data on the file system. This configuration is intended for temporary use and is not recommended for production use. In production environments, the repository is stored in a relational database on a external database server. For more information, see using a database.

The Deploy: Understanding Packages video describes deployables—files and settings, delivered in a deployment package, that your application needs to run—and deployeds—the things that are actually created in your target servers as part of a deployment.

A deployment consists of all actions needed to install, configure, and start an application on a target environment.

When importing a package, Deploy scans the artifacts contained in the package for placeholders that need to be resolved during a deployment. You can turn off placeholder scanning using one of the following methods described in this topic.

Export a deployment package (DAR file) using the Deploy GUI

Artifacts are the physical files that make up a specific version of an application. For example, an application binary, configuration files, or web content. When adding an artifact to a deployment package, you can either:

When you deploy, update, or undeploy an application, Deploy performs a dependency check, which may detect the following issues:

Suppose you are doing a deployment where one of the deployables is a file.Folder or any type derived from this. As part of the deployment, placeholders will be replaced in each of the files contained in the folder, and then the files are transferred to a temporary directory on the target host before moving them to their final deployment destination.

This topic describes using a CI tool plugin to interact with Deploy. However, as a preferred alternative starting with version 9.0, you can utilize a wrapper script to bootstrap XL CLI commands on your Unix or Windows-based Continuous Integration (CI) servers without having to install the XL CLI executable itself. The script is stored with your project YAML files and you can execute XL CLI commands from within your CI tool scripts. For details, see the following topics:

When you create a Deployment Package, name is a mandatory field. It can take various formats depending on the need but it is recommended to follow a standard naming convention so that the Deploy application can sort them the way you want.

Deploy uses the Unified Deployment Model (UDM) to structure deployments. In this model, deployment packages are containers for complete application distribution. These include application artifacts (EAR files, static content) and resource specifications (datasources, topics, queues, and others) that the application requires to run.

When you update a deployed application, Deploy resolves the properties for the deployeds in the application in the same way that it does for the initial deployment of the application. This means:

This topic provides some helpful tips and tricks to use when managing deployment packages.

In Deploy, you do not need to manually create a delta package to perform an update, the Deploy auto-flow engine calculates the delta between two packages automatically. For more information, see what's in an application deployment package.

Placeholders are configurable entries in your application that will be set to an actual value at deployment time. This allows the deployment package to be environment-independent and reusable. At deployment time, you can provide values for placeholders manually or they can be resolved from dictionaries that are assigned to the target environment.

The Deploy Manifest Editor is an open source, stand-alone tool for Microsoft Windows that helps you create valid deployit-manifest.xml files for your deployment packages.