Production Operations User Guide
|
 |
 |
|
|
 |
 |
Introduction to Production Operations
The life cycle of a WebLogic Portal application requires careful planning and management. During its lifetime, a typical portal moves back and forth between development, staging, and production environments. The process of configuring and managing these environments, and of moving portals between them, is called Production Operations. This guide discusses the following major areas of Production Operations. The rest of this chapter provides a brief description of each area:
- Managing the Portal Life Cycle
- Setting Up a Team Development Environment
- Configuring the Portal Cluster
- Building and Deploying the EAR File
- Propagating a Portal Application
- Performing Round-Trip Development
Managing the Portal Life Cycle
Production operations addresses the tools, procedures, methodologies, and best practices that provide the backbone for managing the portal life cycle, from portal development to staging and testing to live production environments. As Figure 1-1 shows, portals are typically developed in a team development environment by developers using WebLogic Workshop. Portal components are then moved to a staging environment, where portal administrators use the WebLogic Administration Portal to create desktops, add entitlements, set up content repositories, and perform testing. The production environment is the live environment, where users access and interact with portal applications. The arrows between environments indicate that you can move portals and portal resources back and forth between each of these environments using utilities provided by BEA. Utilities such as the Propagation Utility and the Export/Import Utility allow you to easily and reliably move and merge changes between environments.
Figure 1-1 Typical WebLogic Portal Environments
Like considering the architecture of a network or a software system, you should also consider and carefully plan how you will address production operations for your portal system. It is important to consider your particular portal system configuration, how your development team is organized, how you will test and configure portals, how your server is configured, and how you will plan to manage the life cycle of your portal applications. This guide describes the specific methodologies, tools, and best practices to help you achieve the goal of creating solid, manageable environments for portal development, staging, and production.
Setting Up a Team Development Environment
Team development of a WebLogic Portal Web site revolves around good source control. Proper use of a source control management system has many benefits, such as close integration between team members, the ability to quickly scale the size of a development team, and protection against data loss.
Managing a Team Development Environment shows you how to configure, store, and manage a common development domain, database data, and portal applications in source control, letting you quickly and consistently develop, build, and update your portal applications.
Configuring the Portal Cluster
By clustering a portal application, you can attain high availability and scalability for that application. Configuring a Portal Cluster discusses how to set up a production database, choose a cluster architecture (single versus multi-cluster) and configure the domain.
Building and Deploying the EAR File
Deployment refers to preparing deployment descriptors and configuration files, building an Enterprise archive file (EAR), and deploying the EAR file to a destination server. Preparing and Deploying the EAR File describes how to prepare a portal application's descriptor files and deploy the EAR file.
Propagating a Portal Application
Propagation refers to the process of moving the database and LDAP contents of one portal domain environment to another. During the typical portal life cycle, portals are moved between the following environments:
- Development - In the development phase, developers use WebLogic Workshop to create portals and portal components, such as portlets.
- Staging - In a staging environment, administrators use the Administration Portal to build and configure portal desktops, create entitlements, and create content repositories.
- Production - A production, or live, environment can be modified by administrators using the Administration Portal and customized by users using Visitor Tools.
BEA provides tools to help with portal propagation. These tools not only move database assets and LDAP information, but they also report differences and potential conflicts between the source and the target environments. You can define policies to automatically resolve conflicts, or an administrator can view a list of differences and decide the appropriate actions to take on a case-by-case basis. These tools are described in detail in this guide, and they include:
- The Propagation Utility, described in Using the Propagation Utility
- Datasync Web Application, described in Using the Datasync Web Application
This guide also helps you through the process of planning a strategy for propagation and provides detailed information on the best practices. See the following chapters for more information:
Performing Round-Trip Development
Round-trip development refers to moving portal assets back and forth between a WebLogic Workshop-based development environment and a staging environment where portal assets are assembled with the WebLogic Administration Portal and stored in a database. The Export/Import Utility lets you export portal assets from a database to .portal and .pinc files that can be loaded into WebLogic Workshop. The utility also lets you import .portal and .pinc files into a database, as shown in Figure 1-2.
Figure 1-2 The Export/Import Utility Allows Round-Trip Development
Tip: The Export/Import Utility is also known as the xip tool (pronounced "zip"). Typically, developers use this utility to move assets back and forth between a development and a staging environment.
In addition, the Export/Import Utility allows you to:
- Merge
.portalfiles into a database - Specify rules to determine how objects are merged
- Specify scoping rules
The Export/Import Utility is described in Using the Export/Import Utility.
