Shared Salesforce Sandbox Issues

Sharing a Salesforce org for development can be a challenge. I’ve heard about some teams successfully using version control and continuous integration in their Salesforce development, but their process may not work for every team for a variety of reasons. I’d like to point out a few issues in particular when sharing development sandboxes with other developers.

Best practice dictates that development should occur in a development environment, then migrating to the production environment after thorough testing. This works quite well for traditional OS-level development as each developer has their own workstation on which they can replicate the entire application. Each developer, then, makes changes on their local copy of the application and pushes it to a team copy of the application only when their own portion of the project is complete.

Beyond the first one, extra Salesforce sandboxes must be purchased at a relatively high cost, which encourages, or even forces, development teams to share a single environment. While this may work for smaller projects, problems can start to appear as a project grows.

The first issue that a developer can experience is sharing incomplete code. While a developer can write code on their local machine, it is impossible to tell if their code will compile until it is saved to the shared environment. Even if the code does compile, it may still be incorrect, causing team members to experience shifting function outputs as development continues. This can be alleviated by having team members work on unrelated parts of the system, but there are still times when shared logic must be changed.

Another issue is that of clobbering a team member’s code. Suppose you need to make a change in a file you haven’t touched in awhile. While you can make the change and upload it, it is very possible that someone else modified the file the previous week and has it working fine. Without knowing any better, you would be overwriting the newer version of the file with an older version, destroying a team member’s hard work. If your team is using the Force.com plugin for the Eclipse IDE, this tool will notify you if you are about to upload an older version of the file. However, the possibility of overwriting still exists if you use any other tool for Salesforce development.

These are just two of the more immediate issues when developing in a shared sandbox. While they can be alleviated, the rough edges that are exposed by the practice will add to the development time of a project as well as add to the risk of introducing bugs and should be avoided.

Posted in: Programming, Salesforce