More Related Content
More from Chris Sparshott (20)
Release Management for WebSphere Portal - a discussion
- 1. WPLC
Release
Management
WebSphere Portal
© 2009 IBM Corporation
http://www.flickr.com/photos/destinysagent/2259321835/
- 2. 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
- 3. Lotus Software – WPLC – Federal
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
3 © 2009 IBM Corporation
- 4. Lotus Software – WPLC – Federal
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
4 © 2009 IBM Corporation
- 5. Lotus Software – WPLC – Federal
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)
5 © 2009 IBM Corporation
- 7. Lotus Software – WPLC – Federal
Managing Release Components
7 © 2009 IBM Corporation
- 8. Lotus Software – WPLC – Federal
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
8 © 2009 IBM Corporation
- 9. Lotus Software – WPLC – Federal
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
9 © 2009 IBM Corporation
- 10. Lotus Software – WPLC – Federal
The Tools (cont.)
Site Management Portlet: GUI interface to manage and
publish/promote/demote pages
– Run ConfigEngine
enable-http-basic-
auth-tai-sitemgmt
10 © 2009 IBM Corporation
- 12. Lotus Software – WPLC – Federal
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
12 © 2009 IBM Corporation
- 13. Lotus Software – WPLC – Federal
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
13 © 2009 IBM Corporation
- 14. Lotus Software – WPLC – Federal
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
14 © 2009 IBM Corporation
- 15. Lotus Software – WPLC – Federal
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
15 © 2009 IBM Corporation
- 16. Lotus Software – WPLC – Federal
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
16 © 2009 IBM Corporation
- 17. Lotus Software – WPLC – Federal
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.
17 © 2009 IBM Corporation
- 18. Lotus Software – WPLC – Federal
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
18 © 2009 IBM Corporation
- 19. Lotus Software – WPLC – Federal
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
19 © 2009 IBM Corporation
- 20. Lotus Software – WPLC – Federal
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
- 21. Lotus Software – WPLC – Federal
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)
21 © 2009 IBM Corporation
- 22. Lotus Software – WPLC – Federal
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)
22 © 2009 IBM Corporation