Build a Release

 

+

Search Tips   |   Advanced Search

 

ReleaseBuilder allows you to compare the XML configuration files that describe server REV1 and server REV2, and create an XML configuration file that contains the differences between the two servers. This output file is then used to import only the differences from REV2 onto the production server. Features that are unchanged from REV1 on REV2 are not affected.

Before running ReleaseBuilder, verify all environments are configured to allow required artifacts to be moved.

ReleaseBuilder should preferably be run on an integration or staging server. Running ReleaseBuilder on the production server is not advised because ReleaseBuilder will consume resources and affect portal services to users.

If you have a completely new installation of the staging server and the production server:

  1. Install the staging server, then install the production server.

  2. Develop a release on the staging server.

  3. Build the release on the staging server.

  4. Empty portal contents on the production server.

      cd WP_PROFILE/ConfigEngine
      ConfigEngine.sh empty-portal

  5. Import that release onto the production server.

When using virtual portals as production servers, create the virtual portals using the create-virtual-portal task;

If you do not create the virtual portals using this task, the virtual portal instance is not empty and cannot be used to import a fresh release as a baseline.

If you already have a production server without a staging system:

  1. Export the release of your production server.

  2. Install an empty staging server using one of the following two methods:

    • Install the staging server with the flag...

        -W emptyPortal.active=True

    • After installing and configuring the staging server, run the task...

        ConfigEngine.sh empty-portal

  3. Import the production release onto the staging server.

  4. Develop and build a new release on the staging server.

  5. Export that new release from the staging server.

  6. Use ReleaseBuilder to generate the differential between the two releases.

  7. Import the differential onto the production server.

If you plan to use an existing virtual portal as a production server, remove the virtual portal and recreate it;


Steps for this task

XML configuration files are used by ReleaseBuilder to create a differences XML configuration file that will be used to transfer the new portal configuration from your staging server to your production server.

To export the configurations of the servers, use the XML configuration interface.

  1. Log on to REV1

  2. Export the entire portal configuration (not including users, user's access control, or any other user configurations) of REV1.

  3. Export REV1 configuration...

      cd WP_PROFILE/PortalServer/bin
      ./xmlaccess.sh -in ExportRelease.xml -user wpsadmin -password wpsadminpwd -url http://stagingserver.example.com:port/wps/config -out REV1_config.xml

    The exported configuration is stored in REV1_config.xml file.

  4. Develop and test new functions and portlets on the staging server. This phase is where functions are added or deleted. Note that this phase can last for a very long time. Ensure the staging server is fully tested and the portal is ready.

  5. Export REV2 configuration

    Export the entire portal configuration (not including users, user's access control, or any other user configurations) of REV2.

  6. Log on to REV2

  7. Export REV2 configuration using the XML configuration interface and the provided sample file named ExportRelease.xml...

      cd WP_PROFILE/PortalServer/bin
      ./xmlaccess.sh -in ExportRelease.xml -user wpsadmin -password wpsadminpwd -url http://stagingserver.example.com:port/wps/config -out REV2_config.xml

    The exported configuration is stored in REV2_config.xml file.

  8. If you have installed other portlets or applications additional to the ones shipped with the portal, copy the necessary WAR files from the staging server to...

      WP_PROFILE/PortalServer/deployed/archive

    ...on the production server.

    As Windows limits the maximum path length to 260 characters, the name of the WAR file must be 25 characters or less. Installing a WAR file with a name that is more than 25 characters will result in an error.

  9. Analyze REV1/REV2 staging server differences

    1. Stop the WebSphere_Portal server.

    2. Generate the differences file containing the additions and deletions configuration file...

        cd WP_PROFILE/PortalServer/bin
        ./releasebuilder.sh -inOld REV1_config.xml -inNew REV2_config.xml -out outputfile.xml

      The resulting output configuration file will contain the additions and deletions to be imported onto your production server.

  10. The outputfile.xml which contains the differences between REV1 and REV2 portal server is then used to import these differences onto the production server.

      ./xmlaccess.sh -in outputfile.xml -user wpsadmin -password wpsadminpwd -url http://productionserver.example.com:port/wps/config

    If portlet parameters are deleted from a configuration, the output script generated by ReleaseBuilder does not remove those parameters on the target system.

    XML files generated by ReleaseBuilder do not have any transaction levels set. To set a transaction level edit the XML file generated by ReleaseBuilder and add the transaction level to the XML file.

  11. Restart the server1 and WebSphere_Portal servers.

 

Parent topic

About ReleaseBuilder