This rollout approach is incubation phase.
Unique needs clients to adopt the new process to collect experience in order to mature it and make it generally available.
Unique applies the same process to its Single Tenants. Naturally, as the Customer Managed Tenants and On Premise Tenants 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.
Disclaimer
The information provided in this Confluence page is for informational purposes only and is not intended as advice or a recommendation for choosing or implementing any specific tooling or process. For detailed advice and assistance on choosing and implementing the best setup for your needs, please contact the Unique Solution Engineering or Customer Success Team directly.
Unique offers Solution Engineering at a rate, where the client gets support in setting up the necessary tooling, processes and landscape to rollout Unique releases.
Glossary
Term | Meaning or Synonyms |
|---|---|
Release | A release is herein one Unique release as described in Release Process. |
Rollout | Applying the Release to the clients environment is herein called a Rollout, to rollout or rolling out. Synonyms herein: Update, to update, updating |
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 Infrastructure requirements.
Reference Rollout Process
Unique outputs a regular release package. The content and details about its production can be seen in https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/436536500/Release+Process#Release-Content.
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
Unique strongly discourages deploying infrastructure that directly depends on Uniques infrastructure.
Read below in each sub-chapter why a client is advised to mirror Uniques artefacts.
Ferryman
The script is called ferryman (as in ferrying things from A to B), de facto it is a tiny https://oclif.io CLI package.
Unique provides automation scripts that can fulfil the mirroring job in a basic use case. The script is contained within Uniques https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/436536500/Release+Process#Release-Content. If clients have specific needs, they can customise or extend (or use completely other means) to mirror the artefacts.
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
uniquecrartefacts 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.
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 Co-Development 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!
Author |
|---|