With the rapidly evolving migration to the cloud SharePoint teams are faced with a new challenge: How do we develop and deploy for SharePoint Online?
If your feet have been firmly planted with on-premises development for SharePoint it can be a little daunting trying to move your process to the cloud. Where and how should we conduct development? How can we implement release through development, quality assurance and production?
This article aims to help you get started and is based upon the hands-on experience of working with SharePoint 2013 Online during the past 18 months.
Perficient Model
Develop for the Service
Above all recommendations it is highly advisable to build new features for the service using SharePoint Online. Whether you are writing CSOM, customizing a Master Page or building an App you should do this for the service and not in a local (on-premises) development environment. SharePoint Online offers a very rich API which is very extensible but it can be extremely sobering to realize the feature you just spent the last few weeks building relies upon a feature not available Online. If you are developing features for both Online and On-Premises you can always bring things back on-premises later.
With a MSDN subscription developers can provision their own Office 365 tenant and begin development within a few minutes. How many hours would this have taken for the developer to build their own VM for on-premises development? If the developer does not have an MSDN subscription they could always use a trial tenant on a temporary basis or pay for a single user tenant for indefinite use. When provisioning any new tenant for development ensure that it is under the same license as QA and production (e.g. E3).
Once a developer is ready to deploy and review new features they can do this on a separate Development (Integration) tenant accessible to the team. This Development Environment is typically used for demonstrations of new features, in SCRUM Review meetings for example.
Tenant Isolation
Consistent with any mature software development it is important to ensure that Development, QA and Production are properly isolated and permissions configured accordingly. Developers will most likely have full administrative access to Development but will only have read or less access to QA and Production. Keeping your developers out of Production is a key principle for stability and ensures good consistent deployment techniques are employed. It also ensures that we maintain healthy disagreements between developers and administrators which is as old as time and ensures the project is fun!
It helps to name tenants consistently. We usually use the convention:
- https://<production tenant name>.sharepoint.com
- https://<production tenant name>DEV.sharepoint.com
- https://<production tenant name>QA.sharepoint.com
A key consideration with this isolation is how to maintain accounts across all three environments. Most likely the Production environment will have federated identities synchronized to the cloud with ADFS and DirSync or FIM. This allows us to work with corporate credentials in Production. However, a single domain can only be synchronized to one Office 365 tenant. So what should be configured for Development and QA? It is of course possible to build new domains (on-premises) and mirror the synchronization for Production. This is of course the most pure form of ensuring Development and QA are true representations of Production. However, this may be overkill for your development and testing needs.
It can be advantageous to use cloud accounts (onmicrosoft.com) in Development and QA, they are extremely lightweight and easy to manage as your team grows. Cloud accounts are particularly useful when working with professional services organizations as setup can usually avoid what might otherwise be a lengthy setup process. However, if your solution relies heavily on synchronized identities then it may be necessary to have Development and QA domains which mirror production.
Another key driver for isolating tenants in this way is that it ensures no global configuration changes during development can impact the production system. Consider the configuration of:
- Content Types
- Term Store Configuration
- Tenant-level Search Managed Properties
- Tenant-level Search Result Sources
One could argue that developing in a single Site Collection isolates development appropriately. However, the misconfiguration of these items alone could easily break a production system and take some time to recover from e.g. Search may need to re-crawl or the Content Type Hub will need to wait for a scheduled push.
Scripted Deployment
This article will not fully elaborate upon Scripted Deployment to SharePoint Online I will write another article shortly on this topic. However, it is an important principle of this model. Automating any task which is repeated can be a productivity benefit providing the time invested in developing the automation takes less time than repeating the task itself. Automation also significantly reduces chance of human error. It is less obvious how to automate deployments for SharePoint Online but the benefits are clear and have paid huge dividend for our teams working with the service.
What is Scripted Deployment? For SharePoint Online this means writing PowerShell with XML configuration and using the SharePoint Server 2013 Client Components SDK (currently v16). The PowerShell is run locally on the developer or administrator’s machine but connects to SharePoint Online using the Client Object Model. Through this script we can deploy most things required for SharePoint Online customization such as:
- Master Pages
- Page Layouts
- Content Types
- Display Templates
- Term Store Terms
It has taken some investment in the development of PowerShell modules but these become highly reusable across projects.
As developers work with their own tenant they develop the deployment scripts required for their feature. Those familiar with SCRUM will relate to ‘Done Criteria’. Our Done Criteria includes development of a feature and its scripted deployment to the Development (Integration) tenant where it can be reviewed. There are some exceptions which cannot be achieved by this technique but the Client Object Model does support a very wide range of common needs for deployment and configuration. Where exceptions exist these are documented in a deployment document for manual execution by an administrator.
Replication of Production Data
It is desirable to have recent data available in QA to ensure good and valid testing. For this replication it is advisable to use a third-party migration tool like Metalogix Content Matrix. When selecting a tool for this purpose ensure that it can migrate the data faithfully to ensure good testing but also that it can transform data as required. For example, if Production data uses synchronized identities but QA uses Cloud Accounts it will be necessary to perform some transformation. E.g.
chris.hines@contoso.com could be mapped to chris.hines@contosoqa.onmicrosoft.com
Happy development and deployment!
How do you handle the differences that occur in multiple tenants when they are on different update schedules from MS? With your approach, it is quite possible for Prod to get updates before your Dev and QA tenants which could cause some issues. Have you any experience with this or recommendations about how to deal with the potential problems caused by Microsoft’s lack of update scheduling information?
Great question! We are signing-up our Development and QA tenants for the ‘First Release’ program. This is available under your O365 Settings for the tenant. First Release means that these tenants will receive updates at least two weeks prior to general release to other tenants. Keep an eye on the O365 Public Roadmap, this should alert you to the headlines of what’s changing. Your First Release tenants (Dev and QA) should then get the updates first giving you time to respond to change before the same updates hit production.
Do I need separate license for each tenant. for Development, QC, UAT & Proudction do I need for licenses?