Skip to main content

How we release

Graia CCaaS is updated up to twice a week, whenever changes are ready – some weeks have no release at all. Each release goes through the same checks before and after it reaches your system, and one release note every Monday sums up the previous week's changes.

How a release is made​

Every release – whatever its size – goes through these steps:

  1. Release candidate. Finished features and bug fixes are collected into a release candidate.
  2. Regression testing. We test the release candidate to make sure that existing features still work as before, not only the new changes.
  3. Deployment. The release is rolled out to production, outside peak hours.
  4. Platform check. We confirm that all services are running and healthy after the deployment.
  5. Production smoke testing. We run the key everyday tasks on the live system to confirm they work.
  6. Release finalized. The release is complete, and its changes go into the next weekly release note.

If a check fails, the release doesn't go ahead as planned. Depending on where the problem is found, the release isn't deployed, only the unaffected changes are deployed, or – if it's already deployed – the affected services are rolled back to their previous version.

Release types​

How much we tell you in advance depends on the type of release.

Silent release​

No visible changes to the user interface or to how the system behaves, and no risk to availability – typically urgent bug fixes. Silent releases can happen at any time and are not announced in advance.

Standard release​

Changes to the user interface or to system behaviour that users may notice, with no risk to availability. Standard releases never happen at peak hours. We notify you in advance when a change affects how people already work – see When we notify you.

Major release​

Significant changes, often with many new features and bug fixes. A major release can occasionally cause a short interruption of part of the system, so we perform them in the least busy periods, typically at weekends. We always let you know in advance.

When we notify you​

We let you know in advance about:

  • every major release,
  • any change to something your users already know – for example a button that moves, is renamed or is removed, a step that now works differently, or a changed default. These changes break habits, so we tell you before they happen, and
  • any change to what existing roles can do – for example a role gaining the right to delete data.

How we let you know:

  • Your Customer Success contact gets in touch with you.
  • The change is listed under Changes to how you work on the Upcoming changes page.
  • When the change is scheduled for a release, a notice appears at the top of this documentation site, linking to the details.

New features don't need a notification: something that didn't exist before can't change how anyone works. A new feature may add a button or some information to your users' screens, but everything they did before still works the same way, and nobody has to use the new feature. You'll find new features in the weekly release note.

Stay up to date​

  • Release notes: every Monday, covering the previous week's releases. Use the filter to see only the changes for your role, channel or feature.
  • Upcoming changes: changes we announce ahead of time.
  • Subscribe: get each new release note in Teams, Outlook or a feed reader – see Subscribe to the release notes.