Creating a new portal: Part 5. Developing, building, and deploying the portal

Document options Document options requiring JavaScript are not displayed Sample code Rate this page Help us improve this content

Level: Intermediate

Anthony Bernal (abernal@us.ibm.com), Sr. Consulting IT Specialist, IBM Software Services for Lotus
Varad Ramamoorthy (varad@us.ibm.com), Consulting IT Specialist, IBM Software Services for Lotus
Yixing Gong (yixingg@us.ibm.com), Senior IT specialist, IBM Global Business Services
John Barron (jwbarron@us.ibm.com), Senior IT Specialist, IBM Global Business Services
Julia Weatherby (jw@us.ibm.com), IT Specialist, IBM Software Services for WebSphere

09 Jun 2006

Design your processes and set up your environments for developing, building, and deploying your portal. Learn how to control the source code and build components, ways to manage continuous integration and deployment to test environments, and how to deploy production release packages. Learn best practices, which tools to use, and strategies for creating you own processes.

Introduction

In this part of the series on Creating a new portal, you see how to create your own processes for building and deploying code components in WebSphere Portal environments. You integrate different technologies and products into a cohesive system that you can manage.

• You can consider the overall task to be a series of processes:
• Control of the source code and build components
• Continuous integration and deployment to test environments
• Definition and deployment of production release packages

This article provides some best practices and general information to help you create your own processes. It provides an overview of the process behind compiling (or building) the code, and deploying the custom portal application within the portal framework and associated infrastructure.

Why is the build and deploy process important?

So, why is this discussion important? If you have been through any type of IT or software project you probably know the answer to this question; however, to be clear, we will specify the reasons here.

Build and deploy processes help to insure that:

• Code is checked in, stored, and versioned by all developers, so that no important intellectual capital is lost.
• Items are not moved to production environments without going through some accountability process.
• The code base on the system can be reproduced if something goes wrong or a bad update or configuration change is made to the system.

While you see additional reasons why some process is important in this article, the major areas to consider are:

• The portal and its related infrastructure
• The portal application or custom code

These factors are heavily intertwined; however, each involves a unique set of design aspects and challenges. The desired end result is that these items come together and provide a successful working portal for use by your customers.

How does the process affect my project?

Initially, you might not see any advantage in putting in place a build and deploy process. In fact, it might seem like a lot of work that brings more structure and rules that offer very little in return. Do not be lulled into a false sense of comfort at this point, because the value of the process will likely soon become apparent.

For example, a critical time in the life-cycle of a project is in the time period before your go-live date. The infrastructure is in place, some code has been deployed to the environment, and testing is taking place. In most environments, several types of tests are in process, such as:

• Quality assurance testing
• User acceptance testing
• Load or performance testing

Each of these types of tests can result in a feedback loop to the development team, which creates new versions of the software or bug fixes.

This is the point where many projects take a wrong turn. As different versions of various components are created and need to be deployed and tested, it becomes critical to be able to quickly build, deploy, and test on different environments. Equally important is the ability to know what versions of each component are deployed to each environment, as well as the results of the testing.

No single process works for everyone. Different organizations need to take different approaches. Team hierarchy, leadership structure, code repositories, and choice of build tools all affect how your process works. You can select from the ideas in this article to design your own process.

Is the process different for portals versus other projects?

Inherently, portals are not that different from other J2EE projects; however, the portal framework does provide some limitations and challenges. You need to decide how to set up projects to work best within your IDE, to enable consistent builds, and how to deploy the different components to different environments.

Building Java components is pretty similar for most projects, especially for J2EE or server side components. The primary differences are that you use different libraries and APIs, and you need to set up projects to make the best use of your IDE.

The deployment part of your process can make use of tools or approaches that are different then those you use for deploying non-portal Web applications. Your portal and your WebSphere Portal environment require additional configuration beyond just installing portlets or components. You need to consider the portal layout and access control issues; you can configure, version, and deploy using an xmlaccess command that is specific to Websphere Portal. You learn more about these considerations later in this article and you learn some tips you can apply to your project's build and deploy process.

Back to top

Establishing a development process

