Release Definition

The Definition tab on each release allows for editing basic release details, as well as managing release content (projects/packages) and work items.

1 Editing Basic Details
2 Content (Projects/Packages)
- 2.1 Adding Content
- 2.2 Viewing/Editing Content
- 2.3 Table Options
3 Work Items
- 3.1 Adding Work Items
- 3.2 Removing Work Items
4 Automatic Adding of Release Content
5 Automatic Adding of Work Items

Editing Basic Details

To edit basic release information, go to the Definition tab and select the icon on the right side panel.

Field	Description

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, 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 When a release is Completed or Paused, all the scheduled build triggers for each project/package in the release will be deleted. Release Scheduled Build Processing 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. All projects/packages in a release with a Build Environment set will be configured for build trigger based on the snapshot schedule. 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 or Webhook 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/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 and 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.

Content (Projects/Packages)

The content table on a release lists all items which are actively being built/deployed for any running snapshots, and is made to be constantly changing as snapshots are created. It can also be used to track the history of what’s been deployed as part of the release by viewing inactive/completed packages and inactive projects. To view all projects and packages in your release, make sure you have the content view selected on the Definition tab.

Adding Content

To add a project or a package to the release, enter the name in the Add Content input field and select the content you want to add.

To add multiple projects and packages at once, select the icon at the end of the input field.

In this popup, you can toggle between showing just projects, just packages, or both by using the icons. When showing only packages, you can optionally filter by only packages in a particular project. These selections are saved and remembered for future use. The Filter Results input field can be used to search by project name, package name, and folder path.

Selected content will appear on the right side of the popup. To add all selected content to the release, click the button.

You can add multiple packages to the release for the same project from the popup. Change the top left toggle to show only packages, then filter by the project to easily add only packages from a specific project.

Viewing/Editing Content

After adding content to a release, it can be configured from the context menu or actions column at the end of each row. To edit an individual item, open the context menu and select Edit or choose a field to update directly from the menu.

Multiple rows can be updated at once by selecting the rows you want to edit and right clicking on any of the rows, or by pressing the [2] icon above the table.

The table below explains each field displayed in the table and how it is initialized/updated.

Column	Description

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

Show Completed Packages - If this option is enabled, any completed packages in the release will be included in the content table. This filter can be helpful for viewing the content history of a release. These items are not eligible to be deployed and therefore will be left out of all future snapshots.

Work Items

Each release contains a listing of work items which can be used to track what's been deployed and manage content. The work items listing is shown in order of last added, with an option on the list menu to export all work items to CSV or PDF.

To view all work items in your release, make sure you have the work item view selected on the Definition tab.

Adding Work Items

To add a work item to the release, find it in the Add Work Item input field and select the work item to add it. The search input will initialize the ITS instance and ITS project(s) (if applicable) to the ITS settings configured on the release's folder. The last 50 updated work items will be shown in the list, or you can search for them.

To add multiple projects and packages at once, select the icon at the end of the input field. Similarly, when the add popup is opened, the ITS instance and ITS project(s) (if applicable) will be initialized to the ITS settings configured on the release's folder.

The results are shown in the table based on the filters provided. Depending on your release settings, there may be an arrow on the left in each row which can be expanded to show any projects and packages which are associated to the work item and therefore, would be added to the release if that work item is added. The arrow may be disabled if the work item has not yet been built in FlexDeploy.

Selected work items will appear on the right side of the popup. To add all selected items to the release, click the button. Saving will automatically add any associated projects/packages to the release if enabled by the Auto-Add Content Options release setting. Learn More.

Removing Work Items

Work items can be removed from the context menu on each row. If any related projects/packages are found in the release, a popup will be shown where you can select which related item(s) to remove along with the selected work item.

Automatic Adding of Release Content

If enabled by your Auto-Add Content Options release setting, there are scenarios when projects/packages could be automatically added to your release based on the work items in the release, which are explained in the image below.

Automatic Adding of Work Items

A work item will be automatically added to the release in the following scenarios:

The work item is added to a package, and that package is in the given release
A package is added to the release, and the work item is already linked to that package
A snapshot is created containing a build version linked to the work item