To create a new release, navigate to the Search Releases screen using the Releases menu.
Click on the 
button to create a release. To edit a release, click on the release name link in the Name column.
Field | Description |
|---|---|
Name | The name of the release. |
| Status | The current status of the release (read-only).
|
Description | An optional description for the release. |
Start Date | The date and time in which the release was started (read-only). |
| End Date | The date and time in which the release was ended/completed (read-only). |
| Pipeline | The pipeline which is used to process snapshots for the release. |
Projects
To add a project to the release, enter the project name in the Search Projects to Add input field, and click the 
button. Configure the project details as defined below.
Column | Description |
|---|---|
Priority | The name of the release. |
Application Path | The fully-qualified path of the project (read-only). |
Project Name | The name of the project. |
| Project Type | The type of the project (read-only)
|
| Project Stream | The stream used for the project/package. Only one stream per project/package per release may be used. |
| Project Groups | An optional categorization based on groups defined in associated pipeline. Selection will affect the behavior/implementation of Deploy All, Test All, and Execute All pipeline stage steps. |
| Request All Files | Identifies whether the project is using selected files or all files for the release. Only applies to partial deployment projects. See also Managing Files for Partial Deployment. |
| Package Name | The package name for the project (required for partial deployment projects if not Request All Files). |
To add multiple projects at a time to the release using filter criteria, click on the 
button.
Optionally enter a criteria in the Project Name or Path field to filter the project list, and click the 
button to filter button. Next, select one or more projects to add to the release, and click 
the button, or simply click the 
button to add all projects displayed to the release.
You can add multiple packages to the release for the same project. Simply add the same project to the release and provide the package name.
Click the 
button to save your changes. To start the release, and allow snapshots to be created and sent to the pipeline for execution, click the 
button.
To temporarily pause the application so that no snapshots can be created and sent for execution, click the 
button. A paused release can be resumed by clicking the button again.
Once a release is completed, click the 
button to end the release. Like paused/suspended releases, snapshots can be created and sent for execution once ended. Ended releases cannot be resumed, and at this point you would need to create a new release.
Change Management
The Change Management System tab allows association of the release with any Change Management Instance which was configured in the topology. You must create the instance prior to configuring your release to it. Edit a Release, and select a Change Management System Instance from the drop down to associate it to the release. Association of a Change Management Instance is optional, and used only to integrate with ServiceNow.
Field | Description |
|---|---|
Change Management Instance | The Change Management Instance in Topology to associate with this release. Optional. |
The Default tab provides configuration which applies to every stage of the associated pipeline. Check the Require Change Ticket for Deployment checkbox if you want to enforce that every stage in the pipeline have an associated change ticket in order to submit a deployment request for that stage/environment. If any of the execution related steps (e.g. Deploy, Deploy All, etc.) are executed in the pipeline for a stage which requires a ticket, and no ticket is provided, the step will fail indicating a ticket is required.
The Environment Configuration allows configuration by pipeline stage. To override from the default, click the 
button, and then click the 
button to add a new row. In the row, select the environment/stage, and indicate whether or not you wish to require a change ticket. The execution behavior is the same as with default configuration when execution related steps are performed in the the particular environment within the pipeline. To delete the configuration override for a an environment, click the 
button in the row. The fallback to the settings on the Defaults tab, click the 
button.
Tip
To require a change ticket for Production only, set Require Change Ticket for Deployment to "No" on the Defaults tab, and add an override for Production environment with Require Change Ticket for Deployment" set to "Yes" (on the Environment Configuration tab).
Pipeline Team
The pipeline referenced by the release optionally defines a set of pipeline roles, and default members. The Pipeline Team tab allows viewing the roles their members, and overriding the members. For example,
Example
The Release Manager role could have Group1 as a member for Release1 and Group2 as a member for Release2.
The list of pipeline roles from the associated pipeline are displayed along the left-hand side. To view the members, select a pipeline role. Those members are displayed on the right.
To override the members for the release, click the 
button. The Members are displayed enabled for modification, and you can change the Groups and Users by shuttling from Available Groups/Users on the left, to Member Groups/Users on the right. Multiple email recipients (used for notification only) can be specified by semi-colon delimiting them. To revert the members of a role to the defaults defined on the pipeline, click the button.
Tips
- Filter the list of available Groups or Users by typing all or part of its name into the
Search fields. - As a best practice, avoid assigning users directly to pipeline roles. Instead, create a group with assigned users, and assign the group to the role. This allows managing users in a centralized location, and avoids management across potentially many pipelines and releases.
- Establish defaults in the role definitions of the pipeline, especially if team members are common across releases, to eliminate the need to configure the team on each and every release.
Pipeline Properties
blah
Security
blah