Release Lifecycle Management in Federated Environments

Release Bundles v2 can be used to manage the release lifecycle in a Federated environment, which is where Federated repositories provide Enterprise organizations divided across multiple geographical sites with a single source of truth for their binaries as if they were one seamless unit. This is particularly useful when Federations are employed in a disaster recovery or Active/Active multi-site framework, as it ensures that your releases, as contained in an immutable Release Bundle, are replicated across all sites.

Prerequisites

The following elements need to be configured on each Federation member:

• Keys: Signing keys must be configured on each Federation member.
• Projects: Release Bundles v2 created within the scope of a specific project can be Federated only if the project is configured on the other members. If you try to convert a local repository to a Federated repository within the scope of a specific project, and the project is not configured on the other members, you receive an error.
• Stages: Stages and their association with repositories used as promotion targets must be configured on each Federation member.
• Distribution targets: Distribution targets such as Edge nodes must be configured on each Federation member. It is possible to configure the same Edge node on each member.
• Permissions: Project roles and distribution destinations for each project must be defined for each Federation member.

Once all prerequisites are met, you can manage your SDLC with Release Bundles v2 in a Federated environment.

Release Bundle v2 Behavior in Federated Environments

The following behavior applies when using Release Lifecycle Management in a Federated environment:

• A Release Bundle v2 version can be created by any member of the Federation. The new version is replicated to all Federation members.

• A Release Bundle v2 version can be promoted and distributed by any member of the Federation. Enterprise+ is required for distribution. However, these operations are not replicated by the other members. The other members receive a timeline entry to inform them of the operation after it is complete.

  

• If multiple Federation members promote the same Release Bundle v2 version independently, update events for artifacts with the same checksum on the receiving site are skipped to prevent queue blockage.

• If multiple Federation members share the same distribution target, for example an Edge node, and one member has already distributed a Release Bundle v2 version to that target, a message is displayed that the version already exists if a second member tries to distribute the same version to the same target.

• A Release Bundle v2 version can be deleted by any member of the Federation. The deletion is replicated to all Federation members.

• If multiple Federation members share the same distribution target, deleting a Release Bundle v2 version from the target affects all members that use the target.

Limitations

Before creating the Federation, verify that the repositories do not contain existing Release Bundles v2 with the same name and version. Creating a Federation under these circumstances can lead to unpredictable behavior, including the possibility of artifacts getting overwritten within those Release Bundles. Other Release Bundles that do not have clashing names and versions will federate successfully.

Related Topics

• Understanding Release Bundles v2
• Release Lifecycle Management Setup
• Create Release Bundles v2
• Promote a Release Bundle v2 Version
• Federated repositories