Skip to main content
DevOps Image

This post is from the XebiaLabs blog and has not been updated since the original publish date.

Last Updated Dec 21, 2014 — DevOps Expert

Simplifying Life with XL Rules: Always Deploying an Artifact

DevOps

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.

One does not simply set it and forget it

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:

More from the Blog

View more
Mar 04, 2021

Getting key stakeholder buy-in for changes perceived as risky

DevOps
Organizational leaders must recognize that change is vital for the sur ...
Read More
Mar 01, 2021

Discover the change management practices that are ripe for optimization

DevOps
Change has become the most important part of modern digital product cr ...
Read More
Feb 22, 2021

Reckoning DevOps’ role in the enterprise value stream

DevOps
If you’re a software or digital solutions company, you may use DevOps ...
Read More
Feb 10, 2021

Customer spotlight: Schneider avoiding bumps in the road with DevOps adoption

DevOps
Everyone wants to deliver software faster and more reliably. Companies ...
Read More
Contact Us