Free cookie consent management tool by TermsFeed

Releases

On This Page

A release is a way to group packages of related functionality to deploy at the same time. Releases can help you to organize changes, manage overlapping work across teams, and coordinate deployments.

You can associate packages with a release and set a target release date. This helps you to get started organizing related functionality at the beginning of your development lifecycle.

You can create and manage releases directly from the Packages view at the environment level.

Why use releases

Releases help you organize your changes from the beginning of your development lifecycle by enabling you to associate multiple packages with a release. Releases provide information, like if they are active/inactive and a target release date, that help you better understand which packages are actively being worked on and when they are expected to be released to users. This especially helps deployment managers manage larger sets of changes for deployment.

Releases provide developers with real-time visibility into overlapping work across teams. If the same object is included in packages associated with multiple active releases, both packages will be flagged. This way, you can make sure no in-progress changes are deployed with either release.

Key benefits of releases:

  • Group related packages for coordinated deployment.
  • Track target release dates for better planning.
  • Filter and search packages by release.
  • Streamline deployment workflows.
  • Help identify overlapping in-progress work.

Create a release

You can create a new release from the Packages view at the environment level in multiple ways: through the MANAGE RELEASES action, when creating or editing a package, or through the CHANGE RELEASE action.

To create a release through the MANAGE RELEASES action:

  1. On the Packages view, click MANAGE RELEASES, then CREATE RELEASE.
  2. In Create Release, configure the following properties:

    Property Description
    Name A unique name for the release. Release names must be unique across the environment.
    Description Additional details about the release.
    Target Release Date The date the release is planned to go into production.
    Color A color to help visually identify the release. Defaults to the first color in the list, which is red.

    create releases dialog

  3. Click CREATE.

All new releases are marked as active by default.

Associate packages with a release

You can use the CHANGE RELEASE action on the Packages view to:

  • Associate packages with an existing release.
  • Change the release associated with a package.
  • Remove the release associated with a package.
  • Create a new release and associate packages with it.

Excluding creating a release, you can take all of these actions individually on a package or in bulk on multiple packages at once.

To associate one or more packages with a release:

  1. From the Packages view, select one or more packages in the list.
  2. In the toolbar, click CHANGE RELEASE.
  3. For Release, select a release to associate with the selected package(s) or remove the release associated with the selected package(s).
  4. Click Save.

To create a release through the CHANGE RELEASE action:

  1. From the Packages view, select one or more packages in the list.
  2. Click CHANGE RELEASE.

    change release

  3. Under Release, click the .
  4. In Create Release, configure the following properties:

    Property Description
    Name A unique name for the release. Release names must be unique across the environment.
    Description Additional details about the release.
    Target Release Date The planned deployment date for this release.
    Color A color to help visually identify the release. Defaults to the first color in the list, which is red.
  5. Click CREATE.

The selected packages are automatically associated with the new release.

Note:  A package can only be associated with one release at a time. Associating a package with a new release automatically removes it from the previously associated release.

Manage a release

You can manage the properties of a release through the Manage Releases action on the environment level of the Packages view.

shows the Manage Releases dialog

Active and inactive releases

Active releases are releases that are currently being used to organize your development work and help with feature planning. You can only associate a package with an active release. Once all packages for a release have been successfully deployed, we recommend marking the release as inactive and deleting associated packages to keep your releases relevant and well organized. You can easily make inactive releases active again by editing the release.

Marking releases as inactive helps keep you organized in a few ways:

  • Inactive releases are not shown in release pickers, so it's easier to find and select the correct release for new packages.
  • Inactive releases are excluded from messages about objects in packages being associated with multiple releases, so messages in the Packages view are relevant and actionable.
  • When you mark a release as inactive, we'll give you the option to delete the packages associated with that release so that your packages always reflect in-progress work. You can always reference your deployment history for an accurate audit of previously deployed objects.

You can view and filter for inactive releases in the Manage Releases dialog.

Edit a release

To edit a release's properties:

  1. In the Packages view at the environment level, click MANAGE RELEASES.

    shows the Manage Releases dialog

  2. In the row of the release you want to edit, click .
  3. Select Edit.

    edit release

  4. In Edit Release, edit any of the following properties:

    Property Description
    Name A unique name for the release. Release names must be unique across the environment.
    UUID A universally unique identifier (UUID) for the release.
    Description Additional details about the release.
    Target Release Date The planned deployment date for this release.
    Color A color to help visually identify the release. Defaults to the first color in the list, which is red.
    Active/Inactive Status showing if a release is being used for active development and organization.
  5. Click SAVE.

Note:  Changes to release properties do not affect the Last Modified information of packages associated with the release.

