Turn Off Tabs
Release Control 6.2 Release Notes
These Release Notes contain information about this release. Last updated on 2017-11-06.

Contents

About this Release

Welcome to Release Control 6.2.

See the What's New tab for a complete list of new features in this release.

Please note the following important information:

  • Before installing Release Control, please consult the Release Control Installation and Setup Guide on the Documentation Center for the detailed process. There are required steps before and after running the installer to complete a working Release Control solution.
  • Before you install Release Control 6.2, you must ensure you are running SBM 11.1 or higher. SBM installations are documented in the SBM Installation and Configuration Guide and SBM upgrades are documented in the SBM readme. If you are upgrading SBM and already have an earlier version of Release Control installed, see Pre-Upgrade Steps.
  • An updated set of plugins is available for this release. For details, see the Release Control Plugins Release Notes on the Documentation Center.

New Installations of Release Control

If this is a new installation, download Solutions Business Manager version 11.1 or higher from Support website and then follow the instructions in the SBM Installation and Configuration Guide to install and configure Solutions Business Manager.

CAUTION:
If you plan to install Release Control on SBM 11.3, the default SBM installation file path is too long. It will cause the promote of Release Control process apps to fail. When installing SBM 11.3, change the installation path to something shorter, such as C:\Program Files\Serena or C:\Program Files\MF.

After you have verified that Solutions Business Manager is installed successfully, download Release Control version 6.2 from Support website and follow the installation and configuration instructions in the Release Control Installation and Setup Guide.

Installer Components

The installer delivers these components:

  • Solution Files – You import the Release Control 6.2 solution file in Application Repository. The Release Control solution file contains the following process apps:
    • RLC - Approvals
    • RLC - Environment
    • RLC - Manual Deployment Task
    • RLC - Release Data
    • RLC - Release Package
    • RLC - Release Train
    • RLC - Sample Request
    • RLC - Task Templates
  • Framework Files – The framework files augment your underlying SBM installation and enable certain features in the Release Control process apps. The framework files include new templates, images, and code.
  • Provider Plugins – The Provider plugins installed with Release Control enable integration with other products for request and deployment information and execution. You configure Provider server and database settings in the Release Control Administration.
  • Release Control SDK Files – The Release Control SDK files installed with Release Control enable you to write your own custom Provider plugins.

Supported Configurations

Detailed information about supported platforms and software configuration is available in the Supported Platform List.

Important:
  • SBM Support:

    Release Control 6.2 is not supported for SBM versions earlier than 11.1.

  • SBM Interfaces

    Work Center is required for Release Control.

  • Web Browsers

    Internet Explorer versions earlier than 11 are not supported for Release Control.

    Compatibility mode must be deselected in all versions of Internet Explorer.

Third-party Tools

For more information regarding third-party software copyrights and license information, see the Attribution Report.

What's New

For information on changes included in this release, see the following:

Enhancements

The following enhancements are included in this release.

  • Environment Approvals
    • You can now add approvals for environments, so that approval must be given upon deployment to those environments.
    • Approvals are automatically generated based on rules that are pre-configured in an auxiliary table.
  • Parallel Deployments
    • You can now initiate the same set of tasks in multiple environments at once using environment groups.
  • Environment Support on Task Templates
    • You can now add environments to task templates for ease in reusing deployment task configurations. Options are as follows:
      • Tasks can be configured for each environment

      • Scheduling is supported in the templates

      • Partial setup is supported
      • When added to a release package, any environments that do not match those in the release package require manual configuration
  • Task Scheduling
    • You can now schedule deployment tasks using the following options:
      • Specific Time (with optional Grace Period)
      • Opportunity Window
      • Time Window
      • Delay
      • Hold Until Released
  • Train Driven Deployment
    • A new deployable release train enables you to drive deployment from the release train.
      Note: Planning release trains have been maintained for backward compatibility.
  • Failure Tasks
    • You can now configure a set of deployment tasks to be executed if deployment fails. These are executed in all environments targeted by the original deployment request.
  • Release Control Administration Interface

    A new Release Control Administration interface is available at a new link. For example:

    http://serverName/workcenter/tmtrack.dll?StdPage&Template=rlc/admin

    The new interface enables administrators to do the following:

    • Install and add provider plugins and their configurations
    • Create and manage configurations, including:
      • Easily update shared content at the base level so that it is inherited by configurations under that base
      • Manage which fields are allowed to be overridden
      • Allow and set overrides to base settings at the configuration level
      • Easily copy relevant fields into auxiliary tables and the SBM Composer properties editor
    • Create and manage tags to enable filtering of collection data and configuration overrides for field value selections
  • Object Creation
    • You can now create objects in the following integrating products directly through the provider plugins:
      • ChangeMan ZMF change packages
      • Dimensions CM baselines and requests
      • Deployment Automation snapshots
      • JIRA items
      • ServiceNow items
  • Provider Polling
    • The system uses an internal scheduler to allow polling for results within plugins, which eliminates the need for callbacks in integrating products. The following plugins include this by default:
      • Jenkins
      • Nolio
      • ChangeMan ZMF
  • Provider Generalization
    • An object provider is used instead of separate providers for requests and deployment units. This gives the flexibility of creating multiple objects per plugin. For example:
      • For Dimensions CM, a single plugin now enables requests to be associated as requests and as deployment units
      • For Deployment Automation, a single plugin now handles functionality for component versions and snapshots
    • Tags in Release Control Administration are used to group and identify requests and deployment units.
    • All plugins have been updated to use the new architecture. Functionality available is as follows:
      • JIRA - Add and create JIRA items

      • SBM - Add, create, and transition SBM items

      • ChangeMan ZMF - Add, create, and deploy change packages

      • Deployment Automation - Add, create, and deploy snapshots and add and deploy component versions, all from a single plugin

      • Dimensions CM - Add and create baselines and requests from a single plugin

      • ServiceNow - Add, create, update, and check status of Service Now items
  • Provider Independence
    • Providers can now handle notifications in the plugin without needing to change the core system.
    • Any message type is supported.
    • Multiple versions can be run simultaneously.
    • Upgrade support is included.
    • Plugins have been moved to their own location for simpler management.
  • Locking/Unlocking to Disallow Linking Release Packages
    • You can use the lock and unlock transitions to prevent linking of release packages to deployable release trains and release packages.
  • Support for SBM 11.1 and higher
    • Release Control now runs under SBM versions 11.1 and higher.
  • Other Changes
    • Release Packages: By default, Return to Construction now returns the release package to the beginning of the workflow. It does not invoke any failure tasks, and a rule is set that will not allow this transition if you are requiring failure tasks.
    • Deployment Tasks: For deployment tasks created using Release Control version 6.2, you can view existing deployment task information without a live connection to the integrating system.
    • Deployment Executions: You can now see all parameters that were used for executing tasks by clicking the eye icon beside an execution title.
    • Bypass Deployment Complete Option: This option has been removed, so you can no longer choose to bypass the Deployment Complete state. Users must manually transition to the Deployment Complete state.

Defect Fixes

Several defects were fixed in this release. For the full list see the Knowledgebase.

Upgrades

This section provides important information for upgrades to Release Control 6.2.

Important: If you do not follow the snapshot promotion exactly as documented during the process app upgrade, you could get unexpected results.

Before you upgrade, review the following sections, and then proceed with the upgrade.

About Upgrades

The upgrade process consists of the following phases:

  • In the installation upgrade phase, you run the Release Control 6.2 installer and configure your installation using SBM Configurator. This does the following:
    • Installs the newest versions of the framework files, and configures your installation to use the new files.
    • Automatically upgrades all default plugins to version 3.0. Any previously-added plugins and their configuration will automatically use the upgraded jar files.
  • In the solution upgrade phase, you import the new solution file and decide if you will preserve or overwrite any modifications that you have made to the process apps.
Note: You should at minimum run the installation to upgrade the framework. You will benefit from performance improvements and any framework issues that were fixed. If you decide not to do the solution upgrade phase, you will not have access to process app modifications made in this release.

Pre-Upgrade Steps

Before you begin the upgrade process:

  1. You should finish deploying or cancel execution for as many release packages as you can. However, if you cannot do this or have already upgraded without doing this, you can transition these as needed after the upgrade.
  2. If you have any plugins that do not have configurations, you must delete these in the Release Control Providers administrator page before upgrading.

    An example link for the administrator page is as follows:

    http://serverName/workcenter/ tmtrack.dll?shell=swc&StdPage&template=rlm%2fprovideradmin

    If you do not delete any plugins with no configurations before upgrading, the new Release Control Administration cannot display plugin information after the upgrade.

    See Troubleshooting Upgrades if you encounter this issue after upgrading.

  3. If you are using the ServiceNow plugin and have an existing configuration that references multiple ServiceNow tables, you must create a different configuration for each table. After upgrade, the configuration will just contain information for a single table and some configuration settings may be lost for other tables.
  4. Back up Release Control, including all plugin jar files, before upgrading SBM.
    1. Backup up the contents of the following directory:

      C:\Program Files\Serena\SBM\Common\Tomcat 7.0\server\default\webapps\rlc\WEB-INF\lib

    2. Backup your existing database before you run the Release Control installer.
  5. If you are not on SBM to version 11.1 or higher, you must upgrade before beginning the Release Control upgrade. For details, see the Release Notes on Documentation Center on the SBM page. The Release Control upgrade will NOT work on earlier versions of SBM.
    Note: If you're upgrading from Release Control 6.0.1, you must manually back up your plugins before upgrading SBM.
  6. If you want to preserve any changes you have made in your process apps, use the Compare feature in SBM Composer to create a comparison report. (If you do not want to preserve your changes, or if you did not customize the apps, skip this step). You will use this report to help you merge your modifications into the new apps. For details on using the Compare feature, see the "Comparing and Merging Process Apps" topic in the SBM Composer Guide.
  7. If you didn't do this earlier, create a backup of the installation directory structure for SBM on your SBM Application Engine machines.
  8. Download the latest version of Release Control from the Support website.

Installation Upgrade

The instructions in these Release Notes are for upgrading your installation from version 6.0.1 or later. If you are upgrading from a version earlier than 6.0.1, please contact Support.

Upgrading from Version 6.0.1 or Later

To upgrade your Release Control framework from version 6.0.1 or later:

  1. Run the Release Control version 6.2 installer on the server or servers that have the following SBM components enabled:
    • SBM Application Engine
    • SBM Application Repository
    • SBM Common Services
    Note: If these SBM components are enabled on separate servers, you must run the installer on each server.
    The "Welcome to the Install Wizard" message appears. Click Next to continue.
  2. Allow the installation to complete.
    Note: For new installations, the directory defaults to the Program Files\Micro Focus location. For upgrades, it defaults to the existing installation location, typically Program Files\Serena.
  3. After the installation is finished, click Configure to launch SBM Configurator.
  4. Click Apply to apply the solution files to SBM. This stops the services, updates various configuration files on the server, and prepares the system for use.
  5. Click Close to close SBM Configurator, which forces it to start all necessary services.
  6. Give the services time to restart, and then log in to Work Center using the following URL:
    http://serverName/workcenter
    Important: Launching Work Center immediately after clicking Apply and closing SBM Configurator is an important part of the upgrade process. This enables SBM Application Engine to import the new framework files.

You have now upgraded the framework files and completed the installation upgrade phase. To upgrade your process apps to the latest versions, you must continue with the next section.

Upgrading the Process Apps

If you want to upgrade your process apps, continue with this section. If you do not want to upgrade your process apps, and prefer to continue working with an earlier version that you have customized, continue to Upgrading Without Promoting New Process Apps.

To upgrade your process apps:

  1. After you have finished the installation upgrade phase, launch SBM Application Repository, and then import the Release Control 6.2 solution file.

    After import of the new solution:

    • Earlier versions of Release Control solution files are deleted and in SBM Application Repository, and the Installed Solutions section shows only the latest version.
    • The snapshots and process apps are available for deployment or promotion.
  2. For each process app, choose one of the following options:
    • Compare, merge, and deploy the process apps

      If there are custom modifications that you made to the process apps that you want to preserve, review the comparison report that you generated as part of the pre-upgrade process. Use SBM Composer to compare and merge your changes into the new process apps, and then deploy them.

      Note: You won't get the latest reports unless you promote the new snapshots. See Knowledgebase item S142151 for recommendations on how to resolve this.
    • Promote the process app snapshots
      1. In SBM Application Repository, promote the new versions of the snapshots without comparing and merging, which will overwrite your modifications (if any). Promoting the snapshots places the latest contents of the solution, including all reports, notifications, process apps, and auxiliary table data, onto your SBM Server.

        Promote in the following order:

        1. RLC - Approvals
        2. RLC - Environment
        3. RLC - Manual Deployment Task (optional)
        4. RLC - Release Data
        5. RLC - Release Train
        6. RLC - Release Package
        7. RLC - Sample Request (optional)
        8. RLC - Task Templates

        When promoting, in the Entities tab, do the following:

        1. For all snapshots, select the Merge conflicts check box to preserve changes that you made to the existing application.

          For example, if you want to keep the user roles that you added to an application, select the Merge conflicts check box to preserve them in the target environment after the promotion. If Merge conflicts is not selected, the existing entities will be deleted in the target environment.

        2. For RLC - Release Data only, deselect the Include entity data check box to preserve changes that you made to the default RLC Custom Column auxiliary table entries, Default DU Custom Columns and Default Request Custom Columns. If you do not do this, these entities will be replaced in the target environment with default fields, and you will need to reconfigure the fields as needed.

        3. For RLC - Release Package only, deselect the following reports:
          • RLC Deployment Items Execution Log for Deployment Path
          • RLC Deployment Log for Release Package
          • RLC Deployment Units for Environment
          • RLC DU Execution Log for Deployment Path
          Tip: To do this, select the Reports sub-tab, select Selected, and scroll down to deselect these reports.
      2. Prepare the views for the deployment information tables as follows:
        1. Open a command prompt.
        2. Navigate to the following SBM folder:

          \Application Engine\bin

          For example, here are the commands to navigate to the default location:

          cd\

          cd Program Files\Serena\SBM\Application Engine\bin

        3. Execute the following command and wait for it to complete:

          ttadmin.exe /GenerateViewsAllowDelete

      3. Promote the Release Package snapshot again, this time with the Merge conflicts check box and all reports selected in Entities..

        The solution views now appear in the Release Package process app as the following tables:

        • RLC Deployment Log
        • RLC DU Execution Log
        • RLC DU Environment (New in this release)
      4. To ensure that all release package metadata is saved in SBM, promote the Release Package snapshot for a third time, this time with the Merge conflicts check box and all reports selected in Entities.
      5. In Application Administrator:
        • Give privileges to all groups for the RLC DU Environment table generated in step c and any other new privileges needed for your implementation.
        • Verify privileges remain set properly for all groups for the other tables:
          • RLC Deployment Log
          • RLC DU Execution Log

        For more information, see "Creating Groups and Assigning Roles and Privileges" in the online Help or Release Control Installation and Setup Guide.

      6. Any release packages left in the Deploying, Deployed, or Deployment Error states must have an addition transition executed to complete properly after upgrade.

        After promoting all new process apps, run the Upgrade Release Package transition on all release packages. Any release packages in the deploying, deployed, and deployment error states will be upgraded. You can see if a release package is upgraded by looking at its latest deployment. If it has a blank Grp ID field, it has been upgraded.

        For more details, see Knowledgebase item S142123.

      7. Review the "Creating Release Elements" section of the Release Control Installation and Setup Guide for any new elements you may need to add. For example, approval rules must now be predefined.

Upgrading Without Promoting New Process Apps

If you decide to upgrade without promoting the new process apps, or only want to promote some of them, ensure you run the installation to upgrade the framework. See Installation Upgrade.

After that you need to do some additional steps to ensure the earlier versions of the process apps work with the upgraded framework. You will benefit from performance improvements and any framework issues that were fixed, but you will not have access to new functionality offered in the new versions of the process apps, such as failure tasks.

See Known Issues in these Release Notes for issues you may encounter and how to work around them.

Note: You won't get the latest reports unless you promote the new process apps. See Knowledgebase item S142151 for recommendations on how to do this.

Plugin Upgrades

This release supports multiple versions of plugins. For details, see the Release Control Plugins Release Notes.

Installed Plugins

The plugin instances and their configurations will automatically use the versions of the jar files installed with version 6.2, because earlier versions of the plugins are not supported. However, if other supported versions of the plugins are manually installed, existing plugin instances are not automatically upgraded to use the new versions. Instead, an upgrade notification appears in the Release Control Administration UI and you can choose to manually upgrade instances of the plugin when you are ready. After upgrading plugins:

  • If you have existing requests or deployment units for the upgraded plugins, in each release package in the Requests or Deployment Units tab, click Reload Request Data or Reload Deployment Unit Data respectively to pick up any plugin changes.
  • If you have existing deployment tasks for the upgraded plugins, in each release package in the Deployment Tasks tab, edit and save the deployment tasks to populate them with the provider data that was stored differently in the prior release.

For additional instructions for specific plugins, see the Release Control Plugins Release Notes.

Additional Plugins

To upgrade custom plugins or to upgrade to a version released after your version of Release Control, see the Release Control Plugins Release Notes Upgrades section.

Related Upgrades

You may need to upgrade SBM before upgrading to this version of Release Control.

Troubleshooting Upgrades

After upgrading, you may encounter one of the following issues:

  • Some transitions are not working properly, such as associating child release packages to parents.

    Check to see if your target server URLs have changed. If so, you must re-promote or redeploy the process apps in SBM Composer.

  • Existing release trains are locked after upgrade. see Knowledgebase item S142133 for instructions on how set the lock setting to unlocked through mass update.
  • The columns in the Deployment Units and Requests tabs no longer show the fields you had configured in the RLC Custom Columns auxiliary table Default DU Custom Columns and Default Request Custom Columns entities. This means those table entries may have reverted to the defaults. This happens if you upgrade without deselecting the Include entity data check box in the Entities step when promoting the Release Data process app.

    If this occurs, you will need to reconfigure the default custom column entries as needed.

  • If you have issues with deployment path or deployment path history, you may have missing reports or settings. Ensure you have done the following:
    • Promoted the release package three times using the required settings for each promotion
    • Assigned all roles and privileges as documented

    Some symptoms of missing reports or settings:

    • You may have a message similar to "Contact Your Administrator" at the top of the page
    • You may not see any information in the deployment path history
    • The deployment units shown may be for all environments instead of for the environment for which they should be shown

    If these symptoms occur, see Knowledgebase item S142152 for the deployment path report settings. Compare your reports to these and fix them as necessary.

  • If any plugins had no configurations before upgrading, Release Control Administration cannot display plugin information and an error similar to the following example appears in rlc.log:

    Context initialization failed

    Error creating bean with name 'upgradeOldPlugins': Invocation of init method failed; nested exception is java.lang.IllegalStateException: There is no provider type BASE in provider ProviderPlugin [ id=10005 name=Jenkins]

    To fix this, you must delete the entry for the plugin from the database. See Knowledgebase item S142179.

    Tip: An example link for the new Release Control Administration interface is as follows:

    http://serverName/workcenter/tmtrack.dll?StdPage&Template=rlc/admin

Known Issues

For a complete list of known issues and potential workarounds, see the Knowledgebase.

For issues related to plugins, see the Plugins Release Notes on the Documentation Center

Core solution issues known to exist at the time of release are as follows:

  1. After upgrading, when viewing deployment tasks that existed before upgrading, field names are shown as the field names from the database rather than the display names. (DEF294664)

    For deployment tasks that existed before the upgrade, only the information that was stored prior to the upgrade is shown. To refresh the deployment tasks with the current information from the provider, you must edit and save them.

  2. After upgrading, existing trains are locked by default. (DEF301859)

    After upgrading, the Train is Locked field is set to Yes or null for existing release trains, but set to No for new release trains. The result is that all existing release trains are locked.

    You can do a mass update to set Train is Locked field to No and then manually set it to Yes in any release trains that you want to lock. For details, see Knowledgebase item S142133.

  3. After upgrading, in release packages that existed before the upgrade, you will not be able to link existing requests to a deployment task. (DEF299245)

    Since requests and deployment units were stored in separate collections in earlier versions of Release Control, the release packages created in those versions still have them stored separately. To use the new feature of linking existing requests to a deployment task, you must add the requests so that they are in the new collection and then link them to the deployment tasks.

  4. If you upgrade without promoting process apps, you will see two execution reports on your Deployment Path tab in release packages. (DEF299372)

    To fix this, you must:

    1. Open the Release Package application in SBM Composer.
    2. Modify the Master State Form and ParentQuickview form to remove the embedded report from the Deployment Path tab.
    3. Deploy the Release Package process app.
  5. If any plugins had no configurations before upgrading, Release Control Administration cannot display plugin information. (DEF303521)

    If any plugins had no configurations before upgrading, Release Control Administration cannot display plugin information and an error similar to the following example appears in rlc.log:

    Context initialization failed

    Error creating bean with name 'upgradeOldPlugins': Invocation of init method failed; nested exception is java.lang.IllegalStateException: There is no provider type BASE in provider ProviderPlugin [ id=10005 name=Jenkins]

    To fix this, you must delete the entry for the plugin from the database. See Knowledgebase item S142179.

  6. If you upgrade without promoting process apps, the deployment unit view does not load. (DEF298719)

    If you do not promote the process apps after upgrading, when you try to view deployment units, you will see a blank page with a spinner, as the view cannot load. For information on how to fix this, see Knowledgebase item S142124.

  7. In clustered SBM environments, if you change something in Release Control Administration, Release Control may not automatically recognize the change because the changes may not be transferred to the other SBM Tomcat nodes. (DEF289915)

    If you change something in Release Control Administration, Release Control may not automatically recognize the change and may continue using the old values. The result is that you may have a message that objects, such as Deployment Automation applications, are not found, when the issue is that the login is failing due to the configuration change not being recognized on the correct node in the cluster. To resolve this, restart SBM Tomcat on all nodes.

  8. For deployment task scheduling Opportunity Window, the deployment does not allow the start value to be at an earlier time than the end time. Therefore, there is no way to start the window at a later time in the day and end at an earlier time of day the next day. (DEF294128)

    For deployment task scheduling Opportunity Window, you can specify a day and a 24-hour period of time, but that time cannot overlap into the next day. For example, if you want the window to be 11:00 pm on Monday to 2:00 am on Tuesday, you cannot use the Opportunity Window to do that.

  9. SBM 11.3.1 and Later Only: Environment groups can be created with environments belonging to different types. (DEF309344)

    If you are using SBM 11.3.1 or later, it is possible to successfully submit environment groups with environments that have different types, such as Standard and Restricted. This should be disallowed. All environments within a specific environment group should have the same type.

  10. Documentation: In the Release Control Installation and Setup Guide and online Help, the section title "Promoting Release Package Again with All Reports" should be named "Promoting Release Package Again".

    In the Release Control Installation and Setup Guide and online Help, the section title "Promoting Release Package Again with All Reports" is misleading, because for new installations, you do not need to deselect any reports for the first promotion of the RLC - Release Package snapshot. This is necessary only for upgrades.

For additional Known Issues, see Knowledgebase item S142175.