Release Management for WebSphere Portal - a discussion

WPLC

Release
Management
WebSphere Portal

© 2009 IBM Corporation

http://www.flickr.com/photos/destinysagent/2259321835/

Lotus Software – WPLC – Federal

Objectives
 Release Management
– Release artifacts
– The tools
– XMLAccess
– Release Builder
– Site Management Portlet
– Release creation
– Build creation

2 © 2009 IBM Corporation


Components of a Release – Portal Config
 Portal configuration (does not include end-user customizations)
– Portal Content Tree (Navigation, Pages, Layouts)
– URL Mappings
– Portlet Application Configurations
– Portlet Application Settings
– Portlet Configurations
– Portlet Settings
– Portlet Data (legacy portlets)
– Portlet Preferences (JSR168 portlets)
– Access Control Data (Roles, ActionSets)
– Credential Data
– Themes
– Skins
– Cross-page wires


Components of a Release – Portal Artifacts
 Portal artifacts
– Portal System Configuration (property files)
– Themes and Skins (JSP files and stylesheets)
– Portal Customizations (Java Classes)
– Portlet services, Active Credentials, Credential Vault
Adaptors
– Portlet Code (Java Classes, JSPs, XML files)
– Portal Filters (Java Classes)
– Servlet Filters (Java Classes)
– J2EE Artifacts (managed by WebSphere Application Server)
– Shared Libraries


Components of a Release – Other Artifacts
 Portal Extension Artifacts
– Portal Search and search collections
– Web Content Management
– Document Repository
– Documents, flows, roles
– Collaboration Components

 External Artifacts
– Application data
– Surfaced applications (ex. WPAI integrated apps)



Managing Release Components



Portal Artifacts - Considerations
 Property files (ConfigEngine)
– Should not be copied as they are environment specific
 Service properties (modified with WAS Admin Console)
– Make the changes in the target environment using the same
process used in the source environment
 Themes and Skins (JSPs and CSS)
– Manually transfer and deploy it
 Portlet Code (WAR file)
– Manually transfer to the target location



The Tools
 XML Access: generates a snapshot of the portal’s
configuration as an XML file.
– Represents the configuration data stored in the portal
database
– Syntax example:
xmlaccess.bat –in infile.xml –user wpsadmin –pwd
wpsadminpwd –url http://portalhost:10040/wps/config -out
outfile.xml
–out outfile.xml

 Release Builder: Compares two XML Access files to
create a differential XML script
– Syntax example:
releasebuilder.bat –inOld REL-0.xml –inNew REL-1.xml –out
DIFF.xml


The Tools (cont.)
 Site Management Portlet: GUI interface to manage and
publish/promote/demote pages
– Run ConfigEngine
enable-http-basic-
auth-tai-sitemgmt



Building the Initial Release
 Source Server (Staging)
– Install WebSphere Portal
– Build initial release
– Export release (REL-0) using XMLAccess
 Target Server (Production)
– Install WebSphere Portal
– Run ConfigEngine empty-portal
– Copy source WARs, themes/skins, etc. over
– Import initial release using XMLAccess
– Run ConfigEngine.bat activate-portlets
– Restart the cluster


Building Subsequent Releases
 Source Server (Staging)
– Build the new release
– Export release (REL-N) using XMLAccess
– Create the differential configuration using Release Builder
– Compare REL-N with REL-(N-1) to create DIFF

 Target Server (Production)
– Copy source WARs, themes/skins, etc. over
– Import DIFF configuration using XMLAccess
– Run ConfigEngine.bat activate-portlets
– Restart the cluster


Portlet Deployment
 Copy the portlet application WAR
– Identify the portlet application’s folder from the source
machine
– Ex. C:IBMW ebSpherewp_profilePortalServerdeployed
archivePA* (where PA* is the application folder)
– Copy the folder to the corresponding archive directory on the
target machine.
– Use XMLAccess to deploy and transfer the settings

 WAR install location can be changed
– Can be a file server (the portlet source is a url)
– Requires <url> locations for portlets to be updated in the
XMLAccess file



Deploying New Themes and Skins
 Package the theme/skin into a WAR file
 Deploy the WAR file using the WebSphere
Administrator’s Console
– Map the module to the Portal server/cluster
– Start the application
 Register the theme/skin with Portal
– Use the sample DeployThemeFromWebModule.xml script to
register the new theme
– A Themes and Skins portlet is provided
– Can be used to register theme



Updating Existing Themes/Skins
 Locate the Enterprise Application entry in the
WebSphere Administrator’s console
 Update it
– Replace the entire application
– Specify the path to the replacement WAR
– Specify the context root
– Map the module to the Portal server/cluster



Updating the Default Portal Themes/Skins
 Export the WebSphere Portal EAR file, wps.ear.
– If the environment is clustered, the WebSphere Portal EAR must be exported from the Deployment Manager.
 Create a temporary directory to store the ear file.
 Export the wps.ear to the temporary directory
– wsadmin.bat -user admin_user_id -password admin_password -c "$AdminApp export wps directory/
wps.ear"
 Create a subdirectory in the directory created above called wps_expanded subdirectory.
 Use the EARExpander tool to expand the contents of the exported EAR file:
– EARExpander.bat -ear directorywps.ear -operationDir directorywps_expanded -operation expand
 Place the updated themes and skins JSPs into the correct directory within the expanded EAR.
For example:
– HTML themes go in directory/wps_expanded/wps.war/themes/html
– HTML skins go in directory/wps_expanded/wps.war/skins/html
 Delete the original the wps.ear file from the directory where you initially exported it.
 Use the EARExpander command to collapse the EAR directory back into an EAR file:
– EARExpander.bat -ear directorywps.ear -operationDir directorywps_expanded -operation collapse
 Use the wsadmin command to update the WebSphere Portal EAR.
– For a managed cell (with or without a cluster), perform this step on the deployment manager machine.
– wsadmin.bat -user admin_user_id -password admin_password -c "$AdminApp install directory/wps.ear {-
update -appname wps -nodeployejb}"
 Restart WebSphere_Portal Server. In a cluster configuration, restart the cluster to resynchronize
the nodes.



Enabling JSP Reloading to Test Themes/Skins
 Only enable on development and test servers
 Edit the wp_profile/config/cells/cell_name/applications/
wps.ear/deployments/wps/wps.war/WEB-INF/ibm-web-
ext.xmi:
<. . . xmi:id="IBM_W PS_Ext" reloadInterval="3“
reloadingEnabled=“true" fileServingEnabled="true"
directoryBrowsingEnabled="false“
serveServletsByClassnameEnabled="false"
preCompileJSPs="false">

 In non-clustered test environments, can simply update
the expanded files in wp_profileinstalledAppscellname
wps.earwps.war
– No need to update the master configuration ear in this case



Best Practices for Version Control and
Build Scripts
– Consider the use of a Version
Control System to be mandatory. – Apache Ant is the defacto standard
– Version Control is not archiving – Build scripts are needed, do not let modern
IDE’s fool you!
– Never go to sleep with un- – Use separate build process for:
committed changes – Development/Debugging – Use RAD’s
incremental compiling and integrated Unit
– Use a consistent directory Test Environment to minimize turnaround
times during development
structure – For release/deployment and all
– Enables reuse of build scripts “official builds” – Use Apache Ant for a
robust, reproducible and automated
– Do not use CVS when starting a process with minimal dependencies/
requirements on the local workstation
new project: Subversion (or if you – Externalise all parameters that are
are lucky: Rational Clearcase) environment specific into ”environment
profiles”
– Revision control everything – It’s – Avoid having to compile different ”packages”/
deployment units for each target environment
not just for Java code – defer the selection of target environment to
the moment of installation.
– Include the build tools and all
external dependancies



Apache Ant is not Just for Compiling Version Control

R scr
Java Code

e le ip
as t
Development env

e-
 Build scripts: Transform source code into Source code (in a
broad meaning) Build scripts )
Compiled code
executables/deployables (e.g. jar/war-filer)

 Release scripts: Fetch contents from

Release-script
Version Control, invoke Build Scripts and
assemble installation package
 Installation scripts: Ant controls the Target env (portal)
deployment, delegating to other tools (etc Installation
xmlaccess, wsadmin, bash when needed). WebSphere Portal
Installation
package (compiled
code, environment
Scripts
config and
installation scriipts )

Continuous Integration
when you can build, test and deploy your solution with a “single click” – why not automate the
 Assemble all components
“click”
of your solution often to get Evaluate new Integration Test
Check out latest code, Continous Integration
build, test and deploy Server (Cruisecontrol or
a true view of progress version Environment
new version Rational BuildForge)

and to avoid nasty
Rapport Status (e.g, email, sametime or
integration surprises lava lamp) for c
h an g e
s

 Integration takes time – but Li st en
Version Control System
it will take less time the Commit code (Subversion eller
Rational Clearcase)
more often you do it
 Requires a high degree of
20 automation © 2009 IBM Corporation


WebSphere Portal – A Configuration Management Challenge

Many kinds of artifacts compared Publishing or Installing Requirements for Config Mgmt –
Don’t forget to formulate them
two ways to think about deployment
to traditional J2EE development  Important input to sizing and
Multiple tools and technologies atrchitecture
(xmlaccess, wsadmin, syndication, Installation
Staging Package – Impact on which test- and
file copy, shell scripts) staging environments are
needed
Customers have very different

publish

Install
– Ask if multiple releases be
requirements, expectations and under development in
needs parallell (e.g, deployment of
Difficult to create a cook book bugfixes during a major
solution. Balance agility and control. Target enhancement)?
Production
Environment  Which process or workflow governs
Update process Artifacts
each type of release

Content Creation
 Workflow driven (publishing) or C ontent Managem ent

Portal
Shared
Jars
Enterprise
applications
software process driven Process 1 – Editorial Content (2hours)

Portal Administration
(wpsadmin)
Page
Structure
Portal
(installation) release
philosophy?
Process 2 – Business Content (1 day)
Page Personaliz
WCM Structure, ation Rules

Infrastructure
Configuration
Design compo
 What kind of portal do you
Themes
Access
Control
Search
Config
Portal have? D evel opm ent
and Skins
– Application-driven
Java Programming Process 3 – Simple Portlets (1 week)

Custom
Portlets
Third Party
portlets
Static
Content  Installation
End user Process 4 – Transactional Portlets (6 weeks)
personalization
Portlet
Services
End user
preferences
– Content-driven
WCM-

...
content Publicering Process 5 – Portal Configuration (1 day)



Possible model for Configuration/Release Management
Requirements Analysis Team Release Management Team
Analyses incoming requirements from Controls release process
stakeholders recieves delivery from development
Identifies Releases Express Manages Issue Trackling system Express
Release Release Release Release
Selects appropriate Release Process Release Records test results and acceptance Release
#3 #1 #3 #1
(based on criteria specified by #2 Coordinates releases of different #2
development team and others parties) systems

Release Scope #1 Release
Release Scope #2 #3
Release Scope #3
Release
#1 Production Zone
Development Zone
Compile Release Package based on VCS contents

Operations Team
Install Releases and
System Test Zone Monitor System
WCM Design and Portal
Test Team Production Env
Integration Test Env Structure Development
performs formal
and Test
testing, installs

Content

Design
(Master)
Content

Design
System Test Env
Customers

Content

Design
Local Dev 1

Published, Automatic

Published, Automatic
Local Dev 2
XML Access Export
Local Dev 3
Manual/All
Development Team
Owns code base
Does All programming
Authoring Env

(Master)
Content

Design
Portal All, Automatic
Business SImple
Global Portal Layout
Portlet Portlet
Services Structure (Theme/ Internal Users /
Projects Projects
Skin) All, Automatic Content Authors

Manual / Published
Version Control Repository (Controlled by Dev team)


Release Management for WebSphere Portal - a discussion

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (17)

Plus de Chris Sparshott

Plus de Chris Sparshott (20)

Dernier

Dernier (20)

Release Management for WebSphere Portal - a discussion