When working with development, build, and deploy issues it really is all about process. Developers do not always like a lot of process because they feel it restricts getting their jobs done as quickly and easily as possible. In reality, we all have the same goal; therefore, the goal is to put together a process that is simple and non-intrusive. This approach is key to making things work, and the process should always start with the developers. Putting together some very technical or complex set of steps, and trying to force the team to follow them, is probably not going to be very effective. Instead, put together a simple set of steps using tools that integrate and work well with the current set of tools that everyone uses.

Along with process definition, you create development standards and conventions. We will start with this task and then work through the process definition, adding in some points that you might want to incorporate in your own project's development process definition.

What are development standards?

Development standards provide a set of reusable, common sense guidelines that developers should follow when delivering a code module or component. Defining an initial set of standards and templates for a project conveys architecture, design, and implementation guidance to the team. Outlining these standards also sets forth an expected behavior from developers when they code the various modules. Not having any standards or putting some initial thought into the development process can result in chaos when the time comes for deployment, and later, when supporting the various modules.

When defining standards you need to stay within the framework that WebSphere Portal provides. You need to know and understand the functionality out-of-the-box to insure that your design works with WebSphere Portal -- not against it. If you are new to WebSphere Portal these simple guidelines can help you as you start your first portal application.

1. Start small. Scope the project appropriately so you do not try to build a super portal right away. Get some experience under your belt in an initial project that cannot go too far out-of-control.
2. Use a WebSphere Portal expert. This person should be available for continuous support during the end-to-end process of developing your first portal. Even if your team is experienced in using Java™, a WebSphere Portal specialist can help you take advantage of the framework and provide architecture support.

Because each project is different and can have widely varying requirements, you need to separate standards definition from environment definition. That is, create a separate Development Environment Setup and Configuration document to describe the specific configuration information, and maintain it while building your environment. Include:

• Naming conventions
• Error and exception handling
• The .war and .ear file structure
• Unit and functional testing guidelines
• Source Control Management (SCM) process guidelines
• Environment setup
• Specific libraries or code sequences

However, do not get locked into a set of standards for your project or development effort. No set of guidelines can handle every situation you might encounter. You will have times when the current standards do not apply. When you fall into a situation like this think out-of-the-box for a moment and do the following.

• Talk with your team or project leader and fellow developers about the situation. If the problem is big enough, or you think others might encounter a similar situation, call a short meeting to discuss and come up with solutions.
• If the standards need to be changed, or you go against the standards in a particular case, document it! Let others know either in the guide, or within your code, that you went against the standards, and why
• Identify any problems with the approach that you are taking and the conditions that can cause this situation.
• Finally, notify the owner of your standards document and let them know about the situation that you encountered. Others might learn from your experience, and the guide should be updated.

Why standards matter

There are many reasons for promoting standardization with your development process. You have probably been in situations that required you to look over or modify the code written by another team member. Testing, reviewing, and debugging code that does not follow any standards can be a daunting task, even for the best of programmers. How many times has a piece of code been scraped and rewritten for lack of understanding?

Following well-designed programming standards can result in greater consistency within the delivered code, as well as better quality code that is easier for other developers to understand and maintain. Well-designed and documented code reduces the cost of long-term maintenance and transitioning of artifacts to another team or team member.

Separation of concerns

By the phrase separation of concerns we mean the use of different environments to control the flow of code and other files that make up a deployment release. Keeping different environments isolated and only allowing files to flow through a defined process helps insure some of the key elements in a build process such as control, repeatability, and reliability.

Figure 1 illustrates the separation of concerns concept by showing the flow of code between the development workstation to final production. If you understand this flow and environment separation you can control your environment during the build and deploy process.

Figure 1: Build and deploy process

Development team member workstation

Most developers work on their local workstation. This is the way it has been for the last few years, and there is no real reason to change this approach. Developers who use Rational Application Developer for WebSphere and its Portal Test Environment can be extremely productive when WebSphere Portal is the target environment. These tools require minimal setup time. You could also consider using development images that contain the target environment. This will allow programmers to reset when something happens to destroy their environment.

In some cases a developer might need a complete portal installation on his or her development workstation; for example, you might want to work with the correct directory server (LDAP) and database to reflect the components used in production. Developers who are building security components require that security be set up in their development space similar to how it will be in production.

Development build server

Some teams are confused about the need for a separated build server and a separate development integration and test. There are really no hard and fast guidelines for how to use these environments. We will tell you one approach and recommendations in this area, but you might come up with your own strategy for managing these environments.

