Stage portal to production
- Proof of concept and demonstration phase
- Development of applications and portlets phase
- Integration and staging phase
- Production phase
Proof of concept and demonstration phase
This phase is used to determine and validate the direction of the WebSphere Portal deployment. During this phase, examine and test the functions and features of WebSphere Portal in order to decide how we can best use WebSphere Portal to help accomplish the business goals.
- 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
During this phase, applications, portlets, and the portal's look and feel are developed for the WebSphere Portal solution. This development process is based upon the results of the findings from the proof of concept and demonstration phase, and can include modification of existing applications and creation of entirely new portal applications.
- Create new applications and a new look and feel for the portal
- Modify existing applications
- Unit test the applications and the new themes and skins appearance
- Use the WebSphere Portal development environment
- Portlet developers and portal developers are involved in this phase.
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 solution.
Summary of integration:
- Transfer applications and portal themes and skins from the development environment to the integration environment
- Perform integration, function, and acceptance testing
- Portlet developers and portal developers are involved in this phase.
Summary of staging:
- Migrate the WebSphere Portal solution to the staging system
- Fully test the portal applications and appearance elements in a production-like staging environment
- Portal administrators, 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.
Summary:
- Transfer applications and appearance from staging environment to production environment
- Use the completed WebSphere Portal solution in the business production environment
System topologies
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 (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, probably Cloudscape. Not connected to actual business user repositories Where is portal user data stored? Local database, probably Cloudscape. Not connected to actual business user repositories Who uses the system?
- Portlet developers
- Portal developers and designers
System Requirements
- Access to administrator user IDs
- Access to user groups
Process
Prerequisite: Development system is physically installed and loaded with a supported operating system.
- Install WebSphere Portal (including basic configuration)
- 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
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.
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
Process
Prerequisite: Integration system is physically installed and loaded with a supported operating system.
- Install Portal Product (including basic configuration)
- 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, IBM recommends 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 external security management systems Where is portal configuration data stored? Remote database. Use same database as is used in 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
System Requirements
- Operational Architecture derived from production system
- Installation without Portlets, or Demo Portal.
- Access to administrator user IDs
- Access to user groups
- Access to production databases and systems
Process
Prerequisite: Staging system is physically installed and loaded with a supported operating system.
- Install WebSphere Portal (without demonstration portal and portlets)
- 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 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 the 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 external security management systems 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?
System Requirements
- Fully scaled
- Installation without Portlets, or Demo Portal.
- Access to administrator user IDs
- Access to user groups
- Access to production databases and systems
Process
Prerequisite: Production system is physically installed and loaded with a supported operating system.
- Install Portal Product (without demonstration portal and portlets)
- Run configuration tasks to configure the portal.
- Additional steps typically performed on production systems:
- Establish backup routines to allow node recovery in case of failures.
- Database backups (all configuration and data databases)
- File System Backups (all portal product files and portal solution files)
- Integrate Portal into system monitoring infrastructure.
Results
WebSphere Portal is installed for use as a production system.
Parent topic:
Planning considerations