Remove a package from a release

To remove the release association from one or more packages:

  1. From the Packages view, select one or more packages that are currently associated with a release.
  2. Click CHANGE RELEASE.

    change release

  3. For Release, select the No Release placeholder text to remove the association between the release and the selected package(s).
  4. Click Save.

The packages are no longer associated with any release, but the release itself remains in the environment and other packages may still be associated with it.

Deploy a release

When you deploy packages that are associated with a release, the release information is included in the deployment. After deployment, the release is automatically created or updated for you on the target environment.

The Incoming tab of the Deploy view with deployments filtered by release

When packages associated with a release are deployed to a target environment:

  • The release properties are included in the deployment.
  • If the release doesn't exist on the target environment, it is created automatically.
  • If a release with the same UUID already exists on the target environment, its properties are updated to match the properties of the imported version.
  • The release is included in the details for the relevant deployments on both the source and target environments.
  • A package is automatically generated on the target environment for each deployed release. Each generated package contains all the objects from the deployed packages associated with the release.

Deploying all packages associated with a release

You can deploy some packages associated with a release to a target environment without automatically deploying all other packages associated with that release. Once deployed, the release metadata and the selected packages are available in the target environment for reuse.

To deploy all of the packages associated with a release in a single deployment, use the Release filter on the environment level of Packages view to find and select the associated packages for deployment. Since packages associated with a single release can belong to different applications, using the filter on the Packages view at the environment level helps ensure that you include all the associated packages in your deployment.

The environment level Packages view filtered by release

Generated packages for releases

When releases are deployed to a target environment, packages are automatically generated in the target environment to hold all of the objects in deployed packages associated with each release. In order for these packages to be automatically generated, enable this setting in the Administration Console of the target environment.

Shows a release in the Deploy View of the source environment and a package generated with the same name in the target environment

In each modified application, one package is created for each release. This package has the same name as the release. For instance, if your release named "Quality Management 2.0" is associated with packages that contain objects from multiple applications, one package named "Quality Management 2.0" is generated for the release in each of the applications that were updated by the deployment.

Since the original deployed packages do not persist in the target environment, the newly generated packages allow you to keep track of which objects were deployed alongside which release. This helps you stay organized and more easily deploy all the relevant objects and releases to the next environment.

Note:  Database scripts, plug-ins, and application configurations from the deployed packages are automatically included in the packages generated in the target environment.

However, Import Customization Files from the deployed packages are not automatically included in the packages generated in the target environment.

View releases information for deployments

After deploying packages associated with a release, you can go to the Deploy view to view the following information about the releases included in each deployment:

  • In the Releases column on the Deployment history grid of both the INCOMING and OUTGOING tabs, you can view and filter by which releases were included in each deployment. This is especially useful for tracking which deployments have deployed changes for a given release.
  • In the Deployment details, you can view the releases associated with a deployment.

If a release is deleted after deployment, the release name still appears on past deployments as read-only text so you can keep track of which releases were part of each deployment.

Release name conflicts during deployment

If a release on the source environment has the same name but a different UUID as a different release on the target environment, a numeric suffix is appended to the deployed release name. For example, if "Release 2.3" already exists on the target with a different UUID, the incoming release of the same name is renamed to "Release 2.3 (2)".

Delete a release

To delete a release:

  1. In the Packages view, click MANAGE RELEASES.
  2. In the Action column for the row of the release you want to edit, click .
  3. Select Delete.
  4. Click DELETE.

When you delete a release:

  • The release is removed from the environment.
  • Packages that were associated with the release are no longer associated with any release.
  • The Last Modified information of the packages is updated.

Release security

Any user with access to Designer can view releases.

A user can associate a release with any package they have access to. All packages created in an application are visible to any user with Viewer permissions or higher to the application. In packages, users can only see the objects that they have permission to view.

Deploying packages that have an associated release follows the existing deployment security paradigm.

Security and release overlap alerts

The Packages view displays release overlap alerts whenever packages associated with different active releases contain the same object(s). Release overlap alerts are displayed on these packages even if a user does not have access to the shared object.

What you can see in the alert depends on your permissions:

If you have access to… You will see… You should…
The application, package, and object The full alert with all relevant application, package, and object names. Discuss the overlapping changes with other developers to determine if the changes can be deployed safely.
The application or package, but not the object An alert about the overlap for an object that you do not have permission to view. Reach out to other developers in the environment to understand the potential impact of deployment.
At least one object and package, but not all packages or the application An alert about the overlap for the object, without all the package or application names. Check the object's version history and decide if the object is in a good state to deploy.

Feedback