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.
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.
AWS CodePipeline is the Amazon Web Services continuous delivery service. It facilitates modelling and automation of the software release process.
You can specify multiple orchestrators for each deployment to achieve complex use cases.
This topic describes how to add and remove an extension on JBoss Plugin using Deploy server. It assumes you have the JBoss Domain plugin installed.
This topic describes how to configure and deploy the application by logging subsystem enabled on JBoss server using Deploy. It assumes you have the JBoss Domain plugin installed.
You can configure the following advanced Deploy client settings in /centralConfiguration/deploy-client.yaml. For more information, see Deploy Properties:
This topic describes how to configure system properties on JBoss server using Deploy. It assumes you have the JBoss Domain plugin installed.
In Deploy, deployment tasks are executed by dedicated worker instances. A Deploy master generates a deployment plan that contains steps that a Deploy worker's task execution engine will carry out to deploy an application. You can read more about masters and workers here
In Deploy you can create rules that define which steps should be included in a deployment plan. Each rule in the xl-rules.xml file defines a number of steps to add to the deployment plan. The available step primitives determine what kind of steps can be used. A step primitive is a definition of a piece of functionality that Deploy may execute as part of the deployment plan. For more information about Deploy rules, see Getting started with Deploy rules.
This topic describes how to configure an environment for running batch application and manage batch using the Batch-Jberet subsystem in JBoss DM plugin. It assumes you have the JBoss Domain plugin installed.
After you have installed Deploy and the IBM WebSphere plugin, log in to Deploy and follow these instructions to:
This tutorial describes how to deploy an application on Apache Tomcat. It assumes you have the Tomcat plugin installed.
This tutorial describes how to deploy an application on GlassFish. It assumes you have the GlassFish plugin installed.
This tutorial describes how to deploy an application on JBoss EAP 6 or JBoss AS/WildFly 7.1+. It assumes you have the JBoss Domain plugin installed.
After you have installed Deploy and the Microsoft IIS plugin, log in to Deploy and follow these instructions to:
This tutorial describes how to deploy an application on Oracle WebLogic. It assumes you have the Oracle WebLogic plugin installed. In this tutorial you will:
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.
This topic describes how to use the Deploy command-line interface (CLI) to deploy an artifact from a Maven repository such as Artifactory or Nexus. This tutorial uses this sample application. This is a WAR file that you can deploy to middleware such as Apache Tomcat or JBoss AS/WildFly.
After you have installed Deploy and the Microsoft IIS plugin, log in to Deploy and follow these instructions to:
A deployment consists of all actions needed to install, configure, and start an application on a target environment.
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.
A task is an activity in Deploy. When starting a deployment, Deploy will create and start a task. The task contains a list of steps that must be executed to successfully complete the task. Deploy will execute each of the steps in turn. When all of the steps are successfully executed, the task itself is successfully executed. If one of the steps fails, the task itself is marked as failed.
When you deploy, update, or undeploy an application, Deploy performs a dependency check, which may detect the following issues:
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.
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:
You can use the Deploy rules system and a PowerShell script to find and update the value of a previously deployed property with a new deployed property value.
You can use the Deploy health REST endpoint (/deployit/ha/health) with a GET or a HEAD request to check if the Deploy node is up and accessible.
The Deploy user interface includes a monitoring section that provides an overview of deployment tasks that are not archived. To access it, click Monitoring in the left pane.
In Deploy with the custom microservices deployment technologies, concurrent deployments are causing issues because of middleware limitations that allow only for a single deployment to be performed to the target at a given time.
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 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.
Using Deploy, you can schedule deployment tasks for execution at a specified moment in time. For more information, see scheduling tasks.
In Deploy you can schedule or reschedule a task for execution at a specified date in time. You can schedule or reschedule tasks that are in a PENDING or SCHEDULED state.
To ensure that the downtime of your application is limited, Deploy can stage artifacts to target hosts before deploying the application. Staging is based on the artifact Checksum property, and requires that the plugin being used to deploy the artifact supports staging.
A step is an action to be performed to accomplish a task. All steps for a particular deployment are grouped together in a steplist.
Stop a running deployment
The rules system works with the Deploy planning phase. You can use XML or Jython to specify the steps that belong in a deployment plan and how the steps are configured.
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.
To remove an application and its components from an environment, you need to undeploy the application. Similarly, to tear down a cloud-based environment provisioned by Deploy, you need to deprovision it.
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.
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.
Until the WAS plugin 9.8.x, application updates were performed by undeploying the previous application and then deploying the newer one. However, as of version 10.0.0, the WAS plugin provides you with distinct update strategies to undeploy, deploy or update an application.
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.
In Deploy, you can use the tagging feature to configure deployments by marking which deployables should be mapped to which containers. By using tagging, in combination with placeholders, you can prepare your deployment packages and environments to automatically map deployables to containers and configuration details at deployment time.
Deploy contains information about your applications, environments, infrastructure, and deployments. Using the reporting functionality, you can gain insight into the state of your environments and applications.
In Deploy you can view the deployment pipeline for an application or a deployment/provisioning package. In the deployment pipeline you can view the sequence of environments to which an application is deployed during its lifecycle. The deployment pipeline also allows you to see the data about the last deployment of an application to each environment. You must first define a deployment pipeline for each application you want to view.
Deploy uses the FreeMarker templating engine to allow you to access deployment properties such as such as the names or locations of files in the deployment package.
You can view the history of successful deployments of application versions to an environment. This is useful when you want to determine placeholder value changes between versions for an environment, determine who made a specific change, and to support deployment rollbacks.