Versions Compared

Key

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

...

Field

Description

Name

The name of the release.

Folder

The folder the release is located in. All security and settings are inherited from this folder, unless overridden.

Pipeline

The pipeline which is used to process snapshots for the release.

The pipeline attached to the release is displayed below the folder path for quick access, and can be updated both from here and from the right side panel.

Description

An optional description for the release.

Status

The current status of the release. 

  • Started - the release is eligible to process snapshots

  • Paused - the release has been paused, and is not currently eligible to process snapshots

  • Completed - the release has ended, and will never process snapshots again (status can still be reverted back to started if needed)

Since FlexDeploy 7.0, all new Releases will be in Started status and Not Started status has been removed. This means that Release may be Started even without any content, and obviously Snapshot can only be created after some content is added to Release.

Snapshot Schedule

A cron expression to initiate the creation of a snapshot on a regular basis, using new project versions for all release projects. Project-level scheduled build triggers are created, which can be viewed from the project triggers screen as well. More than one cron expression can be provided using ; as a separator. This would allow for more complex schedules, but all projects in the release will use the same schedule.

For example,

  • 0 0/10 * 1/1 * ? *  - create snapshot if there are SCM changes every 10 minutes

  • 0 15 10 ? * *  - create snapshot if there are SCM changes at 10:15 AM every day

If a project added to the release does not have a build environment selected, then a new build will not be triggered as part of the snapshot creation. The latest project version will be used for that project.

When a release is ended, all the scheduled build triggers for each project/package in the release will be deleted.

Info

Release Scheduled Build Processing

  • All projects/packages in a release with a build environment set will be configured for triggered builds build trigger based on the snapshot schedule. This will initiate a build for each release project by creating a snapshot for the release containing all new project versions. You can view (but not edit) associated scheduled build triggers on project screen (Configuration → Triggers Tab) as well. They are automatically managed when the snapshot schedule is configured for a release.

  • A single release snapshot is created even when more than one project is found to have changed in SCM.

  • Projects with SCM set to None

    • Change detection is not possible

    • If there is a newer version for the project than what is in the latest snapshot, the new snapshot will contain this newer version.

    • Build is never invoked automatically based on the snapshot schedule in this case as SCM is None, but separate build triggers can be created from the project to automate this.

  • Projects with SCM other than None

    • Change detection will be performed.

    • If changes are detected in SCM, a new build will be initiated for those projects as part of the snapshot creation.

    • If no changes are found in SCM, then the latest version for that project, branch, and package combination will be used in the snapshot.

  • If there are no changes found in any projects/packages and no newer project versions since the latest snapshot, then a snapshot will not be created.

  • A project or package can be added to multiple releases with the same branch. In such situations, if the project/package is built once, even without release selection, that latest project version will be included in all releases that contain that project/package with the selected build branch, when individual snapshot schedule trigger fires for those releases.

...