This preview shows page 102 - 105 out of 150 pages.
AdministratorOperatorDeveloper WorkbenchPortal CustomizationPortal LayoutPortlet DevelopmentPage DefinitionEntitlement DefinitionUnit Test
Chapter 4. Deploying, testing, and maintaining a portal 91Determining what to moveTo deploy a portal release, resources must be synchronized, packaged, and deployed to a portal server. This is a manual process that involves many people and few tools. Resources can be:Portal configuration (this is stored in the portal database):–Portal content tree–Portal application configuration, settings, and data–Portlet access control informationPortal artifacts (these are stored in the file system):–Portal configuration (property files)–Theme and skin file assets (JSPs, style sheets, images)–Portlet code (Java classes, JSPs, XML files)4.3.1 Automating custom code deploymentAlthough there is no automated method to move portal applications from one environment to another, there are two options:Completely replace the old release with a new release. The drawbacks of this option is that any data that was customized by the user is lost. Although this option works, we do not recommend it.Use the XMLAccess tool to load incremental or differential releases.4.3.2 Staging conceptsA subsequent solution release is staged from the integration to the staging and to the production system. The physical implementation of configuration staging through a series of systems does not really move these configurations between systems. This process is based on repeatable modifications of portal solution releases on multiple systems. For each solution release, a differential portal solution configuration is imported into the system; artifacts are managed manually by manual updates and deletions.What elements of the portal you move depends on the type of release you have. If you have an incremental release, you:Add new resources to a release.Update resource attributes (only add properties to lists).If you have a differential release, you:Maintain all functionality of the incremental release.Delete existing resources.Update resource attributes (add or delete properties in lists).If you have data that has been configured by the user, configure the scope of the portal for a single user. The following process (Figure 4-4 on page 92) is an example of a possible subsequent portal solution staging process. Derivations of this process are possible and expected. It focuses on configuration and artifact management.Important:You must define and test your application deployment process.
92WebSphere Portal Best PracticesFigure 4-4 A subsequent portal solution staging process4.3.3 Clustering and deploymentIn WebSphere Application Server, a cluster is composed of multiple identical copies of an application server. A cluster member is a single application server in the cluster. WebSphere Portal is installed as an enterprise application server within the WebSphere Application Server infrastructure. All of the clustering features available within the WebSphere Application Server infrastructure are also available and apply to WebSphere Portal. Therefore, a