Salesforce provides several different types of environments, but how do you know which is right for your specific use case?
In this article, we’ll discuss the various use cases in the Salesforce release pipeline, while explaining which Salesforce environment is the best choice for each scenario.
What’s the Right Org for My Use Case?
If you don’t have enough time right now to read the whole article, here’s a quick visual overview of the right Salesforce Sandbox to use for every use case:
Note that you don’t have to purchase six Full Copies to give everyone on the team their own Sandbox. As a rule of thumb, start with the highest-level org listed for that use case. If you don’t have that specific type of org available, move one level down. On this chart, that means one level to the left.
For example, for UAT, a Full Copy Sandbox is the best choice. If you don’t have a Full Copy available, your next best choice is a Partial Copy Sandbox.
Additionally, it’s ideal to use separate orgs for separate use cases – but not entirely necessary. You can combine performance testing and staging, for example.
The one exception to this is the build stage, where everyone should work in a dedicated Salesforce environment. Weigh the cost of procuring and maintaining environments when defining the best release path for your company.
Stages of the Release Pipeline With Their Appropriate Orgs
Let’s start by examining the various stages in the Salesforce release pipeline from the beginning of the development process. We’ll match them to the right Salesforce environment and explain why it’s the best fit.
Build
The build stage is when you develop your new features. If you follow DevOps best practices, you know that it’s advisable to give everyone on the development team their own Salesforce environment. This gives them the freedom to work on their own parts of the project without stepping on each other’s toes.
Scratch orgs are the future of agile development. A scratch org is a disposable, fully-configurable, source-driven org. Because you can configure it with the metadata and data you want, you can imitate different features and preferences in various Salesforce editions.
Use a scratch org for a short project of a few days or a week – and then move on. Salesforce DX lets you define the shape of the scratch org and promote changes up the release chain. For a simpler, faster solution, use Prodly’s Sandbox Management tool which allows you to spin up a scratch org with one click.
If you’re not ready for scratch orgs, Developer Pro Sandboxes are the best orgs to start development. They come with metadata from production while being the most affordable orgs. You can easily try out new ideas and solve problems here.
However, you still need to populate Developer Sandboxes with data, which involves manually creating records, manually seeding the Sandboxes, or using an automated Sandbox management tool like Prodly AppOps.
You can use Developer edition orgs for proof of concept work or experimental projects. However, these orgs aren’t connected to your production org and won’t contain any of your Production org customizations. Some automated Sandbox management tools let you connect any org to any other, which removes that hurdle.
Quality Assurance
QA is ongoing.
First, check your work in your Developer sandbox or scratch org. Again, you’ll need to ensure it has the metadata and data you care about to make it look like a mini version of production.
QA continues into integration testing as you bundle your work with that of your other team members and in every release stage – and org – as you move work towards production.
Integration Testing
In the integration testing stage, you test how the newly developed features or components of a new application function as a combined entity.
Your Full Copy Sandbox is the first choice for integration testing because it’s the closest possible reproduction of your production environment. It contains all the same metadata and data as your production org. Any testing you carry out here is like testing in production – but without the risk of disrupting your business.
A Partial Copy Sandbox is the next best choice for integration testing since it more closely recreates the user experience in production. It’s not ideal, because you only have up to 5GB of storage. That means you have to carefully pick and choose which records you copy from production to recreate the user experience.
A Developer Pro Sandbox is also a possibility. However, it has much lower storage limits – only 1GB – and you need to provide records from production to accurately test a new feature. That means you must be very selective about the data you want to test with. Depending on how many records you need, you can use Data Loader or an automated data migration tool.
Batch Data Testing
Batch data testing involves testing a high volume of transactional data over a specific period of time.
To get the highest ROI out of this stage, use a Full Copy Sandbox. You want to determine how your new application functions in the real world. That’s why you should refresh your Full Copy as frequently as possible – preferably once every 29 days.
Don’t fall into the trap of delaying refreshing your Full Copy Sandbox because you’re in the middle of a project. The longer you wait to refresh it, the less like your production environment it will be – and the less reliable your test results.
You can also use a Partial Copy Sandbox for batch data testing. However, be aware that due to the limitations of a Partial Copy, you might not see the whole picture of the user experience. Again, a Sandbox management tool can help define the specific data you want to include for testing.
User Acceptance Testing
During UAT or the Beta phase, you release the new application to a limited number of real-world users so they can test how it impacts user behaviors.
You can use a Full Copy Sandbox for UAT because it’s a snapshot of your production environment. That means all the functionalities you’ve built into this new application should ideally work in a Full Copy.
Nevertheless, you can also use a Partial Copy Sandbox. It should be an adequate testing environment, since it provides 5GB of storage and lets you select as many as 10,000 records per object.
Performance Testing
Performance testing involves assessing how an application performs in terms of stability, speed, and responsiveness under a specific workload.
Because this stage is critical to determining whether an application can handle all the pressures of production, perform it in a recently refreshed Full Copy Sandbox. Workloads in a Full Copy more closely resemble those in production, and you can identify any issues regarding stability and speed in a real-world Salesforce environment.
Staging
Staging is the critical last step before going live with a new application. Here, you deploy the new functionality for final review before you deploy it to production.
Your Full Copy Sandbox is the best place for staging because it allows you to test all the configurations and verify that all the features are working as desired. If not, you still have the opportunity to make changes before you deploy the application to production.
Training
When you roll out a new functionality, you might need to train your users on how it works before making the change in production.
A Full Copy Sandbox is the best Salesforce environment for this use case. If you’ve refreshed it regularly, it’s a close reproduction of your production environment. It will also look more familiar to your users, which makes training easier and helps achieve optimal results.
You can also use a Partial Copy. It’s easy to set one up with a template to get the metadata and data you need – without having to use a Full Copy.
Final Thoughts
Now you know which type of org to use for every stage in the Salesforce release process to help you leverage automation and maximize your lower-level orgs. However, we’ve also discussed that it takes a significant amount of work to get Developer Pro, Developer, and scratch orgs ready for development.
You can solve this problem by using a “clicks, not code” tool like Prodly Sandbox Management. With Prodly, you can seed data to up to five Salesforce environments automatically and even migrate in-flight metadata to keep all of your sandboxes in sync. Plus, you can quickly spin up a new scratch org (with all the right data and metadata) with the click of a button.
For more information about Sandbox management, please contact us at www.prodly.co.