Building a Release

 

+

Search Tips   |   Advanced Search

 

You can use ReleaseBuilder to compare the XML configuration files describing REV1 and REV2 portal servers, and create an XML configuration file containing the differences between the two servers. Use this output file to import only the differences into REV2. Features that are unchanged from REV1 on REV2 are not affected by the import.


Before you begin

Before you run ReleaseBuilder, see Manual steps prior to using ReleaseBuilder.

Running ReleaseBuilder on the production server is not advised because ReleaseBuilder will consume resources and affect portal services to users.


Setting up a staging system

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. Export the release from the staging server.

  4. Empty portal contents from the production server.

      cd profile_root/ConfigEngine
      ./ConfigEngine.sh empty-portal task,

  5. Import that release onto the production server.

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

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 the following method:

    • After configuring the staging server, run...

        ConfigEngine.sh|bat empty-portal task.

    • Import the production release onto the staging server.

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

    • Export that new release from the staging server.

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

    • 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

The empty-portal task acts on the base portal only and should not be relied upon to delete virtual portals or empty virtual portals of content.


Steps for this task

XML configuration files are used by ReleaseBuilder to create a differences XML configuration file. This file 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. Export the staging server configuration REV1

    Export the entire portal configuration REV1 of the staging server; do not include users, users' access control, or any other user configurations.

    1. On the staging server change to the profile_root/PortalServer/bin directory.

      This is the directory that contains the portal tools.

    2. Export the staging server REV1 configuration by using the XML configuration interface and the provided sample file named ExportRelease.xml by entering the following command:

        ./xmlaccess.sh -in ExportRelease.xml -user wpsadmin -password wpsadminpwd -url http://stagingserver.example.com:port/wps/config -out stagingserverREV1_config.xml

      The exported configuration is stored in the stagingserverREV1_config.xml file.

  2. Develop and test new functions and portlets on the staging server.

    This phase is where you add or delete functions. Note that this phase can last for a very long time. Ensure the staging server is fully tested and the portal is ready.

  3. Export the staging server configuration REV2

    Export the entire portal configuration REV2 of the staging server; do not include users, users' access control, or any other user configurations.

    1. On the staging server change to the profile_root/PortalServer/bin directory.

      This is the directory that contains the portal tools.

    2. Export the staging server configuration REV2 by using the XML configuration interface and the provided sample file named ExportRelease.xml by entering the following command:

        ./xmlaccess.sh -in ExportRelease.xml -user wpsadmin -password wpsadminpwd -url http://stagingserver.example.com:port/wps/config -out stagingserverREV2_config.xml

      The exported configuration is stored in the stagingserverREV2_config.xml file.

  4. 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 the profile_root/PortalServer/deployed/archive installation directory 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.

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

    Perform these steps on the staging server and not on the production server. Computing a release difference produces a high load on the system and consumes a lot of memory for large releases, therefore do not perform it on the production system.

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

    2. On the server where you just stopped the portal server, change to the profile_root/PortalServer/bin directory.

    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 will contain the additions and deletions to be imported onto your production server.

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

  6. 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 -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.


Parent topic:

About ReleaseBuilder


Related reference


Manual steps prior to using ReleaseBuilder