Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

To create a new release, navigate to the Search Releases screen using the Releases menu.  

Click on the Image Modified 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). 

  • Not Started - the release is not yet started, and is not eligible to process snapshot
  • Started - the release is eligible to process snapshots
  • Suspended - the release has been paused, and is not currently eligible to process snapshots
  • Completed - the release has ended, and will never process snapshots again (cannot be resumed).

Description

An optional description for the release.

Start Date

The date and time in which the release was started (read-only).
End DateThe date and time in which the release was ended/completed (read-only).
PipelineThe pipeline which is used to process snapshots for the release.
Scheduled Build

Cron expression to setup scheduled build for release projects. Project level Scheduled Build triggers are created, which can be viewed from project screen as well. More than one cron expression can be provided using ; separator. This would allow for more complex schedules. But all projects in release will use same schedule.

For example,

  • 0 0/10 * 1/1 * ? *  - build if changed every 10 minutes
  • 0 15 10 ? * *  - build if changed at 10:15 AM every day

If project added to release does not have Build Environment selected then it will not be part of scheduled build.

When Release is Ended, all Scheduled Build triggers associated with release will be deleted.

Info
titleRelease scheduled build processing
  • All projects in release with build environment Build Environment set will be setup for scheduled build.
  • Single release snapshot is created even when more than one project is found to have changed in SCM.
  • Projects with SCM set to None will not be processed, i.e.
    • Change detection is not possible
    • If there is a newer version for the project than what is in latest snapshot, new snapshot will contain
    same project version as latest snapshot for projects with SCM type set to None.During scheduled build processing,
    • if newer version.
    • Build is never invoked automatically in this case as SCM is None.
  • Projects with SCM other than None
    • Change detection will be performed.
    • If changes are detected in SCM, new build will be initiated for those projects, if .
    • If no changes are found in SCM, then latest version for project/stream/package will be used.
  • If there are no changes found in any projects or no newer project versions then snapshot is not created.
  • Project can be defined to be part of multiple releases with same stream. In such situations if projects is built once even without release selection that latest version will be included in all releases that contain that project with specific stream, when individual scheduled build trigger fires for those releases.


...

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.

Image Modified

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 Image Modified button, and then click the Image Modified 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 Image Modified button in the row.  The fallback to the settings on the Defaults tab, click the Image Modified button.

Image Modified

Tip
titleTip

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).

...