Wondering how to create a separate environment for development? Looking for different configurations and use cases? Salesforce Sandboxes might be the answer… You might be wondering, this post is in wrong timing or you might be leaning towards Salesforce DX. Of course, it is an amazing product. 🙂
Sandboxes never cross their path with Salesforce DX nor DX is a replacement for sandboxes. Below is an explanation from the product managers of Salesforce DX:
It’s worth noting that scratch orgs aren’t a replacement for sandboxes. Sandboxes are an important part of the larger development lifecycle, and work with our new source-driven development process as the destination for packages built directly from source. All sandbox types, from developer to full, offer the ability to act as user acceptance testing (UAT) and staging environments of the production org.
So for now let’s get into how sandboxes are useful for the team in Developing and testing (But don’t worry, I will be posting a separate article for all Dx enthusiasts out there). Salesforce Sandboxes are definitely a boon for the team to make copies of the production environments. These come in pretty handy if you’re into developing and testing, and are perfect for building effectively in the Salesforce.
But wait! Do they come in different types to help you solve different problems? You guessed right as there are four different types of Sandbox. These are:
- Developer Sandbox
- Developer Pro Sandbox
- Partial Copy
- Full Sandbox
All of these Sandboxes fulfill some primary use cases and you can use them for different purposes. So, you might be thinking that which one is the most effective Sandbox design? Let us find out.
But first, let’s understand about software development cycle for Salesforce
The cycle that is usually followed for software development for Salesforce starts with the generation of ideas. A company would then put these ideas in the backlog, from where they can prioritize.
The next step is the development process. First there is the developing and testing, followed by QA, and finally, there is the User Acceptance testing (UAT). Once everything is approved, you move into the production phase.
The Salesforce Sandboxes Desing Environmental Management primarily focuses on the developmental process.
Still confused as to why it’s important to have a good Sandbox design? It is essential to have a good Sandbox design for a number of reasons. It is a good practice to create separate environments for your development, your testing, and your training. Having a good Sandbox design is also a great way to develop a regular release status.
But there are other reasons tooOther reasons for having a good Sandbox design matters include:
- It provides more stability for your different activities. So the different teams can work simultaneously, without halting any of the processes.
- It helps shorten the cycle times for trials and testing, even though an organization may have to manage a greater number of environments.
- Helps you create realistic training and testing environments, helping you reduce operational risks, raise your productivity, and efficiency, and ultimately enhance your user satisfaction and increased business volumes.
So, how many types Salesforce Sandboxes, are there, to be honest?
There are four different types of Sandboxes offered by Salesforce, with their distinctive use cases and configurations. These include:
Developer Sandbox: This is the special configuration sandbox meant for coding and testing by one single developer at a time. So you can develop in isolation, and are widely considered to be the most agile environment to work in. This Sandbox design has a refresh interval of one day. It is a configuration-only but doesn’t include any sample data. It has a data limit of 200 MB.
Developer Pro Sandbox: The primary difference between the Developer Sandbox and the Developer Pro Sandbox is the data limit. With the Developer Pro Sandbox, you can store data up to 1 GB. The other major difference is that the Dev Pro Sandbox design also helps you grab some amount of product data. Just like the Developer Sandbox environment, it can be refreshed every single day. It also includes setup configuration.
Partial Copy Sandbox: This is possibly the most ideal Sandbox design available to users. It is a great blend of the basic Dev and Dev Pro Sandbox designs and the Full Sandbox. It comes with a full set of your customizations. It also comes with a very easy way of getting some sample data. The data limit for this environment is 5 GB.
Full Sandbox: This is considered to be the least agile environment. Developing in the Full Sandbox environment can become quite a challenge, as it can be refreshed only once a month (29 days). But on the plus side, it is a full copy of your production environment. This is the ideal environment for conducting all the expanded testing. It also allows the users to pick specific data and objects, and copy them to their Sandbox.
Cool, isn’t it?
Now, don’t you want to know some of the use cases for each of the Sandbox designs?
The Developer and Dev Pro designs are ideal for building and coding in isolation. They may also be used for some limited amount of QA purposes. More complex types of testings, the Partial Copy is more suitable. It is suitable for batch data testing, training environment, and integration testing. In case of more complex performance testing, UAT, and staging, the Full Copy is more suitable.
Why can’t I use a Full-Copy for the whole lifecycle??? Is everything hunky-dory, then? To be very honest, that would be the worst idea ever, and there will be a lot of issues in using the Full Sandbox environment to do all of the work, including the development, QA, UAT, training, staging, and production support. Here are some issues that one may encounter:
- It can slow down the overall development, testing, and release.
- All the different processes become fully reliant on one particular sandbox, halting a process in order for another one to start.
- Running multiple releases is definitely not a possibility in the Full Sandbox design.
- Its really difficult to run a refresh, as its going to halt all the different works.
Now, what are the Best Sandbox Practices you can adopt?
The first step to developing a good Sandbox practice is to plan. You need to think about your release process and determine which are the environments that you need. Here are some questions that will help you map out your requirements better:
- Where are you going to develop the new features?
- Where are these new features going to be tested?
- Where are your UAT going to be completed?
- Where are you going to do your training?
Once you have determined the answers to these questions, you will be able to develop a solid “Refresh and Release” calendar. This step is very important, as it will help you map out your timeline better. Determine the Sandbox design and make it work now….
Depending on your “Refresh and Release” calendar, you can chalk out whether you want to go for the Dev and Dev Pro one day refresh cycle, or a 5-day refresh cycle with the Partial copy, or a 29-day cycle with the Full Copy Salesforce Sandbox design.
The cool would be to plan out a comprehensive Test Data Management Strategy. The downside is that in the Dev and Dev Pro designs, there is very limited data space available. If you’re planning to use either of these, it is a good idea to explore the internal and third-party data tools to help you combat this.
Build time for deploying configuration between the different environments that you are going to use. You should also make sure to document all the sandbox refresh procedures. This is especially important in case of reuse across multiple people, including developers and admins.
You also need to appoint a release manager to your team. This person will be responsible for the overall decisions and activities within the environments.
What’s an ideal Sandbox architecture? Although there is no common architecture that is suitable for all customers, there is one that is quite popular among the Salesforce clients. You can use this as a guide to help determine the most effective Sandbox design for your organization’s requirements.
If you’re looking at a concurrent development, multiple sandboxes are the ideal way to go. You can have a mix of Developer and Developer Pro environments. Here you can merge all the codes that are being written, constantly, and also keep running the unit tests.
Once your codes are ready, you can move them into a QA environment. The Partial Sandbox design is the best-suited environment for this use case. This helps you use multiple templates at the same time.
Once the QA team has given the go-ahead, you can move into the UAT phase, this is where the Full Copy design is ideal. It is also a great Sandbox for staging. Once this phase is also approved, you can move into the production.
Deployment options for environments
Change Sets: This is a simple and declarative way to move your changes between environments. It uses easy point and click method to add the changes, configurations, and codes to a changeset. Once the changes are moved, they can be easily deployed to any Org within the environment.
Force.com Migration Tool: This is a free tool provided by Salesforce, but is a bit more complex to use. It is a command line utility built on an open source project called Ant. This is great for large development projects for moving metadata packages.
Third Party Tools: There are a lot of third-party deployment tools that Salesforce offers for its Sandbox migrations. These provide features such as automation and continuous integration. Examples include AutoRabit, Eclipse IDE, Copado and many others.
But it gets better…
There have been many enhancements that have made the Salesforce Sandbox experience all the more smooth for users. Take for example the Sandbox post creation refresh scripting, that allows you to fire an Apex class immediately upon creation or refreshing of a Sandbox.
Now that you know the different types of Sandboxes and their use cases and enhancements, what are you waiting for? Go ahead suggest to your customers, bring them inline with Salesforce Best Practices in Sandbox Design. 🙂
