Serena Release Manager Guide

SERENA®SERENA RELEASE

MANAGERGetting Started Guide

Serena Proprietary and Confidential Information

Copyright © 2011-2013 Serena Software, Inc. All rights reserved.

This document, as well as the software described in it, is furnished under license and may be used or copied onlyin accordance with the terms of such license. Except as permitted by such license, no part of this publicationmay be reproduced, photocopied, stored in a retrieval system, or transmitted, in any form or by any means,electronic, mechanical, recording, or otherwise, without the prior written permission of Serena. Any reproductionof such software product user documentation, regardless of whether the documentation is reproduced in wholeor in part, must be accompanied by this copyright statement in its entirety, without modification. This documentcontains proprietary and confidential information, and no reproduction or dissemination of any informationcontained herein is allowed without the express permission of Serena Software.

The content of this document is furnished for informational use only, is subject to change without notice, andshould not be construed as a commitment by Serena. Serena assumes no responsibility or liability for any errorsor inaccuracies that may appear in this document.

License and copyright information for 3rd party software included in this release can be found on the product'snews page at http://support.serena.com/ProductNews/default.aspx and may also be found as part of thesoftware download available at http://www.support.serena.com.

Trademarks

Serena, TeamTrack, StarTool, PVCS, Comparex, Dimensions, Prototype Composer, Mariner and ChangeMan areregistered trademarks of Serena Software, Inc. The Serena logo, Version Manager and Mover are trademarks ofSerena Software, Inc. All other products or company names are used for identification purposes only, and maybe trademarks of their respective owners.

U.S. Government Rights

Any Software product acquired by Licensee under this Agreement for or on behalf of the U.S. Government, itsagencies and instrumentalities is "commercial software" as defined by the FAR. Use, duplication, and disclosureby the U.S. Government is subject to the restrictions set forth in the license under which the Software wasacquired. The manufacturer is Serena Software, Inc., 1850 Gateway Drive, 4th Floor, San Mateo, CA 94404.

Part number: Serena Release Manager 5.0

Publication date: 2013-12-13

2 Serena® Serena Release Manager

Table of ContentsPart 1: Overview ................................................................................................7

Chapter 1: Welcome to Serena Release Manager ...................................................9

About This Document .......................................................................................9

Getting Help ...................................................................................................9

Chapter 2: About Serena Release Manager ......................................................... 11

Key Terms ................................................................................................... 12

Release Manager Participants ........................................................................ 12

Typical Release Manager Flow ........................................................................ 13

Release Manager Processes ........................................................................... 14

About Release Trains ................................................................................. 15

About Application Releases........................................................................... 17

About Environments .................................................................................... 19

About Turnovers ....................................................................................... 19

About Runbooks and Deployment Tasks ......................................................... 21

About Approvals, Stage Gates, and Milestones ................................................ 22

About the Sample Process Apps .................................................................. 24

Release Automation Deployment Features ...................................................... 24

Key Metrics ................................................................................................ 24

Part 2: Installation .......................................................................................... 29

Chapter 3: Getting Started .............................................................................. 31

Overview ................................................................................................... 31

Serena Release Manager Install Components ................................................... 31

Installation Considerations ........................................................................... 32

Pre-Installation Checklist .............................................................................. 33

Chapter 4: Installing Serena Release Manager ................................................... 35

Installation Process Overview ........................................................................ 35

Running the Installer .................................................................................... 36

Chapter 5: Configuring Serena Release Manager ................................................ 37

Configuring Release Manager Authentication ................................................... 37

Getting Started Guide 3

Configuring Relationship Service ..................................................................... 38

Configuring Release Manager ........................................................................ 39

Accessing Serena Work Center........................................................................ 42

Chapter 6: Importing Serena Release Manager ................................................... 43

Importing the Solution ................................................................................. 43

Chapter 7: Promoting Serena Release Manager ................................................... 45

Promoting the Snapshots .............................................................................. 45

Chapter 8: Post-Installation Tasks ..................................................................... 47

Updating Endpoints ....................................................................................... 47

Starting the SBM Relationship Service ............................................................ 48

Setting Authentication for Orchestrations ......................................................... 48

Chapter 9: Troubleshooting .............................................................................. 51

Troubleshooting Imports .............................................................................. 51

Troubleshooting Promotions ........................................................................... 51

Troubleshooting Rest Grid Widget Errors ......................................................... 51

Troubleshooting Report Errors ........................................................................ 52

Part 3: Implementation .................................................................................... 55

Chapter 10: Configuring the Process Apps ......................................................... 57

Assigning Users to Roles .............................................................................. 57

Subscribing Users to Notifications .................................................................. 58

Reviewing the Application Group ..................................................................... 58

Chapter 11: Creating Release Artifacts ............................................................... 61

Creating Applications .................................................................................... 61

Creating Environments ................................................................................. 62

Creating Runbooks ....................................................................................... 63

Creating Release Train Templates .................................................................. 63

Chapter 12: Common Customizations ............................................................... 65

Customizing Approvals ................................................................................. 65

Changing Environment Options for Turnovers ................................................... 66

Part 4: Integration .......................................................................................... 69

Chapter 13: Integration Overview ..................................................................... 71


Chapter 14: Application and Environment Integration .......................................... 73

Application and Environment Integration Overview .......................................... 73

Auto Registration in Release Automation ......................................................... 73

Chapter 15: Business Request and Development Task Integration ........................ 75

Business Request and Development Task Integration Configuration ..................... 75

Configuring ServiceNow for REST Calls ............................................................ 76

Business Request and Development Task Integration Usage .............................. 77

Business Request and Development Task Integration Customization .................. 78

Business Request and Development Task Integration Architecture ..................... 78

Business Request and Development Task Transition Forms .............................. 78

Application Release Base State Form ......................................................... 79

Application Release Associate SBM Forms ................................................... 79

Application Release External Tool Forms ...................................................... 80

Application Release REST Grid Widgets ...................................................... 81

Application Release Form Actions ............................................................... 82

Turnover Base State Form ........................................................................ 83

Turnover Associate Dev Tasks Form ............................................................ 83

Turnover REST Grid Widgets ..................................................................... 83

Turnover Form Actions .............................................................................. 83

Chapter 16: Deployment Task Integration ......................................................... 85

Deployment Task Integration Configuration ...................................................... 85

Deployment Task Integration Usage ............................................................... 86

Deploying Dimensions CM Baselines ............................................................ 87

Deploying ZMF Change Packages .................................................................. 88

Deploying Using Nolio Processes .................................................................. 89

Deploying Using Other Plug-ins ..................................................................... 90


Part 1: Overview

This section contains the following information:

• Chapter 1: Welcome to Serena Release Manager [page 9]

• Chapter 2: About Serena Release Manager [page 11]


Part 1: Overview


Chapter 1: Welcome to Serena ReleaseManager

Serena Release Manager brings control, collaboration, and automation to your releaseprocess. Use Release Manager to bring visibility, traceability, and compliance across thebusiness, development, and operations teams in your enterprise.

• About This Document [page 9]

• Getting Help [page 9]

About This DocumentThis document describes Serena Release Manager and explains how to install, configure,and administer the solution. This guide's primary audience is administrators who willperform these tasks.

Release managers and other release participants, such as product owners and releaseengineers, may also find useful information in Chapter 2: About Serena Release Manager[page 11]. Online help is also available for these users on each form in Release Manager,as discussed in Getting Help [page 9].

This document is divided into these parts:

• Part 1: Overview [page 7]

Provides key terms and concepts and a typical release flow. Each Release Managerprocess is described, along with the interaction with Release Automation.

• Part 2: Installation [page 29]

Provides installation prerequisites and steps for server installation and configuration.Steps for importing the solutions and promoting process app snapshots are alsoprovided.

• Part 3: Implementation [page 55]

Explains process app implementation steps, such as preparing user accounts andcreating release artifacts, such as applications, runbooks, and environments.

• Part 4: Integration [page 69]

Provides information on configuring integrations for associating business requestsand development tasks with application releases and deploying using the ReleaseAutomation deployment hub.

Getting HelpAside from this document, Serena provides additional for configuring and using thisproduct.


Custom Online Help

Every Serena-provided solution that is powered by SBM includes end-user help that youcan customize to suit your needs. End-user help is added to solution design elements inSBM Composer, deployed as part of the solution, and shown to end users as they workwith items at runtime.

For details, refer to the SBM Composer Guide or SBM Composer online help.

Documentation Center

Visit the Documentation Center for the most current documentation for Serena productsand solutions, along with an extensive documentation archive.

Support and Knowledgebase

The support site at http://www.serena.com/support provides an extensive, searchableKnowledgebase and other information about Serena products.

You must have a serena.com user account to view items in the Knowledgebase. Registerfor a free account if you do not have already have one.

User Forums

Visit the Serena User Forums to interact with other users and learn more about using ourproducts.

You can view and search for information, but you must create and log in to a forumaccount to respond to articles and interact with other users.

Part 1: Overview


http://help.serena.com/doc_center/doc_center.html

http://www.serena.com/support

http://communities.serena.com/serena

Chapter 2: About Serena Release Manager

Release Manager brings control, collaboration, and automation to your releasemanagement activities by providing oversight and accountability to the various releaseteams in your organization. Release Manager bridges the communication and processgaps between your project management, development, and release engineering teams,while providing visibility and consistency to your entire release process.

Use Release Manager to create a repeatable process for all of your organization's releases,from mainframe and distributed applications to cloud and mobile apps.

Release Manager is powered by Serena® Business Manager and includes ReleaseAutomation.

Release Manager highlights include:

• Proactive dashboards, calendars, and reports

Provide immediate updates from the task to release train levels. Shared calendarsprovide visibility to your entire organization.

• Planning, tracking, and control for application releases

Streamline the process of assembling, managing, approving, and tracking releases.

• Managed deployments and environments

Streamline the transfer of releases between teams and reduce the build-to-deployment time for each release stage.

• Powerful release automation

Use Release Automation capabilities to design automated environments andintegrate with source control systems, application servers, and more. Easilyautomate environment configurations that provide a detailed audit trail.

• DevOps collaboration and coordination

Ensure compliance with release policies.

• Enterprise-level availability, security, and scalability

Bring governance and reliability to your release activities; capture subject matterexpertise for subsequent sharing.

The section includes the following information:

• Key Terms [page 12]

• Release Manager Participants [page 12]

• Typical Release Manager Flow [page 13]

• Release Manager Processes [page 14]

• Release Automation Deployment Features [page 24]


• Key Metrics [page 24]

Key Terms• Release Train

Calendar-based management of a set of application releases across various life cyclestages: schedule/scope, construction, verification, deployment. Refer to AboutRelease Trains [page 15].

• Application Release

Manages the release of a specific instance of one or more applications through arelease train. Refer to About Application Releases [page 17].

• Application

A deliverable attached to an application release.

• Stage Gate

A way to ensure exit criteria is met for each stage in a release train. Refer to ExitCriteria for Stage Gates [page 23].

• Milestone

Date-based activities against which progress can be measured. Milestones aretypically interim deliverables within a lifecycle stage. Refer to Milestones [page 23].

• Turnover

A scheduled deployment. Refer to About Turnovers [page 19].

• Environment

A set resources to which turnovers are deployed. Refer to About Environments [page19]

• Runbook

A template of ordered deployment tasks. Refer to About Runbooks and DeploymentTasks [page 21].

• Deployment Task

A step or set of steps in the deployment process. Deployment tasks can be manualor executed in Release Automation. Refer to Deployment Tasks [page 22].

Release Manager ParticipantsRelease Manager provides roles for users in your organization who may have the followingtitles and responsibilities.

• Release Managers

Ensure that a release process is followed over the entire life cycle of each releasetrain.

• Product Owners

Responsible for application releases.

Part 1: Overview


• Release Engineers

Responsible for working within the release process, including creating runbooks andaccepting and deploying turnovers.

• Developers

Responsible for development of applications.

• Approvers

Responsible for approving release trains, exit criteria for stage gates, andmilestones.

For guidance on assigning users to these roles, refer to Assigning Users to Roles [page57].

Typical Release Manager FlowThis section describes the standard successful flow for most release trains. The steps inthis section assume that Release Manager has been installed and configured, and thatrelease artifacts have been created using the steps in Chapter 11: Creating ReleaseArtifacts [page 61].

1. Release train is created.

• Release type, manager, purpose, and proposed scheduled are set.

• Approvals are defined (train, development, and executive).

• Environments are reserved for the train.

• Exit criteria are defined for stage gates.

• Milestones that apply to all application releases are added to the release train.

• Exit criteria set for the scoping stage gate is verified.

Scoping may be considered complete at this point. The release train may requireapproval at this stage gate to move to the construction phase.

Tip: To simplify the process of creating release trains, you can createtemplates that include most release artifacts. Refer to Creating ReleaseTrain Templates [page 63].

2. Application releases are created and associated with the release train.

• An application is specified for each application release.

• The schedule is set for each application release.

• Dependencies on other application releases are noted.

• Milestones are added to each application release. Common milestones may alsobe inherited from a release train.

