- Docs Home
- Getting started
- XL Release
- Overview
- Installation
- Get started with XL Release
- Manage your installation
- Model your releases
- Release your software
- Release overview
- Create and start releases
- Configure release properties
- Schedule releases
- Start a release from an archived release
- Start a release from a template
- Start a release from another release
- Create a release from a Git repository
- Add a phase to a release or template
- Add a task to a phase in a release or template
- Import a release template
- Trigger releases
- Work with running releases
- Work with plugins
- Using reports
- Customize XL Release
- API and scripting overview
- Create custom task types
- Create custom configuration types
- Create custom trigger types
- Extend the XL Release GUI
- Declare custom REST endpoints
- Create custom tiles
- Create custom task types
- Create custom configuration types
- Using scheduling in scripts to connect to long running jobs
- Implement a custom failure handler
- Listen to XL Release events
- Configuration settings
- Release manuals
- XL Deploy
- Overview
- Installation
- Get started with XL Deploy
- Manage your installation
- Logging
- Start XL Deploy
- Shut down XL Deploy
- Back up XL Deploy
- Upgrade XL Deploy
- The XL Deploy repository
- Configure the repository
- Configure XL Deploy to fetch artifacts from a Maven repository
- Manage security
- Manage system settings
- XL Deploy configuration files
- Configure failover for XL Deploy
- High availability with master-worker setup
- Add, start, and use workers
- Configure active/hot-standby mode
- Configure the task execution engine
- Troubleshoot the Jackrabbit JCR repository
- Configure XL Deploy client settings
- Enable XL Deploy maintenance mode
- Update the XL Deploy digital certificate
- The XL Deploy work directory
- Reclaim disk space on an XL Deploy server
- Hide internal XL Deploy server errors
- Automatically purge packages according to a user-defined policy
- Automatically purge the task archive according to a user-defined policy
- Specify file encoding on the XL Deploy server
- Automatically archive tasks according to a user-defined policy
- Best practices for maintaining XebiaLabs tools
- Connect to your infrastructure
- Set up applications and environments
- Prepare your application for XL Deploy
- Create a deployment package
- Define application dependencies
- Configure an environment
- Using placeholders and dictionaries
- Working with deployment packages
- Preparing your application for XL Deploy
- Understanding deployables and deployeds
- XL Deploy manifest format
- Deprecated XL Deploy manifest format
- Using the XL Deploy Manifest Editor
- Understanding archives and folders in XL Deploy
- Add an externally stored artifact to a package
- Extend the external artifact storage feature
- Add a package to XL Deploy
- Export a deployment package
- XL Deploy for developers
- Tips and tricks for deployment packages
- Deploy an application
- Deployment overview
- Understanding the XL Deploy planning phase
- Steps and step lists in XL Deploy
- Understanding tasks in XL Deploy
- Deploy an application
- Use tags to configure deployments
- Preview the deployment plan
- Use orchestration
- Working with deployments
- Stopping, aborting, or canceling a deployment
- Schedule a deployment
- Update a deployed application
- Staging artifacts in XL Deploy
- Monitor and reassign deployment tasks
- Make previously deployed property values available in a PowerShell script
- Undeploy an application or deprovision an environment
- Perform canary deployments
- Perform dark launch deployments
- Perform hot deployments
- Deploying an externally stored artifact using the XL Deploy CLI
- Schedule or reschedule a task
- Using the deployment pipeline view
- Deploy to remote datacenters
- Get started with provisioning
- Introduction to the release dashboard
- Work with the CLI
- Work with plugins
- Create an XL Deploy plugin
- Base plugins and the deployed object
- Implement custom XL Deploy plugpoints
- Add a checkpoint to a custom plugin
- Step options for the Generic, PowerShell, and Python plugins
- Sample Java-based XL Deploy plugin
- XL Deploy plugin tutorial
- Standard plugins
- Middleware plugins
- Apache Tomcat
- BizTalk
- F5 BIG-IP
- GlassFish
- IBM WebSphere Application Server
- IBM WebSphere Process Server
- IBM WebSphere Liberty Profile Server
- IBM WebSphere MQ
- JBoss Application Server 5 and 6
- JBoss Application Server 7 and up
- Microsoft Internet Information Services
- Microsoft Windows
- NetScaler
- Oracle Service Bus
- Oracle Service-Oriented Architecture
- Oracle WebLogic Application Server
- Provisioning plugins
- Container platform plugins
- Tools
- Community plugins
- Using control tasks
- Using the explorer
- Using XL Deploy reports
- Customize XL Deploy
- Release manuals
- DevOps as Code
- Get started with DevOps as Code
- Install the XL CLI
- XL CLI command reference
- Work with the YAML format
- YAML snippets reference
- Manage values in DevOps as Code
- Track progress using XL CLI output
- Manage risk profiles
- Manage XL Deploy permissions in YAML
- Manage XL Release permissions in YAML
- Manage XL Release folder permissions in YAML
- Tutorial: Managing an XL Release template as code
- Blueprints
- API and CI references
- Plugins
- XL Release plugins
- XL Deploy plugins
- Standard plugins
- Middleware plugins
- Apache Tomcat
- BizTalk
- F5 BIG-IP
- GlassFish
- IBM WebSphere Application Server
- IBM WebSphere Process Server
- IBM WebSphere Liberty Profile Server
- IBM WebSphere MQ
- JBoss Application Server 5 and 6
- JBoss Application Server 7 and up
- Microsoft Internet Information Services
- Microsoft Windows
- NetScaler
- Oracle Service Bus
- Oracle Service-Oriented Architecture
- Oracle WebLogic Application Server
- Provisioning plugins
- Container platform plugins
- Tools
- Community plugins
- Videos
- Community
- Fix Trackers
- Archive
Add a step to a deployment plan using the Command plugin
For a deployment, XL Deploy calculates the step list based on your model. But what if you want to add an extra step? There are several ways to do this. This topic will explain a simple case: executing a remote shell command on a server.
In this example we will show how to add a step to log the disk usage using the df
command. We will do this using the Command plugin.
When to use the Command plugin
As said, you can add a step to the step list in several ways. Choosing the command plugin has the following implications:
- The command is part of a deployment, so the command must be mapped to the particular hosts you want to run it on.
- The command must be independent of the environment, since the same package (and command) may be deployed to multiple environments.
- This approach automatically scales to environments with one or more hosts (i.e. using the auto-map button, you get the disk usage of every host in the environment)
Setup
We will assume a simple setup for the PetClinic WAR, that will be deployed to a Tomcat server. When doing a deployment, we have the following steps.
To monitor the target server’s disk, we want to add a step that displays the output of the df
command at the end of the step list.
We will add this step in three stages:
- Use to UI to add a command to the application
- Test and refine the command
- Add the command to the Manifest file, so it will be packaged for subsequent versions of the application.
We will be adding the command using the Command Plugin. Make sure the command-plugin-X.jar
is copied to the plugins
folder of the XL Deploy Server home directory.
Adding the command in the UI
Go to the Repository tab, find the PetClinic-war under Applications, and right-click a version to add a new command. Select New > cmd > cmd.Command.
Name the command ‘Log Disk Usage’ and set the command line to df -H
.
Save the command.
Testing and refining the command
Go to the Deployment tab and start a deployment of the version you just added the command to. In our case, that would be deploying PetClinic war 1.0 to Tomcat.
Note that the command will be mapped to an Overthere Host, so make sure the environment you deploy to contains the overthere.SshHost
(or equivalent) Tomcat is running on.
When doing a deployment, we will see that the step has been added:
Don’t start the deployment just yet; we want to to move the step to the end, so we will see the disk usage after deployment.
The steps in the step list are ordered by weight. Plugins contribute steps with order values between 0 and 100. So if we want to move the step to the end of the list, we have to change the order value to 100.
Go to the Repository tab and open the Log Disk Usage command. Change Order to ‘100’ and save. Now redo the deployment and we will see that the step has moved:
When executing the deployment, we will see the output of the df
command in the logs:
Adding the command to the manifest
We did our changes in the UI, because it’s easier to see what’s going on and the development cycle (edit-test-refine) is faster. But now we want to make the changes more permanent, so other versions of the same application can use it as well. We do this by editing the Manifest.MF file, that is used to create the application package DAR file.
This is how the above example looks like in Manifest format:
Name: Log Disk Usage
CI-name: Log Disk Usage
CI-type: cmd.Command
CI-commandLine: df -H
CI-order: 100
You will need to add this snippet to your Manifest, so the next time you create a DAR package, the Log Disk Usage command is included.