Unique applies the same process to its Single Tenants. Naturally, as the Customer Managed Tenants and s are very specific to each client Unique can only provide a guidelines including best practises.

In CMT and ST, the client is accountable and responsible to rollout the changes, for that they must also host or provide the Supporting Tooling.

Scope

This page provides

Audience

This Confluence page is intended for IT professionals, cloud architects, and decision-makers involved in the planning, deployment, and management of Unique. It is particularly useful for those seeking to understand the mechanics of how the Unique product(s) and the updates/changes towards them get rollout out into their respective setup. The content is also relevant for project managers and finance teams responsible for budgeting and financial planning of the infrastructure, tooling and staff necessary to accommodate the work items described below.

Glossary

Infrastructure requirements

In order to reliably, automatically rollout a release, certain infrastructure is needed. Of course one can apply all changes manually, but this is highly discouraged.

The tooling required for a rollout is described in Supporting Tooling of Uniques .

Reference Rollout Process

Unique outputs a regular release package. The content and details about its production can be seen in .

Once published, clients receive notifications and can choose to update at will. Unique recommends to update regularly as Unique does only provide fixes in the latest versions and only supports the last two versions without further contractual and/or monetary agreements.

rollout

New release available

Unique has announced and documented a new release.

Mirror artefacts

Supporting scripts

@unique-ag/cli

The Unique CLI empowers clients to efficiently adopt the Unique product(s). Please refer to its documentation to see its capabilities.

The CLI is open-source and clients are empowered to actively contribute towards it (is it issues or even pull requests).

Ferryman

In some client scenarios directly using the CLI is not possible as the underlying system is not able to run NodeJS code.

https://github.com/Unique-AG/monorepo/pkgs/container/ferryman is a simple Docker image, which provides a NodeJS environment that clients can then install the CLI in and leverage its command palette.

uniquecr.azurecr.io

Unique publishes new images (regularly) and helm charts (less regular as they rarely change) towards a private Azure Container Registry.

Access

During a clients preparation or setup phase, the client will be provided client-specific OCI credentials (Username and Password). They are repository-scoped tokens.

Limitations

• uniquecr.azurecr.io has no SLA

• The registry does not scale and is shared with all clients

• Unique will regularly remove unsupported versions from the registry, clients using EOL versions will fail to deploy/scale/provision if direct registry access is used in production

Due to these limitations alone, it is strongly discouraged to directly rely on the release infrastructure of Unique.

Unique advises all clients to setup a mirroring registry on their side for the following reasons:

• Security: you can control which images are pulled into your environment and scan them for vulnerabilities

  • Supply Chain Security: Even though uniquecr artefacts are immutable, only an own registry gives you a 100% guarantee, that the images used are never tampered with or corrupted.

• Compliance: you can ensure that only approved images are used in your environment and that they are scanned for vulnerabilities

• Resilience: you can ensure that your environment is not affected by outages in Unique's registry or the network between your environment and Unique's registry

• Performance: you can ensure that your environment is not affected by outages in Unique's registry or the network between your environment and Unique's registry

• Cost: you can reduce the cost of pulling images by caching them in your environment

Unique-AG/release

Besides the images and charts, Unique publishes additional release content that does not suit a OCI registry really. For this purpose, the rest of the Unique release content is published into a private GitHub repository.

Access

During a clients preparation or setup phase, the can provide up to three GitHub collaborator handles that Unique will invite to pull (read) from this repository.

Invited collaborators will get an invitation like this which they can accept and afterwards read from the repository.

Open

Reference invitation for a clients collaborator

Limitations

The repository is generic meaning no client specific code is within it. Clients customise Unique within their repository to match their landscape and thus this repository is only suitable as generic information or upstream source but no code can be pushed into it from client side.

registry@client

From this registry, a clients infrastructure can and should depend. This not only lets the client manage the registries SLA or scale, but also allows clients to leverage existing infrastructure. Clients mostly have a preferred registry(ies) already, probably with in-built vulnerability scanning, reporting etc.

git@client

Infrastructure or configuration as code contains client specific values. Additionally each client can extend Uniques reference artefacts for their own components. All these extensions and customisations are specific and most probably sensitive to the client. Unique recommends clients, to properly rollout and configure Unique from a client-side repository. This also empowers clients to have a clean audit-trail and history of which releases and changes of Unique were rolled out when and by whom.

Privacy of the Registry and the Repository

The registry and repository are private as Unique is not open source and the product contain prompts and is commercial.

Clients with a agreement can naturally still or already see the disclosed source code in the other Unique-AG repositories.

Deploy

Once the images, charts and code is in place, the client can deploy according to their own specifications (timing, stages, audience etc.) from within their own repository using their automation (or discouraged: manually). The deployment mechanisms are equally specific per tenant and each clients (central) architecture or platform team might have different requirements.

Unique provides reference files to enable and empower clients to rollout the changes!