In the age of digital transformation, most companies strive to drive innovation by developing on the Salesforce platform. They do this by integrating with AppExchange apps and enhancing their environments with custom apps and new features. According to IDC, the Salesforce platform can significantly impact agile application development and rapid iteration. After switching to Salesforce, enterprise companies develop 60% more apps per year and get releases out the door 69% faster.
But when you’re required to develop and test quickly, how can you make sure that any new features or capabilities you add don't corrupt or change your production data and workflows? It all starts with developing, testing, and training in sandboxes, rather than directly in production.
Since smaller sandboxes, such as Developer, Developer Pro, and Partial Copy, have limited capacity, you must populate those environments with a sample subset of data from production. This process is commonly known as data seeding.
Previously, we explained how to streamline partial copy sandbox seeding. In this post, we’ll explore when you should use Developer and Developer Pro sandboxes, and the four seeding tasks you should automate to speed up your Software Development Lifecycle (SDLC).
Developer and Developer Pro Use Cases
Much like you receive your own computer when you start at a new company, you should have your own sandbox when starting a new project or sprint. A personal sandbox will allow you to create and test functionality without interfering with other team members’ code, and will most likely be a Developer or Developer Pro sandbox. Which one may be best for your use case?
Admins and developers use Developer and Developer Pro during the early stages of the SDLC. Dev sandboxes, in particular, are usually used during the Build, Unit Test, and QA SDLC stages. You can use Developer Pro sandboxes for these same stages, but they’re also an excellent Integration and Training environment since they have additional data storage.
If you’re unfamiliar with SLDC, here’s a Trailhead with more information and some brief definitions.
- Build includes both low-code to no-code development and more challenging code written through an integrated development environment.
- Unit Test entails trying out specific components or modules of code to ensure all elements are functioning as intended. You only need a small subset of data for this kind of testing.
- QA involves varying scenarios across several different objects. It requires a subset of data across most or all objects to do proper testing.
- Integration testing requires combining separately developed components to confirm they work well together. More data from more objects are needed for integration testing since there are more inputs and outputs involved.
- Training typically needs a specific data set for educating users that are either new to the system or need to learn a new feature.
Which Seeding Tasks Should You Automate?
With so much pressure on admins and developers to speed up their SDLC, it’s no surprise that some will skip sandbox seeding altogether, especially at the early stages of development and testing. However, this short-sighted strategy can have severe consequences later. You'll end up fixing problems much later in the process when they could’ve been detected by the original developer while working in the code.
Rather than skipping the sandbox seeding process altogether, why not make it more efficient through automation?
Here’s how.
1. Populating Sandboxes
When you refresh a Developer or Developer Pro sandbox, it copies all of the current metadata from production into the new sandbox. You can refresh these sandboxes daily. Unfortunately, unlike other sandboxes, they don’t include any actual data. That means you need to take the time to populate relevant data into your sandbox after each refresh. You’ll also need to ensure that parent/child relationships are maintained so that your environment remains as close to production as possible.
If your SDLC is fast-paced, this may be an excellent task to automate. That way, you won’t encounter issues with cycles outpacing your ability to populate sandboxes with relevant data. Incomplete data sets could allow code to execute correctly in Developer sandboxes, but then encounter bugs in the more complete Partial or Full Copy sandbox.
You may spend hours manipulating multiple .CSV files and pushing countless Data Loader uploads (an application used to bulk import or export of data) to seed your sandbox with the perfect data—only to have new requirements identified partway through the project! You’ll have to re-seed all over again, trying to create the necessary relationships of any new objects.
2. Filtering Attachments and Files
Development and Development Pro sandboxes only allow 200 MB and 1 GB of file storage, respectively, which may not fit all of your attachments and files. Therefore, you’ll need to filter down to a smaller set to stay within the size limitations.
The process of filtering down attachments and files could drastically slow down your SDLC. It requires you to export .CSV files containing the attachments’ and files’ metadata. Then, create a .CSV file with the metadata of each attachment or file (i.e., Name, File Location, etc.) and mass upload.
Files, which are common to Lightning, need to be handled differently within Salesforce. When uploading Salesforce Files, ensure you include "ContentDocumentLink" and "ContentVersion" where appropriate.
3. Anonymizing Data
Since sandbox data is often a subset of production data, it’s likely to contain confidential information that could be accessed by several people, even during building, testing, and training stages. Unauthorized access to personal data by employees, vendors, or contractors is a massive liability that many teams overlook when testing with real data. Sandbox anonymization is a way to make secure data unreadable, replace it with mock data, or convert it to an empty data set.
Unfortunately, manually anonymizing your data could be time-consuming. First, you would have to export the .CSV files that contain all of the data you’re going to anonymize. Then, you would manually anonymize the data within the .CSV files. Finally, you would have to mass update each .CSV file through Data Loader or create your own script to do it for you. Anonymization would have to be redone again after each sandbox refresh.
4. Comparing Configurations
Consistent data allows for faster development by preventing errors from slipping from Developer or Developer Pro sandboxes into the next environment used during the SDLC. It’s best practice to always compare your origin and destination environments both before and after each release.
However, this presents a significant challenge. Without a tool to compare your data and metadata, the only way to uncover differences before and after deployment is to download and compare large data sets of .CSV files in Excel using V-Lookup and XML metadata files using a third-party comparison tool. A process that’s so painful that most teams don’t even bother.
Luckily, there’s an easier way.
Automate Data Seeding with Own Accelerate
“Our seeding time went from 2-4 weeks to just 24 hours with Accelerate.”
-Tarun Bakhru, IT Manager - CRM, AGCO
Own Accelerate is an intuitive and powerful sandbox seeding solution for organizations that want to maximize their Salesforce platform for training, development, or testing. Salesforce administrators and developers can easily seed quality data to any sandbox with desired objects and records while maintaining all relationships and masking all sensitive information.
To learn more about Own Accelerate view our eBook.
.avif)
