Using Deployment Tags in XL Deploy

XL Deploy’s tagging mechanism provides a handy way to control the automated mapping of deployable object to their containers. When your environment has multiple containers of a particular type, and multiple deployables that can map to them, XL Deploy will perform a deployment for each possible mapping. A good example is this: you have two jee.War files in your deployment package, and two GlassFish domains in your environment. This will result in a deployment plan of four steps, as each WAR file is deployed to each domain.

But if you intended that WAR “A” should go to domain1 and WAR “B” should go to domain2, then this is the perfect use case for tagging. Simply place a tag on each deployable and container, and then the artifacts will be deployed accordingly. A tag is nothing more than a text string: “A” and “B” would be perfectly functional in this respect, but of course you’d want something more descriptive. Wildcarding is also possible.
Within the XL Deploy GUI, tags are a set of strings under the “Deployment” tab on a container or a deployable. Inside the deployment manifest, tags appear as a series of values in this fashion:

 
  
   
    TAG1
    TAG2
    ...
   
   ...
  
 

Tagging also comes in handy when working with xl-rules to contribute additional steps to your deployment.
Let’s use a simple example: we’re deploying a cmd.Command script object to two hosts in same environment, and we want to have xl-rules contribute a second script to only one of the hosts. Our hosts here are WAS85ND-host and WAS85SA-host.
First, let’s define a rule in xl-deploy-server/ext/xl-rules.xml:

 planning/add-rules-contributed-script.py

Next, define a Python script in the location you specified as the planning-script-path.  This script has decision-making logic about what steps to add to the deployment plan.

# xl-deploy-server/ext/planning/add-rules-contributed-script.py
from java.util import HashSet
def containers():
 result = HashSet()
 for _delta in deltas.deltas:
  if (_delta.operation != "NOOP"):
   for mem in deployedApplication.environment.members:
    if str(mem.type) == "overthere.SshHost":
     if 'RUN_RULES_CONTRIBUTED_SCRIPT_HERE' in mem.tags:
  result.add(mem)
 return result
for container in containers():
 context.addStep(steps.os_script(
  description = "Run rules-contributed script",
  order = 55,
  script = "scripts/demo/rulesContributedScript",
  freemarker_context = {'container' : container},
  target_host = container)
)

Finally, define the script to be executed, referenced by the script keyword in the context.addStep() method:

# xl-deploy-server/ext/scripts/demo/rulesContributedScript.sh.ftl
echo Running rulesContributedScript.sh on ${container.name}

Note that here we can use a property of the object we inserted into the FreeMarker context.
When we map the deployment we get the two scripts from the cmd.Command objects, one for each host.
 
And we see the step contributed by our rule as the third step in the step list.  The ordering is controlled by the order value we specified, in this case 55.The correct execution of the script contributed by our rule is confirmed by the output:

Creating path ssh:sudo://vagrant:root@10.10.10.85:22/tmp/ot-20141218T182927390/working.directory.tmp/scripts/demo on host Infrastructure/WebSphere/WAS85ND-host
Processing freemarker template scripts/demo/rulesContributedScript.sh.ftl to /tmp/ot-20141218T182927390/working.directory.tmp/scripts/demo/rulesContributedScript.sh
Executing /tmp/ot-20141218T182927390/working.directory.tmp/scripts/demo/rulesContributedScript.sh on host Infrastructure/WebSphere/WAS85ND-host
Running rulesContributedScript.sh on WAS85ND-host

You can view the complete reference for tagging at