This blog post provides guidance and rationales for when and why PowerShell - and not compiled Feature and Solution Packages (WSPs) - may be the most suitable technology platform for deployment and Application Lifecycle Management (ALM) for customized SharePoint 2010 implementations.
This post targets two audiences; internal corporate development staff and SharePoint Portal and Collaboration Microsoft Partners, both tasked with creating a road map for sustainable and extensible SharePoint 2010 customized implementations.
All Paths Lead To Rome, or Visual Studio 2010 Solution Packages
If I had to distill the dominant message from the corpus of technical articles, books and blogs published by Microsoft and the community regarding Best Practices for SharePoint 2010 customization, branding and development, it would be this:
"Package and Deploy Every Customization with Features and Solution Packages using Visual Studio 2010."
This message has been reinforced with the updates to SharePoint Designer 2010, which has been elevated from bastard child in the 2007 development process and neatly folded into the development lifecycle story for 2010, as clearly reenfoced with images such as this excellent graphic from http://msdn.microsoft.com/en-us/library/gg604045.aspx
Two Paths Diverged in a Wood: Custom Content vs. Custom Artifacts
And the newly published information regarding ALM with SharePoint 2010 has vastly improved the community's ability to differentiate between strategies for deploying and upgrading customized content created by end users, vs. customized artifacts created by designers and developers to support customizations, particularly where it concerns customized artifacts deployed within the content database, such as the blurb under Understanding Differences Between Solution and Authored Artifact Development in the dated, but still relevant article: http://msdn.microsoft.com/en-us/library/dd179854(office.12).aspx (Solution and Authored Artifact Development Models for SharePoint Products and Technologies). Similar content such as the Developing Applications for SharePoint 2010, published by the Patterns and Practice group, go even farther in helping us understand which path to take in the SharePoint 2010 development woods.
Together with the new ability to version customize artifacts in upgrade scenarios, and other improvement the development story for SharePoint 2010 shows which fork in the wood we should take, where we are pointed to the path less travelled, which invariably leads to Rome.
This post does not question the wisdom and value of extracting all customizations and using WSP's to deploy, maintain and extend those customizations. The wisdom and rationales stand on their own merit.
However, I wanted to share an observation I have found in my own practice as a veteran SharePoint architect and developer regarding the degree and timing of leveraging Best Practice guidance for developing, deploying and maintaining customizations in SharePoint 2010 with compiled packages. And bring to light the powerful value I have found in tailoring the degree of Best Practices methodologies with PowerShell to better match the Best Practices for the situation.
Goldilocks and Best Practices:
Like many other practitioners of the Art of SharePoint, I have yet to see a SharePoint project fully embrace the entire set of recommended Best Practices for SharePoint app dev. It is too hot a porridge for the tougues of many.
I have also seen many SharePoint projects require extensive customizations, but with an aversion to all things Best Practices. The result is too cold; not enough flavor makes its way to the end user's tongues, and adoption freezes or dies.
Instead, I have found that PowerShell has been the most flexible ingredient for preparing a "Just Right" porridge of Best Practice deployment and ALM methodologies to tailor deliverables which can be savored, stomached and digested.
Full-Bore Best Practices: The Hidden Costs of Complexity and Risk, Trends in Deployment
I have witnessed 2 trends in SharePoint deployment methodology that bear witness to the value and benefit of keeping to the core principals of Best Practice Deployment Methodology, but only to the degree that can be stomached and no more.
The first trend occurred around 2007 with the improved Feature Stapling and Activation functionality, which was championed by many as The Way To Provision, moving away from the cryptic alchemy of declarative Site Definitions for provisioning site artifacts to leveraging Feature Stapling and Feature Activation events to provision almost wholly through code. At the time, Site Definitions were the Documented Way to Do Things, but real life proved that Site Definitions were too hot a porridge. Over time, moving declarative deployment customizations into code was the hot workable trend.
For site definitions, the trend has been absorbed by Microsoft, where published literature describes the possibilities for declarative Site Definition provisioning, but now encourages the use of Feature Stapling. This trend in recommended best practices for site provisioning continues today in the 2010 world, where Feature Stapling remains one critical path for working with Publishing Sites.
Trend 1: Discovery that published Best Practices may have their alternatives, which may prove to be superior, simplification of provisioning with compiled "scripted" methods over declarative methods.
The second trend I have observed was triggered by reading Paul Culmsee's (of CleverWorkarounds fame) most exquisite posting, SharePoint Fatigue Syndrome. Paul's post got me Googling for similar posts from other SharePoint architects regarding the struggles of adoption of Best Practices with deployment methodologies, most notably the tension between complexity of features demanded up front, the frail comitment to adopt Best Practices in deployment, and the inevitable crumbling of that commitment when they learn exactly how big a bowl of scalding Best Practices can be as the project progresses. My own experience has reflected a general trend where the use of Visual Studio 2010 for deployment is to be feared, shunned and avoided at all costs, even if there are expressed contradictory desires to follow Best Practices, or demands features that require them.
Let's face it. A Visual Studio 2010-based compiled Best Practice deployment methodology is like doing the desired implementation at twice the cost and time. Roughly speaking, for every set of customization, there must be an equivalent deployment package. Deployment packages as compiled solutions require testing as much as the customization itself. That alone doubles the work effort for any customization. Many still harbor the illusion that SharePoint is a product, like MS Word. You pay for it, install it and it just works, right? Faced with the news that the cost and time to deliver their grand vision is twice what they expected because one must also roll the equivalent of a robust installer package for their customized vision, and I find myself suddenly in the realm of negotiating how much blood can be squeezed from the stone as corners are cut.
Suddenly the initially accepted and project plan, beautiful architecture and design begin to morph like so much film under a hot lamp.
Trend 2: SharePoint practitioners are becoming more wary of swallowing even a moderate does of compiled Best Practices methodology using Visual Studio 2010 as they realize the hidden costs and complexity of following published Best Practices guidance for development, deployment and ALM.
The End Result: Role and Rationale of PowerShell for Realistic Best Practice Deployment Methodology
In a nutshell, I have learned that the published Best Practice Customization and Deployment Methodologies for SharePoint 2010 tend to be way too much for many (but not all) to absorb and accept. There is either delayed shock at finally realizing the complexity, cost and commitment associated with published ALM guidance as the project progresses, or a lack of sufficient resources or expertise internally to do anything with a robustly deployed set of compiled deployment artifacts, or a simple unwillingness to pay for the cost.
In these instances, I have found the best way to balance the requested customizations and still provide a solid measure of Best Practice Deployment methodology is to use PowerShell in the place of code normally created in feature activation and other events in compiled solution packages. Between leveraging the sandbox where possible (and with great care), I have found using PowerShell to be an essential and flexible tool for tailoring and providing as much Best Practice Deployment Methodology as can be stomached.
Specifically, I have found that just as declarative Site Definitions were moved into compiled "scripted" chunks of code in the feature stapling and activation events, there can actually be tremendous benefit in migrating those compiled chunks of code out of compiled solution packages and into PowerShell.
Below is a list of possible benefits and rationales I have discovered for implementing deployment code typically added as code in Visual Studio 2010 solution packages as script in PowerShell, permitting a greater degree of compliance with published Best Practices than simply avoiding any deployment methodology whatsoever:
• PowerShell combines scripting with full access to the SharePoint SDK. Virtually anything you can do with the SDK, you can do in PowerShell.
• Changes to deployment scripts, feature activation, provisioning of artifacts can be made without compiling
• Order and sequencing of feature activation and upgrading can be controlled and easily altered
• Issues with Feature Stapling, such as asynchronous provisioning of artifacts defined in the site definition, can be avoided
• A set of lightweight "code-free" wsp's can be implemented, "glued" together with PowerShell Scripts for deployment and upgrades
• Upgrade/update scenarios, where new versions of features need to be deployed without modifying production data can easily be more easily accommodated
• Flexibile, customizable logging opportunities for the staff running the script
• PowerShell Scripts can be a viable deliverable and learning tools for those with inexperienced staff who are still ramping up on SharePoint app dev. Leave behind code samples and snippets
• Uncompiled nature of PowerShell scripts can lead to greater speed in ramping up internal IT and developer resources as they can open the scripts and see what is being done, and leverage and reuse snippets
• For evolving IT SharePoint administrators, it can empower non-developers by exposing elements of the SDK to admins, to provide them greater flexibility in what they can do for their internal clients.
• If one previously unprepared for a robust, compiled deployment methodology has the good fortune to find resources to begin to adopt a more rigorous approach to deployment, converting existing PowerShell deployment code to C# or other languages is a very viable path.
The list could go on, but you get the idea.
Summary:
If you are lucky enough to participate in a SharePoint implementation where it is fully possible to implement the full nine yards of the published SharePoint Development and Deployment Methodologies using Visual Studio 2010, walk that path with pride.
If, however, you happen to find yourself in a situation where there is a lack of interest, commitment, ability or time to pursue a heavily compiled deployment and ALM approach, PowerShell may be just the ticket for flexibly tailoring the degree and timing of the deployment methodology with your projects.
Finally, I have come to learn that just because a Best Practice exists, does not always mean that shoe will fit, and that sometimes the less technically desirable and elegant solution is in fact, the best solution.