Release Process
Description of the Unique FinanceGPT release process and potential instructions for rolling them out in the different Infrastructure.
- 1.1 Release Types
- 1.2 Overview
- 1.2.1 Continuous releases
- 1.2.2 Regular releases
- 2 Release Lifecycle
- 2.1 About the Lifecycle
- 2.2 Phases and Objectives
- 2.2.1 EXPERIMENTAL
- 2.2.2 BETA
- 2.2.3 General Availability (GA)
- 3 Release Content
- 4 Release Naming
- 5 Release Notes
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 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 |
---|---|---|
|
|
|
|
|
|
|
|
|
* 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
BETA
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: