Release Process

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



Release Types

Unique features two different release types, modes or models:

Overview

Continuous releases

Unique releases continuously every single change to Platform as a Service.

Regular releases

Uniques current release cycle is bi-weekly. Depending on the customers choice this frequency can be lowered upon request. However, the SLA is only valid if the Client deploys at least once a month as bugfixes are only performed on the latest version of the software.

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

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

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

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

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 https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/623378549.

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

https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/623378549

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

In some versions they also include the pre-release information of the next FinanceGPT release, see below.

An example for Calendar Week 28 2024 would be; 2024.28-cd47.

image-20240110-132759.png
Version example of the Chat

Bi-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 <YYYY>.<CW>(-SHA) YYYY Year CW Calendar Week Padded SHA Build version for continuous releases

Examples are

2023.01 // padded 2023.12 2023.34 2023.34.1 // patch 1

Note on the format

In Docker tags, it is conventional and recommended to use dots (.) rather than dashes (-). Docker tags typically follow a format that resembles a versioning scheme, such as major.minor.patch. For example, 1.0.0 or latest.

Here are a few reasons why dots are preferred over dashes:

  1. Semantic Versioning: Docker tags often follow semantic versioning principles, where a version number consists of major, minor, and patch components separated by dots (.). This format helps in understanding the compatibility and changes in the image.

  2. Consistency: Using dots for versioning tags aligns with the broader software development community's practices, making it easier to understand and integrate with other tools and systems.

  3. Compatibility with Docker Registry: Docker registries and tools are designed with the assumption that tags follow a dot-separated format. While dashes are technically allowed, they might lead to confusion or unexpected behavior in certain scenarios.

While Docker allows a degree of flexibility in naming tags (including using dashes), sticking with dots for versioning tags promotes clarity and consistency, which are crucial in software development and deployment workflows. Therefore, it's generally better to use dots (.) in Docker tags, especially when indicating version numbers.

To create a Docker tag that includes the components YYYY (year), CW (calendar week), and a 6-character Git short SHA, you can use a delimiter to separate these components clearly. Given the nature of Docker tags and to ensure readability and consistency, a suitable format would be:

YYYY.CW-GITSHA

Here's what each component represents:

  • YYYY: Year, represented by four digits (e.g., 2024).

  • CW: Calendar week, typically represented by two digits (e.g., 01 for the first week of the year).

  • GITSHA: Git short SHA, the first 6 characters of the Git commit hash.

Example

If today is July 11, 2024, and the Git short SHA is abcdef, the Docker tag could look like this:

2024.28-abcdef

Explanation of the format

  • Dot (.) between YYYY and CW: The dot separates the year and the calendar week, providing a clear distinction between these temporal components.

  • Dash (-) between CW and GITSHA: The dash separates the calendar week from the Git short SHA, helping to distinguish between the time-based portion and the Git-related portion of the tag.

Advantages of this format

  • Readability: Using dots and dashes makes the tag easy to read and understand, aligning with typical versioning practices.

  • Consistency: This format is consistent with common Docker tag conventions, ensuring compatibility with Docker registries and tools.

  • Clarity: Each component (YYYY, CW, GITSHA) is clearly delineated, making it straightforward to parse and comprehend the tag's meaning.

By following this format (YYYY.CW-GITSHA), you achieve a well-structured Docker tag that incorporates both temporal and source control information in a clear and standardized manner.

Collisions risk

The collision risk depends on the probability of two different commits having the same short SHA within the same calendar week. Let's break down the components:

  1. Calendar Week (CW): There are 52 weeks in a year.

  2. Git Short SHA: The Git SHA-1 hash is a 40-character hexadecimal string, and the probability of collisions is extremely low even for shorter versions of this hash.

Calculating Collision Probability

For 3-character SHA:

  • There are 163=4096163=4096 possible combinations.

  • The chance of collision increases with the number of commits, but for practical purposes, the risk remains relatively low for small to moderate repositories.

For 4-character SHA:

  • There are 164=65536164=65536 possible combinations.

  • This significantly reduces the risk of collisions compared to a 3-character SHA.

Recommendation

Using a 4-character SHA reduces the collision risk significantly compared to a 3-character SHA and is generally sufficient for most practical purposes.

Release Notes

Release notes are always published before a release is being provided on https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/628654186

 


Author

@Dominik Meyer

 

© 2024 Unique AG. All rights reserved. Privacy PolicyTerms of Service