Every non-trivial implementation of WebSphere Portal (are there any trivial ones?) will need some degree of automation, mostly around release management. Most customers have three or more portal environments: Development, Production, and one or more in the middle. In the last few years, we’re seeing a greater demand for Disaster Recovery environments as well. Promoting code and other portal assets through these environments from development to production isn’t a trivial task.
There are a number of different ways to tackle the problem, but the solution that is right for your environment will depend on a few things:
- What individual or team will do the actual deployments? Does it change in each environment? What is their skill level?
- What are your most frequently changing assets? WCM content, page configurations, custom portlet code, pure Java EE applications, something else?
- What is the initial budget for automation (as always)? Keep in mind that automation, done properly, will save time and prevent errors long-term.
- Do you already have scripts or processes and just need to fill some gaps, or are you starting from scratch?
- Do you need to just deploy to one vendor’s products (e.g. IBM), or do you also need to manage deployments to other application servers, portals, etc?
Unfortunately, the technique to move each Portal-related asset from environment to environment is different. Here are some, but not all, of the asset types and deployment techniques for them:
- Portlet applications – scp to primary node, then deploy to WAS or Portal, and run XMLAccess to activate
- EAR or WAR files to WebSphere AppServer – scp file to the Deployment Manager, then use wsadmin or hot deployment.
- WCM content – syndication (either manual or automatic)
- Portal pages, layouts, etc – XMLAccess, ReleaseBuilder, Site Management functionality
- Portal Configuration (properties stored in WAS) – wsadmin
- Themes and skins – deploy as WAR to WAS, register via XML; Redeploy wps.ear
We have built and extended various solutions over the years, and we’ve seen a many IBM customers do the same. While a number of products have come out in recent years to try to address this issue, many customers still attempt to build their own solution. The custom-built solutions are typically command-line only, have a limited number of features, and have to be maintained by the 1 or 2 people who created it. If the original author left the company, the solution often sits idle or even dies when the infrastructure upgrades to a new version of WAS or Portal.
You have two high-level options:
- Buy + customize. Your “buy” options today are:
- BMC BladeLogic Application Release Automation (was Phurnace)
- IBM Rational Automation Framework for WebSphere (RAFW)
- Xebia Labs Deployit
- Nolio
And there may be others that are harder to find. It’s likely that none of those will be perfect for your needs, but they should still save you significant effort overall, and they are all supported by more than just the scripting wizard in your infrastructure team. So it’s definitely worth evaluating those tools before choosing to…
- Build it all. This will involve some combination of wsadmin (Jython usually), wpscript, XMLAccess, ReleaseBuilder, scp/ssh, Ant, and other commands at your disposal. You should also consider a command execution framework such as STAF, Fabric, or Capistrano.
I hope you weren’t looking for an easy answer. When this question came up 2+ years ago, build-your-own was almost always the best option. The companies I mentioned above have made a lot of progress since then, so now I typically recommend to investigate them first and build only the pieces that they do not address.
Let me know if you have any opinions on this. I’d also love to hear about any horror stories you have around this topic.
