IBM BS029ML Self Help Guide - Page 44

2.4.4 Moving a configuration between environments A common deployment approach in any IT implementation is to provide separate environments for development, quality assurance, performance testing, pre-production, and production (or some subset of these). As applications move through this life cycle, there is the need to repeatedly promote code and configuration data between environments. Furthermore, the need becomes even more important with the exploitation of a dual clustered WebSphere Portal Server V6.0.x architecture with "Two Lines of Production". As such, there are several methods for replicating WebSphere Portal Server configuration data between environments. However, it is important to understand the limitations and assumptions associated with each method. To get an exact replica of one environment to another, it is first necessary to make a full XMLAccess export from the source environment. At this point, you could import the XML file resulting from the previous XMLAccess export action into another Portal instance to create what would at first seem to be a duplicate configuration. However, as the import action by default applies the literal object IDs associated with the resources from the source environment, there is a high likelihood that these object IDs will clash with any existing object IDs in the target environment. You could avoid this by using the ID generating mode (see the XML reference documentation for detail). When you use the ID generating mode, the object IDs in the input are not taken literally; instead, during the import process, the resources obtain new object IDs when they are created on the target system. However, while this prevents any clash in terms of the object IDs, it does not yield an exact replica. In certain situations, this may be sufficient for a number of customers. The recommended approach, therefore, for creating an exact replica of one environment to another involves the additional task of "cleaning" the target environment. As such, the target environment needs to be an empty Portal void of any object IDs. Importantly, this must only be undertaken on the target environment after it has been configured completely (including activating security, WCM, and so on). This then allows the literal object IDs from the source environment to be restored as is. Using literal object IDs only makes sense if you really want to create two instances of the same resource, and if you have a controlled environment where you can guarantee that all object IDs that your resources depend on have exactly the required values. In addition to any XMLAccess and Release Builder tasks, it is necessary to manually copy the associated Portal artifacts between environments. For example, it is necessary to copy the Portlet WAR (Web Archive) to the installableApps directory of the target environment. 2.5 Architecting for performance WebSphere Portal Server architectures that perform and scale are not accidental. They are the result of proper design development and rigorous assurance processes that include iterative performance verification and re-verification during the entire solution life cycle. The importance of addressing performance as early in the project as possible is crucial to project success. A positive result requires a strong effort to ensure that performance maintains visibility and importance throughout the project life cycle. Performance, like security, is a secondary consideration on too many projects, resulting in failure, lower capabilities, or frequent critical situations (that IBM must often help to resolve). Such results need not occur if performance is correctly handled and supported from the outset of the project. 30 IBM WebSphere Portal V6 Self Help Guide