...
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 8.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. When Snapshot Schedule is added or updated, Project-level scheduled build or webhook 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/packages in the release will use the same schedule. For example, When a release is Completed or Paused, all the scheduled build triggers for each project/package in the release will be deleted. | Info |
|---|
Release Scheduled Build Processing |
project.When a release is ended, all the scheduled build triggers for each /package in the release will be deletedRelease Scheduled Build Processing | | Info |
|---|
All projects/packages in a release with a build environment Build Environment set will be configured for 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. . If project is Webhook enabled then Webhook trigger is created otherwise Scheduled Build trigger is created. For Scheduled Build trigger, build will be initiated for each release project/package on Snapshot Schedule, and for Webhook trigger build will run via Incoming Webhook. New snapshot will be created automatically on schedule, if changes are found for Scheduled Build projects or new builds are found for project/package. This means that for Webhook enabled projects, incoming webhook should initiate build. You can view (but not edit) associated
scheduled build A single release snapshot is created even when more than one project/package is found to have changed in SCM or built via Webhook. 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 Noneand Webhook Disabled Change detection will be performed on Snapshot Schedule. 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.
Projects with SCM and Webhooks are Enabled Change detection is not performed on Snapshot Schedule. Incoming Webhook is responsible for performing build based on incoming payload. New build for project/package will be picked up on Snapshot Schedule. Incoming Webhook scripts will only find project/package to build if Webhook is Enabled on Project and project/package is added to Release with Build Environment.
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.
|
|
...
The table below explains each field displayed in the table and how it is initialized/updated.
Column | Description |
|---|
Priority | Priority defines the sequence of deployment for the project/package when a release snapshot executes the Deploy All Step. Priority does not have to be in increments of 1. For example, you can define priority for various release projects/packages as 3, 4, 8, 20. Priority must be greater than 0. Unlike project priority, this value is not limited to 100, so you can use larger values if desired. You can use the same priority for more than one project/package. If you set priority as 2 for 4 projects and packages, then all 4 of them will deploy at the same time (parallel execution). When the Deploy All Step executes, it will deploy from lowest to highest priority project/packages. All projects/packages with the same priority are deployed in parallel. If successful, then next priority projects/packages are deployed. If deployment fails at any point, then any higher priority projects/packages will not be deployed and the Deploy All Step will fail. Priority setting can be used in conjunction with Project Groups, in which case you will have multiple Deploy All Steps in your pipeline stage. For example, you could have pipeline steps like Deploy EBS Projects, Deploy MuleSoft Projects, etc. General recommendation is to use single Deploy All Step and control sequencing (dependency) using Priority. When content is added to a release, the deploy priority on the project is used to default the value of the project’s/package’s priority in the release.
|
Item | The project and package (if project is package-based). The project/package combination cannot be edited after adding to the release. The project’s full folder path will be displayed only when not using Dense mode. Hovering over the project or package name in the content table will open a hover menu displaying more details for that item. Selecting the name at the top of the hover menu will open the corresponding project/package.  Image Modified |
Project Groups | An optional categorization based on groups defined on the associated pipeline. Selection can affect the behavior/implementation of Deploy All, Test All, and Execute All pipeline stage steps, if any of these steps are configured to execute against only certain project group(s). This will only be displayed if the attached pipeline has project group(s) defined. |
Branch | The branch used when building the project/package during snapshot creation. Only one branch per project/package per release may be used. When an item is added to the release, the branch is initialized in this priority: The branch matching the name of the package being added, if it exists on the project The default branch name defined in settings for the release, if the branch exists for the project being added The main branch of the project being added
|
CI | Read-only column which defines how builds are initiated for the project/package. This column will appear only if a snapshot schedule is configured for the release. Scheduled  - Builds are initiated on an interval based on the snapshot schedule defined. Webhook - Builds are triggered by webhooks. Manual - Builds are done manually. None - Build environment is not configured for the project/package, so builds cannot be initiated from the release.
|
Build Environment | The environment to use for builds triggered based on the snapshot schedule. If no build environment is specified and the release has a snapshot schedule, this project/package will not be included in the scheduled build. This environment is also what’s set initially for this item when creating a snapshot manually, although it can be updated. If there is only one build environment for the project, then this will be auto-set. Otherwise, the build environment will be initialized to the last environment the project/package was built against, if one exists. |
Added | The FlexDeploy user who added this item to the release and timestamp of when it was added. Note that this could be a FlexDeploy Bot user if the item was auto-added based on linked work items. |
Table Options
Just like other tables in FlexDeploy, displayed columns and ordering can be updated from the table menu. Even though there’s no saved query support, your table settings will be saved for future use and applied to all releases. Note that the Project Groups column will appear only if the pipeline attached to the release has project group(s) defined, and the CI column will appear only if a snapshot schedule is defined for the release.
...