Best practices for rules
This topic provides examples of best practices to use when writing Deploy rules.
Before you start to write rules, ensure that you look at the open source plugins in the Deploy/Replace community to understand naming conventions used in synthetic.xml
and xl-rules.xml
files.
Types of operations that are required
At a minimum, a rules-based plugin should contain CREATE
rules, so that Deploy executes actions during a deployment.
You need to include DESTROY
rules to update and undeploy deployeds. You can perform an update using a DESTROY
rule followed by a CREATE
rule and you can use MODIFY
rules to support more complex update operations.
Using a namespace
To avoid name clashes between plugins that you have created or acquired, you can use a namespace for your rules based on your company name. For example:
<rule name="com.mycompany.xl-rules.createFooResource" scope="deployed">...</rule>
Using unique script names
You can use step types to refer to a script by name. Deploy will search for the script on the full classpath. This includes the ext/
folder and the conf/
folder, inside JAR files, and so on. Ensure that scripts are uniquely named across all of these locations.
Some steps search for scripts with derived names. For example, the os-script
step will search for my script
, myscript.sh
, and myscript.bat
.
Referring from a deployed
Do not refer from one deployed to another deployed or container. They are difficult to set from a dictionary.
Increasing logging output
To view more information during the planning phase, you can increase the logging output:
- Open
XL_DEPLOY_SERVER_HOME/conf/logback.xml
for editing. - Add a statement:
<logger name="com.xebialabs.deployit.deployment.rules" level="debug" />
<logger name="com.xebialabs.deployit.deployment.rules" level="trace" /> - Use the
logger
object in Jython scripts.