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:
- XML Configuration Interface (xmlaccess)
- Portal Scripting Interface
- Release Builder
- pznload
- Syndication or export/import of content libraries
- wsadmin scripting
- ConfigEngine
- scp (or other remote file placement technology) for jar files
- WebDAV
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.
- portlets – xmlaccess (see WebSphere Portal and Maven)
- themes/skins – wsadmin AND xmlaccess
- portal screens – scp
- portlet services – scp AND wsadmin for registering REP/REE custom properties
- J2EE artifacts – wsadmin
- custom user registry
- credential vault adapters
- custom credentials
- JAAS login modules
- 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 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?