Implementing Release Control Across Multiple Product Groups

Serena Release Control comes with multiple predefined projects. Which of these projects do you need to duplicate in order to limit product groups access to only their release packages, environments, deployment paths?
This article explains how you can configure Serena Release Control to work across the multiple product groups. It explains which projects you should create duplicates of and which projects can be left alone as they are only used in the background.
The following approach is designed for easier maintenance and future upgrades. 
Here are the topics covered:
  1. Creating Projects for Each Group
  2. Granting Privileges
  3. Updating Work Center Feeds
  4. Duplicating or Modifying Workflows
  5. Common Problems and Solutions



Creating Projects for Each Group

You can create separate projects to determine who has privileges to items. You do not have to create separate projects for all items, as some are only used in the background and trying to create duplicates of these projects will create headaches for future upgrades.
Note that after you have added the new projects, you must modify any post transitions to point to the new projects. For example, in the Release Train application, you must modify the “Add Milestone” and “Create Release Package” transitions.
Here are the recommend items to create separate projects for.  

·         Environments - Create another project under Environments Projects.

·         Deployment Paths - Since there is no subproject by default under the Deployment Path Project, you will want to add projects for both the new department and for the department using the default Deployment Path project. You will need to move the existing Deployment Paths into this project Also, it is recommended to turn off submissions into the base level Deployment Path Project so that no one submits into this project. 

·         Path Elements Group - Leave the one project. This project is not accessed directly so it is recommended that you leave it in the background.

·         Release Package - Create a separate project under Release Packages Project.

·         Environment Schedules – Leave the one project. This project is also not accessed directly but through other apps. If you must create another project for environment schedule, contact Serena Services for assistance.

·         Application Release - Create another project under Application Version Projects

·         Release Trains - Create another project under Release Trains Projects.

·         Manual Deployment Task - Can create another project. Afterward, you must add a provider configuration for submitting items into this project

·         Task Templates - Create a separate project under Task Template Projects

·         Approvals - No need for another project as these are usually accessed through the release train. If you want a new project, you will need to update the post transitions from release train to point to the new project.


Granting Privileges

To handle permissions for users, you will need to restrict each user’s access to only the projects that they should have access to. In addition, they will need to have the ability to "Run Guest Level" reports at the upper project level.
NOTE: That allowing users to “Run Guest Level” report at the upper level does not give them access to the data in projects they do not have privileges to. It does allow you to use the same reports for all users, allowing easier maintenance.
When giving permissions, remember that users need permission to submit into the Environment Schedule project if they are going to create Release Packages.
Here are the high level steps for adding these permissions:
1. In Application Administrator, under Groups, add a new group for each RLC role.
2. Under Roles for each new group, navigate to the projects that you added and enable the appropriate RLC role for that group.
3. Under Privileges, navigate to the high level projects and enable "Run Guest Reports" for Environments Project, Deployment Path Project, Release Packages Project.


Updating Work Center Feeds

Include the new projects in your Serena Work Center views. 
To modify the views:
  1. Select the view, such as "All Packages."
  2. Select Edit in the view. 
  3. Choose to modify the System View so it affects all users. 
  4. Edit the feed to include the new projects:
  5. Save the modified feed. 


Duplicating or Modifying Workflows

What if I need to modify a workflow specifically for one department?
It is recommended that you make a sub-workflow and modify that workflow for that one department. This will eliminate the need to modify all of the orchestrations/rules/groovy scripts associated with that application.  After modifying the workflow, you would choose that workflow for the project that you created.
But what if I really need to make a duplicate of a workflow?
Maybe you have to make a copy of the release control workflow due to the original workflow having already been modified for another department, the following are the high level steps that you need to perform for each process that you have created. In addition, there is an example of the specific list of changes that you would need to make if you duplicated the release package workflow.
In the duplicate workflow, you need to:
- Update all of the rules that check for the state value. Even though the new workflow has the same state name, it is considered a new state by composer and the rules need to be modified to include this new state.
- Update all of the orchestrations to point to the correct transition
- Update the groovy scripts to point at correct update transition. (C:\Program Files\Serena\SBM\Common\jboss405\server\default\deploy\rlc.war\WEB-INF\classes\scripts)
- Update the state forms (buttons/state form action)
TIP: After you deploy the new workflows, you will get new projects created in SBM. You can move the new projects underneath the existing projects by using the Move command in Application Administrator.


Common Problems and Solutions

  1. Calendar view does not work when viewing an environments. You need the ability to run guest level reports at high level environment project.
  2. You cannot create a Deployment Path. Verify that user creating a deployment path has the permissions to submit into Path Elements project. 
  3. User cannot submit schedule maintenance/other when adding new project. You need to modify the post settings for the "Schedule Maintenance" and "Schedule Other" transitions using Application Administrator. Choose the new projects for submitting into.
  4.  State box appears black on state forms. This problem appears if you have added a new workflow. In Composer, update the form action on the state form to include the new states from the new workflow.
  5. Buttons do not appear for transitions on state forms. In Composer, select the buttons on the Master State Form, and then on the Behavior tab, choose correct transition in the duplicate workflow.
  6. Deployment Path does not appear in selection list. If you add a second deployment path workflow, then you must update the "Active Deployment Paths" report to include the new active state in the other workflow.
  7. Release Package transitions such as being Link Package or Start Deploy are not available. This is due to the addition of a new duplicate workflow without the updating of the rule. In Composer, update the rules to add the states from the new duplicate workflow.
  8. The Link Packages transition does not work in the duplicate workflow. This fix requires updating the orchestrations and groovy scripts to point to the new system update transition in the duplicate workflow. See the detailed example of updating Release Package.
  9. Items not showing up on dashboard view in Serena Work Center. You need to add feeds to include the new projects that you have added. In the system view of Work Center, update the feeds to include the new projects.
  10. Create Release Package transition in Release Train opens up to error message. When you attempt to create a release package from release train, you see an error message. First, update the "Create Release Package" post transition to ensure that it is submitting into the correct release package project. Second, if you have added a new workflow for your release package, you will need to update this post transition to use the correct submit transition. It is recommended that you delete the “Submit from Release Train” transition, leaving only one “Submit” transition. This one will be used by default for this project and should fix any deploy error.
  11. Error when attempting to submit a release package or task template. This error can occur when you have attempted to create new Path Template project or Environment Schedule project. Delete these projects to continue. 

    The error message will appear as follows on the submit form:
    The Application Engine did not invoke Web service operation runScript at transition No and sent the following message: Error occurred during web service invocation:
    SOAP Fault Code: soap:Server
    SOAP Fault String: Fault occurred while processing.


New Release-Feature
Comment List
Related Discussions