Skip to main content

Digital Transformation

Release Management for WebSphere Portal

Releasing your portal project to a brand new environment can be a fairly large challenge.

I maintain the reason for the challenge is that there are so many tools and procedures required for this process. It is difficult to find somebody on your team that has deep administrative experience coupled with a development background so that communication with the developers can occur with maximum efficiency during the mad rush to production that many teams experience. There will often be one or more developers on the team who are only familiar with packaging and deploying these artifacts using RAD/Eclipse or some other Integrated Development Environment (IDE) toolset. I maintain that a release manager should struggle to maintain the maxim that nothing ever goes to production without a script.

Consider the fact that your portal project will require several of these tools for deployment:

Each one of these toolsets is feature rich and complicated. Your release manager generally has to rely on the reference material published in the various infocenters and the IBM forums that address questions in these areas. These tools also change at a fairly rapid pace. Finally some tools do not have remote execution capability (which makes automation from a single machine more difficult).

The most recent advice from IBM concerning this topic is published in a DeveloperWorks article named IBM WebSphere Portal Version 6.0 staging scenarios using ReleaseBuilder.

I want to draw attention to the WebSphere Portal artifacts not covered by ReleaseBuilder and Items that cannot be staged with ReleaseBuilder sections that contain 9 portal artifacts and 4 other items for a combined total of 13 items that are not addressed by the recommended strategy. The more recent Manual steps prior to using ReleaseBuilder lists 10 portal artifacts and 17 environment configurations for a combined total of 27 items that require attention. Now let’s analyze these lists to come up with a comprehensive strategy.

The checklists for portal artifacts differ by one because one list combines themes/skins while another lists them separately.

These additional portal artifacts are listed separately because I wish to classify them as security configurations that some portal teams may not need to be aware of. This category of items generally involves placing jar files in a specific location and registering them with the server through REP/REE custom properties.
  • custom user registry
  • credential vault adapters
  • custom credentials
  • JAAS login modules
The next list combines portal hosted artifacts and adds a few of my own categories based on newer capabilities of WPS 7.x:
  • wcm content – syndication OR export/import of content libraries
  • pzn rules – pznload
  • wcm jsp component files – wsadmin (package as WAR file and reference as contextPath;jspPath in WCM)
  • iWidgets – wsadmin AND ConfigEngine
  • WebSphere Portlet Factory (WPF) portlets – ant
I will start addressing all these items in a series of posts that aim to use maven and some Continuous Integration (CI) server like Hudson to automate and document this complicated topic.

Thoughts on “Release Management for WebSphere Portal”

  1. I am not sure if you have worked on or are interested in release management for small to medium web startups that use PHP, Ruby or Pythong platform. Because I am looking for experts on release management for web applications and websites, then I found your website.

    I am now building a release management software and I would like to kindly receive your expertise feedback on the software by trying the beta version. Therefore, could you please visit the project website: http://www.ngashint.com and join the beta user list?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Kevin StClair

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram