After passing the engineering quality assurance (QA) process, changes are released to the internal UAT environments for business-led testing. After passing this Cirrus-UAT, customer release planning begins. This entails:

• Communication and impact assessment—Addition testing may be required in cases of complex configurations that entail multiple integrations with customer systems. 
• Deployment to Sandboxes/Pre-Prod instance. These instances do not contain any data from product instances. 
• Training, either through online learning or face-to-face with our in-house education specialists.
• Production deployment. 

Issues are raised with and prioritised by the Cirrus Support Desk. 

After investigation, if an issue is believed to result from code failure, a defect is raised with our engineering team for investigation. After an investigation of the route cause, an engineer is allocated to fix it. 

Once fixed (which includes passing QA), defects are fast-tracked through the continuous deployment (CD) pipeline and are patched onto the affected product. 

The Cirrus support desk will ensure efficient communication with all affected customers and partners. 

Our engineering and QA teams use many environments, which simulate specific and common configurations. Once code is deemed ready for deployment, the release process undergoes further deployments depending on the functionality that is due to be deployed and the expected impact on customers. There are: 

Alpha refers to the release of new functionality to select customers to gather feedback. Alpha releases don't always progress to Beta and have no warranties. 

Beta Refers to the initial release of a Major (sometimes Minor) version. This allows customers to 'test' the impacts of the functionality before a production/live release. 

Production Refers to the live customer instance or environment. 

We split our release notes into the following sections so that customers can quickly navigate to the areas that will have the most impact:

New Functionality

As the name suggests, this is new functionality that will require some form of training or change management depending on the type of functionality. For example, new integrations would be technical in nature and be supported by sufficient document to negate the need for face-to-face training. 

However, functionality that is not new, but contains a substantial change to the user experience and the interface will be treated as new functionality with a more focused communication and training plan. 

Enhancements

These are changes to existing functionality to enhance the features that are already being used. For example, this may be a quicker way of doing something or the iterative deployment of a messaging channel. 

Fixes

We don't communicate all code changes. We deploy changes to the codebase every day to ensure the products' operational resilience or to improve the codebase itself. These changes do not impact customer use. However, large fixes that may impact two or more customers are communicated via our support desk. They may not be included in the release notes. 

We have recently opted to focus on monthly releases with the content in the release notes describing the level of product change. This allows customers to assess the level of product change for their business. 

However, internally, we version control all of our products with the following two segments:

Releases - change to the product that progresses the code versioning. 

Patches - changes to an existing version of code. Usually fixes. 

We aim to release twice per year for major product changes and monthly for ongoing changes, with patches deployed as and when required.