Page Comparison

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:

1. The branch matching the name of the package being added, if it exists on the project

2. The default branch name defined in settings for the release, if the branch exists for the project being added

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