Configuration Management with Sandboxed Solutions

In our current project, we’re just about to introduce our first sandboxed solution into our SharePoint farms. This raises some interesting questions regarding how this fits into our existing configuration management process.

Until recently, we only had full trust solutions in our farms. Do deploy these, we go through a pretty straightforward change management process: The build server builds the solution packages, labels the code and assigns the version number to the WSP name. Developers can then deploy the packages to the integration environments, to which they have full access as administrators. When the packages are ready for testing, developers sends a request to Configuration Management (CM) to deploy certain packages to the test environment. CM then contacts operations, who perform the deployment. When user acceptance testing is completed, the packages are deployed to production.

This process works very well for full trust solutions. But how do things change when we start introducing sandboxed solutions? It’s not obvious at first how these fit into the established configuration management process.

If the user code service is enabled, sandboxed solutions can be deployed to any site collection without involvement of the farm administrator. It’s considered safe to do so because the code runs in an isolated process, and because the resource usage is monitored and limited. Does this mean that should be free for all site collection administrators to install whatever solutions they want on their sites?

The answer is, of course, no. The sandbox is just an execution model that affects the maintainability and the level of isolation the code runs in. However, from a configuration management point of view, sandboxed solutions are no different than full trust solutions.

Sure, the sandboxed solution can’t compromise the overall stability and performance of the farm, but it can still mess up the site collection it runs in. If the code you write provides features that are business critical for the end users (or might become in the future), it doesn’t matter if you run it in a sandbox or not. If you want predictable results, you still need to test your solution in a production-like test environment. And of course, you still need to keep track of exactly which version is deployed to each environment.

So, we decided to apply the same CM process to all solutions – sandboxed or not. The only difference is that operations doesn’t need to perform the deployment, site collection admins can do that themselves after getting approval from CM. And of course, all packages must go to the test environment first to ensure everything works as expected before deploying to the production environment.