Best Practices for Rules
This topic provides examples of best practices to use when writing Deploy rules.
This topic provides examples of best practices to use when writing Deploy rules.
In Deploy you can create rules that define which steps should be included in a deployment plan. Each rule in the xl-rules.xml file defines a number of steps to add to the deployment plan. The available step primitives determine what kind of steps can be used. A step primitive is a definition of a piece of functionality that Deploy may execute as part of the deployment plan. For more information about Deploy rules, see Getting started with Deploy rules.
When you want to create a custom deployment step, you can use Java to implement the Step interface. For more information, see Javadoc API documentation.
Deploy rules allow you to use XML or Jython to specify the steps that belong in a deployment plan and how the steps are configured.
Deploy features a modular architecture that allows you to change and extend components while maintaining a consistent system. This is a high-level overview of the system architecture:
You can disable any rule that is registered in the Deploy rule registry, including rules that are:
The Database plugin uses the Deploy rules system to provide improved rollback support for SQL scripts.
When preparing a deployment, Deploy must determine which steps to take for the deployment, and in what order. This happens in three phases:
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 Deploy figures out how to install the components in a target environment using rules. Rules are used to teach the Deploy execution engine how to generate your deployment steps in a scalable, reusable, and maintainable way.
You can use the Deploy rules system and a PowerShell script to find and update the value of a previously deployed property with a new deployed property value.
When you define an XML or script rule in Deploy, you use expressions or scripts to define its behavior. These are written in Jython, a combination of Python and Java.
A Stitch rule is a customization rule that can either transform the content of the provided configuration file or generate it. A rule comprises of conditions (the 'when') and processors (the 'how').
The rules system works with the Deploy planning phase. You can use XML or Jython to specify the steps that belong in a deployment plan and how the steps are configured.
To execute commands as part of a deployment:
Deploy rules enable you to use XML or Jython to specify the steps that belong in a deployment plan and how the steps are configured. Several Deploy plugins include predefined rules that you can use when writing rules. For more information on rules, see Get started with rules.
You can define new step primitives by using predefined step primitives such as jython and os-script. These are called step macros. After you define a step macro, you can refer to it by name, as you refer to a predefined step. You can reuse built-in steps and customize them for your system. Step macros can include one or more parameters of any valid Deploy type.
Deploy uses the FreeMarker templating engine to allow you to access deployment properties such as such as the names or locations of files in the deployment package.
A script rule adds steps and checkpoints to a plan by running a Jython script that calculates which steps and checkpoints to add.
The Deploy rules system enables you to use XML or Jython to specify the steps that belong in a deployment plan and how the steps are configured. For more information, see Get started with rules and Writing script rules.