The main idea is to separate the process of building (or compiling) and packaging the software from the developer’s workstation. Usually the build server will be a physical machine which is not the same as any single developer’s workstation. However, in small environments, it could be a logical separation on the same developer’s workstation. The key is to insure that all components coming into the build process are pulled from version control, and not from other development workstations or machines to insure that every build can be repeated from the same, single source.

We recommend that you enforce this practice rigidly. Once you have established the process, it takes very little time to update with the latest code or missing jars, through source control, when a build occurs.

Development integration and test environment

Follow a similar approach for the development integration environment. No code should be deployed to this machine except through the SCM or the build repository. Developers need access to this machine to examine logs and view results; however, they should never be allowed to deploy their own code, which would result in these issues:

1. Repeatability is destroyed. It makes it difficult to recreate a deployment or component at will.
2. When multiple people work with a single machine at this level, diagnosing conflicts and environment crashes is more difficult.

One concern that teams might have with this approach is that putting constraints on the environment can slow the development team down. You can get around this issue by either allowing some or all developers to put a full portal infrastructure on their local workstation, or by streamlining your build process to include continuous integration and deployment so that components are automatically built and deployed.

Release environments

Release environments are absolutely hands-off to most of the team, except as required for deployment and configuration. Multiple release environments are usually required to avoid competition between environments while various testing efforts are underway. Quality Assurance (QA), User Acceptance Testing (UAT), performance, and stress testing can all create issues that need to be evaluated.

Because access to these environments is forbidden to developers, you need some approach to allow developers to view and configure logs on different machines so that they can diagnose problems. You could grant limited access to certain users. Alternatively, you could enable access to some logs and property files on different machines through a Web page.

Controlling the process

The development lead should either be in control, or assign someone control, of the source code management process so that the team manages the process instead of the process managing the team. This person insures that all code is checked in and ready for the build and deploy step. By working with and gaining an understanding of all the components that make up the current code base, he or she can communicate with other teams regarding how components work together and how they are deployed.

Back to top

Implementing a build process

In many WebSphere Portal project plans, “a build” is often identified as a single line or task on the project plan. In some project plans, the build is not even defined as a task because some project manager see that as part of developers’ routine work. The build is the process of creating the portal artifacts for a portal project. WebSphere Portal best practice suggests that the build process is an important activity in the release cycle of a portal project.

What is a build process?

WebSphere Portal is an application server as well as an application framework. It enables developers to create their own code, customized to the framework, and to deploy the code to WebSphere Portal to create a new portal Web site. A build process compiles the code and generates the deployable packages, containing the WebSphere Portal project solution artifacts.

Defining a build process insures that each time the team generates a deployable package it is composed of the correct code level, and the process occurs in the exact same manner. The entire build process should be repeatable and traceable. Establish, document, and automate the exact series of steps in the build process as much as possible. Because the build process gets much more complex in larger portal projects, it is even more necessary to achieve such standardization.

A clearly defined build process helps close the potential gaps among the development, integration, staging, and production environments. You can use the build process to spend migrate portal artifacts from one environment to another. It can also remove many issues that are related to compilation, classpath, or properties; these issues can cost a lot of project time and money.

You could define two types of build processes:

1. Local build: In this case, a developer builds the code on his or her workstation using either Rational Application Developer or Ant or Maven scripts. Then the developer uses the test environment to test the code.
2. Build server build: The build server extracts the code from the version control system and builds using the scripts that the build manager created. This process also builds any dependant JAR files and packages them appropriately.

Creating the build process includes the following activities:

• Define the steps of this build process
• Define the source code that are the input to this build process
• Define the artifacts that are generated by this build process
• Create a tool to execute this build process

What the build manager does

In many portal projects, the development team consists of code developers only. Near the end of the development phase, a developer creates an Ant or Maven script to compile the code and generate the portal artifacts such as war files for portlets and a zip file for themes and skins.

You might want to designate two people on the team to be the build manager (or code maintainer) and deployment manager (or release manager). Both the build manager and deployment manager are important roles in a development team for a large portal project. One person could play both roles depending upon the size of the project.

The build manager maintains the code, runs the build process, and insures that the portal artifacts are generated using precisely the same steps each time.

