Sandbox Solutions are not the ‘Agile’ Way to Bypass Application Lifecycle Management

In my role at AvePoint, I get to speak with a lot of enterprise customers – including many in the Fortune 500 – about all things SharePoint. Based on the conversations, especially as of late, a common theme is emerging: Developers that work with customers externally – or even in-house teams – seem to be pushing for sandbox solutions, which is not what you’d expect. Typically, you’d expect IT Pros and Governance Committees to be pushing sandbox solutions from an isolation perspective on customizations. I found this quite puzzling, as sandbox solutions by design have a limited SharePoint API subset and are scoped to the site collection and below. Subsequently, this puts huge constraints on what can be built compared to full-trust solutions. Why Sandbox Solutions? ISVs and customers were not happy in the customization experience within SharePoint 2007 Online multi-tenant farm, available in BPOS, because it could be only done via SharePoint Designer 2007. There was no concept of full-trust solutions in SharePoint 2007 Online, nor is there one in SharePoint 2010 Online – available in Office 365 – for multi-tenant scenarios (Standard Plans – P and E). Sandboxed solutions were envisaged by Microsoft purely to handle SharePoint 2010 Online’s ability to deploy customizations with managed code and packaged artifacts. Although designed for multi-tenant scenarios, sandbox solutions are also useful on-premise because it isolates the execution of managed code and intelligently monitors resources consumed. If the resources consumed hit particular defined limits, all sandbox solutions within that site collection are switched off. This is often something that people do not realize, and assume that only the offending sandbox solution is switched off within the site collection. This adds significant risk where one site collection may have many sandbox solutions, and the business functionality of the entire site collection will be impacted due to one offending solution. I did some more digging, and found that the reason that developers wanted to use these over full-trust solutions was because it didn’t require remote access to the SharePoint servers to deploy them. How? With site collection root site full-control permission or site collection administrator membership, they can be deployed via the web user interface. Change Management The concern with allowing anyone outside of IT with these elevated permissions to deploying sandboxed solutions is that it breaks the typical process for application lifecycle management. Essentially, it gives developers the ability to quickly deploy updated solutions into an environment. I wouldn’t allow them to do this in production even if I were on my deathbed!!! I heard that they are using the new “agile” methodology of development, and that this was required. I completely disagree with this statement: Sure you can be agile in your development environments, but the same level of rigor is required outside of that regardless of the methodology you use to implement customizations. The application life cycle management process ensures that any changes to an environment are promoted through development environments, to integration environments and test environments where they are quality assured, and then into production. At each stage, there is change management process that occurs to enforce quality and ensure no downtime in production. Significant quality assurance is required when solution packages are updated as existing site collection data, and any artifact changes that occur – such as site columns being added to existing content types – needs to be tested. Preventing Deployment It is actually not possible – if they have full control or site collection administrator – to deny the ability to deploy to the solution gallery, which is in fact a library with permissions just like a document library. The only real way to prevent sandbox solutions is to turn them off completely by disabling the sandbox solution windows service on each of the SharePoint servers in the on-premise farm, obviously not viable in SharePoint 2010 Online. This is an all or nothing approach which is not desired by most organizations. It is not often possible to take away full control or site collection administrator privileges from users either, because there may be other aspects of SharePoint that require they possess that level of permission. Scoping Availability of Features One benefit of sandbox solutions, which some of our customers appreciate, is that when you deploy it into a site collection, the features and artifacts are only available there. With full-trust solutions deployed to a web application, the feature is available in all site collections. This is often not a viable approach, because a solution maybe only required in one location in the farm and should not be available for other site collections to activate. Our customers have also found that utilizing third-party products, such as AvePoint’sDocAve Deployment Manager for SharePoint, can also help with effectively managing and automating release operations to promote successful application lifecycle management in their SharePoint deployments. Wrapping Up You must treat sandbox solutions with the same level of process as full-trust solutions. ReferencesSandboxed solutions: Introducing tiers and resource points – TechnetNot all sandboxes are treated the same – Maurice Prather (MCM, MVP)Sandboxed Solutions – Bill Simser (MVP)Upgrading Sandboxed Solutions – Chris O’Brien (MVP)Sandbox solutions – Good or Bad? – Shai Petel (MVP)SharePoint Sandboxed Solutions – Arpan Shah (Microsoft)SP 2010: Validate Sandboxed Solutions using SPSolutionValidator – Tobias Zimmergren (MVP)SharePoint Sandboxed Solutions Podcast – NothingButSharePoint.comSandbox Solutions are pretty damn good – Sahil Malik (MVP)​