In this guest blog post, Jeremy Thake, enterprise architect and Microsoft SharePoint MVP at AvePoint looks at the different options available for first-step real-world deployment of the SharePoint proposition.
As discussed in the previous article, SharePoint is a rapid application development platform. What brings real power to the organisation, however, is that there are different tiers available to build different solutions at different levels:
• Beginner – many solutions can be built purely from the web user interface SharePoint provides by creating new sub sites, lists and libraries as well as modifying configuration settings and content within pages,
• Advanced – in addition to the latter, more advanced development skills within Visual Studio 2010 you can build complex solutions leveraging managed code to construct event receivers, imperative workflows, custom web parts and package these for re-use across SharePoint.
The benefit of both the beginner and intermediate tiers is that it can be done remotely from any personal computer with a browser and SharePoint Designer 2010 rich client, respectively. It is worth highlighting that when building solutions, they should be constructed in a development environment rather than directly into production.
The primary reason for this is so that when v1.0 of the solution is in production and used by the business, you can make changes without affecting the business operation and then release v1.1 once quality assurance has occurred and a change management release window has been agreed upon.
Microsoft Office 365 has no concept of a development or staging environment, only offering production; this immediately encourages the wrong practice. The easiest approach is to create a development site collection from the Office 365 administration panel and ensure that, in terms of security, it is restricted. This approach will not allow for remote debugging of managed code required by advanced tiers, but will suffice for beginner and intermediate tiers.
Another cloud approach to development environments would be to use a third-party dedicated server provider to spin up a SharePoint 2010 environment.
One of the major risks here is that this will be an on-premise instance and has slightly different functionality in certain scenarios. If you steer clear of the server object model and stick to the Representational State Transfer (REST), client object model, and sandboxed server object model, you should prevent the mistake of leveraging unsupported features when deploying to SharePoint 2010 Online.
True on-premise options for development environments require hardware that may not be readily available or may take time to procure and provision.
The options are:
• Install on Windows 7 workstation – will require additional software on your workstation such as SQL and some functionality will be missing, such as user profile service application.
• Virtualisation on workstation – leverage virtual machines on your existing workstation to give added benefit of isolation, snapshotting, cloning and sharing VMs with your team.
• Dedicated servers (virtual/physical) – typically the slowest route to obtaining an environment but will mean an “always on” environment accessible by all in the team and better performing than workstation environments.
In the next article, we will discuss how you can introduce application lifecycle management (ALM) into SharePoint 2010 Online development processes.