Building components versus packaging

A good build process should define which artifacts are generated. Theses artifacts can be components, such as war files or zip files, or they could be files placed in the wps.ear package. Putting together a build process to generate and these different types of artifacts requires careful study of the design of your portal solution. Building a Portlet can be different from building other artifacts that your portal may require. See the download for Maven and Ant sample scripts for building a portlet using a Rational Application Developer project structure.

Working with other teams

After the development team completes its code development work, the build manager works closely with the development and deployment teams to generate and deploy the portal artifacts into the portal environments. The build manager runs the build process to generate the portal artifacts, and the deployment manager deploys them into the development, integration, staging, and production environments.

When the development team wants to deploy its new code to the development environment, it sends a build request to the build manager. This build request specifies:

1. Which projects in your SCM to build
2. Version of these projects
3. Destination environment
4. Timeframe when the build should be completed

As illustrated in Figure 2:

1. The build manager uses the build tool to generate the portal artifacts
2. The build manager notifies the development team of the status of the build process
3. The build manager sends a deployment request to the deployment manager indicating the availability of the portal artifacts and requesting that they be deployed into the designated destination environments.
4. The deployment manager notifies the build manager when the deployment is complete.

Figure 2: Working with project teams

As the development work is gets closer to the start of portal testing, the build manager can create a daily build and deploy the artifacts to the development environment for developers. He or she should do the same thing weekly (or more often) with more mature marked code to the integration environment for testers.

Picking a build tool

Picking a build tool can be a challenging task since there are a lot of choices. Choices can include open source tools such as Ant, Maven, or Cruise Control for your build server. Both are open source projects from Apache. Some research will be required to pick the correct tool for your environment, and in many cases these tools can work together to provide additional functionality...

Here is a short comparison by Julien Dubois from the article Master and Commander.

While Ant provides you with flexibility, Maven provides you with more structure and good dependency management. You can use some of the Maven features within Ant and vice versa.

You could use Ant or Maven together with CruiseControl to automate your build process. If you already have Ant, you could call Ant from Maven. There are also tasks available to use Maven features from Ant and vice versa.

CruiseControl lets you schedule your builds - nightly or at any specific times. So you can save some time especially during in the initial phase of a project where the builds are needed more often. It is a framework for a continuous build process. Using CruiseControl you could

1. Extract the source code from Version Control System
2. Build the source code using Maven or Ant into portal artifacts such as war, zip and other files
3. Place those files into a deployment area
4. Deploy the artifacts
5. Save the files back into the SCM, and give them a new version label or tag
6. Run Build Verification Tests
7. Send email notification
8. Using Maven you could generate reports and send emails about the build status.

AntHill from urbancode.com is another build tool (with a small licensing fee) that uses Ant and is easy and quick to set up and use.

Artifacts to consider when during build process

Here are some the artifacts to consider when creating build and deployment scripts.

1. Portlets
2. Skins
3. Themes
4. Property files
5. NLS Resource Bundles
6. Configuration files that go under <PortalServer>/shared/app/config/services
7. Shared Libraries
8. XMLAccess scripts
9. Web Files

Version control

For traceability and failover recovery, after placing the portal artifacts into the deployment area, you should also save them into your SCM as a new version. You can trace the build history of these portal artifacts from within the SCM

One of the most important decisions you will make is to determine which source code management system your team will use. There are many systems available, and which system you use might be dictated by your organization or corporate standards.

There are two distinct types of source code management systems.

• Check-in/Check-out; such as Visual Source Safe, CMVS or Rational ClearCase.
• Continuous Stream; such as Concurrent Versioning System (CVS), which uses a merge type of system to commit new code instead of check-in/check-out. Developers use this process:
• Copy – Get a local version of the latest copy of code.
• Change – Make changes as necessary.
• Merge – Submit the changes and merge them with the existing code.

CVS or Concurrent Versioning System can be a viable choice, especially when there is no other SCM system available to your team. CVS is a freely available, open source system which has been widely accepted and used within the development community. One potential drawback that management can point to is the lack of file locking within CVS. This can be seen as an advantage or disadvantage based on your point of view or management style. With a well- organized team that communicates effectively, lack of locking has not been an issue.

