- 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
Writing Jython scripts for XL Deploy
Jython scripting is a very powerful way to extend or customize XL Deploy. There are several components of XL Deploy that can use such scripts and, although each of them puts different objects on the context of scripting engine, there are some general rules and good practices for writing, organizing, and packaging your scripts.
Pointing to a Jython script from configuration files
Usually when you attach a Jython script to an XL Deploy action, event, or component, you specify a relative path to it. In this case, the only way XL Deploy can find this script is by attaching the path to the each segment of its own classpath and looking there.
If you have a configuration snippet such as ... script="myproject/run.py"...
, then XL Deploy can find the script at ext/myproject/run.py
because the ext
folder is on the classpath.
Also, the script can be packaged into a JAR and placed in the plugins
folder; XL Deploy scans it at startup and adds the JARs it finds to the classpath. In this case, the JAR archive in this case should contain the myproject
folder and run.py
script.
Creating a JAR
Different tools create JARs differently, so it is important to verify that the file paths in the plugin JAR do not start with ./
. You can check this with jar tf yourfile.jar
. If you package two files and a folder, the output should look like:
file1.xml
file2.xml
web/
And not like:
./file1.xml
./file2.xml
web/
Splitting your Jython code into modules
It is possible to split your code into modules. Note that:
- You have to create an empty
__init__.py
in each folder that becomes a module (or a segment of a package name). - Start the package name with something unique, otherwise it can clash with other extensions or standard Jython modules. For example,
myproject.modules.repo
is a better name thanutils.repo
.
Let’s imagine we have the following code in run.py
:
# myproject/run.py
infrastructureCis = repositoryService.query(None, None, "Infrastructure", None, None, None, 0, -1)
applicationsCis = repositoryService.query(None, None, "Applications", None, None, None, 0, -1)
# do something with those cis
You can create a class that helps perform queries to the repository and hides unnecessary parameters.
# myproject/modules/repo.py
class RepositoryHelper:
def __init__(self, repositoryService):
self._repositoryService = repositoryService
def get_all_cis(self, parent):
ci_ids = self._repositoryService.query(None, None, parent, None, None, None, 0, -1)
return map(lambda ci_id: self._repositoryService.read(ci_id.id), ci_ids)
Then, in run.py
, you can import and use RepositoryHelper
:
# myproject/run.py
from myproject.modules import repo
repository_helper = repo.RepositoryHelper(repositoryService)
infrastructureCis = repository_helper.get_all_cis("Infrastructure")
applicationsCis = repository_helper.get_all_cis("Applications")
# do something with those cis
The contents of the folder and JAR archive will then be:
myproject
myproject/__init__.py
myproject/run.py
myproject/modules
myproject/modules/__init__.py
myproject/modules/repo.py
Using third-party libraries from scripts
In addition to your own scripts, you can use:
- Third-party Python libraries
- Third-party Java libraries
- Your own Java classes
In each of this cases make sure then they are available on the classpath in the same manner as described for your own Jython modules.
Best practices during development
Develop in directories, run in JARs
While developing and debugging scripts, it is convenient to keep the files open in the editor and change them after every iteration. After you have finished development, it is recommended to package them into a JAR file and place it in the plugins
folder.
Restarting the server
Normally there is no need to restart the server after changing a Jython script; however, modules are cached by the scripting engine after their first execution. To avoid this effect, you can use built-in reload()
function.
from myproject.modules import repo
reload(repo)
# ...
Examples
You can find an example of scripting in the UI extension demo plugin, which is available in the samples
folder of your XL Deploy installation.