Simplifying Life with XL Rules: Always Deploying an Artifact

The addition of XL Rules to XL Deploy was meant to simplify the way that you treat deployable artifacts and the logic behind their deployment. The following is an example of converting a deployment process from before version 4.5, to one that’s taking advantage of 4.5’s new feature set.

Note: It may be a good activity to look through your deployment process and see where XL Rules may help you as well!

This issue’s origin was more process oriented than anything, but as we all know you can’t change your business process overnight. Your deployment logic may need to be the one to bend while the business side can be reevaluated. Continuous Delivery and DevOps require a constant reevaluation of your release continuum; it’s not a Ron Popeil style “Set it, and forget it!” code-rotisserie.

In this example, we have a fairly straight forward IIS application deployment. We’re defining the Application Pool specification, the Website Specification, and copying over its Web Content. The issue that arose is that there is another set of Web Content that’s pulled in from another source after the code has been built. During the deployment, this sub directory of Web Content is overwritten but not deployed again since XL Deploy thinks it has not changed, which is true. There were three options I came up with in this scenario:

• Modify the IIS plugin to ensure that directory is not removed, or is at least backed up and redeployed
• Create a custom type that will always deploy the Web Content after the original Web Content has been deployed
• Modify the existing deployment process to utilize XL Rules to always deploy the artifact

The first option seems like overkill, the second required a little work but did not affect anything globally, and the third is just…easier. I like easy, but let’s go over the hard way first... First, we modify our <XLD_SERVER>\ext\synthetic.xml file to create a new type. This will require a server restart.

<type type="file.DeployedWebConfigFolder" extends="generic.ExecutedScriptWithDerivedArtifact" deployable-type="file.WebConfigFolder">
    <generate-deployable type="file.WebConfigFolder" extends="generic.Folder"/>
    <property name="targetDirectory" hidden="false"/>
    <property name="createTargetDirectory" kind="boolean" default="true" hidden="false"/>
    <property name="createOrder" kind="integer" default="60" hidden="true"/>
    <property name="createVerb" default="Copy" hidden="true"/>
    <property name="createScript" default="IIS/DeployWebConfigFolder" hidden="true"/>
    <property name="noopOrder" kind="integer" default="60" hidden="true"/>
    <property name="noopVerb" default="Copy" hidden="true"/>
    <property name="noopScript" default="&lt;#if deployed.alwaysRun!false&gt;IIS/DeployWebConfigFolder&lt;/#if&gt;" hidden="true"/>
    <property name="alwaysRun" kind="boolean" default="true" hidden=”false”/>
</type>

If you look at the following line:

<property name="noopScript" default="&lt;#if deployed.alwaysRun!false&gt;IIS/DeployWebConfigFolder&lt;/#if&gt;" hidden="true"/>

As you can see, we added some freemarker in to check the alwaysRun property to see whether it should be deployed every time or not. This is not required, but would allow the user to decide whether or not they want this action to be performed. We then have the script that is calling (IIS/DeployWebConfigFolder.bat.ftl) to run a copy command within Windows:

echo "Copying Web Config Files(${deployed.file}) to ${deployed.targetDirectory}"
xcopy ${deployed.file} ${deployed.targetDirectory} /E /Y

Now the easy method using XL Rules… First, we still need to define a new type within <XLD_SERVER>\ext\synthetic.xml. The XL Rules system still depends on the type system to create a deployment workflow, but gives you more powerful ways to do it, along with not having to restart the server at all.

<type type="iis.PublishedWebContentNoop" extends="udm.BaseDeployedArtifact" deployable-type="iis.WebContentNoop" container-type="iis.Server">
    <generate-deployable type="iis.WebContentNoop" extends="udm.BaseDeployableFolderArtifact"/>
    <property name="targetPath" hidden="false" required="true" />
</type>

We have defined the framework of the artifact and told the system how it should be mapped, but now we need to give it actions to perform during a deployment. To do that, we edit <XLD_SERVER>\ext\xl-rules.xml.

<rule name="iis.PublishedWebContentNoop.ALWAYS" scope="deployed">
    <conditions>
        <type>iis.PublishedWebContentNoop</type>
        <operation>CREATE</operation>
        <operation>MODIFY</operation>
        <operation>NOOP</operation>
    </conditions>
    <steps>
        <upload>
            <artifact expression="true">deployed</artifact>
            <target-host expression="true">deployed.container.host</target-host>
            <target-path expression="true">deployed.targetPath</target-path>
            <create-target-path>true</create-target-path>
            <order>55</order>
            <description>Rule based always copy WebContent step</description>
        </upload>
    </steps>
</rule>

Using the built-in ‘upload’ step-type, we can use it to copy the artifact without writing any scripts. This also means we don’t need to worry about having scripts for different types of targets. Hopefully this was of use to everyone that is, or has, recently upgraded from versions 3.x and 4.0 of XL Deploy. Rules can be very powerful and this was the equivalent of dipping your toe into the pool. I dare you to jump in and enjoy the waters of XL Rules…and remember, don’t “set it, and forget it”! Here are some additional resources to find out more about XL Rules:

• XL Rules Tutorial
• XL Rules Manual
• XL Rules Steps Reference