Sandboxes, change sets, and Packages are all necessary items to know when it comes to the application Lifecycle and Software Development Lifecycle in Salesforce.
All these things are necessary to know for the SDLC or software development life cycle. Although the Application Lifecycle and Software Development Lifecycle may sound daunting, these words essentially mean the same and are used interchangeably in this post.
When starting out in your salesforce career, understanding these and when/where to use them can be challenging.
Below you will see that I have broken each item down to what they are used for and the limitations they face. Let’s jump into it!
Full Sandbox
Before we jump into sandboxes let’s explain something first. Sandboxes are a copy or a partial copy of a production org and should be related to a production or to move changes.
It’s not possible to move changes from an unrelated sandbox to an unrelated production through change sets. This can only be done through an unmanaged package.
Now that the disclaimer is out of the way let’s talk about the full copy sandbox. This sandbox has all the data! All metadata and other data. It simply is a full copy of the production environment.
Every single object, field, flow, account, lead, and note is in this sandbox. Most of the time this sandbox is used to do a test deployment from your UAT environment.
Here are the quick stats. This sandbox is only available for performance and unlimited editions of salesforce. The refresh interval is 29 days. The storage limit is the exact same as production it takes over all metadata and data from production and sandbox templates are available but not required.
Partial Sandbox
The second type of sandbox is the partial sandbox. This sandbox is a partial copy for testing and is only available for performance, unlimited, and enterprise editions.
Additionally, this sandbox environment is used for UAT testing in the application/software lifecycles.
The quick stats. It has a refresh interval of 5 days. Data storage is 5GB and file storage matches the production org.
The partial copy sandbox contains all metadata as well as some sample data and a sandbox template is required.
Dev Pro Sandbox
The next type of sandbox we’re going to cover is the Developer Pro Sandbox. This is only available in performance and unlimited editions and you get 5 of these sandboxes in each!
This sandbox is typically given to developers and configurators to build the new functionality when the developer sandbox does not have the necessary tools.
The quick stats are the refresh interval of 1 day. Data/File storage is 1GB each with metadata only in this sandbox and templates are not available.
Dev Sandbox
The final type of sandbox is the developer sandbox! This one is the main one you use for any type of metadata changes that could be put in a sandbox.
This sandbox is available in professional, performance, unlimited, and enterprise editions. With them all having many of these types of sandboxes and they can kinda be given out like candy!
Alright, the quick stats here. 1 day refresh, with 200 mb of data storage and 200 mb of file storage. Only metadata is copied over and sandbox templates are not available.
Sandbox Template
We can’t talk about sandboxes without talking about sandbox templates. Templates are configured to bring over particular metadata or data from the production sandbox to partial copy or full copy sandboxes.
You can find more info/documentation on it here!
Change Sets
Next, let’s talk about change sets in salesforce!
These are ways to move configurations between related salesforce environments. This does not work when moving items between unrelated salesforce environments.
Change sets allow you to select specific items such as objects and fields to move forward in the deployment stages.
Once you are moving the pieces there is a screen to show any errors that might popup.
SDLCs
One item we have talked a lot about but have yet to define is the software development lifecycle.
This lifecycle is about improving the production org through different stages of planning, developing, testing, user testing, and eventually deploying it to the production environment.
The software development lifecycle is split into a few different parts or sections.
These sections are:
- Plan Build
- Develop
- Test
- Build Release
- Test Release
- Release
Managed Packages
Next, we have made it to the packages portion of the application lifecycle.
Packages are a fantastic resource when you are looking to deploy large projects, code, and any code/configuration combinations from two unrelated orgs.
Additionally, there are two types of packages.
Let’s talk about the first which are managed packages.
These packages are typically used for bringing a completed product into the salesforce environment.
These are usually managed/upgraded through different releases by the package owner over time.
For example, think about DocuSign as a product you are using in your salesforce instance. You have downloaded a package from them off of the app exchange and every few weeks they update their code for features and bug fixes.
Here DocuSign is managing their package.
Unmanaged Packages
Finally, let’s talk about unmanaged packages.
This type of package is not updated by the original package owner and is typically used for a one-time movement of a developed product from one org to another.
The fantastic part about this type of deployment is that the changes can be moved from one org to another regardless of the relationship!
Additionally, this option is great to use when you are looking for a template to build off of in your salesforce environment.
Conclusion
A big congrats to you for making it through this blog post! We hope you found it useful!
Check out the salesforce Emily youtube channel here.
You can read more about us here
And check out our courses here