Corey Roth [MVP]

I’ve seen this conversation come up a few times.  Deploying code to SharePoint Online is not like deploying code to your test and production environments back on-premises. I thought I would give my thoughts on it and that will help you make a better decision.  Office 365 is not like Azure in the fact that you can simply spin up another web role for testing.  Nor do we have the ability to deploy code to one role and then swap it into production like we can with Azure either.  That means we have to get more creative.  Sure, you can develop code locally on a local SharePoint 2010 server and deploy it.  You can even use Visual Studio 11 to help you publish the solutions to the cloud faster.  However, this isn’t necessarily a good “test” environment since SharePoint 2010 and SharePoint Online have a lot of differences.

Effectively, the way I see it, we have two options for a test environment.

• Create a new site collection
• Create a new Office 365 account (tenant)

I know what you are thinking.  As a traditional developer building on-premises solutions, neither of these sound ideal.  Maybe they are not, but they actually make a lot of sense when we start thinking about it.  Let’s look at each option in detail.

New Site Collection

Now when this may not make sense for your on-premises farm solution.  It actually makes quite a bit of sense at the site collection level.  Think about it.  Our goal is providing a separate environment.  Well, pretty much everything you do with SharePoint Online operates within the sandbox of the site collection.  This includes solution packages which are published to the site collection’s solution gallery.  This makes it an ideal way to test customizations such as web parts, lists, content types, and more.  Simply create a new site collection, publish your customizations, test it out.  When you are done, you can even delete the site collection and create a new one when you need to test again.  Your code will not affect anything in the other site collections.

When will this not work?  When your code requires you to make changes at things at the tenant level.  For example, if you are testing some new term sets in the Managed Metadata Service or your solution is querying search.  If you were making use of the BCS, this might not be a good option either.  In essence, it works well for testing things like web parts and the use of the Client Object Model, but not so well for tenant based features.  For those features, it’s time to start looking at spinning up another Office 365 account.

New Office 365 account (tenant)

When you need to ensure that everything is absolutely separate in the cloud, the only way to do it is with another Office 365 account.  Go to try.office365.com and create a new account with a new prefix.  I’d recommend using a prefix that is easy to remember and indicates you are on the test environment.  For example, if your main domain is company.sharepoint.com, create something like companytest.sharepoint.com.  The benefit of creating a new account is that your service applications such as search, BCS, and the Managed Metadata service are truly separate.  You can also rest assure that nothing you do on this account, will affect your production account.

Probably the biggest drawback of this approach is that you have to maintain completely separate user accounts.  This can prove to be an inconvenience but it’s not terrible.  There may be some risk if you are testing permissions within your application, but you just have to deal with that.  Another drawback of this approach is that none of your data from your “production” SharePoint Online site will be present.  You’ll have to either manually upload it, deploy it with code, or look at a third party migration tool.

One other benefit of this approach is that you can just use a trial account.  Trial accounts are good for 30 days before you have to start paying.  This very well may be long enough to get you through your test cycle.  If your test cycle runs longer than that you can always just purchase a few licenses.  Keep in mind that Enterprise plans have a one-year term though.

Summary

These are the options I have came up with for testing customizations in the “cloud”.  I tend to go with just creating a new site collection, but I am sure I will find a change that warrants creating a completely separate account.  Have you come up with any other techniques for testing with SharePoint Online?  Post them here in the comments.

Follow me on twitter: @coreyroth.