Popular Articles

The XebiaLabs DevOps Platform provides visibility and synchronizes data across the CI/CD pipeline by connecting issue tracking and ITSM ticketing tools, so that user stories and change tickets are always up to date.

Subscribe for more!

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:

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:

The 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:

Dave Roberts is a Senior Technical Consultant for XebiaLabs. He has worked on both sides of DevOps, as a web software engineer and as a WAS/DB2 administrator.

The Reality of Software Releases

Many organizations model software delivery as if the features that are initially planned for a release are always the features that are actually delivered to production when the release is done. But the reality of software releases is more complicated than that, because it’s hard to predict the delivery of planned features. The XebiaLabs DevOps Platform can help you deal with the reality of software releases. See for yourself!

Start Your Trial

The XebiaLabs DevOps Platform provides the intelligence, automation, and control that technical and business teams need.