Another possible problem is the lack of official support since CVS is not officially sold by one company. This can be a valid reason for not choosing this tool; however, the open source community has a lot of experience with this tool and is very capable of supporting many of the problems that you might encounter.

Using CVS in a manner that is recommended by the development community can also help to alleviate issues. One advantage of using CVS is that there are several free, add-on tools. For example, CVSWeb is a Web-based interface that enables non-CVS users to view the repository without the need for the client software or the plug-in for your development environment (described below).

Figure 5 below illustrates how CVS integrates into your eclipse or RAD development environment.

Figure 5: CVS plug-in for Rational Application Developer

A full-featured CVS plug-in is installed with Rational Application The plug-in which can be setup when in the Team perspective of RAD, enables developers to easily view, extract, and merge code sections as they are developed. This ability is critical to a well-defined and easy-to-use build and deploy process. When developers are provided with a simple SCM integration process they are less likely to take shortcuts which can break your teams processes and control.

When the build fails

There is no guarantee that each build will complete successfully. After the build tool executes, the build manager reads the build tool log file to see if the build process completed successfully. If the build fails, he or she attempts to determine the cause for the failure. Most build tools let you e-mail the build report.

If the failure is caused by the source code, the build manager can send a request to the development team or person responsible to fix the build. After the development team fixes the code, the build manager re-runs the build process. You repeat this process until the build completes successfully.

Applying emergency fixes

In some cases, you might need to apply emergency fixes to the built artifacts so that testing can continue or production can go live on time. Clearly document the emergency fix process as part of the build process document.

Build process summary

In summary, the build process is an important activity in the release cycle of a portal project. The build manager should be a member of the development team. The build process should be defined, and the build tool should be selected (or created) to automate the process.

If the team follows the defined build process, and uses the build tool to standardize it, you can avoid many unexpected issues coming from the build process. The time and money spent in the build process will be returned by eliminating additional unexpected issues during testing.

Back to top

Deploying the portal

For the most part, a portal is a complex J2EE application that can include web modules, ear files, jars, property files and other assets Each Portlet is an independent Web application implementing a specific function; which can operate as independent units. With proper design, you can combine these portlets into composite applications.

In many cases a portal environment can be even more complex then a similar J2EE environment because of the additional framework that WebSphere Portal provides. You need to register certain portal-specific components in the portal database so you can administer them and to make them available to environment.

The WPS.ear is the core WebSphere Portal package, which runs as yet a separate Web application within the Web container. It contains most of the base functionality of the portal, including some important integration functions such as menus and look and feel.

Deploying portlets

You can install portlets in several ways, such as using the portal administration interface or using XML Access. Because the ultimate goal is to automate the process of deploying your portal resources and components, you need to develop a scripted way of deploying them. You can examine the portlet and generate an XMLAccess deploy script based on the portlet.xml file within the portlet.

See the large set of sample scripts in the Reference: Sample XML configuration files section of the WebSphere Portal InfoCenter. You can choose and then modify the ones that fit your deployment needs.

So, you can use your modified script to install the .war file. However, you also need to build and deploy this script using some automated scenario. You can use the script in Listing 1 to generate a portlet automatically by using a custom Ant task that examines the portlet.xml and updates it with some template properties.

Listing 1. Sample Ant script to build a portlet

				
<?xml version="1.0" encoding="UTF-8"?>
<project name="xMethodsTempPortlet" default="main" basedir=".">
<project name="xMethodsTempPortlet" default="main" basedir=".">
<property name="name" value="${ant.project.name}" />
<property name="deployDir" location="dist" />  
<property name="dist.dir" location="${deployDir}" />
<property name="dist.download.dir" location="${dist.dir}/download" />
 <target name="main">
	<echo message="Starting build process...." />
	<antcall target="compile" />
	<antcall target="archive" />
</target>
<target name="compile">
	<property name="build. compiler" value="modern" />
	<javac srcdir="../Java Source" >
		<classpath >
		<pathelement location="../../PortalMain/BaseLibraries/lib/j2ee.jar" />
		<pathelement location="../../PortalMain/BaseLibraries/lib/websphere.jar" />
		</classpath>
	</javac>
