How deployments are executed
XL Deploy is a model-driven deployment solution. Users declaratively define the artifacts and resources that they need to deploy in a package, which is a ZIP file with a
deployit-manifest.xml file, and XL Deploy figures out how to install the components in a target environment using rules. Rules are used to teach the XL Deploy execution engine how to generate your deployment steps in a scalable, reusable, and maintainable way.
You define rules once and XL Deploy applies them intelligently, based on what you want to deploy and where you want to deploy it. From the user’s perspective, there is no distinction between deploying an application to a single server, clustered, load-balanced, or datacenter-aware environment. XL Deploy will apply the rules accordingly.
Deployment involves the creation, destruction, or modification of artifacts on your middleware infrastructure. These changes have side effects such as execution order, restart strategies, error handling, retrying from a failed step, deployment orchestration (such as parallel, load-balanced, canary, and blue-green deployments), rollback, access control, logging, and so on.
The XL Deploy execution engine captures the generic nature as well as the side effects of the deployment. Rules take advantage of these states and side effects to contribute steps to the deployment.
You can think of rules as a way to create intelligent, self-generating workflows. They are used to model your required deployment steps without requiring you to scaffold the generic nature of the deployment, which is usually the case with workflows created by hand.
When deploying to or configuring systems, you need to perform actions such as uploading a file, deleting a file, executing commands, or performing API calls. The actions have a generic nature that can be captured in a few step types.
XL Deploy provides a collection of predefined step types that you can use in your rules. Once a rule is executed, the rule will contribute steps to the deployment plan. For more information, see Step reference and Use a predefined step in a rule.
For example, if you had to configure a Microsoft Windows service, you could use the predefined Powershell step to execute your desired script. XL Deploy will automatically pass the script all of the deployment parameters and execute it on the target Windows host.
$serviceName = $deployed.serviceName $displayName = $deployed.serviceDisplayName $description = $deployed.serviceDescription Write-Host "Installing service [$serviceName]" New-Service -Name $serviceName -BinaryPathName $deployed.binaryPathName -DependsOn $deployed.dependsOn -Description $description -DisplayName $displayName -StartupType $deployed.startupType | Out-Null
The above script will create or update the service. Its associated rule definition would be:
<rule name="sample.InstallService" scope="deployed"> <conditions> <type>demo.WindowsService</type> <operation>CREATE</operation> <operation>MODIFY</operation> </conditions> <steps> <powershell> <description expression="true">"Install $deployed.name on $deployed.container.name"</description> <script>sample/windows/install_service.ps1</script> </powershell> </steps> </rule>
The same pattern can be used for other types of integrations. For example:
- If you need to run a batch or bash script to encapsulate your deployment logic, you could use the OS-Script step.
- If you have complex logic that requires the power of a language, you could use the Jython step to code Python to handle the step logic.
For more information, see XL Deploy rule tutorial.
You can package a group of related rules in an XLDP file and install it in XL Deploy. These are referred to as plugins. For more information, see install a plugin. XL Deploy includes predefined rule sets for technologies such as WebSphere, WebLogic, JBoss, IIS, and so on. Other reusable rule sets can be found in the XebiaLabs community. You can reuse these rules, or refer to them as examples when creating your own rules.