• Business requests, development tasks, and other work items are associated withthe application release.


3. Construction on application releases is completed.

• Status is monitored through the release train and application release timelines.

• Turnovers can be created for each application release that are being executed.Typically, these turnovers are deployed to staging or testing environments.Successful turnovers can be promoted to different environments.

• Completed development tasks and business requests are associated with eachturnover.

• Deployment tasks are added to each turnover.

• Exit criteria set for the development stage gate is verified.

Development may be considered complete at this point. The release train mayrequire approval at this stage gate to the verification phase.

4. Release train is verified and approved.

• Exit criteria for the QA stage gate is verified.

• If approved by the release engineer, the release train is sent for executiveapproval.

5. Production turnover is created for the release train.

• Turnover is created and deployment is scheduled for all application releases onthe train.

• Deployment tasks can be copied from pre-production turnovers, then modifiedand reordered as needed.

6. Production turnover is delivered to release engineering team foracceptance.

• Release engineer reviews and accepts turnover.

7. Turnover is deployed on its scheduled date.

• Manual and automated deployment tasks are automatically created.

• Deployment tasks are completed in the sequence specified in the turnover.

8. Release train is completed.

• Once production deployment is verified, the release train is closed by the releasemanager or a release engineer.

Release Manager ProcessesRelease Manager includes the following process apps:

• Release Trains

Manages release trains from concept approval through scheduling and scoping,construction, verification, and deployment. Each train must meet specific exit criteriabefore it can pass to the next phase or "stage gate."

Refer to About Release Trains [page 15].

Part 1: Overview


• Application Releases

Manages the release of an application instance, such as a version. Business requests,development tasks, and other work items are associated with application releases.

Refer to About Application Releases [page 17].

• Turnovers

Manages deployments of release trains or application releases to variousenvironments through a set of deployment tasks.

Refer to About Turnovers [page 19].

• Environments

Create, schedule, and track environments.

Refer to About Environments [page 19].

• Runbook

A template of automated and manual tasks used for turnovers.

Refer to About Runbooks and Deployment Tasks [page 21].

• Approvals

Manages approvals for release trains, stage gates, and milestones.

Refer to About Approvals, Stage Gates, and Milestones [page 22].

• Manual Deployment Tasks

Tracks manual deployment tasks used for turnovers.

• Sample Business Requests and Development Tasks

Sample process apps that model how you can integrate custom SBM process appswith Release Manager. Refer to Chapter 15: Business Request and DevelopmentTask Integration [page 75]

About Release Trains

Release trains are a collection of application releases. Most release trains are plannedaround a specific time frame, such as a month or fiscal quarter, but some solve a specificproblem, such as improved security or database performance. Release Manager providesseveral types of release trains: major, minor, patch, and emergency.

Each release train item provides easy access to critical data points, such as schedules andmilestones, application release status, stage gate criteria, approvals, and turnovers.

At each phase, release participants and stakeholders can view the status of each releasetrain.

Release trains follow a process organized into these phases:

• Schedule and Scope [page 16]


• Construction [page 16]

• Verification [page 17]

• Deployment [page 17]

Tip: To ease the setup process, create release train templates, and then copythem for new trains as needed. For details, refer to Creating Release TrainTemplates [page 63].

Schedule and Scope

Participants:

• Release manager

• Approval board

A release manager submits a release train and specifies a train name and purpose, thetype of train (major, minor, patch, or emergency), the primary release manager, startand end dates for the train, and end-dates for each of the phases.

The release manager sets train approval requirements during this phase. For details, referto Release Approvals [page 22].

The release manager also completes the following tasks during scoping:

• Adds application releases to the release train and requests that application releasesbe added to a train. This task can be shared with product owners.

• Reserves environments for the train. For example, the release manager may reservedevelopment, testing, and production environments for a train.

• Adds exit criteria to each stage gate. For details, refer to Exit Criteria for Stage Gates[page 23].

• Associates environments with stage gates. For example, a QA environment may beassociated with QA exit criteria.

Once these activities are completed, the release manager sends the train to theconstruction phase. The release train cannot proceed if scoping exit criteria is not met,however.

Construction

Participants:

• Release Manager

• Approval board

Release trains are sent to development during the construction phase. In this phase, allapplication releases are typically under development. Most of the work during this phaseis managed through the Application Releases process app. For details, About ApplicationReleases [page 17].

When development is complete for all application releases on a train, the train is sent tothe release manager for development approval. If construction exit criteria has not beenmet or if the release manager rejects the train, it is returned to the product owner.

Part 1: Overview


After approval, the train progresses to the verification stage.

Verification

Participants:

• Release Manager

• Approval board

During verification, the release manager verifies that the QA exit criteria has been met,and then sends the release train for executive approval.

After executive approval, the train is deployed to production.

Deployment

Participants:

• Release Manager


During this final phase, the release manager determines that the train is ready fordeployment and deploys the train. Release engineers can also perform this task.

Once deployment sucessfully completes, the train is closed.

Other Actions

At various points during the process, a release manager can:

• Cancel the train.

• Add application releases.

• "Fast track" the train to bypass scoping, scheduling, and construction.

• Update train status (green, amber, or red).

• Create turnovers once a train has passed the scoping/planning phase.

• Copy a release train. For details, refer to Creating Release Train Templates [page63].

About Application Releases

Application releases help organize the work needed for applications included in a releasetrain. Business requests, development tasks, and other work items are associated with anapplication release. Once work is done on an application release, its associated applicationis deployed as part of a release train.

Application examples include a software product, a set of application components, orshared services. Application release examples might be a specific version, such as 5.0 or2013.

Typically, application releases must get approval to join a train. An application release canalso be removed from a train or rejected; rejected application releases can request torejoin trains.


At each phase, release managers, product owners, and stakeholders can view the statusof each application release.

Application releases follow a process organized into these phases:

• Planning [page 18]

• Execution [page 18]

Planning

Participant:

• Product owner

Product owners own and typically create application releases. They can do so from therelease train or separately, and then associate the application release with a train.Application releases require an associated application.

Once created, the application release enters planning. During this phase, the productowner defines the schedule for the application release and record any dependencies onother application releases.

Milestones, which represent work that needs to be done for the application release, areadded or inherited from the release train. Each milestone has an owner who is responsiblefor ensuring the work is completed.

The product owner also adds business requests, development tasks (enhancements anddefects), and other pieces of work to each application release. These requests and taskscan come from a variety of places:

• SBM Process Apps

Use the Sample Dev Task and Sample BR process apps as a model of how tointegrate your own SBM process apps with Release Manager.

• External Tools

Release Manager is configured to work with existing implementations of ServiceNowand JIRA. You can also configure other external tools for this purpose.

For details, refer to Chapter 15: Business Request and Development Task Integration[page 75].

Once planning is complete, the product owner sends the application release to theexecution phase.

Execution

Participant:

• Product owner

Work on business requests, development tasks, and other work items occurs during thisphase. The product owner monitors work during this phase; when work is complete, aturnover is created and the turnover is deployed.

Once an application release is deployed, it is closed.

Part 1: Overview


About Environments

Environments represent a set of resources to which turnovers are deployed. Environmentscan be reserved for release trains and linked to stage gates. Turnovers can then bescheduled for reserved environments.

Release engineers typically own environments. They schedule maintenance anddecommission environments as needed. Release managers can also perform these tasks.

Each environment has a schedule view that shows all turnovers and scheduledmaintenance for an environment. Scheduled events are also stored in the EnvironmentTurnover Events auxiliary table.

You can link each Release Manager environment to a Release Automation environment.You can create new Release Automation environments from Release Manager or you canlink to existing environments. For details, refer to Release Automation DeploymentFeatures [page 24].

Note: Environment data is synchronized from Release Manager to ReleaseAutomation, but changes made to environments in Release Automation are notsynchronized back to Release Manager.

Participants:

• Release engineers

• Release manager

Environments follow a process organized into these stages:

• Provision

Release managers or release engineers create logical environments and link them toa new or existing Release Automation physical environment. Each environment mustbe owned by a release engineer.

• Active

Once environments are placed online, they can be reserved for release trains.Turnovers and maintenance can be scheduled.

• Inactive

The environment owner, typically a release engineer, can take environments offlinefor maintenance, and return them back online when maintenance is complete.

• Environments that are no longer needed can be decommissioned.

About Turnovers

Turnovers are containers for steps and tasks used to deploy applications to anenvironment. Turnovers are created for release trains or application releases anddeployed to environments reserved for the release train.

Each turnover is tied to a single environment, but turnovers created from release trainscan contain multiple application releases. Turnovers created from an application releaseare specific to that release.

Turnovers that are successfully deployed can be promoted to a different environment.

Turnovers follow a process organized into these phases:


• Definition [page 20]

• Delivery [page 20]

Definition

Participants:

• Developers


Typically, developers create turnovers form application releases. Depending on theirprivileges, they can also do so from a release train. Regardless of where the turnover iscreated, it must be associated with an environment.

Turnovers can be created at these points in the release process:

• For release trains, turnovers can be created from the construction, verification, ordeployment stages of the process.

• For application releases, turnovers can be created when the release is in theExecuting or Closed workflow states.

Once a turnover is created, developers or release engineers can:

• Schedule deployment. You can see if your target environment has any schedulingconflicts. If so, you can modify your schedule or choose a different environment, ifone is available.

• Add deployment tasks. These can be newly created tasks specific to the turnover orcopied from runbooks and other turnovers. Deployment tasks can be added,reordered, or deleted until a turnover is deployed. For details, refer to The TaskCollection Widget [page 21].

• View and associate development tasks from the application releases associated withthe turnover. These tasks are considered to be complete and can be viewed byclicking the Show Delivered link on the Requirements/Development tab for arelease train or application release.

Once the turnover is defined, it is sent to a release engineer for acceptance. Onceaccepted, the turnover moves to the delivery phase.

Delivery

Participants:


Accepted turnovers move to the "Ready to Deploy" state until their scheduled deploymentdate.

Once a release engineer starts the deployment, deployment tasks are automaticallycreated in either the Manual Deployment Tasks process app or in Release Automation.Manual tasks must be completed by the task owner; automated tasks are completed inRelease Automation.

Once all tasks are complete, the turnover moves to the Deployed state. If any manual orautomated tasks fail, the turnover is sent to the Deployment Failed state. Failed turnovers

Part 1: Overview


can be retried or returned to development for more work. Previously successful steps canbe re-executed or skipped during a turnover "retry."

Successful deployments are then closed.

The Task Collection Widget

The Task Collection widget is available on all turnovers. To open the widget, click theDeployment Tasks tab for a turnover.

To add, copy, modify, or delete deployment tasks, click Edit Deployment Tasks in theupper right corner. Use the links in the upper right corner of the widget to modify the listof deployment tasks.

Once you have a task list, use one of these methods to change their deploymentsequence:

• Click the sequence column header to reorder the entire list.

• Double-click inside a row in the sequence column reorder individual tasks in the list.

For information on the deployment hub that populates the selections for deploymenttasks, see Chapter 16: Deployment Task Integration [page 85].

About Runbooks and Deployment Tasks

Runbooks are templates for a collection of ordered deployment tasks. These tasks can bemanual steps in the process or automated tasks that are executed in Release Automation.

Deployment tasks from approved runbooks can be copied to turnovers. Tasks can beexecuted sequentially or in parallel.

You can create runbooks that are available for any turnover or associate runbooks tospecific environments or applications. For example, you may create a runbook dedicatedto a specific production environment. Tasks from this runbook can only be copied toturnovers for the production environment.

Runbooks can be created directly from the Runbooks application or from turnovers.

Participants:

• Release engineers

• Release manager

Runbooks follow a process organized into these phases:

• Creation

Release engineers typically create a runbook and add deployment tasks. Tasks canbe also copied from other runbooks or turnovers.

Once tasks are added, the runbook is sent to a release manager for review.

For details on task creation, refer to the The Task Collection Widget [page 21].

• Active

Once a runbook is accepted, tasks can no longer be added or modified.


The runbook's tasks can be copied to turnovers, however, and reordered andmodified as needed. New deployment tasks can also be added to turnovers.

Note: To modify an accepted runbook, return it to the construction state.

• Inactive

Inactive runbooks are no longer available to turnovers.

Deployment Tasks

When a turnover is deployed, deployment tasks are created in the order specified in thesequence. As a deployment task is completed, the next task in the sequence is createdand completed. This process occurs until all deployment tasks are complete.

Manual deployment tasks are added to Release Manager project specified for the task inthe runbook and assigned to an owner; automated tasks are created and completed inRelease Automation.

Note: Once manual deployment tasks have been created, they can be used astemplate tasks for runbooks.

Once all deployment tasks are successfully completed, the turnover is automatically sentto the Deployed stage. If any tasks fail, the deployment fails.

For details on deployments, refer to About Turnovers [page 19].

About Approvals, Stage Gates, and Milestones

Approvals bring process and accountability to your release management activities.

Three types of approvals are provided:

• Release Approvals [page 22]

• Exit Criteria for Stage Gates [page 23]

• Milestones [page 23]

Release Approvals

Release approvals are intended for approval boards that need to approve a train atvarious phases. Release managers determine approval needs during the Scoping phase ofa release train.

Release approvals are added and managed from release trains; the Approvals process appstores approvals and determines the approval process, however.

Up to four levels of approval can be required for these approval types:

• Train approvals must be complete before scoping can begin. If approval is notrequired, the train proceeds directly to scoping.

• Development approvals must be complete before trains can be sent to verification.

• Executive approvals must be complete before trains can be deployed.

Part 1: Overview


Train and development approvals are optional, but executive approval is required for eachtrain. The release manager can enable overrides for each approval as needed.

Note: Approvals can be made by individual users, but not groups.

Exit Criteria for Stage Gates

Release managers can use stage gates to require individuals to approve a specific phaseof a release train. Pre-defined stage gates are Scoping, Construction, and QA.

Exit criteria may be added to each stage gate. For example, the QA stage gate may haveexit criteria for successful test automation runs.

If exit criteria is added to a stage gate, approval is required before the train can continuepast that gate.

The release manager is responsible for creating exit criteria for each stage gate. Exitcriteria owners are responsible for ensuring exit criteria are completed.

Use the Timeline view for release trains to monitor stage gates and exit criteria.

Note: Stage gates and exit criteria are added and managed from release trains;the Approvals process app stores these items and determines their process,however.

Milestones

Milestones are date-based activities against which progress can be measured. Forexample, you may create a milestone for completing drafts of technical documentation.

You can set completion dates and owners for each milestone. Milestone owners areresponsible for completing or rejecting milestones.

Milestones can be added to a release train or each application release. If you havemilestones that are common across multiple application releases, you can add them torelease trains and choose to also add them to all applications on the train. This actionautomatically occurs once the release train is moved to the Construction phase.

Use the Timeline view for release trains and application releases to monitor milestoneactivities.


About the Sample Process Apps

Release Manager provides two sample SBM process apps that model the integrationbetween your release process and work planned and completed for application releases:

• Sample Business Requests

• Sample Development Tasks

You can use these simple process as they are, modify them to better follow your internalprocesses, or use own processes.

For details, refer to Chapter 15: Business Request and Development Task Integration[page 75].

Release Automation Deployment FeaturesRelease Automation enables Release Manager to automate the deployment of releaseartifacts to the machines where the release software will be executed.

Release Automation applications and environments can be created or linked to directlyfrom Release Manager applications and environments. Release Manager users areautomatically registered in Release Automation the first time they access ReleaseAutomation applications or environments from Release Manager.

Through the application and environment associations and automation deployment tasks,Release Automation enables you to deploy to many enterprise platforms. Throughautomated deployment tasks, you can select pre-configured Release Automationprocesses that leverage the many Release Automation plug-ins, including specializedplug-ins for Serena Dimensions CM, Serena ChangeMan ZMF, and CA Nolio. You selectand sequence the deployment processes from Release Manager, but the details areconfigured in Release Automation.

For more details, refer to the following topics:

Chapter 14: Application and Environment Integration [page 73]

Chapter 16: Deployment Task Integration [page 85]

Key MetricsRelease Manager provides several views into your release activities:

• Release Dashboard [page 25]

• Timelines [page 25]

• Calendar Views [page 26]

• Activity Views [page 27]

• Custom Reports [page 28]

Part 1: Overview


These views are available when the Release Mgmt application group is pinned andselected. Views are available to all Release Manager users, but privileges determine whichdata is visible to users in each view.

Note: The default views cannot be deleted, but some can be modified as notedin each of the following sections.

Release Dashboard

The Release Dashboard includes widgets with graphical reports that show the overallhealth of your release activities. By default, widgets with the following reports areprovided:

• Current overdue milestones

• Open exit criteria

• Release train throughput

• Deployment failure by application release

• Turnovers by environment by state

• Release train status by type

Administrators can remove the default widgets from the Release Dashboard. They canalso add custom widgets. These changes are visible to all Release Manager users.

Users can resize and reorganize the widgets in the Release Dashboard, but they can onlyremove widgets they have added.

Timelines

Timelines present the overall status for release trains and application releases in acalendar format. Use the Release Train Timeline to see information about trains; use theApplication Releases Timeline to see information about releases.

For example:

1. By default, information is shown for all release trains or application releases. ClickView All to change the filter to show only active trains or releases. You can alsocustomize the timeline by selecting a different listing report.

Note: Changes apply only to the user currently viewing the timeline andfor the current browser session.


2. Select a train or application release to view its details.

3. Hover over icons or colors on the timeline to see specific details about a train orapplication release.

4. Click the Information icon to view a key.

Calendar Views

Release Manager provides several system calendar views that show various releasemetrics in a calendar view. Each of these system views has feeds that show schedules forthese applications; users can choose which of the feeds to view for a browser session.

The following default feeds are included with the system Calendar views:

• Release Calendar

▪ Release Trains - Shows end dates for all trains, along with train status.

▪ Application Releases - Shows the time span between the QA complete date andend date for all application releases, along with release status.

▪ Milestones - Shows due dates for all milestones, along with the approval state.

Part 1: Overview


▪ Turnovers - Shows last deployment date for all turnovers, along with deploymentresult.

• Release Trains/Application Releases

▪ Scoping Complete Dates

▪ Construction Complete Dates

▪ QA Complete Dates

▪ End Dates

▪ Due Dates of Milestones

• Turnovers/Environments

▪ Submit Dates

▪ Deployment Dates

• Approvals

▪ Due Dates

Administrators can edit and remove the default feeds from each system Calendar view.They can also add custom feeds. These changes are visible to all Release Manager users.

Users can add Calendar feeds to the system views, but they can only remove feeds theyhave added.

Activity Views

Release Manager provides system Activity views that give users easy access to releaseitems based on feeds.

Three types of Activity views are provided:

• Release Activity

Shows all release trains, application releases, approvals, environments, runbooks,and turnovers.

• My Activity

Depending on the selected application in the navigation pane, shows all items ownedby the logged-in user. For example, "My Approvals" shows all approvals owned bythe user who is logged in.

• All Activity

Depending on the selected application in the navigation pane, shows all items. Forexample, "All Release Trains" shows all release trains in the system.

Administrators can edit and remove the default feeds from each system Activity view.They can also add custom feeds. These changes are visible to all Release Manager users.

Users can add Activity feeds to the system views, but they can only remove feeds theyhave added.


Custom Reports

Release Manager includes the power of SBM reports, enabling you to define search,display, and sorting information for release activities. Reports offer real-time data basedon the report criteria, giving users current information when they need it. Several types ofreport formats are available, including lists, tables, and charts.

Reports can be added to Dashboard views. For details, refer to the Release Manageronline help.

Part 1: Overview


Part 2: Installation


• Chapter 3: Getting Started [page 31]

• Chapter 4: Installing Serena Release Manager [page 35]

• Chapter 5: Configuring Serena Release Manager [page 37]

• Chapter 6: Importing Serena Release Manager [page 43]

• Chapter 7: Promoting Serena Release Manager [page 45]

• Chapter 8: Post-Installation Tasks [page 47]

• Chapter 9: Troubleshooting [page 51]


Chapter 3: Getting Started

This section discusses the tasks that you perform before installing Serena ReleaseManager.

• Overview [page 31]

• Serena Release Manager Install Components [page 31]

• Installation Considerations [page 32]

• Pre-Installation Checklist [page 33]

OverviewThe Release Manager installation requires that you have a complete and functional SerenaBusiness Manager installation first. You must follow the steps in the SBM Installation andConfiguration Guide to install SBM before you install Release Manager.

You will run the installer on one or more SBM servers, depending on how you performedthe SBM installation.

The installation process depends on a variety of factors, such as the location of the SBMcomponents that you have installed. For example, you must install all of the SBMcomponents in order to have a working installation; however, you could install twocomponents, such as SBM Application Engine and Application Repository, on differentservers. Therefore, you must install Release Manager on both servers (in addition to theserver that hosts SBM Common Services).

For information about upgrades, refer to the Release Manager readme here.

Serena Release Manager Install ComponentsThe following components are delivered as part of every Release Manager installationdepending on which underlying required SBM components are detected on the server:

• Solution Files [page 31]

• Framework Files [page 32]

• Release Automation Files [page 32]

Solution Files

The solution files contain the workflows and data models that comprise each of theRelease Manager process apps. The installer delivers the following solution file on theserver that hosts SBM Application Repository:

• Serena Release Manager (RLM) – Includes the process apps associated withSerena Release Manager:

▪ RLM - Application Release


http://help.serena.com/doc_center/doc_center.html#rlm

▪ RLM - Approvals

▪ RLM - Environment

▪ RLM - Release Train

▪ RLM - Runbook

▪ RLM - Turnover

▪ RLM - Manual Deployment Task

▪ RLM - Sample Business Request

▪ RLM - Sample Development Task

After the installation is complete, you can find the solution file in the Solutions directoryhere: SBM Installation Directory\Serena\Solutions\RLM. The file name is composedof the version number of the current solution and the .sln extension.

Framework Files

The framework files augment your underlying SBM installation to enable certain features.The framework files include new templates, images, and code that are backwardcompatible with your existing installation.

For example, the installer provides a set of HTML templates to display Release Managerimages. The HTML templates are installed on your SBM Application Engine server, but donot affect your current SBM installation.

Release Automation Files

The Release Automation piece performs the deployment activities of Release Manager.You configure Release Automation server and database settings in SBM Configurator. TheRelease Automation files are delivered by the installer on the server that hosts SBMCommon Services.

Installation ConsiderationsThe installer includes both the Serena Release Manager solution file and the SerenaService Manager solution files. By following the Release Manager installation andconfiguration steps, you can successfully install and configure Service Manager as well.However, Release Manager requires unique pre-installation and configuration steps thatare not required for Service Manager; therefore, you cannot use the Service Managersteps to install and configure both solutions.

If you plan to use both Service Manager and Release Manager:

1. Carefully read and perform all of the Pre-Installation Checklist tasks for eachsolution.

2. Perform the Release Manager installation and configuration steps as described in theSerena Release Manager Getting Started Guide.



3. Import the solution files and promote the snapshots for both solutions according tothe steps in each guide. You do not have to import both solutions in ApplicationRepository in order to successfully use either solution.

Important: If you are upgrading Service Manager and installing ReleaseManager for the first time, follow the import and promotion steps in theSerena Service Manager On-Premise Upgrade Guide for the ServiceManager apps.

Pre-Installation ChecklistThe following checklist describes the tasks that you need to perform before you performthe install.

If you do not currently have SBM installed and configured:

• You must successfully install and configure SBM on one or more servers according tothe steps in the SBM Installation and Configuration Guide. You can either perform acomplete SBM installation (in which all SBM components are installed on a singleserver) or you can perform a custom installation (in which the SBM components aredistributed among multiple servers). If you perform a custom installation, note thatyou must install every SBM component in order to have a fully functional SBMsystem.

• Follow the steps in SBM Installation and Configuration Guide to validate your SBMinstallation once you have successfully configured SBM and finished the Create NewDatabase wizard using SBM System Administrator.

• Ensure that you have at least one administrative user who has sufficient privileges toimport and promote the solution files in SBM Application Repository. For details onthese privileges, see the SBM Application Repository Guide.

Once you have successfully installed and configured SBM, review your installation asfollows:

• If your SBM installation is distributed among multiple servers, determine whichservers host the following SBM components:

▪ SBM Application Engine

▪ SBM Application Repository

▪ SBM Common Services

You will install Release Manager on the server or servers that host these SBMcomponents.

• If you are using multiple environments in SBM (such as development, test, andproduction), ensure that each environment has its own instance of SBM CommonServices. SBM Application Repository is the only component that can be shared bymultiple environments.

Important: The SBM environments cannot share one instance of SBMCommon Services. You will encounter problems in Release Manager if onlyone instance of SBM Common Services is used by multiple environments.

Prepare for the Release Manager install by performing the following tasks:


• Procure and install licenses for Release Manager.

• If you are using IIS 7 or higher, you must ensure that the WebDAV handler mappingand the WebDAVModule are removed from IIS on the server that hosts SBMApplication Engine. WebDAV prevents Release Manager from using critical Webservice DELETE and PUT operations. To remove WebDAV, select the Web site in IIS,edit the Handler Mappings and remove WebDAV. Navigate back to the Web siteHome page, edit the Modules, and remove the WebDAVModule.

• Decide if you will use the native instance of Release Automation (which is installedwith Release Manager) or a standalone instance of Release Automation (installedseparately from Release Manager as described in the Serena Release Manager -Release Automation User's Guide).

Important: The ZMF plugin requires a Tomcat application server, which isonly available with a standalone Release Automation instance. This meansthat if you intend to use the ZMF plugin with Release Manager, you mustuse a standalone Release Automation instance (because the nativeinstance only runs under JBoss).

• If you intend to use the native Release Automation instance that is installed withRelease Manager:

▪ Download one of the following applicable JDBC drivers for your DBMS (either SQLServer or Oracle):

▪ sqljdbc4.jar

▪ ojdbc6_g.jar

You must specify the location of the JDBC driver in SBM Configurator if plan touse a native instance of Release Automation with Release Manager.

▪ Create a new database space for Release Automation your DBMS. You will enterthe database name and additional database connection information in SBMConfigurator after the installer is finished.

• Release Manager does not currently support separate Oracle schemas for each SBMcomponent within the same Oracle instance. This also applies to multi-environmentor "path to production" installations—the same Oracle instance cannot be used formultiple SBM environments (such as development, test, and production).

Important: If you currently use multiple schemas with SBM in the sameOracle instance, please contact Support for assistance.

However, SBM can be configured with separate schemas as long as the SBMOrchestration Engine and Common Log tables share the same schema. This meansSBM Orchestration Engine and Common Log will share one schema, while SBMApplication Engine and Application Repository have their own schemas or are sharedin a separate schema. If you plan to use additional environments, you must createthem in separate Oracle instances in this scenario.



Chapter 4: Installing Serena ReleaseManager

Before you install Release Manager, complete the tasks described in Chapter 3: GettingStarted [page 31]. A message appears during the installation if SBM is not currentlyinstalled. If one of the required SBM components is not installed, the installer prompts youto finish the installation on the server or servers that host the missing components.

Installation Process OverviewThis section provides an overview of the entire installation, configuration, and set upprocess for Serena Release Manager. Each step listed below is described in more detaillater in this guide.

To install Release Manager in an on-premise SBM system:

1. Install and configure a supported version of SBM as described in the SBM Installationand Configuration Guide.

2. Close SBM Configurator on all servers if it is open.

3. Run the installer as described in Running the Installer [page 36] and install ReleaseManager on the SBM server or servers that host the following components:

• SBM Application Engine

• SBM Application Repository

• SBM Common Services

4. Launch SBM Configurator, verify Relationship Service settings, configure ReleaseManager authentication settings, and configure Release Automation settings asdescribed in Chapter 5: Configuring Serena Release Manager [page 37]. Click Applyto finish the configuration, and then confirm that IIS, JBoss, and the NotificationServer are running on the Manage Services tab if they are not automaticallystarted.

5. Access Serena Work Center using the following URL:

http://serverName/workcenter

When Serena Work Center is accessed for the first time after the installation iscomplete, the loading time will be longer than normal, which may cause a timeout tooccur. This is due to the server loading data associated with the new solutions. Theslow loading time is a onetime occurrence. See Accessing Serena Work Center [page42] for more information.

6. Import the solution files as described in Chapter 6: Importing Serena ReleaseManager [page 43].


7. Promote the solution snapshots as described in Chapter 7: Promoting SerenaRelease Manager [page 45].

8. Update the endpoints for specific process apps using SBM Application Repository andredeploy the apps as described in Updating Endpoints [page 47].

9. Start the SBM Relationship Service Database as described in Starting the SBMRelationship Service [page 48].

Running the InstallerTo install Serena Release Manager:

1. Run the installer on the server or servers that host the following SBM components:

• SBM Application Engine

• SBM Application Repository

• SBM Common Services

Note: If these SBM components are installed separately, you must run theinstaller on each server.

The "Welcome to the Install Wizard" message appears. Click Next to continue.

2. Accept the license agreement. Click Next to continue.

3. Choose the installation directory. This directory temporarily stores files before theyare copied into the appropriate folders inside the SBM installation directory for useby the SBM Server.

Note: You cannot choose to install in the same directory as your existingSBM installation.

Click Next to continue.

4. The installer detects which SBM components are currently installed on the server. Amessage appears if any of the required SBM components are not detected on theserver. Click Install to proceed.

5. Allow the install to complete, and then click Configure to launch SBM Configurator.For details, see Chapter 5: Configuring Serena Release Manager [page 37].



Chapter 5: Configuring Serena ReleaseManager

After the installer is finished, you must launch SBM Configurator and configure ReleaseManager settings. To successfully configure Release Manager, perform the following tasks:

• Select Single Sign-On (SSO) as the session management option in theAuthentication tab (if you are not using Single Sign-On (SSO) already). For details,refer to Configuring Release Manager Authentication [page 37].

• Verify the default Relationship Service settings on the Common Services tab thatappears on the SBM Common Services and SBM Application Engine servers.

Important: If you have clustered SBM Common Services, you must selectwhich node in the cluster will run the Relationship Service before usersbegin using Release Manager. For details, refer to Configuring RelationshipService [page 38].

• Configure Release Manager settings on the Release Manager tab, and then clickApply to finish the installation and configuration process. For details, refer toConfiguring Release Manager [page 39].

When you click Apply, SBM Configurator updates various configuration files on the serverand prepares the system for use (however, you must still import solution files andcomplete the remaining tasks described in this guide before the process apps are readyfor use by your users).

Configuring Release Manager AuthenticationRelease Manager requires Single Sign-On (SSO). This means that you must select SingleSign-On (SSO) as the session manager for SBM in the Authentication tab.

To enable Single Sign-On (SSO):

1. In SBM Configurator, open the Authentication tab.

2. Select one of the following authentication options in the Validate user credentialsagainst drop-down list:

• Internal SBM Database

• LDAP

• LDAP then Internal

Important: If you are currently using Windows Domain (NTCR)authentication, select LDAP or LDAP then Internal instead to validateyour users. This validates your domain users against Active Directoryinstead of the Windows Controller. This means you must change theauthentication for the tmtrack virtual directory in IIS from WindowsAuthentication to Anonymous.


3. Select Single Sign-On in the User sessions are managed by drop-down list.

4. Configure LDAP server connection settings on the LDAP sub-tab. For details on thesesettings, refer to "Configuring LDAP Authentication" in the SBM Installation andConfiguration Guide.

Release Manager is now properly configured to use Single Sign-On (SSO). Proceed to theCommon Services tab and verify the Relationship Service settings.

Configuring Relationship ServiceIn the Relationship Service tab, you configure settings for the SBM RelationshipService, which enables you to view and analyze relationships between items in separateapplications.

Tip: If you do not have a JBoss cluster for SBM Common Services, you do notneed to change any of the settings on the Relationship Service as part of theinitial configuration process. You can use the information below to configureRelationship Service settings any time thereafter.

Serena recommends that you wait to start the SBM Relationship Service on theManage Services tab until after you have finished promoting all of the Release Managerprocess apps. (This service does not start automatically when you click Apply to finish theconfiguration process.) The initial loading that begins when the service starts consumesserver resources and takes time to complete; therefore, start the service after youpromote the apps in order to allow the promotion process to complete as quickly aspossible.

The Relationship Service and database are installed on the server that hosts SBMCommon Services. Therefore, there is only one active Relationship Service instance perSBM instance.

The Status section displays the current status and activity of the Relationship Service. Forexample, if you have never started the SBM Relationship Service on the ManageServices tab, the Relationship Service database is empty and not in use. That informationis reported in the status section. After you start the service and the initial loading of databegins, the status is updated.

In the Database Server Settings section, enter the HTTP port that will be used toconnect to the Relationship Service database. The default port value is 7474.

In the Database Settings section, configure the following settings:

• Confirm or change the Database location that hosts the Relationship Servicedatabase. This database stores the relationships that exist between items in separateapplications. Click Change to specify a different directory. If you change thedirectory after the initial load is finished and the database has been successfullycreated, you can choose to either copy the database to another location (forexample, if the size of the database requires that you specify a different directory) oryou can initialize a new loading process in another location.

Important: You must click Apply to begin the actual copy or loadingprocess.



• Enter a Backup Location for the Relationship Service database.

Tip: Once the backup database folder has been created, consider saving itto another server or separate partition in order to safely preserve yourdata.

• Click Backup Now to create a backup copy of the database immediately in thedirectory that you specify.

Tip: Use this option if you need to create a backup of the database folderand move it to a new machine. For example, if you decide to create acluster for SBM Common Services and as a result, you need to migrate theRelationship Service database to a new server, use the Backup Nowoption to create a backup of the directory that you need to move.

• Click Schedule to open the Scheduler window and configure the backup frequency.

Configuring Relationship Service in a JBoss Cluster

You can improve Relationship Service performance by clustering the SBM CommonServices component on multiple servers. When you create a cluster for SBM CommonServices, the Cluster Settings group box appears in the Relationship Service sub-tab.

Each node in the cluster is capable of running Relationship Service; however, only onenode in the cluster can actually run the service. You will enter the database settings onthis node. All other nodes in the cluster must know the location of the node that will runthe Relationship Service. No other Relationship Service configuration is required on thesenodes.

To configure Relationship Service in a JBoss cluster, perform the following steps:

1. Define the nodes in your SBM Common Services cluster according to the stepsdescribed in "Clustering the JBoss Server Components" in the SBM Installation andConfiguration Guide.

2. On the node that will run the Relationship Service, select the local host name in thedrop-down list that appears.

3. On each node that will not run the service, select the host name of the node that willrun the service.

4. Click Apply to save your changes.

Configuring Release ManagerIn the Release Manager dialog box, you configure Release Automation settings forRelease Manager. Select the Configure Release Manager check box to beginconfiguring these settings.

Note: For distributed installations, you configure these settings directly on theserver that hosts SBM Common Services.

In the Release Manager Settings sub-tab, you select which Release Automationinstance you plan to use with Release Manager.


Select one of the following options:

• Use native Release Automation instance – Select this option if you are installingRelease Manager for the first time. Release Manager will use the version of ReleaseAutomation that is locally installed on the SBM Common Services server andpowered by Serena Common JBoss.

• Use standalone Release Automation instance – Select this option if you havepreviously installed a standalone version of Release Automation, and you want to useit with Release Manager.

Important: The ZMF plugin requires a Tomcat application server. This meansthat if you intend to use the ZMF plugin with Release Manager, you must use astandalone Release Automation instance (because the native instance only runsunder JBoss).

Configuring Standalone Release Automation Settings

If you select the standalone version, enter the following information in order for ReleaseManager to connect to your existing Release Automation instance:

FieldName

Description

Applicationcontainer

Select the application container that is used by your Release Automationinstance in the drop-down list. If your existing instance uses somethingother than JBoss or Tomcat, select Other.

Host Enter the host name of the server that hosts your Release Automationinstance. Click Test Connection to verify that a connection can be madeto the server.

Use HTTPport

Enter the HTTP port number that is used to connect to your ReleaseAutomation instance. The default HTTP port is 8080.

Use HTTPSport

Enter the HTTPS port number that is used to connect to your ReleaseAutomation instance if you use secure connections. The default HTTPSport is 8443.

AJP13 port Select the AJP13 port. The default port for Tomcat is 8409. The defaultfor JBoss is 6009. The default value changes automatically for youdepending on the application container you select.

Configuring Native Release Automation Settings

The Native Release Automation Settings sub-tab appears if you select Use nativeRelease Automation instance. In the Native Release Automation Settings sub-tab,you configure administrative settings and database connection settings.

Important: The native Release Automation settings cannot be changed usingSBM Configurator after they have been applied the first time. If you need tochange these settings later, refer to the Serena Release Manager - ReleaseAutomation User's Guide for assistance.



Configure the following:

Field Name Description

Profilelocation

Enter the code station path where your artifacts will be stored.Consider using a dedicated partition to store the physical files in orderto save operating disk space for SBM.

Agent mutualauthentication

Select this option for agents to use SSL mutual authentication. If notselected, agents will use unauthenticated mode; communication isencrypted but users do not have to authenticate or verify theircredentials. For more information, refer to the Serena ReleaseManager - Release Automation User's Guide.

Agent port Enter the port to use for JMS-based server/agent communication. Thisis the port on which the Release Automation agents that you installwill make JMS Connections to this server.

Skip databaseinstall

Select this check box if you need to skip the database initializationprocess. For example, if you have clustered SBM Common Services,clear this check box on the first node that you configure (whichinitializes the database), and then select this check box on allremaining nodes in order to prevent the creation of multipledatabases.

Administratoruser

Enter an administrator user name. This is the user name that isrequired to log into the server the first time.

Password Enter the administrator's password.

Confirmpassword

Enter the password again to confirm it.

Configure the following Release Automation database settings:

FieldName

Description

DatabaseType

Select the type of DBMS (SQL Server or Oracle) that will host the ReleaseAutomation database.

JDBCdriver JAR

Type the local path to the JDBC driver .jar file for your DBMS, or clickBrowse to enter the path to the .jar that you downloaded as part of thePre-Installation Checklist [page 33].

JDBCdriverclass

A default class is provided. Change the class value as necessary.


FieldName

Description

Connectionstring

Edit the database connection string, and replace the localhost, port,and DatabaseName values as necessary. Enter the name of the databasethat you created in your DBMS as part of the pre-installation checklisthere.

Schema Enter the Oracle schema name. (Only applicable if you select Oracle inthe Database Type drop-down list.)

User Enter the name of a privileged DBMS user account.

Note: For SQL Server databases, enter a SQL Server useraccount, not a Windows user account.

Password Enter the user's password.

Confirmpassword

Enter the password again to confirm.

Accessing Serena Work CenterAfter you run SBM Configurator and click Apply, a prompt states that the services mustbe restarted for changes to take effect. Confirm that the IIS and JBoss services arerunning after the restart, and then launch Work Center using the following URL:

http://serverName/workcenter

Important: Launching Work Center immediately after clicking Apply in SBMConfigurator is an important part of the installation and configuration process.This enables SBM Application Engine to import the framework files.

When Work Center is accessed for the first time after the installation is complete, theloading time will be longer than normal, which may cause a timeout to occur. This is dueto the server loading data associated with the new solutions. The slow loading time is aonetime occurrence.

After you log in to Work Center, launch SBM Application Repository to continue the setupprocess by importing the Serena Release Manager solution.



Chapter 6: Importing Serena ReleaseManager

This chapter describes how to import the Serena Release Manager solution file into yourenvironment. Importing a solution adds all of the snapshots and process apps for thesolution to your SBM Server. The process apps and snapshots are available for promotionafter the import.

Note the following about importing the solution:

• The solution contains a subset of process apps. You must import the solution if youwant to use all of the process apps.

• If you encounter any problems with importing the solution, refer to TroubleshootingImports [page 51].

Importing the SolutionTo import the solution:

1. Log in to SBM Application Repository using the following URL:

http://serverName:port/mashupmgr

2. Select the Solutions tab.

3. Click the Import button to import the Serena Release Manager solution.

Upon successful completion, the imported solution appears in the Imported solutionslist.

On the Process App Snapshots tab, the snapshots contained in the imported solutionare now available for promotion. For steps on promoting the process app snapshots, seePromoting the Snapshots [page 45].


Chapter 7: Promoting Serena ReleaseManager

After you import a solution, you promote the associated snapshots into your environment.Promoting the snapshots places the contents of the solution, including all reports,notifications, process apps, and auxiliary table data, onto your SBM Server.

Important: You must promote the snapshots before you modify and deploythem. Promoting maintains data that is necessary for some operations such asmaintaining internal IDs. Deploying first could cause compatibility problemslater on.

Note the following information about promoting the snapshots:

• Important: You must promote the RLM – Release Train snapshot beforeyou promote the RLM – Approvals snapshot.

This ensures that reports in the Approvals process app have access to fields from theRelease Train process app. If you did not promote the process apps in this order(and users see a SQL error in the Release Dashboard), promote the Approvalssnapshot again.

• It is recommended that you promote all of the snapshots; however the sample appsare optional.

Tip: If you do not plan to use a particular process app, it is recommendedthat you still promote the snapshot (you do not need to make it availableto your users). Each process app references other process apps and youwill encounter reference errors in SBM Composer when you attempt tomodify the process apps if you do not promote them all.

• If you encounter any problems with promoting the snapshots, refer toTroubleshooting Promotions [page 51].

Promoting the SnapshotsTo promote the Serena Release Manager snapshots:

1. Log in to SBM Application Repository using the following URL:


2. Select the Process App Snapshots tab.

3. Click All and then select to filter on Serena Release Manager.

4. Follow the steps below to promote the snapshots.

Important: Ensure that you promote the RLM – Release Train snapshotbefore you promote the RLM – Approvals snapshot.


a. Select a snapshot and then click Promote. The Summary of the Promotedialog box is displayed.

b. Choose the Destination Environment by selecting the Destination box.

c. In the Entities section, choose which entities to import. It is recommended thatyou import all of them, but it is not mandatory.

Important: Select the Merge conflicts option if you have alreadypromoted the snapshot to the target environment and you want topreserve changes that you made to the existing application. Forexample, if you want to keep new user roles that you added to anapplication, select the Merge conflicts check box to preserve them inthe target environment after the promotion. If Merge conflicts is notselected, the existing entities will be deleted in the target environment.

d. If no mappings are needed in the Mapping dialog box, click Done.

e. Click Promote to finish the operation.

f. Repeat this process for each snapshot in the solution that you want to use.



Chapter 8: Post-Installation Tasks

After you install and configure Release Manager, import the solutions, and then promotethe process apps, perform the post-installation tasks that are described in this chapter.

Updating EndpointsAfter you have successfully promoted all of the Release Manager process apps, you mustupdate endpoints for process apps that use the REST Grid widget to use Security Tokenauthentication.

To update the endpoints:

1. Log in to Application Repository using the following URL:


2. Click Environments. A list of your environments appears.

3. Click the name of the environment that you used to promote the Release Managersnapshots.

4. Click the Endpoints tab. A list of endpoints for all the promoted apps appears.

5. Locate the endpoints that have the following URLs:

• http://localhost:8085/serena_ra/rest/deploy/globalEnvironment/all

• http://localhost:8085/serena_ra/rest/deploy/application/all

• http://relationshipserviceurl/commonsvc/graph/cypherService/run

Update the endpoints to use security tokens:

a. Select an endpoint, and click Edit.

b. In the Authentication drop-down list, select Security Token.

c. Click OK.

6. Edit the following endpoint URLs, and change the host name as follows:

• http://localhost:8085/serena_ra/rest/deploy/globalEnvironment/all

Change localhost to the host name of your Release Automation server. If you areusing the native instance, this will be the server that hosts SBM CommonServices.


• http://localhost:8085/serena_ra/rest/deploy/application/all

Change localhost to the host name of your Release Automation server. If you areusing the native instance, this will be the server that hosts SBM CommonServices.

• http://relationshipserviceurl/commonsvc/graph/cypherService/run

Change relationshipserviceurl to the host name of your SBM Common Servicesthat hosts the Relationship Service.

Tip: If you are not using a native Release Automation instance, andinstead you have a standalone instance that is powered by Tomcat, enteryour Tomcat port number for the serena_ra endpoints. The defaultTomcat port is 8080.

7. Deploy the following process apps that use these endpoints:

• RLM – Application Release

• RLM – Environment

• RLM – Release Train

• RLM – Turnover

To use the ServiceNow or JIRA integrations, you must update additional endpoints toensure the host name in the endpoint matches the host name of the server whereServiceNow and JIRA are running. For details on configuring endpoints for theseintegrations, refer to Chapter 15: Business Request and Development Task Integration[page 75].

Starting the SBM Relationship ServiceAfter you have successfully promoted all of the Release Manager process apps, launchSBM Configurator, and start the SBM Relationship Service on the Manage Servicestab.

The initial loading of relationship data can take ample time to complete for very largedatabases. Therefore, schedule the initial load process ahead of time, and start the SBMRelationship Service prior to granting users access to the Release Manager processapps.

The Status section displays the Relationship Service activities that take place after youstart the service. For example, after you start the service and the initial loading of databegins, the status is updated accordingly.

Setting Authentication for OrchestrationsAs of SBM 10.1, security tokens are issued to all authenticated users whether you useSingle Sign-On (SSO) or not, so you are no longer required to provide authenticationcredentials for SBM Application Engine calls in orchestrations. However, you might want tohard-code specific authentication credentials so that the orchestration runs under aspecific user in either of the following scenarios:



• The calling user does not have sufficient privileges.

Tip: Consider creating a dedicated user with API/Script product access andgrant the following privileges in Application Administrator to the ReleaseManager projects:

▪ View All Items

▪ Update All Items

▪ Transition All Items

• You upgraded from a previous SBM release in which SSO was disabled and you useexternal events in your orchestrations (because no token is issued for anonymousevents).

The following steps explain how to import the process app into SBM Composer, modify theorchestration, and deploy the process app to your SBM Server.

Important: Open all process applications in SBM Composer before attemptingto edit. The applications reference each other, and if one is not imported intoSBM Composer, you could encounter validation errors.

To modify the orchestrations:

1. Open the process app in SBM Composer by clicking the Composer button, clickingOpen, clicking Repository, and then selecting the process app.

2. Configure the orchestrations (if any) in the process app to be authenticated under auser account that is authorized to run orchestrations:

a. Select an orchestration workflow under Orchestration Workflows.

b. Click the Data Mapping tab in the Property Editor.

c. Under Working Data, add a user account to the userId and password DefaultValues. These values will be used to authenticate the orchestration.

d. Repeat for all orchestrations in the process app.

3. Publish and deploy the updated process app to your environment. You are promptedto save your changes, and the process app is then deployed to your environment. Aconfirmation message will appear in the Message List when the deployment iscomplete.

4. Repeat these steps for each of the process apps. When you open the next processapp, you are prompted to check in the application. Click Yes, and then OK toconfirm (even if no changes were made).


Chapter 9: Troubleshooting

This chapter contains information to help solve problems with your installation andconfiguration.

• Troubleshooting Imports [page 51]

• Troubleshooting Promotions [page 51]

• Troubleshooting Rest Grid Widget Errors [page 51]

• Troubleshooting Report Errors [page 52]

Troubleshooting ImportsIf the import of a solution file fails with an error, you can view the error in theApplication Repository Log from within SBM Application Repository.

If there are existing applications in the destination environment during the import, thenApplication Repository attempts to upgrade the existing application with the data in thenew application if the internal IDs (UUIDs) are identical. If the internal IDs are differentbut the application names are identical, then the import fails.

Note: Contact Serena support for information on finding an application's UUID.

If the import fails due to identical application names, the workaround is to delete theprocess app in the repository and then re-import the solution. Note that this will deletethe existing process app and all of its associated data, so make sure the app can safely bedeleted. Contact Serena support for more information on this process.

Troubleshooting PromotionsThe Activities tab in Application Repository contains a log of the promotions. Whenviewing the logs, you may notice warning messages if a related application has not beenpromoted to the target environment yet. These types of warnings are typically fixed oncethe referenced snapshot has been promoted.

Troubleshooting Rest Grid Widget ErrorsThe following process apps use Rest Grid widgets to display information from ReleaseAutomation entities and associated business requests and development tasks:

• Release Trains

• Application Releases (including Applications auxiliary table)

• Environments

• Turnovers


If the Rest Grid is not configured correctly, users will see a recurring loading icon or anerror similar to the one below:

We did not find any matches for your request

Unknown error received from http://localhost/sbmproxy/xhp [url:'http%3A%2F%2Frelationshipserviceurl%2Fcommonsvc%2Fgraph%2FcypherService....(404)

To solve this problem:

1. Verify that Single Sign-On (SSO) is enabled for your installation. Refer toConfiguring Release Manager Authentication [page 37].

2. Verify that the endpoints are correct for the process app where the error occurs.Refer to Updating Endpoints [page 47].

3. Verify that the Relationship Service is running. Refer to Starting the SBMRelationship Service [page 48].

4. If you fixed the endpoints for a process app and deployed it as described in UpdatingEndpoints [page 47], errors may occur if you redeployed the process app from SBMComposer without setting the correct endpoints for the Rest Grid widget in theprocess app.To solve this problem:

a. In SBM Composer, open the process app.

b. Find the form where the error occurs, and then select the Rest Grid widget onthe form.

c. Click the Configure URL button, and then modify the Relationship Service URLto point to your SBM Common Services host, as instructed in Updating Endpoints[page 47].

d. Repeat this step for each Rest Grid widget in the process app. For example, theBase State form in the Release Train process app has four Rest Grid widgets onthe Requirements/Development tab.

e. Redeploy the process app.

Troubleshooting Report ErrorsDatabase exception errors may occur for certain provided reports, such as the "Open ExitCriteria" report used on the Release Dashboard.

A sample error is:



To solve this problem, repromote the Release Trains process app, following the guidancein Promoting the Snapshots [page 45].


Part 3: Implementation

This section contains information about the tasks you need to perform before users canaccess Release Manager. These tasks are typically performed by administrators afterRelease Manager has been installed using the instructions in Part 2: Installation [page29].

• Chapter 10: Configuring the Process Apps [page 57]

• Chapter 11: Creating Release Artifacts [page 61]

• Chapter 12: Common Customizations [page 65]


Chapter 10: Configuring the Process Apps

Release Manager requires minimal configuration after you follow the steps in Part 2:Installation [page 29].

Follow the steps below to prepare your system for users.

1. Assign users and groups to role. Refer to Assigning Users to Roles.

2. Subscribe users to notifications. Refer to Subscribing Users to Notifications [page58].

3. Review the Release Manager application group and instruct users to "pin" theRelease Manager application group in the user interface. Refer to Reviewing theApplication Group [page 58].

4. Optionally, review and modify end-user help provided with each process app. Fordetails, refer to the SBM Composer Guide located on the Documentation Center.

Assigning Users to RolesEach process app contains roles with privilege assignments that control access to eachphase of your release process. Roles also populate the various fields, such as ReleaseManager and Product Owner. Roles are provided for each of the participants described inRelease Manager Participants [page 12].

Along with roles specific to release participants, each process app contains these roles:

• RLM Administrator

Intended for users who will administer the process apps, this role is assigned allapplication-based privileges. Users assigned to this role can also delete releaseartifacts, such as release trains and application releases.

• RLM User

Intended for stakeholders who need visibility into your release process but do notactively work on release artifacts, this role is assigned view-only privileges.

Users and groups are assigned to roles in SBM Application Administrator.


D:\bld\DOCSOLU_5_X\DOCSOLU_5_X-RLM\en\output\rlm_guide\DitaOut\rlm_roles.xml#RoleAssignments


Use the following general steps for establishing user accounts:

1. Determine the types of user accounts you need.

2. To better manage sets of users, log in to Application Administrator, and then creategroups, such as "Release Engineers" and "Product Owners."

3. Add accounts for each active user.

4. Assign users to the applicable groups you created. This will ease the process ofassigning users to roles.

5. Assign groups to roles in each process app.

Note: For best results, non-administrative users should be assigned RegularUser access.

Subscribing Users to NotificationsNotifications "push" information about release changes and approvals to your users. Eachprocess app contains a set of notifications that you can choose to always send to users orthat they can choose to subscribe to.

For example, users can receive e-mail notifications when they need to approve a releasetrain or when a turnover has been created.

Users can also use the Notifications view to search for and view notifications.

You can manage your Release Manager notifications in SBM Application Administrator.From the Administrator portal, select the Notifications icon, and then navigate the listof notifications for each process app. For easier long-term maintenance, use the groupsyou created in Assigning Users to Roles [page 57] to set subscriptions rather than settingthem for individual users.

For more information about notifications, refer to the SBM Application Administrator Guidelocated on the Documentation Center.

Reviewing the Application GroupRelease Manager includes the Release Mgmt application group, which serves as acontainer for all process apps in the solution. This enables users easy access to therelease dashboard, timelines, and activity and calendar views.

Privileges determine which data is returned when users select the Release Mgmtapplication group. For example, a user may select the default "My Trains" view, but datawill not be returned if the user does not have privileges to own release trains.

You must instruct users to "pin" the Release Mgmt application group in the userinterface (http://serverName/workcenter).

While all applications are included in the Release Mgmt application group, only thefollowing applications are listed in the navigation pane for Release Manager:




• Release Trains

• Application Releases

• Turnovers

• Runbooks

• Environments

• Approvals

Administrators can choose to hide applications in custom application groups. Thesechanges are ignored for the Release Mgmt application group, however.


Chapter 11: Creating Release Artifacts

To help users begin working with Release Manager, consider creating the following releaseelements before users access the system. For best results, create these elements in theorder listed below:

• Applications - Refer to Creating Applications [page 61].

• Environments - Refer to Creating Environments [page 62].

• Runbooks - Refer to Creating Runbooks [page 63].

• Release train templates - Refer to Creating Release Train Templates [page 63].

To create these items, log in to Release Manager using this URL:http://serverName/workcenter.

Creating ApplicationsApplications are auxiliary items that are associated with application releases. Applicationauxiliary items can be linked to a Release Automation application.

Application auxiliary items must be created before application releases can be created. Formore information about applications and applications, refer to About Application Releases[page 17].

Users who are assigned to these roles in the Application Releases process app can createapplications in the Applications auxiliary table:

• Release Manager

• Product Owner


To create applications:

1. Click the user icon in the upper right corner, and then select Manage Data.

2. Select Applications from the Tables list.

3. Click Add.

4. Provide a title and descriptions, and then select one of these Release Automationoptions:

• Create new application

Creates the application in the Applications auxiliary table and in ReleaseAutomation.

• Link to existing application


Create the application in the Applications auxiliary table and link to an existingRelease Automation application. Click the Get RA Application button, and thenselect the application.

• Do not link to Release Automation

Create the application only in the Applications auxiliary table.

5. Click Submit.

Creating EnvironmentsEnvironments are created in the Environments process app. Environments items can belinked to Release Automation environments.

Environments must be created and placed online before they can be reserved for releasetrains or assigned to a turnover. A typical environment set might include staging, QA, andproduction environments, but you can create and name the environments needed for yourorganization.

Users who are assigned to these roles in the Environments process app can create andmanage environments:

• Release Manager

• Release Engineer

• Product Owner


To create an environment:

1. Click +New.

2. Search for the project that will store your environment, and then select the projectto open a Submit form. (By default, the Environments project is used to storeenvironments.)

3. Provide a name for the environment, such as Staging or Production, and then selectone of these Release Automation options:

• Create new environment

Creates environments in the Environments project and in Release Automation.

• Link to existing environment

Create the environment in the Environments project and link to an existingRelease Automation application. Click the Get RA Environment button, and thenselect the environment.

• Do not link to Release Automation

Create the application only in the Environments project.

4. Select the release engineer who will be responsible for the environment, and thenclick Submit.

5. Click the Place Online button to activate the environment.



Creating RunbooksIf you have a standard set of tasks that are performed for similar turnovers, environmentsor applications, you can create runbooks that serve as templates for these tasks. Asrelease engineers create turnovers, they can copy tasks from runbooks, and then reorder,remove, or add new tasks as needed.

Users who are assigned to these roles in the Runbooks process app can create andmanage runbooks:

• Release Manager

• Release Engineer


To create a runbook:

1. Click +New.

2. Search for the project that will store your runbook, and then select the project toopen a Submit form. (By default, the Runbooks project is used to store runbooks.)

3. Provide a name for the runbook, and then select values for these fields as theyapply:

• Environments

Select specific environments to which the runbook applies.

• Applications

Select specific applications to which the runbook applies.

Note: Users can copy tasks from any approved runbook, but when youspecify an environment or application, they can choose to filter tasks tothose related to a specific environment or application.

4. Select the release engineer who will be responsible for the runbook, and then clickSubmit.

5. Click the Edit Deployment Tasks button.

6. Use the form to add new manual and automation tasks, copy tasks from anotherrunbook or turnover, delete tasks, or change the sequence of tasks. Click Closewhen you are done.

7. Click Complete to send the runbook to a release manager for review.

8. Once approved, the runbook is available for turnovers.

Creating Release Train TemplatesTo ease the release train setup process, you can create release train templates thatinclude:

• Release manager and release engineers

• Release train type


• Reserved environments

• Milestones

• Stage gate exit criteria

• Train approval levels and approvers

During a release train copy, release managers select new start and end dates. Dates forstage gates and milestones automatically adjust based on the new train dates. Dates canbe adjusted manually as needed.

Environments can also be modified during a copy.

Application releases and turnovers are not copied with the template, however. Theseitems must be added to the newly copied trains.



Chapter 12: Common Customizations

This section provides guidance on the following customization tasks:

• Customizing Approvals [page 65]

• Changing Environment Options for Turnovers [page 66]

Note: The customization information assumes you are familiar with SBMComposer and basic process app tasks. For more details, refer to the SBMComposer Guide or online help.

Customizing ApprovalsRelease approvals are intended for approval boards that need to approve a train atvarious phases. Three approval types are provided by default: train, development, andexecutive.

This section explains how to modify the default approval processes in SBM Composer:

• Changing Release Approval Types [page 65]

• Disabling a Release Approval Type [page 66]

For information about approvals, refer to About Approvals, Stage Gates, and Milestones[page 22].

Changing Release Approval Types

To change names of the default release approval types:

1. In the Release Train process app, select the Release Trains workflow from theApplications Workflows view, and then find the "post" transition that creates arelease approval in the Approvals application. For example, change the name of the"Create Train Approval" transition to "Create Train Acceptance."

2. Select the Data Design tab, and then select the field related to the approval typeyou want to change, and then change the name located on the General tab. Forexample, rename the Train Approval Required field to Train Acceptance Required.

3. Select the Visual Design tab, and then select the Base State form. On the Actionstab, select "Form Load: Train Approval Check," click Edit, and then modify themessage text in the first IF statement to match the names you provided in steps 1and 2.

4. Deploy the Release Train process app.

5. In the Approvals process app, select the Data Design tab, and then select theRelease Approval Type field. On the Options tab, rename the value for the approvaltype. For example, change the "Train Approval" value to "Train Acceptance."


6. Select the Approvals workflow from the Applications Workflows view, and thenchange the name of the submit transition for the approval type. For example,change the name of the "Train Approval Submit" transition to "Train AcceptanceSubmit."

7. Deploy the Approvals process app.

Disabling a Release Approval Type

Release approvals are set to required by default. Release managers can choose not torequire these approval types for each train.

You can choose to set the default approvals to not required, or you can disable anapproval type.

To disable a release approval type:

1. In the Release Train process app, select the Data Design tab, and then Binary/Trinary field for the type of approval you want to disable, and then on theAttributes tab, set the default value to "No". For example, set the default value to"No" for the Dev Approval Required field.

Note: If you want to give users the option to require an approval level atsome point, you can stop here.

2. Select the Release Trains workflow from the Applications Workflows view, andthen find the "post" transition that creates a release approval in the Approvalsapplication. Select the Disabled option on the General tab. For example, disablethe "Create Development Approval" transition.

3. Select the Visual Design tab, and then select the Base State form. On theApprovals tab, remove the transition button that corresponds to the approval type.For example, remove AddDevApprovalButton from the form.

4. Select the Submit form, and then remove the label and control for the fieldassociated with the approval type. For example, removeDevApprovalRequired_Labeland TrainAcceptanceRequired_Control.

5. Deploy the Release Train process app.

Changing Environment Options for TurnoversBy default, users can only choose environments that are reserved for a release train whenthey create a turnover. For example, the QA Environment must be selected for a releasetrain before an application release for that train can be deployed to the QA Environment.

To change this default behavior:

1. In SBM Composer, open the Turnovers process app.

2. Select the Data Design tab, and then select the Restrict to Release TrainEnvironments? field.

3. On the Attributes tab, set the default value to:

• Yes



Select this value to limit the list of environments to those reserved for the releasetrain associated with the turnover.

• No

Select this value to allow users to select any environment for the turnover.

• Yes, except none

Select this value to limit the list of environments to those reserved for the releasetrain. If no environments are selected for the release train, users can select anyenvironment.

4. Deploy the Turnovers process app.

Note: This change can also be made in SBM Application Administrator by editingthe Turnovers project, and overriding the default value for the Restrict toRelease Train Environments? field. This method does not require you to deploy aprocess app.


Part 4: Integration


• Chapter 13: Integration Overview [page 71]

• Chapter 14: Application and Environment Integration [page 73]

• Chapter 15: Business Request and Development Task Integration [page 75]

• Chapter 16: Deployment Task Integration [page 85]


Part 4: Integration


Chapter 13: Integration Overview

The integrations provided by Serena Release Manager enable you to associate externalobjects with your Serena Release Manager objects.

Applications

Release Automation applications can be created or linked to from Release Managerapplications.

Environments

Release Automation environments can be created or linked to from Release Managerenvironments.

Automatic User Registration in Release Automation

When users access Release Automation applications or environments for the first timefrom Serena Release Manager, their user IDs are automatically registered in ReleaseAutomation. This enables the user to access the deployment features provided throughRelease Automation with no extra login and no extra administration.

Business Requests

External business requests can be associated with Release Manager application releases.These may come from SBM process apps or external tools such as ServiceNow.

Development Tasks

External development tasks can be associated with Release Manager application releasesand turnovers. These may come from SBM process apps or external tools such as JIRA.

Deployment Tasks

Release Automation provides the deployment hub for Release Manager, enabling ReleaseManager to deploy to enterprise environments through Release Automation processes andplug-ins for external products such as Serena ChangeMan ZMF, Serena Dimensions CM,and CA Nolio.

For details, refer to the following:

Chapter 14: Application and Environment Integration [page 73]

Chapter 15: Business Request and Development Task Integration [page 75]

Chapter 16: Deployment Task Integration [page 85]


Part 4: Integration


Chapter 14: Application and EnvironmentIntegration

You can create new Release Automation applications and environments from ReleaseManager or link to existing Release Automation applications and environments.

The following topics give more information on the integration.

• Application and Environment Integration Overview [page 73]

• Auto Registration in Release Automation [page 73]

Application and Environment Integration OverviewRelease Automation applications and environments are used to scope the selections towhich you can deploy. You can create environments in Release Manager or ReleaseAutomation and then reserve them in a release train. The integration is implemented asfollows:

• Release Automation applications are created or linked to through the ManageAuxiliary Data details form for the Applications auxiliary table.

• Release Automation environments are created or linked to through the submit formfor the Environments process app.

• Once created, environments and applications are available for selection andassociation to Release Manager items through forms in the Release Train andApplication Release process apps respectively.

• When you link to an existing environment or application, the Name field valueautomatically changes to match the name in Release Automation.

Note: Putting environments online in Release Manager has no affect in ReleaseAutomation unless the environment has resources assigned to it that are eligibleto be put online.

When you create an environment or application, this adds the name and basic propertiesin Release Automation. You must configure additional properties in Release Automation touse these for deployment.

For details on configuring applications and environments in Release Automation, refer tothe Serena Release Manager - Release Automation User's Guide.

For more details on creating applications and environments in Release Manager, refer toChapter 11: Creating Release Artifacts [page 61].

Auto Registration in Release AutomationRelease Automation application and environment functionality is accessed through SingleSign-On (SSO) and various Release Automation authentication and authorization settings.You do not have to manually create your Release Manager user IDs in Release


Automation. These are created and configured through Single Sign-On (SSO) and othersecurity and system settings in Release Automation.

By default, the Release Manager admin user is registered in Release Automation andadded to the Release Automation Admin Group. This gives the admin user administrativeauthorization necessary for creating a Release Automation application or environment.

Other Release Manager users are automatically registered in Release Automation whenthey use functionality in Release Manager that invokes a request in Release Automation.They are added to the Read Only Group in Release Automation, which gives themadequate authorization for selecting and linking to application and environmentinformation through Release Manager.

If you want to change the authorization in Release Automation for a particular user or forthe Read Only Group, you must make the changes in Release Automation.

For details on configuring the authentication and authorization settings in ReleaseAutomation, refer to the Serena Release Manager - Release Automation User's Guide.

Part 4: Integration


Chapter 15: Business Request andDevelopment Task Integration

Release Manager provides sample integrations that enable you to associate externalbusiness requests and development tasks with Release Manager application releases. Thesample integrations include the following:

• Serena Business Manager

You can associate SBM items, such as issues or incidents, with Release Managerapplication release business requests and development tasks. You can use theprovided Sample Business Request and Sample Development Task process apps tocreate items for proof of concept. You can also use these process apps as models foryour own, or change the integration to use your existing process apps.

• ServiceNow

You can associate ServiceNow change requests, such as business services, servicerequests, incidents, or problems, with Release Manager application release businessrequests.

• Atlassian JIRA

You can associate JIRA issues, such as bugs, tasks, improvements, or user stories,with Release Manager application release development tasks.

The following topics tell how to configure and use the integrations.

• Business Request and Development Task Integration Configuration [page 75]

• Configuring ServiceNow for REST Calls [page 76]

• Business Request and Development Task Integration Usage [page 77]

• Business Request and Development Task Integration Customization [page 78]

Business Request and Development Task IntegrationConfigurationBefore users can associate items with Release Manager business requests, you mustconfigure the integration as follows:

1. Ensure that your integrating system is ready as follows:

a. If you are using SBM process apps, configure the process apps as desired foryour implementation, using the sample process apps as models.

b. If you are using ServiceNow, ensure that your ServiceNow System Plugin JSONWeb Service is active and that there are some change requests created inServiceNow. Refer to Configuring ServiceNow for REST Calls [page 76].


c. If you are using JIRA, ensure that you have an active JIRA server and that thereare some issues created in JIRA.

2. Ensure that you have changed any endpoints necessary to point to your integratingproducts' servers.

a. If you are using ServiceNow, change the ServiceNow endpoint URLs to point toyour ServiceNow server. For example:

• https://serverName.service-now.com/change_request.do

• https://serverName.service-now.com/cmdb_ci_list.do

b. If you are using JIRA, change the JIRA endpoint URLs to point to your JIRAserver. For example:

• http://serverName:8080/rest/api/latest/search

• http://serverName:8080/rest/api/latest/project

3. Ensure that the SBM Relationship Service endpoint is pointing to your JBoss serverCypher URL. For example:

http://serverName:8085/commonsvc/graph/cypherService/run

Note: Port number is optional for the Relationship Service URL; it is onlyneeded if a non-default port number is used.

For more details, refer to Updating Endpoints [page 47].

4. After you change the endpoints, deploy the Application Release process app.

5. In the Application Release process app, configure the Requirements/Development tab to invoke the forms you want to use for the Edit BusinessRequest and Edit Development Task transitions as described in Business Requestand Development Task Transition Forms [page 78].

Configuring ServiceNow for REST CallsBefore you can use ServiceNow with Release Manager, you must make sure yourServiceNow System Plugin JSON Web Service is active.

CAUTION:

Serena is not responsible for the demo website ServiceNow provides. Demowebsites are dynamic, so if you do not see the options you need in a demowebsite, switch to another demo website or consult the ServiceNowdocumentation. References to the demo website are provided for yourconvenience in setting up a test or demo integration with Release Manager.

To activate the ServiceNow System Plugin:

1. Access a ServiceNow system. For example, one of the numeric demo websites:http://demo008.service-now.com/

2. Login to the ServiceNow system as a System Administrator. For example: usernameand password admin/admin

Part 4: Integration


http://demo008.service-now.com/

3. Scroll down and select System Definition in the navigation panel.

4. At the end of the System Definition list, select Plugins.

5. Search by name for JSON Web Service.

6. Select JSON Web Service.

7. If the Status field shows Inactive, under Related Links, click Activate/Upgrade.Confirm when prompted.

The ServiceNow System Plugin is now active and ready to communicate with the ReleaseManager REST service calls.

Note: For more information on ServiceNow, see the ServiceNow documentation.

Business Request and Development Task IntegrationUsageYou can use the business request and development task integration as follows:

• Associate Business Requests with Application Releases

▪ Select PPM or IT projects to associate to an application release to filter thebusiness requests. For example: Rebranding, 508 Compliance, Oracle DBUpgrade.

▪ Select a set of business requests to associate to an application release.

▪ Update the set of business requests associated to an application release.

▪ View the selected business requests for an application release.

• Associate Development Tasks with Application Releases

▪ Select the development projects to associate to an application release to filter thedevelopment tasks.

▪ Select a set of development tasks, such as User Stories, Requirements, Defects,or Tasks, to associate to an application release.

▪ Update the set of development tasks associated to an application release.

▪ View the selected development tasks for an application release.

• Associate business requests with development tasks for an applicationrelease

When you add business requests and development tasks in the Requirements/Development tab of an application release, this associates these within thatapplication release.

• Associate development tasks with turnovers

These will be a subset of the development tasks associated with the applicationrelease.


• Show summary information at the release train and application release level

Through association to the DEV and PPM or IT projects, cross-project reports can berun to show related information.

Example reports may include the following:

▪ Total number of requirements planned (business requests)

▪ Total number of open/completed requirements (business requests)

▪ Total number of open defects (development tasks)

▪ Open defects by status/severity (development tasks)

Business Request and Development Task IntegrationCustomizationRelease Manager provides sample process apps to get you started with integrations forbusiness requests (BRs) and development tasks. The sample process apps are based ontypical use cases, but you can customize the process apps to match your organization'sprocesses. For information on changing process apps, refer to the SBM documentation.

The Application Release and Turnover process apps provide the infrastructure for theintegration with the various products from which business requests and developmenttasks can be selected and associated with application releases and turnovers.

The following topics give the details of the implementation in Application Release andTurnover process apps to help you customize the existing implementation or createsimilar integrations with other external products.

• Business Request and Development Task Integration Architecture [page 78]

• Business Request and Development Task Transition Forms [page 78]

Business Request and Development Task IntegrationArchitecture

The Release Manager integrations use REST Grid widgets, REST services, JavaScripthandlers, and the SBM Relationship Service to store the connections. The connections toexternal tools and other SBM items are made only on the Application Release process appitems. Selections for association in turnovers are limited to the business requests anddevelopment tasks that are already associated with the application release.

Business Request and Development Task Transition Forms

The Application Release and Turnover process apps contain the forms for the EditBusiness Requests and Edit Development Tasks transitions. The forms, controls, andactions provided in the default implementation are described in the following topics.

• Application Release Base State Form [page 79]

• Application Release Associate SBM Forms [page 79]

• Application Release External Tool Forms [page 80]

• Application Release REST Grid Widgets [page 81]

Part 4: Integration


• Application Release Form Actions [page 82]

• Turnover Base State Form [page 83]

• Turnover Associate Dev Tasks Form [page 83]

• Turnover REST Grid Widgets [page 83]

• Turnover Form Actions [page 83]

Application Release Base State Form

The Base State Form displays the current business requests and development tasksassociated to an application release item. That information is on the Requirements/Development tab.

The tab contains REST Grid widgets that invoke reports against the SBM RelationshipService using the new commonsvc/graph/cypherService/run REST service residing onthe SBM JBoss server. The associated reports return the business requests(Requirements) and development tasks (Development) for the specific application release.

The tab also contains buttons to invoke the Edit Business Requests and Edit DevelopmentTasks transitions. The default forms used for the transitions are Associate SBM BusRequest and Associate SBM Dev Tasks forms. Refer to Application Release Associate SBMForms [page 79] and Application Release External Tool Forms [page 80] for moreinformation on the provided transition forms.

The new cypherService/run REST service invokes a predefined Cypher Query against theNeo4j database used by the SBM Relationship Service. The two predefined queries aregetRelatedBrsForAppRelease and getRelatedDevTasksForAppRelease. These queriesare stored in the CypherQueries-RLM file in the commonsvc.war\WEB-INF\classesdirectory. For example:

..\Serena\SBM\Common\jboss405\server\default\deploy\commonsvc.war\WEB-INF\classes

These queries take a parameter named recId that contains the SBM Record ID of theapplication release being viewed. For example, param=recId=8. The results are the SBMand external tool items that are associated to the application release.

Application Release Associate SBM Forms

The Associate SBM Bus Request and Associate SBM Dev Tasks forms provide the controlsto associate other SBM items to the Application Release as Business Requests andDevelopment Tasks. The default SBM items are Sample Business Requests and SampleDevelopment Tasks. The integration of these items uses the standard SBM multi-relationalfields to display and hold the associated Business Requests and Development Tasks, withdatabase entry names of RLM_SAMPLE_BR and RLM_SAMPLE_DT respectively.

These forms display the possible items to associate based on performing a title search ofthe Sample Business Requests and Development Tasks. An embedded report used topopulate the multi-relational fields displays the result of the filter and the selectionsmade. Applying a new filter may result in the loss of previous selections if they do notappear in the new results.

The SBM Relationship Service automatically captures the relationships between theapplication release item and the Sample Business Requests and Sample Development


Tasks. These relationships carry the database name of the multi-relational fields of theSample Business Requests and Development Tasks.

Application Release External Tool Forms

ServiceNow provides Business Requests (Requirements) and JIRA provides DevelopmentTasks to associate to an Application Release item. Two forms provide the controls tocapture the associations between an Application Release item and ServiceNow and JIRA:Associate ServiceNow Bus Requests and Associate Jira Dev Tasks.

Release Manager does not enable these forms by default. To use these forms in yourimplementation, in SBM Composer, set the appropriate forms for the Edit BusinessRequests and Edit Development Tasks transitions.

Tip: If you plan to use multiple integrations, such as ServiceNow for one projectand SBM for another, in Application Administrator, you can set the forms for theEdit Business Requests and Edit Development Tasks transitions at the projectlevel.

The design and use of JavaScript is the same for both the ServiceNow and JIRA forms.Each form contains:

• Three REST Grid Controls:

▪ Filter Grid refreshed on Search link click

▪ Item result Grid refreshed on Get link click

▪ Currently selected items Grid never refreshed, loaded using JavaScript

• An edit control to use for pre-filtering the filter Grid

• A link named Search to invoke the filter search (JIRA's filter grid is loaded on pageload and uses a Refresh link instead)

• A link named Get <object type> to retrieve the tool items based on the filterselection (<object type> is the name of the external tool object being retrieved,such as Change Requests)

• Two links to Add and Remove items to/from the currently selected items Grid results

• Four actions to manage the controls using JavaScript executions:

▪ Form Load: Enable used to load the Currently selected item Grid

▪ Add responds to Add link click

▪ Remove responds to Remove link click

▪ On Submit handles the adding and removing of external tool items to thecurrently selected list

• Two JavaScript files:

▪ Solutions Util Loader.js

▪ RelationshipService.js

Part 4: Integration


Application Release REST Grid Widgets

The first two REST Grid widgets interact directly with the external tools to retrieve filteritems and items to associate to the Application Release.

Note:

ServiceNow and JIRA provide single REST service calls to retrieve items. If youwant to integrate with tools that require multiple REST calls or do not provideREST services, custom REST services must be created to wrap the tool's API foruse in the REST Grid Widgets.

The filter REST Grid may or may not require pre-filtering, depending on how many itemsmay be returned in the REST Grid. For the ServiceNow integration, the ServiceNowConfiguration Items are used to filter the Change Requests. The list of ConfigurationItems is large and therefore requires pre-filtering. A Text control takes the pre-filterinformation and passes that to the first REST Grid to return a list of items used to filterthe item list. The columns displayed in this REST Grid are not critical, except for the valueneeded to pass to the second REST Grid service. For example, ServiceNow needs thesys_id of the Configuration Item used to filter the Change Requests. This column may behidden.

The item list REST Grid invokes the REST service to retrieve the actual external tool itemsusing the selected row in the filter REST Grid. The columns contained in the Resultsproperty pane provide the data used to create a node in the Relationship Service andshould include:

• Name/Title (ServiceNow uses Short Description)

• Description

• Submitter/Creator

• Submit/Create Date

• Unique Identifier (may be hidden)

Optionally, the columns may include:

• Item ID/Issue ID a item identifier similar to SBM's Issue ID (ServiceNow has theNumber field)

• URL

The final REST Grid contains a list of the currently associated external tool items for theApplication Release. The list behavior is as follows:

• A Cypher Query initially populates this list. The query is run against the RelationshipService to find tool-specific items associated to the Application Release.

• Changes to the list are made only in the form and do not commit to the RelationshipService until Submit.

• Loading the REST Grid does not use any of the Refresh options in the REST Grid'sproperties. Instead, the REST Grid is loaded programmatically using a JavaScriptfunction invoked in the form's Form Load action. This programmatic load is neededto capture the original results from the REST Grid's request, which is modified by theAdd and Remove links and redisplayed with the changes.


Application Release Form Actions

Form actions control the display, manipulation, and submission of the final REST Grid onthe form. These actions are:

• Form Load: Enable <tool> Dev Tasks

• <toolname> Add

• <toolname> Remove

• On Submit: Handle Relationship Services

The form actions execute JavaScript to load the final REST Grid, add and remove items toand from the REST Grid, and process the results to the Relationship Service upon submit.

The Form Load: Enable <toolname> Dev Tasks action executes the functionenableRelationshipServices("<gridname>"); upon form load. This function initiatesthe load of the REST Grid after setting up to intercept the result processing in order tosave the service's results. The gridname is the name of the REST Grid on its Generalproperties pane.

The <toolname> Add action executes the following JavaScript when the Add link isclicked:

// Column IDs come from the REST Grid Widget displaying the external tool's itemsto relate to the App Release.

// The Column IDs map to Item ID, Title, Description, Submitter, Submit Date, Record ID,and URL and must be in this order

// If a tool does not have one of these, use double quotes for the column name ("")var columnIds = ["records.number", "records.short_description",

"records.description", "records.sys_created_by","records.sys_created_on", "records.sys_id", ""];

// Add the selected CRs to an App Release.// Parameters include:// source grid control name - for the list of items to relate to this App Release// target grid control name - displaying the items related to this App Release// external tool name - no spaces allowed (replace with underscores or remove)// external tool object type - no spaces allowed (replace with underscores or remove)// column ID array created aboveaddDevTasks("SNOWCRGrid", "SNOWDevTasksGrid", "ServiceNow", "Change_Request", columnIds);

The preceding code contains the details of the ServiceNow Add action's JavaScript. Whenadding new tools, change the columnIds and the arguments of the addDevTasks functionto reflect the new names of the REST Grids, tool, and tool object. The addDevTasksfunction adds selected items in the tool's item REST Grid into the results from the originalcurrently selected list REST Grid.

The <toolname> Remove action invokes the removeDevTasks("<gridname>"); functionwhen the Remove link is clicked. This function removes the selected items in thecurrently selected REST Grid. It does not move them to the tool's list of items that may beassociated to the application release.

The On Submit: Handle Relationship Services action invokes thehandleRelationshipServicesSubmit(); function to create the external tool nodes andrelate them to the application release, and remove the relationship between previous

Part 4: Integration


external tool nodes and the application release. The external tool nodes are not removeddue to the need for extra processing to make sure no other application release is relatedto the node.

Turnover Base State Form

The Turnover Base State Form displays the current Dev Tasks associated to the Turnover.These Dev Tasks will include any Sample Development Tasks, ServiceNow ChangeRequests, or JIRA Issues selected to be associated to the Turnover in the Associate DevTasks form.

The form places the Associated Development Tasks under the Requirements/Development tab. The tab contains a REST Grid to display the list and a transition link toinvoke the Associate Dev Tasks transition. The REST Grid uses the commonsvc/graph/cypherService/run REST service to retrieve the list.

Turnover Associate Dev Tasks Form

The Associate Dev Tasks form provides the controls to see the current list of associatedDev Tasks and a list of possible Dev Tasks to associate to the Turnover. Both lists residein REST Grid controls that request data using the commonsvc/graph/cypherService/runREST service. Two pre-defined queries return the proper list of items.

Turnover REST Grid Widgets

The AppReleaseDevTasks REST Grid provides the list of possible development tasks fromthe application releases related to the turnover. The REST Grid is not refreshed on pageload, but is instead loaded by a form action.

The TurnoverDevTasks REST Grid provides the list of actual development tasks from theapplication releases related to the turnover. The REST Grid is not refreshed on page load,but is instead loaded by a form action.

The Add and Remove links provide the controls to add and remove items to theTurnoverDevTasks REST Grid.

Turnover Form Actions

The actions used in this form are similar to the Application Releases Associate formactions. They are:

• Form Load: Load the two Relationship Service REST Grids

• On Click: Add Dev Tasks to Relate

• On Click: Remove Dev Tasks to Relate

• On Submit: Save Dev Task Changes

The Form Load: Load the two Relationship Service REST Grids action invokes theenableRelationshipServices("<gridname>"); JavaScript function to load both RESTGrid Controls. This allows for the saving of the results from both lists for adding andremoving to and from the TurnoverDevTasks.

The On Click: Add Dev Tasks to Relate action invokes theaddRelatedDevTasks("<sourceGridname">, "<targetGridName>"); function to copy


selected items from the source Grid (AppReleaseDevTasks) to the target Grid(TurnoverDevTasks).

The On Click: Remove Dev Tasks to Relate action invokes theremoveDevTasks("<sourceGridname>"); function to remove selected items from theTurnoverDevTasks Grid.

The On Submit: Save Dev Task Changes action invokes thehandleRelatedExistingSubmit(); function to process the items added and removedfrom the TurnoverDevTasks Grid.

Part 4: Integration


Chapter 16: Deployment Task Integration

When you start the deployment in Release Manager, the deployment tasks initiate thepre-configured application processes in Release Automation, which communicate with theintegrating products. In Release Manager, you can focus on selecting and sequencing thedeployment tasks that you need, and Release Automation takes care of the integrationdetails.

Release Manager deployment tasks integrate with the following products through ReleaseAutomation plug-ins.

• Serena ChangeMan ZMF

Release Manager initiates deployment to the z/OS mainframe through ChangeManZMF.

• Serena Dimensions CM

Release Manager initiates deployment to a full set of enterprise platforms throughDimensions CM.

• CA Nolio

Release Manager initiates the execution of Nolio processes to deploy on manyenterprise platforms.

The following topics give more information on the integrations and tell how to configurethem.

• Deployment Task Integration Configuration [page 85]

• Deployment Task Integration Usage [page 86]

Deployment Task Integration ConfigurationBefore users can associate Release Automation processes with Release Managerdeployment tasks, you must configure the integration.

Important: Most of the configuration for the deployment task integration isdone in Release Automation. The integrating applications must be configured inRelease Manager before you can select them. They must be properly configuredor the deployment requests will fail.

To configure the automation deployment integration with Release Automation, use thefollowing procedure:


1. Ensure that you have a supported installation of Release Automation and configureyour Release Automation settings using SBM Configurator if you haven't done soalready. Refer to Configuring Release Manager [page 39].

Note:

SBM Configurator writes settings for the Release Automation REST servicesto the following file. If you need to change the settings after the initialconfiguration in SBM Configurator, you must change this file manually.

../rlm-service/src/main/resources/properties/config.properties

If you need to reconfigure other Release Automation server settings, referto the Serena Release Manager - Release Automation User's Guide.

2. Configure the processes you are using for deployment in Release Automation.

Refer to the Serena Release Manager - Release Automation User's Guide"Integration" section.

Note: The ZMF plug-in is part of the RLM Mainframe Connector, which is aseparate option for Serena Release Manager.

Deployment Task Integration UsageThe deployment task integration enables you to associate turnover deployment tasks withpre-configured Release Automation applications that initiate Dimensions CM, ChangeManZMF, and Nolio operations.

Before using the automation deployment tasks, ensure that you have configured theintegration properly. Refer to Deployment Task Integration Configuration [page 85].

Deployment tasks should be configured by a release engineer who is very familiar with theprocesses needed for a successful deployment using the integrating product. This sectiongives typical use cases Dimensions CM, ChangeMan ZMF, and Nolio. For use in yourimplementation, you must know how to set up a successful sequence of operations inthese product if you plan to use them for your deployment.

The following topics give more information on using the deployment task integrations.

• Deploying Dimensions CM Baselines [page 87]

• Deploying ZMF Change Packages [page 88]

• Deploying Using Nolio Processes [page 89]

• Deploying Using Other Plug-ins [page 90]

Part 4: Integration


Deploying Dimensions CM Baselines

A typical deployment of a baseline based on sample data is given here. This examplegives only one use case. Details may vary for your implementation, but the concepts arethe same.

Note: The process you configure must follow your Dimensions CM stage lifecycle rules. For example, Dev to SIT to UAT to PROD.

To deploy baselines from Release Manager:

1. Configure a release train and link it to the Release Automation environment that isassociated with these Release Automation applications. For example, UAT.

2. Within a turnover associated with that release train, you can then add automationdeployment tasks. Add an automation deployment task as follows:

a. Enter a name and description and in Task type select Auto. The Applicationmenu lists active Release Automation applications. For example: Dimensions CM,Nolio, and/or ChangeMan ZMF applications

b. In the Application list, select a Dimensions CM application.

The Process menu lists all available Release Automation application processesfor the selected Dimensions CM application. For example:

• Promote Baseline

• Deploy Baseline

Important: The Get processes are used by subsequent forms forpopulating the selections, and should not be selected in the Processmenu.

c. Select the Promote Baseline process.

The Parameters tab shows fields for the related Release Automation properties.For example:

• Baseline Name

d. Enter or select the baseline name.

• You can use wildcard filters.

• Select the baseline you want using the resulting Select Value form.

• Entry data is not case sensitive.

e. Enter any other optional information.

f. Save the deployment task.

3. Add any other deployment tasks similarly to how you created the precedingdeployment task. For example, typical processes you'd select are PromoteBaseline and Deploy Baseline. The GET processes are typically used by the formsfor populating the selections.


4. After you have created all your deployment tasks for your turnover, deliver theturnover, accept it, and start the deployment according to your turnover process.

Deploying ZMF Change Packages

A typical deployment of a change package based on sample data is given here. Thisexample gives only one use case. Details may vary for your implementation, but theconcepts are the same.

Note: The process you configure must follow your ZMF promotion life cyclerules. For example, Dev to SIT to UAT to PROD.

To deploy change packages from Release Manager:


2. Within a turnover associated with that release train, you can then add automationdeployment tasks. You'll need to set up all of the deployment tasks needed tosupport the operations in ChangeMan ZMF that you need for the turnover.

Add a Deploy Package automation deployment task as follows:

a. Enter a name and description and in Task type select Auto. The Applicationmenu lists active Release Automation applications. For example: Dimensions CM,ChangeMan ZMF, and/or Nolio applications.

b. In the Application list, select a ChangeMan ZMF application.

The Process menu lists all available Release Automation processes for theselected ChangeMan ZMF application. For example:

• Deploy Package

• Freeze Package

• Approve Package

Important: The Get processes are used by the subsequent forms forpopulating the selections, and should not be selected in the Processmenu.

c. Select the Deploy Package process.


• Package Name

• Promotion Site

• Promotion Name

• Promotion Date

• Promotion Time

• User Variables

Part 4: Integration


d. Enter or select the package name, promotion site, and promotion name.

• You can use wildcard filters for the Package Name, Package Site, andPromotion Name. For example, to specify all packages beginning with cmn02,enter cmn02* in the Package Name field and then click Select. You can alsoenter multiple values using a semicolon as a delimiter.

• Select the package you want using the resulting Select Value form.




3. Add a Freeze Package deployment task similarly to how you created the precedingdeployment task.

4. Add an Approve Package deployment task similarly to how you created thepreceding deployment tasks. When you select the Approvers, all approvers arelisted, including the dynamic approver.

5. Add any other deployment tasks similarly to how you created the precedingdeployment tasks.


Deploying Using Nolio Processes

A typical Nolio process execution based on sample data is given here. Details may vary foryour implementation, but the concepts are the same.

To run a Nolio process from Release Manager:



a. Enter a name and description and in Task type select Auto. The Applicationmenu lists active Release Automation applications. For example: Dimensions CM,Nolio, and/or ChangeMan ZMF applications

b. In the Application list, select a Nolio application.

The Process menu lists all available Release Automation processes for theselected Nolio application. For example:

Run Process

c. Select the Run Process process.


• Application Name


• Environment Name

• Process Name

• Process Tag

• Nolio Servers

• Parameters

d. Enter or select the Application Name, Environment Name, Process Name, andProcess Tag.

• You can use wildcard filters for the Application Name, Environment Name,Process Name, and Process Tag.

• Select the name you want using the resulting Select Value form.




3. Add any other deployment tasks similarly to how you created the precedingdeployment task.


Deploying Using Other Plug-ins

If you want to deploy using Release Automation plug-ins other than Dimensions CM,ChangeMan ZMF, and Nolio, use the following procedure.

To run a Release Automation process from Release Manager:



a. Enter a name and description and in Task type select Auto.

b. In the Application list, select an application.

The Process menu lists all available application processes for the selectedapplication.

c. Select a process.

The Parameters tab shows fields for the related Release Automation properties.Enter or select any properties for the process.

The Components tab shows any components associated with the selectedapplication.

d. Enter any other optional information.

Part 4: Integration


e. Save the deployment task.

3. Add any other deployment tasks similarly to how you created the precedingdeployment task.



Serena Release Manager Guide

Documents

Transcript of Serena Release Manager Guide