Navigate Up
Sign In
Supporters of Developer
Web

Sandbox Solutions are Not the Agile Way to Bypass Application Lifecycle Management Process

Item is currently unrated. Press SHIFT+ENTER to rate this item.1 star selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+ESCAPE to leave rating submit mode.2 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.3 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.4 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.5 stars selected. Press SHIFT+ENTER to submit. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.
In my role, 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.
 
Wrapping Up
You must treat sandbox solutions with the same level of process as full-trust solutions.

References

·         Not 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.com
·         Sandbox Solutions are pretty damn good – Sahil Malik (MVP)
Categories: Sandboxed Solutions

Comments

Lou Estrada

Agreed

Sandboxed solutions are not bad.  Misuse of sandboxed solutions is bad.
 
As a developer, I like them because IT and my customers have more options on how to deploy and administer them.  I don't have access to production, so it is not a shortcut for me, and I certainly do not skip the normal SDLC processes.
 
I think this stems from the idea that SharePoint enables quick, easy solutions.  Developers are pressured to move as quickly as users.  That is keeping professional developers out of SharePoint and fostering this bad behavior.  IT has learned many lessons over the decades that are being tossed aside because SharePoint is perceived by business as the magic bullet.  More and more, SharePoint users/customers will begin to learn the same hard lessons, and professional developers will be welcomed with open arms.
 
(For more of my thoughts on professional development in SharePoint, see my SharePoint Developer Orientation blog series... http://bit.ly/NMRSPBlog... Cross-posted on NothingButSharePoint... http://bit.ly/q2hcwd)
 
Lou Estrada

Posted 21-Nov-2011 by Lou Estrada
Andy Burns

Also agreed, and corollary...

... that Agile development doesn't mean that you can ignore requirements/analysis/design either. Just those get reviewed/repeated during each cycle.

Posted 22-Nov-2011 by Andy Burns

Notify me of comments to this article

E-mail:
   

Add Comment

Title:

 
Comment:
Email:

   


Name:

 
Url: