TABLE OF CONTENTS
# Targeted Release
Targeted release allows admins, change managers, or anyone else responsible for SalesTim 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:
- Open the
- Open the
- Assign the
Change Managerrole to the user
# 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:
|4||production||Customers (All)||Obvious isn't it? 😉|
|3.5||staging||SalesTim||Test automated deployments and upgrades in an iso-production environment|
|3||beta||Customers (Preview)||Preview environment designed to help some customers prepare for updates, from a technical and change management standpoint|
|2||uat||SalesTim (Product Team)||The product team tests SalesTim to verify whether it meets their expectations|
|1.5||alpha||Partners (SI/ISV)||Give strategic partners an early look at the features we're currently working on|
|1||dogfood||SalesTim||SalesTim Internal Dogfooding (opens new window)|
|0||integration||SalesTim (Tech Team)||Integrations 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
SalesTim versioning strategy adheres to Semantic Versioning (opens new window).
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