Release Types
Unique features two different release types, modes or models:
Continuous Releases for our Platform as a Service model
Regular Releases for these models
Overview
Continuous releases
Unique releases continuously every single change to Platform as a Service.
Regular releases
Uniques current release cycle is weekly. Depending on the customers choice this frequency can be lowered (e.g. to monthly) upon request.
While the frequency for customer-managed and on premise tenant can be increased by the client themselves, Unique does not offer a higher frequency for Single-Tenants.
Release Lifecycle
About the Lifecycle
Releasing software in phases allows developers to manage risk and improve product quality by systematically testing and refining the software. It begins with internal testing to catch major bugs, then moves to external testing where real-world users provide feedback on functionality and usability. The release candidate phase follows, focusing on identifying remaining critical issues before the final version. This phased approach helps ensure that the software is stable, meets user needs, and reduces the likelihood of significant issues in the final release, thus enhancing customer satisfaction and reducing costly post-release fixes.
You can learn more about Unique's approach to software development in Secure Software Development Lifecycle or Release Process.
Phases and Objectives
Unique currently maintains 3 phases…
Phase | Key aspects | Target group |
|---|---|---|
|
|
|
|
|
|
|
|
|
* These phases are explicitly excluded from any SLA, only changes that have matured to GA are covered by any SLA. Support for these changes is on best-effort basis.
EXPERIMENTAL
EXPERIMENTAL changes or features are tested with a very small user base, most often a few specific individuals. There are two outcomes to this only:
Unique discovers an added value for the client and progresses the change to
BETAUnique identifies issues, problems or inefficiencies and basically terminates the experiment
Why even document these publicly?
Unique values transparency, collaboration and innovation above everything and there is no reason to hide a change (except for rare Intellectual Property or Market Advantage cases, e.g. in Prompt Engineering).
Displaying the secure innovation externally allows clients to discover interesting ideas, signal their interest or motivation to co-innovate. The clients and Unique can only win from innovating together!
BETA
BETA changes or features already have a stable place within the product and are getting tested against a larger user base.
There is still the option that Unique decides to sunset or terminate a change in this state prematurely but it is highly unlikely and not the goal.
General Availability (GA)
Features and changes that matured to GA have been or are scheduled to be released to all clients, users and/or tenants. They are here to stay and are constantly quality-assured, improved, enhanced or changed by Unique's product teams.
Changes in GA can be sunset or deprecated but it is uncommon and rare. It would involve proper communication, sunsetting notices and durations as well as the implementation of replacing functionality.
Release Content
As seen in the Secure Software Development Lifecycle Unique provides a variety of artefacts per release, delivery or rollout cycle.
One Unique release consists of:
Artefact | Further Use | Format | Consumable | |
|---|---|---|---|---|
Unique Product | ALL | Run Unique workloads with a container orchestrator | Multiple Docker Images | Either as files forked to own Git, tarballs or images from a private Azure Container registry |
Connectors (On Premise and Cloud) | CMT OP | Upgrade local installations of various connectors to connect to the Unique Product | Multiple Docker Images | Either as files forked to own Git, tarballs or images from a private Azure Container registry |
Helm Charts | CMTOP | In order to run Unique on Kubernetes, helm charts are the recommended way to render and apply Kubernetes manifests. | Multiple Helm | Either as files forked to own Git or tarballs from a private Azure Container registry |
Helm Files | CMTOP | Mainly for inspiration as most clients have their own deployment infrastructure already. Enables customers (providing their own customisation) to deploy Unique Product upon a Kubernetes Cluster | YAML ( incl. 3rd party OSS services + their config as code | As files forked to own Git |
Terraform modules | CMT | Terraform own Azure Landscape or just get inspired which components are needed | HCL for Azure | Either as files forked to own Git or published over Azure Container registry |
SBOM Software Bill of Materials | ALL | For further analysis for customers, pinned to the current release | SPDX format incl. Grype Scan results | As files |
Release notes | ALL | A change log for humans | Text | Public docs |
Customisation examples | CMT | Customise each setup from example cases | YAML | Files forked to own Git, then overridden |
Ferryman | CMTOP | A basic script to mirror images and helm charts from Unique to the Client, see Rollout Reference Framework. | NodeJS CLI using https://oclif.io | Files forked to own Git |
Setting up & Maintaining Releases
Rolling out regular releases (the release content) to Customer Managed Tenants or On Premise Tenants is a topic on its own and you clean learn more about it in
Rollout Reference FrameworkRelease Naming
Continuous release names
The continuous releases are not additionally named, they use short SHAs to identify which version it is.
You find them on various screens and they consist of a hexadecimal representation like 37cd467.
Weekly release names
Our release names follow the simple pattern of
<YYYY>-<CW>(-I) YYYY Year CW Calendar Week Padded I Numeric counter if fixes provided
Examples are
2023-01 // padded 2023-12 2023-34 2023-34-1 // patch 1 2023-34-2 // patch 2 - shame on us to need two fixes
Author |
|---|