</target>
<target name="archive" depends="compile">
	<tstamp><format property="build.time" pattern="MM/dd/yyyy hh:mm aa" /></tstamp> 
    	<filter filtersfile="template.properties"/>
 	<filter token="buildinfo" value="(build date: ${build.time})"/>
	<copy file="portlet_template.xml" toFile="..\Web Content\WEB-INF\portlet.xml" 
	overwrite="yes" filtering="true" />
	<mkdir dir="${dist.download.dir}" />
	  <zip zipfile="${dist.download.dir}/${name}-${version}.war" basedir="..\Web Content"/>
</target>	
</project>
	

You could use this example to replace the name of your portlet with a version number for each build. During testing this can be a powerful approach for developers and testers to know which version they are working with. This example includes a timestamp for the build to let you know when it was created.

				
Template.properties
		
version = 1.0.0.29
	

The template properties file is pretty simple. Just a list of properties that you want to be replaced during the filter operation. You can also install a portlet using Ant scripts.

				
<?xml version="1.0" encoding="UTF-8"?>
<project name="xMethodsTemp Portlet" default="main" basedir=".">
<property name="deployDir" location="dist" />  <!-- passed in by Anthill -->
<property name="dist.dir" location="${deployDir}" />
 <property name="dist.download.dir" location="${dist.dir}/download" />
<target name="main">
<antcall target="deploy" />
</target>
<target name="deploy">
  <echo message="Starting deploy to test..."/>
  <java classname="XmlAccess">
    <arg value="C:\anthill\work\xMethodsTempPortlet\build\xmlAccessUpdatePortlet.xml"/>
    <arg value="wpsadmin:wpsadmin"/>
    <arg value="wpsdev/wps/config"/>
    <arg value="2"/>
<classpath >
<pathelement location="C:\WebSphere\PortalServer\bin\XmlAccess.jar" />
</classpath>   
  </java>
  <echo message="deploy complete!"/>  
</target>
</project>
<!--arg value="C:\anthill\work\xMethodsTempPortlet\build\xmlAccessUpdatePortlet.xml"/-->
	

This example calls the XmlAccess class, passing in the required parameters. The xml file for updating the portlet should be included with the portlet and can be saves as part of the version control.

Deploying themes and skins

You can deploy the WPS.war file as an .ear file to the server. Deploying new versions of themes and skins this way is safer than simply coping them to the server.

A portal theme is a file system based structure of JSP and CSS files. The first step in creating a portal theme is to understand its file system. The WPS.ear is an Enterprise Application under the WebSphere Application Server, so you find it in the server file system as:

In this file system, you find the themes and skins folders which have the markups folders.

The main reasons to deploy as an EAR is to practice source code control, repeatability, and consistency across systems. Once you set up a system, you can more easily perform this step during deployments.

You can deploy EJB’s in a couple of other ways:

• Through the application server administration console. You can install, modify or uninstall an Enterprise Application Archive (EAR) file.
• Through scripting using the wsadmin interface

For the basic scripting approach for installing an ear file, you can use the following command:

This command installs the wps.ear file.

You learn more about this approach in the next section.

Handling static files

Traditionally, sites looking for better performance would move static files to the Web server tier to reduce load on the application server. While this is a good practice, it might be a hardship to developers trying to build applications in this manner. The Web server plug-in contains a built-in ESI processor which caches whole pages, as well as fragments, providing a higher cache hit ratio. You can package static files with the portlet and still get the performance advantage of moving them to the HTTP Server. The cache implemented by the ESI processor is an in-memory cache. You can configure the caching processor through the WebSphere Web server plug-in configuration file plugin-cfg.xml.

<?xml version-"1.0"?> <Config> 
<Property Name="esiEnable" Value="true"/>
<Property Name="esiMaxCacheSize" Value="1024"/>
<Property Name="esiInvalidationMonitor" Value="false"/>
	

Deploying portlets in a clustered environment

With the initial release of WebSphere Portal V5, deploy components to a clustered environment required several steps. Because of the way XMLAccess updated the portal database, in a clustered environment conflict issues could occur if the code were updated in only one of several possible locations. Most production environments prefer a clustered approach to provide higher performance and failover capability in case of a server failure. Subsequent releases and fix packs of WebSphere Portal have fixed some of the issues. In this article, we assume a worst case scenario in deployment flows to make sure we have covered all requirements.

Install or update the WAR file(s) using XMLAccess.

1. The portal deployment tool called XMLAccess is a Java based tool that uses XML to make the necessary changes to the WebSphere Portal file system and database. It enables several kinds of tasks required for portal management and maintenance.

   You need to set the active attribute set to false in all the tags, in order to prevent warnings caused by the tryouts to activate the portlet before synchronizing the nodes and starting the application. In the URL tag that contains a path for the WAR file, specify the path for the WAR file you want to install.

2. Wait for the nodes within the cluster to Synchronize the portlets.

   After you deploy a portlet or set of portlets, they are marked as inactive until the nodes can synchronize all the code across the cluster and you can activate all the portlets.

   An interesting activity would be to watch the system.out logs for the node agents on your different servers to see the synchronization process taking place. The process does not take long, but this is a necessary step in the deployment process and with a big deploy could result in a longer downtime for your environment.

3. Now activate the portlets using XMLAccess.
4. Modify the deployment script to activate all the portlets and then run again. You need to:
5. Modify the scripts to remove the URLs to all the portlets.
6. Set activate to true on all the Web applications.

When you run the modified script (after the initial deploy and synchronization), the portal activates all the portlets on your system and populates the necessary pages.

Deploying themes and skins in a clustered environment

In a cluster environment, you must export the portal EAR file from Deployment Manager, update the EAR file with the new theme and skin directories and import the Enterprise Application file back to the Deployment Manager cell. If you are on a standalone portal server, use the application server in place of Deployment Manager. For more information, see the InfoCenter under Deploying customized themes and skins.

Using shared libraries

You can use shared libraries to share resources among different components or portlets within the portal. These are usually determined during the application design phase, when you are determining which components need to be shared across several portlets or components. When you use shared libraries, you need to set variables within the application server to allow them to be loaded when necessary.

To deploy shared libraries.

1. Copy the library files to the correct WebSphere directory
2. Install the library within WebSphere using wsadmin.

Alternatively, place the .jar files directly in the /PortalServer/shared/app directory. If you go with a separate directory for the files, then create the shared library in the server using either the admin console or the wsadmin config command, for example:

$AdminConfig create Library $server {{name myLibrary} {classPath c:/WebSphere/PortalServer/shared/app/myLibraryClasspath}}

Scheduling deploys and system downtime

It is a common problem to reduce the downtime associated with a site; however, scheduled maintenance downtime is a necessary evil. Once your management understands that point, then life becomes much easier. It is possible to have no scheduled downtime for a site; however, you would incur very large hardware costs because you would effectively need to double your infrastructure so that you could upgrade one system while the other maintains the required user load.

If your organization is not ready for the cost associated with a gold standard infrastructure, then it is important to “socialize” or discuss the need for scheduled downtime now with managers and end users, so this can become a routine event after you go live.

If your process if well-defined and your team in sync, then downtime can often be kept to a minimum. Downtime could occur for a couple of reasons:

• Upgrade to the infrastructure components or OS
• A new build release needs to be deployed

In some cases both can occur during a maintenance window. If you have several release environments, you can practice maintenance on a pre-production environment to minimize risk during a production deploy.

Back to top

Managing release environments

A release encompasses the full range of artifacts that can be deployed and configured in the portal. The release could be one configuration change, one portlet update, a complete package to install a new portal, or any combination of changes. Communication among teams and tracking are key to successfully maintaining each environment in your organization.

A release is numbered, typically in major, minor, fix number dot notation, such as release 2.1.0.1. These numbers can stand for major, minor and different types of fixes that are within the release. You will need to document the release; include what is in the release and the deployment instructions. You need to track the release as it moves through each environment: development, integration, operational acceptance testing, user acceptance testing, staging, and production.

In the release schedules, be sure to include maintenance windows, backups, deployment time, back-out time, and testing. Automate the installation to minimize human error; include database updates, access controls, skins, themes, and page updates.

Back to top

Dealing with failed deployments and rollbacks

A complete and thoroughly tested backup and recovery procedure is essential for any production environment. WebSphere Portal is no different. Develop and test (in a testing environment) complete disaster recovery strategies and approaches. Once verified, these same procedures should be implemented into the WebSphere Portal production environment.

While not a detailed procedure for backup and recovery, the provides an approach for WebSphere Portal backup and recovery that can be implemented along with a company’s existing disaster recovery procedures.

