Skip to main content

Release process

Targeted Release


Targeted release allows admins, change managers, or anyone else responsible for nBold updates to prepare for the upcoming changes by letting them:

  • Test and validate new updates before they are released to all the users in the organization.
  • Prepare user notification and documentation before updates are released.
  • Prepare internal help-desk for upcoming changes.
  • Go through compliance and security reviews.
  • Use feature controls, where applicable, to control the release of updates to end users.


Access to targeted release is controlled by an RBAC policy. To grant a user access to targeted release features:

  1. Open the Settings tab
  2. Open the Roles (RBAC) section
  3. Assign the Change Manager role to the user
  4. Click Save

Validation Rings

Our release process is comprised of multiple "rings" of validation that are related to specific environments, to a specific audience and a specific compliance labeling level:

RingEnvironmentsPrimary AudiencePurpose
4productionCustomers (All)Obvious isn't it? ;-)
3.5stagingDevOps TeamTest automated deployments and upgrades in an iso-production environment
3betaCustomers (Preview)Preview environment designed to help some customers prepare for updates, from a technical and change management standpoint
2uatProduct TeamThe product team tests the app to verify whether it meets their expectations
1.5alphaPartners (SI/ISV)Give strategic partners an early look at the features we're currently working on
1dogfoodInternalInternal Dogfooding
0integrationDevOps TeamIntegrations and functional testing by the tech team

Using this kind of rings has many advantages:

  • Clear and common understanding of each ring purpose
  • Separation of concerns
  • Real isolation between environments
  • Enforced security

Versioning Strategy

Our versioning strategy adheres to Semantic Versioning.
A version number may be comprised of 3 to 4 components and takes this form:


Meaning of each component:

  • MAJOR: version that includes incompatible changes (data schema, api signatures...)
  • MINOR: version that includes functionality in a backwards-compatible manner
  • PATCH: version that includes backwards-compatible bug fixes
  • BUILD: incremental development-only version