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. Starting with Artifactory 7.84.3 it is possible to work with Release Bundles v2 in a Federated environment as part of managing your release lifecycle. This is particularly useful when Federations are employed in a DR (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, the user receives an error.
Environments: Environments 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.
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 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 ("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.)