Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Excerpt
namesummary

Description of the Unique FinanceGPT release process and potential instructions for rolling them out in the different Infrastructure.


Table of Contents
minLevel1
maxLevel6
outlinefalse
styledefault
typelist
printabletrue

Release Types

Unique features two different release types, modes or models:

Overview

Gliffy
imageAttachmentIdatt477134901
macroIdfca6b13a-b35f-4925-9cd5-2b3cf7f1f4ff
baseUrlhttps://unique-ch.atlassian.net/wiki
nameRelease 1
diagramAttachmentIdatt476545203
containerId436536500
timestamp1712135691443

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.

Gliffy
imageAttachmentIdatt476676308
macroId4fcbfa56-0fdc-40cd-a545-6e3ef961fb67
baseUrlhttps://unique-ch.atlassian.net/wiki
nameRelease Cycle
diagramAttachmentIdatt476610687
containerId436536500
timestamp1712135781698

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

EXPERIMENTAL*

  • Trying out and innovating new changes

  • Focus on basic functionality and core features

  • Are not designed to but expected to fail

  • Selected individuals or groups specifically opting in for experimental testing

BETA*

  • External testing with real users or clients

  • Collecting feedback on performance and usability

  • Should no longer fail for most cases

  • Interested stakeholders

  • Users/Clients/Tenants specifically opting in for beta testing

GENERAL AVAILABILITY (GA)

  • Final, stable, secure release to the public

  • Product is considered complete and ready for all users/clients/tenants

* 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:

  1. Unique discovers an added value for the client and progresses the change to BETA

  2. Unique identifies issues, problems or inefficiencies and basically terminates the experiment

Panel
panelIconIdatlassian-light_bulb_off
panelIcon:light_bulb_off:
panelIconText:light_bulb_off:
bgColor#F4F5F7

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

Model

Further Use

Format

Consumable

Unique Product

Status
titleall

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)

Status
colourPurple
titleCMT
Status
colourYellow
titleOP

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

Status
colourPurple
titleCMT
Status
colourYellow
titleOP

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

Status
colourPurple
titleCMT
Status
colourYellow
titleOP

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 (helmfile format)

incl. 3rd party OSS services + their config as code

As files forked to own Git

Terraform modules

Status
colourPurple
titleCMT

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

Status
titleall

For further analysis for customers, pinned to the current release

SPDX format

incl. Grype Scan results

As files

Release notes

Status
titleall

A change log for humans

Text

Public docs

Customisation examples

Status
colourPurple
titleCMT

Customise each setup from example cases

YAML

Files forked to own Git, then overridden

Ferryman

Status
colourPurple
titleCMT
Status
colourYellow
titleOP

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 Framework

Release 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.

image-20240110-132759.png

Weekly release names

Our release names follow the simple pattern of

Code Block
<YYYY>-<CW>(-I)
YYYY Year
CW Calendar Week Padded
I Numeric counter if fixes provided

Examples are

Code Block
2023-01 // padded
2023-12
2023-34
2023-34-1 // patch 1
2023-34-2 // patch 2 - shame on us to need two fixes