Share This Page

ShareShareShareShare
Author: Bhushan Dongare |09/17/18

Salesforce Sandbox Usage Strategy

Category:

One of the most common questions that almost every customer is asking is “How can I effectively manage my Salesforce Sandbox environments?”. The answer to this will drive efficiency in the project teams that are delivering highest quality of deliverables and ensures that the teams are efficient while working on the Salesforce deliverables.

Let us understand what Salesforce Sandbox is. It is a copy of the production Salesforce environments where one can perform Salesforce customization, development, Quality Assurance (QA) and User Acceptance Testing (UAT) and then code and configure promotion to production environment. Available number and type of sandboxes are dependent on the type of license, number of licenses and the contract agreement that is made with Salesforce. Sandbox attract cost and because of this Sandbox availability and number of sandboxes are limited for pre-production purposes.

Typically, in an Enterprise, there are multiple project teams working in parallel. But, with limited number of sandboxes and the pressure of timeline and delivery, project teams end up in a situation where these sandboxes are unmanageable, leading to inefficient use of Sandbox resources. Regular examples of these situations are Full Copy Sandbox for Development, whereas Partial Copy or Developer Pro is for QA/UAT or Regression Testing.

Since Salesforce Development is configuration-driven, there is very little or no attention given to implement version control strategy around Salesforce Artefact versioning. Naturally, with isolated and small teams on job, it is assumed that there is no need for version control and Sandbox is treated as the source of truth. Next article on Version Control Strategy for Salesforce will focus on implementing version control around Salesforce.

Environment Management and Version control procedure and discipline form the foundation principles of Salesforce development platform. Without these strategies in place, the whole engineering process lacks the hygiene value of development. Below are the issues that will pop up on a regular basis in the absence of hygiene.

  1. Sandbox environments quickly get out of sync. Refreshing takes time and deployments will have errors. QA or UAT Signed off and Production ready versions are not matching in either of the environments.
  2. Managing multiple environments and multiple project work streams also pose hurdles.
  3. Manual deployments are a bottleneck across projects and test phases.
  4. Developers directly update environments, leading to missed deployment steps.
  5. Future releases built on an old production refresh requires additional testing and deployment time.

To resolve these problems, the team needs to spend time fixing the issues which will result in productivity loss. To address these common questions and issues, engineering teams can make use of the following best practices and recommendations. First and foremost, the important step towards implementation is Standardization of Nomenclature across teams, Sandbox naming or Nomenclature brings the clarity in understanding the type and usage quickly and eliminates guess work. Generally, recommendations on naming is as follows:

Sr.

Sandbox Type

Sandbox Usage

Suggested Names

Examples

1

Developer Sandbox

Individual and Development

Usage of Prefix such as Dev

Individuals can decide naming here

2

Developer Pro

Integration Environment

Usage of Prefix such as Dev

Usage of Postfix such as INT

DEV1INT

DEVMAININT

3

Partial Copy

QA Purpose

Usage of Prefix such as QA

Usage of Postfix such as PC

QA1PC

QAMAINPC

QAALTPC

4

Full Copy

UAT, Regression

Usage of Prefix such as UAT

Usage of Postfix such as FC

UAT1FC

UATMAINFC

UATALTFC

While the correct naming provides clarity in identifying the purpose or intent, we should also focus on the usage of Sandbox based on the size or capacity that each of the sandbox offers. Mostly, the strategy recommendations will follow the following outline:

  • Development happens in Developer/Scratch ORG ONLY.
  • Developers are responsible for maintaining Versioning for Salesforce code and configurations.
  • Developers are responsible for Source Controlling (Check-in) on regular intervals and milestones.
  • Developer Pro- Sandbox is for project specific end to end Development Integration Testing.
  • Partial Copy is valid for project specific QA testing or verification.
  • Full Copy is reserved for Regression and Prod Alternate Mirrors (Previous Production Version).
  • Version Control System is always treated as the source of truth.
  • All environments in the code promotion cycle should be maintained with correct version using automated deployment tools.

Dev Ops Tooling offered by Mindtree Consists of Sandbox Usage Strategy, Version Control Strategy, End to End Deployment Automation Tools and Static Code Analysis Tools. You can read more about the end to end deployment automation in the next article.

To conclude, Sandbox strategy and refresh intervals that align with the Sprint calendars will make the engineering process streamline and will bring productivity in the processes. Further, maturity can be brought in by using tools such as Quick Sandbox Setup Tool, Post Refresh Setup Tool and so on. What did you take away from this Sandbox usage strategy for Salesforce?

READ

Let's Talk About Your Needs

Thank you for your submission. We'll be in touch.