Release Management for WebSphere Portal - a discussion

WPLC

© 2009 IBM Corporation

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

Release ManagementWebSphere Portal

2

Lotus Software – WPLC – Federal


Objectives

Release Management– Release artifacts

– The tools– XMLAccess– Release Builder– Site Management Portlet

– Release creation

– Build creation

3



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

4



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

5



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)

6



7



Managing Release Components

8



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 itPortlet Code (WAR file)

– Manually transfer to the target location

9



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

http://portalhost:10040/wps/config -out outfile.xml



10



The Tools (cont.)

Site Management Portlet: GUI interface to manage and publish/promote/demote pages

– Run ConfigEngineenable-http-basic-auth-tai-sitemgmt

11



12



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

13



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

14



Portlet Deployment

Copy the portlet application WAR– Identify the portlet application’s folder from the source

machine– Ex. C:\IBM\WebSphere\wp_profile\PortalServer\deployed

\archive\PA* (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

15



Deploying New Themes and Skins

Package the theme/skin into a WAR fileDeploy the WAR file using the WebSphere

Administrator’s Console– Map the module to the Portal server/cluster

– Start the applicationRegister 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

16



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

17



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 directory\wps.ear -operationDir directory\wps_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 directory\wps.ear -operationDir directory\wps_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.

18



Enabling JSP Reloading to Test Themes/Skins

Only enable on development and test serversEdit the wp_profile/config/cells/cell_name/applications/

wps.ear/deployments/wps/wps.war/WEB-INF/ibm-web-ext.xmi:

<. . . xmi:id="IBM_WPS_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_profile\installedApps\cellname\wps.ear\wps.war

– No need to update the master configuration ear in this case

19



Best Practices for Version Control and Build Scripts

– Consider the use of a Version Control System to be mandatory.

– Version Control is not archiving– Never go to sleep with un-

committed changes– Use a consistent directory

structure– Enables reuse of build scripts

– Do not use CVS when starting a new project: Subversion (or if you are lucky: Rational Clearcase)

– Revision control everything – It’s not just for Java code

– Include the build tools and all external dependancies

– Apache Ant is the defacto standard– Build scripts are needed, do not let modern

IDE’s fool you! – Use separate build process for:

– Development/Debugging – Use RAD’s incremental compiling and integrated Unit Test Environment to minimize turnaround times during development

– For release/deployment and all “official builds” – Use Apache Ant for a robust, reproducible and automated process with minimal dependencies/requirements on the local workstation

– Externalise all parameters that are environment specific into ”environment profiles”

– Avoid having to compile different ”packages”/deployment units for each target environment – defer the selection of target environment to the moment of installation.

20



Continuous Integrationwhen you can build, test and deploy your solution with a “single click” – why not automate the “click”

Apache Ant is not Just for Compiling Java Code Build scripts: Transform source code into

executables/deployables Release scripts: Fetch contents from

Version Control, invoke Build Scripts and assemble installation package

Installation scripts: Ant controls the deployment, delegating to other tools (etc xmlaccess, wsadmin, bash when needed).

Commit codeVersion Control System

(Subversion eller Rational Clearcase)

Continous Integration Server (Cruisecontrol or

Rational BuildForge)

Check out latest code, build, test and deploy

new version

Evaluate new version

Integration Test Environment

Rapport Status (e.g, email, sametime or lava lamp)

Listen for changes

Assemble all components of your solution often to get a true view of progress and to avoid nasty integration surprises

Integration takes time – but it will take less time the more often you do it

Requires a high degree of automation

Target env (portal)

Development envSource code (in a broad meaning) Build scripts) Compiled code

(e.g. jar/war-filer)

Version Control

Release-script

Installation package (compiled code, environment

config and installation scriipts )

Release-script

WebSphere Portal Installation Scripts

21



WebSphere Portal – A Configuration Management Challenge

Themes and Skins

Custom Portlets

Enterprise applications

Third Party portlets

WCM Design

Portal Page

Structure, compo

Portal Page

Structure

Shared Jars

Portlet Services

Search Config

Static Content

WCM-content

Personalization Rules

End user preferences

Java Programming

Portal Administration (wpsadmin)

Infrastructure Configuration

Content Creation

Portal

End user personalization

Access Control

ArtifactsUpdate process

. . .

Install

Installation Package

Target Environment

publish

Staging

Production

Requirements for Config Mgmt – Don’t forget to formulate them

Important input to sizing and atrchitecture

– Impact on which test- and staging environments are needed

– Ask if multiple releases be under development in parallell (e.g, deployment of bugfixes during a major enhancement)?

Which process or workflow governs each type of release

Many kinds of artifacts compared to traditional J2EE development

Multiple tools and technologies (xmlaccess, wsadmin, syndication, file copy, shell scripts)

Customers have very different requirements, expectations and needs

Difficult to create a cook book solution. Balance agility and control.

Workflow driven (publishing) or software process driven (installation) release philosophy?

What kind of portal do you have?

– Application-driven Installation

– Content-driven Publicering

Publishing or Installingtwo ways to think about deployment

Process 5 – Portal Configuration (1 day)

Process 3 – Simple Portlets (1 week)

Process 4 – Transactional Portlets (6 weeks)

Process 2 – Business Content (1 day)

Process 1 – Editorial Content (2hours)

Content Management

Development

22



Possible model for Configuration/Release Management

Production Env

System Test Env

Version Control Repository (Controlled by Dev team)

Business Portlet

Projects

SImple Portlet

Projects

Portal Structure

Portal Layout

(Theme/Skin)

Global Services

Local Dev 1

Local Dev 2

Local Dev 3

Integration Test EnvWCM Design and Portal Structure Development and Test

System Test Zone

Authoring Env

Production Zone

Con

tent

Des

ign

Cont

ent

(Ma s

ter)

Des

ign

Cont

ent

Desi

gn

(Mas

ter)

Con

tent

Des

ign

All, Automatic

All, Automatic

Manual/All

Manual / Published

Publ

ishe

d, A

utom

atic

Publ

ishe

d, A

utom

atic

XML Access Export

Express Release

#2

Release Management TeamControls release processrecieves delivery from developmentManages Issue Trackling system Records test results and acceptanceCoordinates releases of different systems

Release #3

Development ZoneCo

mpi

le R

elea

se P

acka

ge b

ased

on

VCS

cont

ents

Customers

Internal Users / Content Authors

Test Teamperforms formal testing, installs

Operations TeamInstall Releases and Monitor System

Release #1

Express Release

#2

Release #3

Release #1

Release #3

Release #1

Development TeamOwns code baseDoes All programming

Requirements Analysis TeamAnalyses incoming requirements from stakeholdersIdentifies ReleasesSelects appropriate Release Process (based on criteria specified by development team and others parties)

Release Scope #1

Release Scope #3Release Scope #2

23



Release Management for WebSphere Portal - a discussion

Business

Transcript of Release Management for WebSphere Portal - a discussion