Staging to production overview

Portal solution release

The WebSphere Portal installation and the initial software component configuration create a generic runtime environment for Portal Artifacts...

• portlets
• servlets
• page definitions
• web content

A solution release consists of application payload data...

• content trees
• page layouts
• access control lists
• credential vault configurations
• concrete portlets

User configurations belong to only one user and include...

• Implicit derived pages
• Private user pages
• Portlet data
• Credential data (private or shared but not system scoped)

Initial and differential release

1. The web content dev environment is where the following information is developed:
   • Presentations
   • Authoring templates
   • Taxonomies
   • Content libraries
   • Content components such as personalization components
   • Personalization rules

2. The Portal dev environment is where the following information is developed:

   • Portlets
   • Extensions
   • Themes
   • Applications

3. Use the rendering environment to test the rendering of the web content and portal development artifacts together. Developers might have access to this environment to test their code.

4. Use the preproduction environment to test everything on a cluster configuration that mirrors the live cluster. Only the administrators have access to this environment.

5. Authoring and rendering environments are implemented on separate machines. This configuration allows use to independently test the performance of both systems. This environment is the same deployment environment as the production environment.

6. The production cluster environment is the live web site cluster.

7. The authoring environment is where content developers and editors develop new content and content updates for the site.

The initial release

The initial solution release has to move all artifacts from the source portal to the staging target, which is assumed to be empty. An empty portal does not hold any application payload. The Full-Release 1.0 is an example for this process. There are procedures in place to allow a clean portal installation and to prepare it as target for an initial staging step. Depending on the set of artifacts deployed on the source, multiple tools are required to export the artifacts from the source and import them to the target.

The xmlaccess.sh script allows us to export and import the portal page and navigation definitions. The definitions are exported into an XML file that holds all the definitions.

Once the initial release is deployed to the production system, users access the system and can create additional user data such as customization and other data. Typically a initial release contains the following data:

• Libraries to the application server needed by the applications and extension
• WAR or EAR files to the application server that may contain custom extensions or themes and skins
• Portlet WAR files
• IBM Web Content Manager libraries
• The initial portal content in an XML file format created with the XMLAccess tool
• Personalization rules

The differential release

A differential release holds only the changes and not the complete release and is created by comparing two release exports from the same environment. ReleaseBuilder is the tool that helps with this task.

Difference refers to differences in release configurations, including configuration entities that have been removed, added, or changed compared to the previous release.

A release for a virtual portal

A virtual portal shares several resources with the main portal installation, especially all code artifacts and the JVM. When deploying a portal solution release to a virtual portal, these types of artifacts must not be deployed again. Redeploying can break references in other virtual portals. Shared resources must only be deployed to the master portal. To strip off the shared resources from an XML file, use the Release Builder tool in the virtual portal mode.

Portal application archive (PAA)

Each type of artifact can be..

1. exported
2. moved to the target
3. imported independently

However, there is a common archive format that performs the same tasks. Place all artifacts into the right location inside the archive file. Copy the PAA file to the target and then use the Solution Installer to deploy it.

For an initial release, the archive file contains all the artifacts defined above. Additional custom components require special handling. The PAA file can be augmented by custom actions that modify the behavior of the Solution Installer as required.

Syndication

Syndication allows the business users to define the content of the Portal Site using an Authoring system. They can then synchronize the content structure, navigation, and web content documents between the authoring system and the production system. Thus syndication is another way to stage changes from the authoring system to the production system. It defines the source and target of the syndication. The artifacts are moved in the direction from source to target only. Because the business users do the management, the artifacts that can be syndicated are limited to the less critical ones not having the potential to crash the server. Contrary to the PAA process where the release data can be placed on a medis that can be moved between the systems, syndication uses an online approach to move changes from one system to another. Thus syndication requires a connection between the systems.

Syndication can be set up between main or virtual portals on different systems or on the same portal system. Because the syndicated pages refer to portlets using the ID of the portlets, an initial staging needs to take place before syndication can be used.

Parent: Staging to production