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 Jan 07, 2015 — DevOps Expert

Updating WAS Applications In XL Deploy

DevOps

Some users of WebSphere Application Server prefer to upgrade their EAR/WAR applications using WAS's "update-in-place" option instead of uninstalling it and then re-installing. The latter, of course, is XL Deploy's default behavior, but it can be changed with a simple tweak to a type definition in an XML file.  Here is a look at how the WAS Admin Console presents these options:

[caption id="attachment_8397" align="alignnone" width="300"]WAS Admin Console showing Install, Uninstall and Update options The WAS Admin Console offers Install, Uninstall and Update options (among others) for managing Enterprise Applications[/caption] But before we describe the tweak, let's take a closer look at XL Deploy's analysis of a deployment. Each artifact or resource is compared against what is already out on the target server, if anything.  Then XL Deploy assigns one of four possible actions: create, destroy, modify or noop. Noop, of course, is no-operation, for the case of no changes. XL Deploy has pre-defined behavior for create and destroy when working with EAR/WAR files, and invokes a python script for each of these. Expanding the WAS plugin JAR file reveals these as deploy-application.py and undeploy-application.py. But the operation that pertains to this scenario is modify: the user wants to replace an EAR or WAR with an upgraded version. As there is no specific "modify" behavior defined, XL Deploy executes a destroy and then a create operation, first uninstalling the old module and then subsequently installing the new one, as in steps 2 and 4 in this deployment steplist:Uninstall-Re-install-DeploymentThe result is a "clean" installation -- nothing is carried over from the previous installation of the app, and this is a good way to fight configuration drift. However a user who wants complex applicaton configuration settings carried forward will want to opt for update-in-place even if this approach violates the spirit of XL Deploy's design philosophy -- any deployment package be a complete incaranation of the application that is deployable to any environment, whether a first-time deployment or update. To override the modify behavior, we simply define a modifyScript property on the War or Ear type:
<type-modification type="was.WarModule">
 <property name="modifyScript" default="demo/update-application.py" hidden="true" description="Replace an entire installed application" />
</type-modification>
and then we build the script in the location given, using wsadmin's scripting language and a couple of handy resources supplied via the "deployed" object:
# demo/update-application.py
AdminApp.update(deployed.name, 'app', '[-operation update -contents %s ]' % deployed.file)
And now the update step replaces the uninstall/re-install behavior:UpdateDeployment

More from the Blog

View more
May 06, 2021

Use Value Stream Management to release apps with confidence

DevOps
Many companies worldwide use a blend of DevOps and agile methods to he ...
Read More
Agile or DevOps on Its own Is not enough
Apr 23, 2021

Agile or DevOps on Its own Is not enough

DevOps
As every company becomes a software company, it becomes increasingly i ...
Read More
Mar 16, 2021

Does successful change management require DevOps?

DevOps
Around the world, digital product providers are looking to reduce dysf ...
Read 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
Contact Us