Salesforce developer orgs are underutilized tools for safe testing and experimentation. Each developer should have their own org for CI.
With this article, learn about the benefits of using Salesforce developer orgs, how many orgs are available, why each developer should have their own org, and how admins can also benefit from using dev orgs. Additionally, the article discusses the challenges of using dev orgs and how Blue Canvas can help address those challenges.
Here are our 5 Key Takeaways:
- Salesforce developer orgs are a safe environment for making changes and testing them without affecting production users.
- Most Salesforce plans offer a generous number of dev orgs, but they are still underutilized.
- Each developer and admin should have their own dev org to work in a manner that is more aligned with continuous integration.
- Migrating code between orgs can be challenging, but tools like Blue Canvas can help address this issue.
- The dream for Salesforce dev orgs is to have each developer working on features in their own org, testing them, and then merging the code into a staging or UAT environment before migrating to production.
Salesforce developer orgs are one of the most underutilized tools in the Salesforce developer toolbox. It’s getting better - by now most people know that you should not make changes directly in production - but it’s still surprising to see so many teams cramming 5 or 6 developers on a single sandbox instead of giving them each their own Salesforce developer org to play with. Given the tremendous interest around continuous integration for Salesforce and effective Salesforce sandbox strategy, we might expect to see more use of dev orgs.
Salesforce developer orgs are meant to be a safe environment for you to make changes and test them without affecting your production users. Developer orgs are therefore meant to mirror production as closely as possible. Developer orgs come in several types. Salesforce Developer Edition orgs are a free tool that developers can use if they don’t have access to a sandbox (which is a copy of their Salesforce production instance). Salesforce developer sandboxes are similar to developer edition orgs except they have more storage capacity and are refreshed from a production orgs. Salesforce developer sandboxes come in two varieties: Pro and Standard. Standard Developer sandboxes are limited to 200MB of files and 200MB of data storage. Salesforce Developer Pro sandboxes include 1GB of files and 1GB of data storage.
Unlike Partial Copy and Full Copy Salesforce sandboxes they can be refreshed once a day. This is useful for achieving the aim of keeping your dev orgs looking as much like production as possible.
Developer orgs (sandboxes and Dev Edition) are useful because they allow you to make changes in a safe environment. You wouldn’t want to be updating key pieces of functionality directly for your business without testing it extensively first. Dev orgs allow you to do just that.
They also provide an opportunity to experiment. Developers are born inventors and they often do their best work when allowed to let their imaginations run freely. This can happen in a Salesforce dev org in a way that it cannot in production.
It’s startling that so few organizations are using their Salesforce developer orgs because of how generous most Salesforce plans are with them. Salesforce Professional edition offers 10 Salesforce dev orgs out of the box. Enterprise gives you 25 and Unlimited Edition grants a full 100. So they are not scarce resources for most organizations.
Given the plethora of orgs that most companies have available to them, it is reasonable that every developer on your team should have their own Salesforce dev org.
If each developer has their own org, they are able to work in a manner that is more aligned with continuous integration. One of the key benefits of CI is minimizing merge conflicts. By making frequent, small changes instead of infrequent large changes you can ensure that your code is deployable and you aren’t making large breaking changes that are difficult to understand, test and rollback.
Providing each developer their own org also helps a lot with code clobbering. If two (or six as we often see) different developers are working on the same class in the same org it’s almost certain that they will overwrite each other’s work. Source control can help with this, but it’s still dangerous to have people making changes on the same org because not even source control can always solve that.
This applies to Salesforce admins as well. Declarative changes are just as important as changes to code and should be treated as equal citizens. This is the great thing about the Salesforce platform. If admins each get their own org it will help them avoid conflicts. At the very least, admins should be allowed to use their own orgs for making changes outside of production.
In a perfect world, every developer (and admin) has their own development environment - just like they would in any other software ecosystem.
Each day they can work on features in their own org, testing them as they please. Once a developer is happy with their changes they can check them into source control (or let Blue Canvas handle that for them).
Next, they can merge the code from their Salesforce developer org into a staging or UAT environment such as a Partial or Full Copy sandbox. Here the team can test the feature and ensure that it integrates nicely with other features, data and metadata.
Once that is done, the metadata is migrated from UAT to production.
Finally, all your production changes should be synced downstream to your UAT and Salesforce developer orgs to ensure that the dev orgs are as close to production as possible.
Achieving this workflow in Salesforce today is quite difficult and it requires expensive maintenance and setup.
After talking to hundreds of Salesforce development teams, we think we’ve uncovered the main reason that more people don’t make use of Salesforce developer orgs. It’s not that they don’t have contractual access to more. And it’s not that they don’t agree with the conceptual framework we laid out above. It’s simply that migrating code between orgs is extremely painful. Most teams are no longer making changes directly in production, instead making changes in a sandbox. But the difficulty of getting code and configuration changes from their sandbox into production makes them chary to triple down on the problem by doing work in a large number of different orgs.
This challenge gets worse because you don’t simply need to deploy unidirectionally from your Salesforce dev org to production. To make effective use of this strategy, you will also want to deploy from production back downstream to your sandboxes. The thought of having to manage all this intimidates teams into a suboptimally simple sandbox strategy.
We understand the pain and we built Blue Canvas to address this issue directly. With Blue Canvas you can easily merge code safely between orgs continuously. This makes it possible to use Salesforce developer orgs more effectively and achieve the dream of continuous integration.
