Making updates with ReleaseBuilder

Use ReleaseBuilder to compare the XML configuration files that describe the staging server (REV1) and the updated staging server (REV2). We can also use it to create an XML configuration file containing the differences between the two servers. We can then use this output file to import only the differences from the staging server (REV2) onto the production server. Features that are unchanged from (REV1) on the staging server (REV2) are not affected by the import.

Verify the development, test, and production environments are configured to allow all of required artifacts and the configuration to be moved.

ReleaseBuilder is preferably run on an integration or staging server. Running ReleaseBuilder on the production server is not advised because ReleaseBuilder uses resources and affects portal services to users.

ReleaseBuilder uses XML configuration files to create an XML configuration file of the differences between the two servers. This XML configuration file is used to transfer the new portal configuration from the staging server to the production server. To export the configurations of the servers, use the XML configuration interface.

The XML files from the staging server (REV1) and from the updated staging server (REV2) refer to two exports taken from the SAME portal server. Building a release means to generate an XML file containing the same modifications made to the staging server between REV1 and REV2. ReleaseBuilder is not designed to determine the differences between or changes made to two separate Portal servers.

The following instructions describe the building of a release in installations, which do not use virtual portals. For instructions for staging virtual portals, refer to the topic about Building a Release for virtual portal installations.

1. From the staging server, export the staging server configuration REV1...

    cd WP_PROFILE/PortalServer/bin.
   ./xmlaccess.sh -in ExportRelease.xml 
                  -user wpsadmin_user_ID 
                  -password wpsadmin_pwd 
                  -url "http://stagingserver.example.com:port/wps/config" 
                  -out stagingserverREV1_config.xml
   

   Do not include users, users' access control, or any other user configurations.

   The exported configuration is stored in stagingserverREV1_config.xml.

2. Develop and test new functions and portlets on the staging server. This phase is where you add or delete functions.

   This phase can last for a long time. Verify the staging server is fully tested and the portal is ready.

3. From the staging server, export the staging server configuration REV2:

   cd WP_PROFILE/PortalServer/bin
   ./xmlaccess.sh -in ExportRelease.xml \
                  -user wpsadmin_user_ID \
                  -password wpsadmin_pwd \
                  -url "http://stagingserver.example.com:port/wps/config" \
                  -out stagingserverREV2_config.xml 
   

   Do not include users, users' access control, or any other user configurations.

   The exported configuration is stored in stagingserverREV2_config.xml.

4. If we installed extra portlets or applications, copy the necessary WAR files from the staging server to...
   prodserver:/path/to/PortalServer/deployed/archive

   The deployed/archive directory is always in the original WP_PROFILE installation path, even if the production server is using an extra profile created after installation.

   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 results in an error.

5. Generate the differences between staging server configurations REV1 and REV2:

   Complete these steps on the staging server and not on the production server. Computing a release difference produces a high load on the system and uses much memory for large releases. Therefore, do not complete them on the production system.

   1. Optional: Stop the portal server on the staging system. This option frees resources for computing the release difference.

   2. On the server where you just stopped the portal server, cd WP_PROFILE/PortalServer/bin.

   3. To generate the differences file containing the additions and deletions configuration file, enter one of the following commands:

      ./releasebuilder.sh -inOld stagingserverREV1_config.xml -inNew stagingserverREV2_config.xml -out outputfile.xml

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

      Optional: Restart the portal server on the staging system, if you stopped it before.

      Use the outputfile.xml, which contains the differences between REV1 and REV2 portal server to import these differences onto the production server.

      ./xmlaccess.sh -in outputfile.xml -user wpsadmin_user_ID -password wpsadmin_pwd -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.

      
      Parent Updates using ReleaseBuilder

      Related reference:
      
      Sample XML configuration files