Getting key stakeholder buy-in for changes perceived as risky
DevOps
Organizational leaders must recognize that change is vital for the sur ...
Read MoreThis post is from the XebiaLabs blog and has not been updated since the original publish date.
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.<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="<#if deployed.alwaysRun!false>IIS/DeployWebConfigFolder</#if>" hidden="true"/> <property name="alwaysRun" kind="boolean" default="true" hidden=”false”/> </type>If you look at the following line:
<property name="noopScript" default="<#if deployed.alwaysRun!false>IIS/DeployWebConfigFolder</#if>" 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 /YNow 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: