The following is a glossary of the terminology used in Serena Release Manager.
|
In Serena Release Manager, a program or system in computers or devices that addresses some problem as a whole. Some types of applications are commercial websites, batch and online business systems, and packaged software. Examples: an online teller system for a bank, an online music store, an accounting system. In Serena Release Automation, a high-level design construct whose design and ultimate execution allow achieving a fully-automated implementation of a server-based system. In ChangeMan ZMF, a user software project or domain being implemented. Named and defined by the application administrator; can be a mnemonic. User restrictions are set for it. Type in the exact name of the application in an application, or select from a list of applications by typing a pattern, or use masking. Possible References: APPL, PROJECT, LOCAL. |
|
|
Application Owner |
A possible role in Serena Release Manager that is the business owner of an application. An application owner is responsible for approving an application release during the planning stage and receives notifications of application release status. |
|
Represents a version of an application or project, where the application or project architecture is specified by components. One or more release packages are associated with each application release. |
|
|
Approval |
An action taken by an authorized user to progress an entity in a logical workflow. Approvals are typically required at states in the workflow that require expert review before the associated objects proceed to the next state. |
|
Architecture |
In Serena Release Automation, a generic design of a possible physical configuration for the implementation of an application. |
|
Area |
See Deployment Area. |
|
Automation Deployment Task |
A type of deployment task that integrates with release automation to automate installation and configuration tasks through the release automation software (such as Serena Release Automation) as part of the deployment process. |
|
A possible role in Serena Release Manager that performs builds for a release. This role may also be the Installation Manager in some organizations. |
|
|
Represent customer or business unit change requests that affect specific application releases. BCRs are associated with application releases and are typically associated with tickets from help desk or incident management systems such as Serena Service Manager and other SBM solutions. |
|
|
Change |
In Serena Service Manager, an item submitted into the Change Management process app, which helps ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to controlled IT infrastructure. If you are using the SSM to Serena Release Manager integration, you associate SSM Changes with RFCs. See Request for Change (RFC). |
|
Change Manager |
A possible role in Serena Release Manager that is responsible for the IT Operations for the systems where the pre-production and production release environments reside. A change manager approves deployment into pre-production and production environments. |
|
Change Request |
See Business Change Request (BCR), Development Change Request (DCR), and Request for Change (RFC). |
|
In ChangeMan ZMF, a group of changes to user software. Three levels include simple, super/complex, and participating, made up of members of partitioned data sets such as JCL, source code, copybooks, and so on. |
|
|
The visual representation of release trains and their schedules in Serena Release Manager. |
|
|
DML |
A Definitive Media Library, or DML, is defined by ITIL as the location where all "definitive and approved" versions of media are stored, including software, documentation, and licenses. The DML is a single logical storage area, even if multiple physical storage areas are included. |
|
Deployment |
The activities that make a software system or application available for use in an environment, including the physical movement of files, execution of commands, and configuration of environment settings. |
|
Represents the server or environment to which deployment units are copied during deployment. |
|
|
Deployment Process Template |
Enables you to create and copy sets of deployment tasks for reuse in different stages, release packages, and applications. |
|
Deployment Task |
In Serena Release Manager, an action to be executed as part of the process of deploying a release package into a specific stage environment. |
|
Deployment Task Types |
Determine the forms presented in the user interface and the processes executed during deployment of release packages. Default deployment task types include manual, vault, and automation. |
|
Deployment Unit (DU) |
Represents a set of deployable components. DUs are associated with release packages, and are typically associated with deployable components held in systems used to manage development processes, such as Serena Dimensions CM, Serena Development Manager, and Serena ChangeMan ZMF. Examples of sets of deployable components include Dimensions CM baselines with build outputs and ChangeMan ZMF change packages. |
|
Represent delivered changes from the development process. DCRs are associated with release packages and are typically associated with change requests from systems used to manage development processes, such as Serena Service Manager, the SBM Incident Management solution, Serena Development Manager, and Serena Dimensions CM. |
|
|
Development Manager |
A possible role in Serena Release Manager that is responsible for and approves development activities for a release. A development manager would typically be consulted during the release management process and provide approval on the content of a release package. This is a primary role in Serena Development Manager (DVM). |
|
Emergency Change Package |
In ChangeMan ZMF, unplanned change packages that are scheduled for installation outside of normal business hours. Emergency change packages are automatically assigned a shorter approval list. |
|
Emergency Release Package |
In Serena Release Manager, a release type for unplanned release trains or release packages that must be expedited through the minimum required release stages. In the default implementation, emergency release packages are deployed only to the Production Deployment stage. See Release Type. |
|
Environment |
In general, a physical computer and operating system on which software resides; for example, a Windows or UNIX server. In Serena Release Manager, represents one or more physical or logical computers or systems to which a release package may be deployed. In Serena Release Automation, one of any number of real, physical implementations of a specific architecture that was designed for the application. |
|
In Dimensions CM, the lifecycle that items follow that controls which versions are included in configurations and builds of the project or stream. This lifecycle is defined for the base database. Deployment areas for a project/stream can be associated with these stages so that item files are copied to those areas when they are deployed to the corresponding stage. |
|
|
Incident |
An item in the Incident Management SBM solution. An incident may be mapped to a Serena Release Manager Development Change Request (DCR). |
|
Installation |
In ChangeMan ZMF, the process of either updating the production libraries, or in the case of temporary change packages, concatenating the temporary production libraries before the current production libraries. Change packages are turned over to the ZMF installation scheduler after the final approval. For change packages that have a manual scheduler, ZMF submits the first installation job as soon as the last approval is entered, regardless of the installation date on the ZMF calendar. |
|
A possible role in Serena Release Manager that ensures that the deployment, or installation, of a release is done correctly and completely. An installation manager is assigned manual deployment tasks in Serena Release Manager and is responsible for deployment of request packages into environments. This role may also be the Build Manager in some organizations. |
|
|
Integration Test (INT) |
Testing of all application release components together to ensure that the application release’s functions properly as a whole. This testing typically follows unit testing in a testing lifecycle. In the default implementation of Serena Release Manager, Integration Test is also a stage in release train and release package schedules. |
|
Issue |
An item in the Issue Defect Management (IDM) SBM solution. An issue may be mapped to a Serena Release Manager Development Change Request (DCR). |
|
Item |
In general, a software entity or object that can be listed or selected. In SBM, primary items, such as issues and incidents, are records that are tracked by an application. Primary items are organized in projects, which are assigned to a workflow. You submit primary items into a specific project, and those items follow the project's workflow to completion. In Dimensions CM, an object that represents the physical implementation of an application component. For example, an item in a software application could be source code, an executable file, a specification, or a user guide. An item in a website could be an HTML file, a script, or an image file. |
|
Lifecycle |
The set of states and rules for transitions between states defined for a particular object type. |
|
Major Release Package |
In Serena Release Manager, a release type for release trains or release packages that require the maximum release stages. In the default implementation, major release packages are deployed through the INT, UAT, and Production Deployment stages. See Release Type. |
|
Manual Deployment Task |
A type of deployment task. An action to be executed by a person as part of the deployment process. |
|
Minor Release Package |
In Serena Release Manager, a release type for release trains or release packages that require only some of the release stages. In the default implementation, minor release packages are deployed only to the UAT and Production Deployment stages. See Release Type. |
|
Pre-Production |
The environments to which production-ready application releases are deployed and held before deployment to production. Pre-production can be thought of as final staging or production readiness. In the default implementation of Serena Release Manager, Pre-Production is also a stage in release train and release package schedules. |
|
Process |
In Serena Release Automation, a high-level sequence of planned activity involving one, multiple, or all components of an application. |
|
Production |
The environments to which production-ready application releases are ultimately deployed. Production can be thought of as live or real-time environments. |
|
Production Deployment |
A stage in release train and release package schedules in the default implementation of Serena Release Manager. |
|
Product Test |
Testing of a product’s features and functionality. This testing typically follows unit testing in a testing lifecycle. In the default implementation of Serena Release Manager, Product Test is also a stage in release train and release package schedules. |
|
Project |
In general, a project is an organizing entity made up of a collection of related objects. |
|
Promotion Level |
In ChangeMan ZMF, manages test libraries. For example, promotion Level 10 could be defined for Integration Testing, promotion Level 20 could be defined for User Acceptance Testing, and promotion Level 30 could be defined for Production Readiness Testing. |
|
QA Manager |
A possible role in Serena Release Manager that is responsible for and approves testing activities for a release. |
|
Release |
See Application Release. |
|
Release Automation |
The part of release management that automates application installation and configuration tasks. In the default implementation of Serena Release Manager, the release automation is done using Serena Release Automation. |
|
Release Calendar |
See Calendar. |
|
Release Control |
The part of release management that controls the processes. In the default implementation of Serena Release Manager, release control is powered by Serena Business Manager (SBM). |
|
Release Engineer |
The default role in Serena Release Manager that is responsible for the automating the release deployment and resolving any deployment failures. For example, a release engineer may create deployment tasks for release packages. This role may be the Installation Manager or Build Manager in some organizations. |
|
Release Management |
The management of defining and deploying versions of applications into production environments. The activities of release management include defining, scheduling, monitoring, changing, provisioning, and analyzing history of multiple releases deployed into production environments. |
|
Release Manager |
The default role in Serena Release Manager that is responsible for releases within a particular organization. A release manager manages and monitors releases, plans releases in collaboration with development managers, and responds to successes, failures, and other statuses. |
|
A portion of IT or service infrastructure normally built, deployed, tested, and released together. Release packages define the set of changes to be deployed and drive the deployment processes. |
|
|
Release Runbook |
Represents a set of tasks and activities to be performed in a specific order to implement an application release. The release runbook is implemented in association with a release train. |
|
Release Schedule |
See Release Train. |
|
Gate that the release goes through on its path into production. Typical stages in a release are integration test (INT), user acceptance test (UAT), and production deployment (PROD). A stage may have one or more environments related to it. Releases may be deployed into an environment based on availability. |
|
|
Provides a published schedule of changes to production. One or more application releases are associated with each release train. |
|
|
Drives release policies on what types of changes may be delivered for release trains and determines the stages release packages are deployed through. In the default implementation of Serena Release Manager, release types include major, minor, and emergency. See also Release Stage. |
|
|
The location where all development tested versions of media, typically software or documentation, are stored. In the default implementation of Serena Release Manager, the provided release vaults are Dimensions CM and ChangeMan ZMF. |
|
|
In Dimensions CM, an object used to report a defect, suggest an enhancement, or detail other work for a particular product. Requests can include external files (such as requirements or specification documents) as attachments. A request may be mapped to a Serena Release Manager Development Change Request (DCR). See also Request for Change (RFC), Business Change Request (BCR), and Development Change Request (DCR). |
|
|
Represent operational changes that may affect multiple applications or implement system infrastructure changes within an enterprise. RFCs are associated with release trains and are typically associated with tickets from service management systems such as Serena Service Manager. |
|
|
Server |
A computer that manages centralized data storage or network communications resources. A server provides and organizes access to these resources for other computers linked to it. (American Heritage Science Dictionary) In Serena Release Automation, the actual physical machines on which a Web-based application will ultimately run. |
|
Server Type |
In Serena Release Automation, an abstract representation of a server specified for a particular architecture. |
|
Site |
In ChangeMan ZMF, locations where change packages are stored. These are typically IBM z/OS LPARs, either local or remote. |
|
Software Application |
See Application. |
|
Stage |
In Serena Release Manager, a Release Stage. In Dimensions CM, a stage in the Global Stage Lifecycle. |
|
State |
A key part of a Serena Business Manager (SBM) workflow. States are positions that a primary item, such as a release package, resides in while moving through a process workflow. States can also be considered a stopping point along a workflow's path. |
|
Status |
A measure of where an item is in relation to a preset goal. For a release train, status is the lowest status of the application releases associated with it. Release managers manually set the status for application releases. Release package status is automatically set by Serena Release Manager based on movement of the release package through underlying SBM states. |
|
Status Indicator |
A visual representation of status, such as green for on schedule, yellow for schedule at risk, and red for behind schedule. |
|
System |
Depending on the context, can refer to a software application, to an environment, or both. |
|
Unit Testing |
Testing of individual or groups of similar components of a software application as part of the development process. This testing is typically done by software engineers who are developing the components and is done before the components are considered complete and packaged for deployment (baselined). |
|
User Acceptance Test (UAT) |
Testing of an application release by key users to evaluate the application release’s compliance with its specified user requirements. This testing typically follows system testing in a testing lifecycle. In the default implementation of Serena Release Manager, UAT is also a stage in release train and release package schedules. |
|
Vault |
See Release Vault. |
|
Vault Deployment Task |
A type of deployment task that integrates with a release vault, such as Dimensions CM or ChangeMan ZMF, for secure deployment of deployment units. For example, Dimensions CM vault deployment tasks move baselines securely to environments. |
|
Vault Request |
Enables you to easily bring components from disparate SCM and build management systems into Serena Release Manager and provides you with the option to identify components as definitive media. |
|
Vault Template |
Created either standalone or from vault requests to more easily create similar vault requests. |
|
Workflow |
In Serena Release Manager and SBM, a collection of states, transitions, and fields that define an organization's tracking process. |