In this guest blog post, Jeremy Thake, enterprise architect and Microsoft SharePoint MVP at Avepoint looks at exporting artifacts and some of the other real world issues you may face when taking a SharePoint project into a live production environment.
As discussed in the previous article, the original promotion of a v1.0 solution from development to production is relatively easy out of the box by saving the site as a template and restoring it. The problem with this, however, is that when you modify v1.0 in development to make v1.1 and are ready to promote it, you cannot use this approach because it will overwrite anything in production and therefore lose all production data.
Repeating development in production
The only out-of-the-box approach to promote subsequent versions is to repeat all the steps made in development in the production environment. This in itself introduces risks, such as incorrectly repeating steps with misconfiguration or simply omitting steps that are later discovered.
Some artifacts can be exported individually and imported into existing sub sites relatively easily:
• Copying and pasting file contents from one SharePoint Designer 2010 window to another, from one sub site to another
• Exporting web parts from pages and importing them onto the target pages
• Exporting and importing a declarative SharePoint Designer 2010 workflow from one sub site to the other
Configuration settings in existing sub sites, content types, lists and list items require a manual export/import out of the box. For simple solutions, this could be a matter of minutes. However, in more complex solutions this may require too many steps and lead to downtime of the existing solution in production, potentially causing business disruption issues.
A way to automate these changes from one version to another is to leverage the advanced tier of Visual Studio 2010 development of sandboxed solutions. One thing to take into account with this approach is that this will still require you to (declaratively in XML, and imperatively in managed code) write the incremental changes to go from one version to the next.
Sandboxed solutions are really a sub set of full trust solutions that are built on on-premise environments. Why? Certain managed code server-side APIs are not available for use, such as elevated security permissions.
There are two important reasons for this:
• First, there are security concerns that the Office 365 SharePoint 2010 Online multi-tenant environment and managed code accessing site collections not owned by the customer.
• Second, the managed code blocks contained in sandboxed solutions are executed in their own worker process and monitored for certain resource counters such as the number of exceptions thrown and CPU cycles consumed.
This allows SharePoint to disable sandboxed solutions that consume more than their limit and therefore do not affect other site collections and customers within the same SharePoint multi-tenant farm.
Visual Studio 2010 SharePoint Sandbox solutions support Team Foundation Server (TFS) as well as other source control providers for source control. One of the core tenants of application lifecycle management is continuous integration with automated builds based on source control check-ins.
This immediately becomes very complex in SharePoint 2010 Online and simply cannot be done without the advanced tier. In addition to the sandboxed solutions, a strong knowledge of PowerShell is required to remotely automate these builds into environments.
There are vendors that produce products that will automate this promotion of artifacts from one environment to the other for those without the appropriate resources.
In the next article, we will discuss migrating solutions from SharePoint 2010 on-premise to SharePoint 2010 online.