Rolling back from a failed deployment or if there are problems with the new code can cause some difficulty. You can take advantage of some Portal features to make this easier when things go wrong. Since you are following a defined build and deploy process with formal releases, the easiest way to “roll-back” is to redeploy your last release. This is not always the cleanest method but for the most part will ensure that the last good code package for portlets is reinstalled in the portal.

Currently, the only way to ensure total rollback capability is to do a full file system and database backup before the deployment. This will ensure the file system is correct and any new configuration changes are reverted in the database backup. You can also use “Transactionality” within XML scripts to ensure that a script is run in an all or nothing mode.

Back to top

Conclusion

This article provided ideas and suggested steps for creating a build and deploy process for your portal project. The major intent of this article is to convince you that putting some thought into this process is a worthwhile practice. We purposefully kept the discussion at a higher level of abstraction so you could determine the details that will fit your environment. We provided some examples and scripts to help get you moving as quickly as possible.

Keep in mind some of the guiding principals discussed for use during this process. Keep it simple, and start as early as possible within the project scope. Even if nothing is built right away, start with the scripts and keep running them until they work regularly. The scripts need to evolve with the project so the task of creating should not be as daunting as when they are put off until the end a project. If there is not a build server in place, a simple test of your scripts can be to extract the necessary code components run the scripts. If they don’t run, then you probably have problems with the relative paths that need to be fixed. Finally, do not try to design a process that does everything you think it might need to do. Let the system evolve with your needs, rather then trying to build the whole process at once.

This article did not really discuss the entire build, deploy, and migration process with the detail that is necessary for your project to be successful. For example, we did not cover the building and transfer of the page and portlet layout within the portal. This step is important because you do not necessarily want your administrators changing the layout in production without going through a more formal QA and performance testing process to determine the impact any changes will have. Having a release strategy for all components enables you to quickly recover from any mishaps that might occur within your environment.

Back to top

Download

Description	Name	Size	Download method
Portal build samples	portalbuild-samples.zip	36KB	FTP|HTTP

	Information about download methods

Resources

• An introduction to Maven 2 shows how to optimize the Java build process.
  
  
• Master and Commander (Maven), learn about And and Maven and how they relate to J2EE building.
  
  
• Automate your build process using Java and Ant
  
  
• WebSphere Portal in Action: Read Joey Bernal's blog on developerWorks.
  
  
• developerWorks WebSphere Portal zone: Find more resources to help you develop portals and portlets.
  
  
• WebSphere Portal production documentation: Provides access to all current product documentation including InfoCenters, release notes, and readmes for all releases of WebSphere Portal.
  
  

• Try out Rational Application Developer.

About the authors

		Anthony (Joey) Bernal is a Sr. Consulting IT Specialist with IBM Software Services for Lotus (ISSL). Having worked with WebSphere Portal since the initial 1.1release, he has an extensive background in the design and development of portal applications, and has led the implementation of many projects using IBM WebSphere Portal. Joey is an accomplished author, speaker, and instructor in various topics concerning WebSphere Portal and related technologies. He is a co-author of the book Programming Portlets.

		Varad Ramamoorthy is a Consulting IT Specialist with IBM Software Services for Lotus. He has worked with WebSphere Portal since its initial release, and he uses his expertise to help solve customer issues. He has published numerous articles on WebSphere Portal and related technologies.

		Yixing Gong is an IBM certified senior IT specialist in Portal, Content and eCommerce practice of IBM Global Business Services. He has been with IBM for eleven years to architect and develop web applications on WebSphere Application Server and portal sites on WebSphere Portal. He has been providing his consulting services on WebSphere Portal to his clients nationwide since the inception of WebSphere Portal.

		John Barron is a Senior IT Specialist with IBM Global Business Services. He has over 22 years in the IT industry with experience in systems and software engineering. Having worked with WebSphere Portal since the initial 1.1 release, he has an extensive background in configuring, integrating, and maintaining portal applications.

		Julia Weatherby is an IT Specialist with IBM Software Services for WebSphere. She has 9 years of experience working with a variety of products in the IBM software portfolio. Her expertise includes implementing WebSphere Application Server, WebSphere Portal and related technologies for IBM’s clients.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top