If you had to provision SharePoint Online in the past, then you would agree that it can be quite tedious with all the steps required. Doing it once is ok, but if you have to do it over and over, it can be quite error prone and frustrating. Imagine yourself at the last steps of a tedious deployment when you receive an email from your dev asking you to redo the implementation because of some changes they just introduced. Frustrating!
In this article, I’ll be discussing common tools and strategy for deploying SharePoint Online successfully.
SharePoint Deployment Types
When you think about deployments, have you ever stopped and wondered what it means to deploy SharePoint? SharePoint Deployments typically fall into four distinct groups:
- Information Architecture (IA)
This group includes all the definitions and structure to support the content that the site will manage. IA typically includes elements such as taxonomy (or metadata), site columns, content types, sites and subsites, lists and libraries, and workflows. - Configuration
Configuration deployment includes both SharePoint as well as overall tenant elements, such as features, search, and user profiles. Unlike the other types of deployment, there are a finite set of configuration parameters that available. Once a tenant or SharePoint site have been configured, you won't typically have to redo these changes when redeploying other parts of your SharePoint site unless your configuration requirements have changed. - Branding
The next typical group of deployments is branding. Branding is what gives your SharePoint site the experience your users require. Traditionally, branding relied heavily on master pages, page layouts, and other customizations. Recently, there has been a shift towards client-side branding that involve more Javascript-type solutions. In both cases, SharePoint solutions are used to deploy such branding changes. - Content
The last group of deployment is your content. You may not think of content as something that gets deployed per se. But imagine a scenario where you have to create numerous sites that should have some content already available when the site goes live. In those cases, you need to include the content as part of your deployment steps.
To deploy a full SharePoint site from the ground up, you would likely need to include components of all of these four groups. During the process, it’s important to consider not only what you are deploying, but also the order in which you perform the tasks. Some dependencies will dictate the order of operations. You shouldn’t start adding content to an empty site just as you wouldn’t start building a house by raising a roof before building its walls.
SharePoint Site Deployment from the Ground Up
As you can see in the image below, there are many building blocks required to create a SharePoint site from the ground up. Let's have a look at the order in which a typical site gets created.
After creating your tenant, you can start making any tenant-level configurations even before you have a SharePoint site. At the same time, you can build out a shared taxonomy (term group, term sets, etc.) for all SharePoint sites. That’s about as far as you can go in the first step.
Next, you create the SharePoint site which will house all the IA, branding, configurations, and content goodies you’re about to create. Once your site is ready, you can get down to business with the big stuff.
With your newly created site and taxonomy in hand, you can simultaneously apply any site-specific configurations and build out your site’s IA by adding site columns, taxonomy columns, and content types. Leveraging site columns and content types has many benefits and is best practice in managing your metadata across multiple sites, lists, and libraries.
Now you’re ready to create any subsites, lists, and libraries that will leverage everything you’ve built thus far. You can really see your site come to life at this point.
If you have any workflows, you will deploy them next as workflows often operate on events generated by list or libraries.
You can add the branding to the site as well now. It is possible to do this step earlier, but depending on how the branding implementation, there may be a dependency on some parts of the IA which need to be in place first. Also, it’s a good idea to have the overall site structure built to see how the branding will look.
Finally, you add the content to the site. If there were no problems in the previous steps, then the site should be able to store the content (IA), act on it (workflows), and present it in the right way (branding).
So far we looked at the type of deployments available for SharePoint and what steps are required to create a site from ground up. Now let’s look at the tools available to get the work done
SharePoint Deployment Tools
The most obvious choice is to use the Office 365 and SharePoint user interfaces as they offer much of the functionality required for any of the deployment types. Other deployment tool options include SharePoint
Designer and PowerShell.
There are pros and cons to each, but there is a strong gravitation towards using PowerShell to automate and simplify the process.
Unlike the on-premises, server-side versions of the SharePoint PowerShell cmdlets, your choices for SharePoint Online are more limited and require you to use CSOM which complicates writing of your scripts.
Fortunately, a group of community contributors got together back in 2013 and created the OfficeDev Patterns & Practices initiative. Although the original goal was to help in the transformation effort of Office 365 Dedicated customers to multi-tenant and moving full trust code to add-in model, they since progressed into other areas of development including Office 365 APIs, Office Add-ins, and Unified APIs.
An offshoot of the original initiative is the OfficeDev PnP PowerShell library includes SharePoint specific libraries that encapsulate the complex CSOM into over 160 distinct cmdlets. The libraries are available for SharePoint Online as well as SharePoint 2013/2016. What’s also great about these libraries is that due to their common core base, code written for SharePoint Online can work in an on-premises environment and vice versa. Also, the OfficeDev PnP libraries include a provisioning engine that helps automate the remote provisioning of tasks, such as site column, content type, list, composed looks, and page creations. In essence, the provisioning engine allows you to save your entire SharePoint site’s definition into one or more XML files and then use the engine to deploy these definitions to another site. Again, by leveraging the same core libraries, you can interchange site provisioning templates between SharePoint Online and on-premises environments.
Choosing the Right Tools
There are several factors which you need to consider when choosing the optimal deployment methods for your specific scenario. No one solution fits all, and in some situations, you will need to use multiple methods simultaneously.
Technical Constraints
Some things can only be done using specific tools. If you need to create custom user profile properties, then you have to use the SharePoint Administration UI in Office 365. Are you deploying workflows? Then SharePoint Designer is your choice. Do you want to create a taxonomy, site columns, and content type with specific ID’s that will be consistent on any site? PowerShell it is.
Frequency
How often do you deploy changes to SharePoint? Once, only? Annually? Monthly? Daily? If your deployments only happen on a rare occasion, then using a less efficient method such as the SharePoint UI may outweigh the effort involved in creating a custom script in PowerShell.
Volume
Suppose you’re doing a deployment infrequently but you deploy a significant amount of information architecture and content. Would you want to do it manually even if the task is simple to perform?
Complexity
As you’ve seen earlier on, deployments can vary from a simple SharePoint solution (WSP) deployment to the creation of numerous sites with IA, configurations, and more. The complexity of your deployment can also be a driver for which deployment methods you end up using.
Conclusion
SharePoint deployments come in many forms and sizes. With all the possible combinations of information architecture, configurations, branding, and content deployments, it can be hard to determine which is the best solution to adopt. In reality,
With all the options available, you may be wondering which is best for you. The simple answer is – it depends. In the following table, I summarize the various options discussed and which is the optimal tool(s) for each task
