Best practices for rules

This topic provides examples of best practices to use when writing XL Deploy rules.

Before you start to write rules, ensure that you look at the open source plugins in the XebiaLabs 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 XL 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. XL 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.

Note: 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:

  1. Open XL_DEPLOY_SERVER_HOME/conf/logback.xml for editing.
  2. Add a statement:

    <logger name="com.xebialabs.deployit.deployment.rules" level="debug" />
    <logger name="com.xebialabs.deployit.deployment.rules" level="trace" />
  3. Use the logger object in Jython scripts.