WebSphere

 

Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows

 

Staging the portal to production

Deploying IBM® WebSphere® Portal Express in your business requires careful planning, a significant commitment of time, and involves many phases of deployment and system topologies. This topic discusses common phases of deployment.

 

Phases of deployment

This section introduces some common deployment phases and examines their differences. Use this information to determine which phases are needed for the deployment of WebSphere Portal Express in your business. Some common phases of deployment are:

  1. Proof of concept and demonstration phase

  2. Development of applications and portlets phase

  3. Integration and staging phase

  4. Production phase

 

Proof of concept and demonstration phase

This phase is used to determine and validate the direction of your WebSphere Portal Express deployment. During this phase, examine and test the functions and features of WebSphere Portal Express in order to decide how you can best use WebSphere Portal Express to help accomplish your business goals.

Summary:

 

Development of applications and portlets phase

During this phase, applications, portlets, and the portal's look and feel are developed for your WebSphere Portal Express solution. This development process is based upon the results of your findings from the proof of concept and demonstration phase, and can include modification of existing applications and creation of entirely new portal applications.

Summary:

 

Integration and staging phase

During this phase both new and existing applications and portlets are fully tested before they are deployed as part of the WebSphere Portal Express solution.

Summary of integration:

Summary of staging:

 

Production phase

During this phase, tested applications and portlets are migrated to the production environment.

Summary:

 

System topologies

typical development, integration, and staging systems arrangement

This diagram shows a typical development, integration, and staging systems arrangement. It covers all roles of systems that are involved in the development, integration, and staging process for WebSphere Portal Express.

The actual number of systems will vary for different enterprises, depending on the size of the portal project and the quality processes in place. It is expected that multiple systems with identical roles (for example, multiple integration systems, one for each development or project team) are used to better support larger teams. Another reason for using more systems is splitting the individual roles of the system at a finer level granularity (for example, load test and production preparation might be performed on different systems to better support the team divisions in an enterprise). The difference in the actual number of systems involved at a given customer site and the number of systems described here does not change the staging process and tools.

 

Development System

The development system is typically a simple portal installation. This system is not clustered and does not have security enabled. This system is used by portlet developers, portal developers, and portal designers.

Questions Answers
What type of installation is this? Simple installation, usually a single machine
Is this system part of a cluster? No
Is security enabled? No
Where is portal configuration data stored? Local database. Not connected to actual business user repositories
Where is portal user data stored? Local database. Not connected to actual business user repositories
Who uses the system?

  • Portlet developers

  • Portal developers and designers

development system

 

System Requirements

 

Process

Prerequisite: Development system is physically installed and loaded with a supported operating system.

  1. Install WebSphere Portal Express (including basic configuration)

  2. No additional configuration is required

 

Results

Portal is installed for use as a Development system.

 

Integration System

The integration system is typically a simple portal installation. This system is usually not clustered. An external database might be used, and external security management systems may be configured. Security is usually enabled.

Questions Answers
What type of installation is this? Simple installation, usually a single machine
Is this system part of a cluster? No
Is security enabled? Yes and possibly with external security management systems
Where is portal configuration data stored?

Remote database. Use same database software as would be used in production, however this can be a staged database.

Where is portal user data stored?

Remote user registry. Use same user registry software (such as database or LDAP) as would be used in production, however this can be a staged user registry.

Who is the system used by?

  • Portlet developers

  • Portal developers and designers

integration system

The integration system needs access to all user IDs of administrative users and to all user groups. This can be achieved by pointing the integration system to the same user directory as the production system, or by copying these users and groups from the production user directory into the user directory that is used by the integration system. Passwords do not need to be identical for these systems. The XML configuration interface might be used to copy the administrator user IDs and the user groups. If the amount of data to be copied is large, using LDAP for data replication is the preferred choice.

Using different user IDs for administrators and user group names in the production system and the integration system requires additional steps in the staging process and makes the process more complicated.

 

System Requirements

 

Process

Prerequisite: Integration system is physically installed and loaded with a supported operating system.

  1. Install Portal Product (including basic configuration)

  2. Run appropriate config tasks to configure the portal

 

Results

Portal is installed for use as Integration system.

 

Staging System

The staging system operational model is derived from the production system operational model. Typically they are using the same operating system and comparable hardware platforms. The staging system is usually smaller in size than the production system, but the applied operational architecture building blocks are the same as for the production system. These two systems need to be as comparable as possible from an operational perspective. Usually the production system as well as the staging system use an external database, and both systems have security enabled. If the production system is clustered, the staging system is also clustered. If the production system uses external security management, the staging system also uses external security management. If the production system uses an external HTTP server (or reverse proxy) the staging system should also use an external HTTP server (or reverse proxy). If the production system infrastructure is separated by firewalls, the staging system should also be separated by identically configured firewalls.

The staging system needs access to all user IDs of administrative users and to all user groups. This can be achieved by pointing the staging system to the same user directory as the production system, or by copying these users and groups from the production user directory into the user directory that is used by the staging system. Passwords do not need to be identical for these systems. However, it is recommended to use a copy of the production user directory for the staging system. Using a copy of the user directory prevents load tests performed on the staging system from impacting the production system. A dedicated test user directory allows for a clear separation of test users and production users. Usually the test user population should be the same size as the expected user community of the portal. The XML configuration interface might be used to copy the administrator user IDs and the user groups. If the amount of data to be copied is large, using LDAP for data replication is the preferred choice.

Using different user IDs for administrators and user group names in the production system and the staging system requires additional steps in the staging process and makes the process more complicated.

Questions Answers
What type of installation is this? Production-like installation
Is this system part of a cluster? If the production target environment is clustered
Is security enabled? Yes, with an approved user registry
Where is portal configuration data stored?

Remote database. Use same database as production.

Where is portal user data stored?

Remote user registry. Use same user registry (such as database or LDAP) as is used in production.

Who uses the system?

  • Portal administrators

  • Portal and portlet developers

staging system

 

System Requirements

 

Process

Prerequisite: Staging system is physically installed and loaded with a supported operating system.

  1. Install WebSphere Portal Express (without demonstration portal and portlets)

  2. Run configuration tasks to configure the portal (these are the same tasks run on a production system)

 

Results

WebSphere Portal Express is installed for use as a staging system.

 

Production System

The production system operational model is the most complex operational model among the different systems described in this document. Usually production systems use an external database and have security enabled. Production system operational models include consideration of system availability, therefore clustering and other techniques that increase the system availability are implemented. External security management might also be used depending on the security policies in place in your environment. Production systems usually use external HTTP servers (or reverse proxy). Firewalls are used to protect sensitive data and processing nodes.

Questions Answers
What type of installation is this? Production installation
Is this system part of a cluster? Yes, if clustering is being used
Is security enabled? Yes, with an approved user registry
Where is portal configuration data stored?

Remote database. Use production database.

Where is portal user data stored?

Remote user registry. Use production user registry (such as database or LDAP).

Who uses the system?

  • Portal administrators

production system

 

System Requirements

 

Process

Prerequisite: Production system is physically installed and loaded with a supported operating system.

  1. Install Portal Product (without demonstration portal and portlets)

  2. Run configuration tasks to configure the portal.

  3. Additional steps typically performed on production systems:

    1. Establish backup routines to allow node recovery in case of failures.

      1. Database backups (all configuration and data databases)

      2. File System Backups (all portal product files and portal solution files)

    2. Integrate Portal into system monitoring infrastructure.

 

Results

WebSphere Portal Express is installed for use as a production system.

 

Parent topic:

Planning considerations

 

Related concepts
Planning considerations