Deploy your portal

 

Phases of deployment

Phases of deployment include:

  1. Proof of concept and demonstration
  2. Development of applications and portlets
  3. Staging and testing
  4. Production

 

Proof of concept and demonstration phase

This phase is used to determine the direction of your deployment. During this phase, experiment with the functions and features of WebSphere Portal.

  • Use sample applications provided with WebSphere Portal

  • Use sample themes and skins provided with WebSphere Portal

  • Use the WebSphere Portal development environment

  • Portlet developers and portal developers should be involved in this phase

 

Development of applications and portlets phase

This phase is used to develop applications and portlets to connect your users to your business. This often involves working with existing applications and creating new applications.

  • Create new applications and a new appearance for your portal

  • Work with existing applications

  • Unit test applications and appearance

  • Use the WebSphere Portal development environment

  • Portlet developers and portal developers are involved in this phase

 

Integration and staging (testing) phase

This phase is used to test both new and existing applications and portlets before making them available to your users.

  • Transfer applications and appearance from the development environment to the integration environment

  • Perform integration, function, and acceptance testing

  • Migrate to the staging system(s)

  • Fully test applications and appearance in a production-like staging environment

  • Portlet developers and portal developers are involved in this phase

 

Production phase

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

  • Transfer applications and appearance from staging environment to production environment

  • Use the production environment

 

Set up systems for development and staging to production

 

Systems involved

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

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 (e.g. 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 (e.g. 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? Cloudscape. Not connected to actual business user repositories
Who uses the system?

  • Portlet developers
  • Portal developers
  • Portal designers

 

System Requirements

  • Access to administrator user IDs

  • Access to user groups

 

Process

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

  1. Portal Operator: Install WebSphere Portal (including basic configuration)

  2. Portal Operator: Run the appropriate configuration tasks to configure the portal

 

Results

Portal is installed for use as Integration 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
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? External database
Who is the system used by?

  • Portlet developers

  • Portal developers

  • Portal designers

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

  • Access to administrator user IDs

  • Access to user groups

Questions Answers
What type of installation is this? Complex, production-like installation
Is this system part of a cluster? If the production target environment is clustered
Is security enabled? Yes, with external security management systems
Where is portal configuration data stored? External database
Who uses the system?

 

Process

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

  1. Portal Operator: Install Portal Product (including basic configuration)

  2. Portal Operator: 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 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 to impact 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.

 

System Requirements

  • Operational Architecture derived from production system

  • Installation without Portlets, or Demo Portal.

 

Process

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

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

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

 

Results

WebSphere Portal is installed for use as 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 used to protect sensitive data and processing nodes.

 

System Requirements

Fully scaled

Installation without demonstration portlets or demonstration portal.

 

Process

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

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

  2. Portal Operator: Run configuration tasks to configure the portal.

  3. Additional steps typically performed on production systems:

    1. Portal Operator: 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. Portal Operator: Integrate Portal into system monitoring infrastructure.

 

Results

WebSphere Portal is installed for use as a production system.

 

See also

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.