Different Portal build And deployment strategies

0 comments



Portal development is inherently a complex process. Unlike typical J2EE applications which produce a single EAR file portal development produces various kinds of artifacts and involves different people roles. A tight Build and Deployment strategy becomes necessity for successful portal implementation.

Success of portal development is very much dependent on Build and Deployment process employed, which is often put on second priority. It’s very important to keep Build and Deployment strategy very clear and tight and automate all the tasks so that they are efficient and repeatable.

The build and deployment process involves different kinds of challenges in portal development.

Solution Release

As mentioned earlier portal development cycle produces a number of elements. These elements can be broadly classified as:-

Portal Configuration – These elements include configuration done by administrators and shared across multiple users. These are stored in portal configuration database. Some of the examples are:
  • Portal content tree
  • URL Mappings
  • Portlet Application Configurations & Settings
  • Access Control Data
  • Themes & Skins
Portal Artifacts – These are all the software deliverables created by portal developers and are stored on portal file system. Some of the examples are:
  • Themes and Skins (JSPs & style-sheets)
  • Portlet Code
  • J2EE artifacts
  • Servlet Filters / Portlet Filters
Extension Artifacts – These elements are not part of core portal installation but are required for functioning of portal. These can be stored in portal configuration or portal file system. Some of the examples are:
  • Portal Search and search collections.
  • Web Content Management
  • Document Repository
  • Documents, flows, roles
  • Collaboration Components
Solution release is the portal site developed which meets all the business requirements and consists of all the types of elements mentioned above.

Generally for most of the portal development (medium to large scale) the Solution Release must be moved through different environments (test, qa, staging, production)

Tools for Managing Solution Release

Since a portal solution release consists of various different elements, there are various tools and utilities involved in managing a solution release.

IBM provides three tools out of the box to manage the solution release elements, specifically the elements which are stored in portal configuration database. The following section provides a brief description of these tools.

IBM tools:

XMLAccess – This is a command line tool, which connects remotely to a Portal server using an HTTP connection. Its used to process portal resources like pages, portlets etc. Typically it’s used in the initial release to install full portal solution release.

Release Builder – This is a command line tool, which compares two xml access files and produces a differential output file, which could be installed on portal server using XMLAccess tool. Typically it’s used in subsequent releases to install only the differential solution release rather than full portal. Before advent of release builder, portal administrators would have to manually compare xml access files from old and new releases to create a differential release file by manually merging the files and manually deleting the obsolete features. Only other option was to wipe out entire old portal configuration and do a full install of new portal solution release. Both the approaches were clearly error prone and risky. Release builder has greatly simplified the differential release management.

Site Management Tool – This is a new feature introduced with 6.1 release. Using Resource Manager Portlet administrator can publish pages/urls/labels etc from a source server to a destination server. The published resource becomes available to a select group of users to review and approve, once approved the resources can be promoted and made public to be accessible by authorized user.

It’s also possible to demote a resource or rollback to previous version of a resource.

All the three IBM tools mentioned above are only applicable to solution release elements that are stored in portal configuration database viz., Portal Configuration. For other elements such as Portal Artifacts one has to look at other tools and technologies and create custom scripts to automate their management. Some of the tools and utilities available are ANT, Jacl/Jython etc.

Tools applicability

The tools discussed in section above are applied to different elements of solution release to create automated, repeatable build and deploy process.

A typical solution release deliverables and corresponding tools to manage them are given below:
  • J2EE EAR/WAR files – Can be deployed using Jacl/Jython scripts
  • Portlet war files – XMLAccess + Release Builder can be used to deploy them
  • Themes & Skins JSPs, images, htmls etc – XMLAccess + Release Builder can be used to deploy them
  • Portal resource configuration (like pages, urls, labels etc) - XMLAccess + Release Builder or Site Management tool can be used to deploy them
The process of creating solution release deliverables can be completely automated using various available tools. Once such tool is ANT, an example of how an ANT project can be organized to create solution release deliverables, is given below:
  • buildJ2EE.xml – compiles and packages J2EE artifacts ( output is WAR/EAR)
  • buildPortlet.xml – compiles and packages portlet (output is WAR)
  • deployJ2EE.xml – distributes the WAR/EAR file to correct location on portal server file system, invokes Jacl/Jython scripts to deploy the WAR/EAR to the Websphere Application Server.
  • deployPortlet.xml – distributes the portlet WAR file to correct location on portal server file system, invokes XMLAccess script to install the portlet webapp on to Websphere portal server.
  • deployThemesSkins.xml – distributes the Themes & Skins files to correct location on portal file system, invokes XMLAccess script to install and configure the Themes and Skins.
  • installPortalConfiguration.xml – invokes the XMLAccess scripts to install the portal configuration.
Solution Release Life Cycle

This section suggests a life cycle for a typical portal development. It incorporates concept of continuous integration and agile development in development stages. There are proven benefits of continuous integration based development such as reduced risk, easy integration, rapid software development etc.

Developers, Administrators, Designers create solution release elements and check-in those to repository. The check-in process is mediated by a continuous integration tool like Team City. Team City triggers build and test suites for each check-in, commit is allowed only if build and test suite pass. This ensures that no check-in to repository is breaking the code integrity and allows easy integration.

The builds and deployment happen at developer’s workstation and on development servers.

At certain timeline when solution release complete, release manager pulls out source from repository and triggers build on build on machine. This is typically an ANT script which compiles & packages J2EE, Portlets and Themes/Skins files. The compiled deliverables (J2EE EAR/WAR, Portlet WAR, and Themes/Skin JAR, XMLAccess files) are checked into software distribution tool such as CA Harvest.
At appropriate timeline release manager promotes the solution release deliverables to TEST region. The software distribution tool (CA Harvest) actually sends down the selected version of deliverables to the TEST servers and triggers deploy scripts on the TEST servers.

The deploy scripts are combination of ANT, Jacl/Jython, XMLAccess, Release Builder tools.

The sequence of events that happen on target server during promotion:
  • ANT script distributes the deliverables to designated places on file system
  • ANT script triggers Jacl/Jython scripts to install J2EE components.
  • ANT script triggers XMLAccess script to install portlets.
  • ANT script triggers XMLAccess script to install the pages, labels, themes, skins etc.
  1. After good amount of testing on TEST server, the Release Manager promotes the solution release to QA. The promotion event triggers same steps as outlined in step 3.
  2. Once solution release is stable in QA it’s promoted to Staging, which is always in close sync with PRODUCTION. The promotion event triggers same steps as outline in step 3, except for following:
  3. ANT script triggers XMLAccess script to take export of portal configuration after solution release is deployed.
  4. ANT script triggers XMLAccess script to take export of portal configuration from the PRODUCTION server.
  5. ANT script triggers Release Builder to compare the current staging and current production configuration and create a differential file.
  6. The differential file is checked into Harvest.
On production date, the solution release is promoted to PRODUCTION. The promotion event triggers following steps:
  • ANT script distributes the deliverables to designated places on file system
  • ANT script triggers Jacl/Jython scripts to install J2EE components.
  • ANT script triggers XMLAccess script to install portlets.
  • ANT script triggers XMLAccess to install the portal configuration from differential file created on Staging env.

No comments:

Post a Comment

Recent Posts

Popular Posts

© 2011-2019 Web Portal Club