First Release and NDA Preview for Office 365 – early access to Microsoft’s changes for testing

One of the most interesting sessions I attended at SPC 2014 was around change management in Office 365. For those of us who have worked on Office 365 (i.e. SharePoint Online) or hybrid projects, it’s been a challenging time recently – Microsoft have made various updates and patches to Office 365, which have subsequently caused lots of customizations to break and ultimately made it hard to support organizations on Office 365. And I think it’s normal to have *some* level of customization in an Office 365 project – for some it might just be branding, but since the SharePoint user experience is still not ideal in places, our clients are often requesting enhancements around search, user profiles, sites, OneDrive for Business (the new name for My Sites) and so on. Some examples of unannounced Microsoft changes which have caused valid customizations to break are:

• The HTML change to the “title” attribute of form elements, as described by Marc Anderson at Office 365 Update Changes ‘Display Name’ on Required Fields
• Several issues reported by Andrew Connell at Office 365 Needs to Treat the UX as an API if Our Customizations are to Stay Off the Server
• API changes – changing the “throttling” on CSOM batches, so that code which previously worked now failed

Of course, a big part of this is that Microsoft have taken a leaf from the Facebook/Yammer book, and have shifted their “release cadence” – updates are deployed to Office 365 in small batches very frequently(every month), which is very different to the on-premises world with a big release every 3 years and service packs and cumulative updates within that.

Taking a step back – lack of Office 365 test environments

Clearly, Microsoft are always going to need to update Office 365/SharePoint Online. And in many cases, all we need is a way of testing the change (and any impact on our customizations) before it’s in production. I recently had a meeting with some Microsoft UK folks about this, and I summarized this aspect as:

• Lack of test environments in Office 365
  • Whilst we can (and do) create and pay for multiple O365 tenancies/environments to simulate non-production environments, we have no control of the *sequence* that tenants are patched in – in other words, a Microsoft update can hit our “production” tenant before our dev/test tenants
• No notice/awareness of the date that an update will occur on (for our tenants)

Announced at SPC 2014 - “First Release” and “NDA Preview” options

The good news is that Microsoft are taking big steps to improve this situation – it’s a topic close to my heart, so I wanted to provide my interpretation here (as well as publicize the initiative), but will also link to official TechNet pages when they arrive. In a slightly “under the radar” session on the schedule, a few changes were announced by Jake Zborowski (Group Product Manager, Office 365) at the conference:

1. Improved communication about updates
2. A more structured approach to releasing updates
3. “First Release” for Office 365
4. “Office 365 NDA Preview”

The next sections go into some more detail on each one.

Improved communication about updates

This includes:

• A published *public* roadmap – used to communicate some types of upcoming updates
  • This is targeted for April 2014
• Use of the Office 365 updates blog to communicate changes
• Use of the Office 365 System Requirements page to communicate changes
• Changes to the Message Center
  • Ability to display messages/warnings specific to the tenant (currently cannot)
  • Will show near-term warnings, recommended actions etc.
  • New API, so that developers can write notification apps
  • Enhancements to the existing Office 365 Admin mobile app

A more structured approach to releasing updates

Changes will be classified into different types, and each given a different communication and release plan. The slide below summarizes the communication aspect - but note that at a lower level, communications will actually appear at different times in the different communication vehicles (e.g. an upcoming change will be announced on the public roadmap before it shows up in Message Center etc.):

“First Release” for Office 365 

This is the ability to switch mode for a certain Office 365 tenant – effectively you are signing-up to be “first in the queue” for many types of changes/updates, before they get made generally available in Office 365. The scope of this is for changes to SharePoint Online and Exchange Online. This is AWESOME news, and should go a long way to solving some of the issues for us. Some more details:

• Opt-in switch (off by default):
  • The switch will appear in the Office 365 admin center around early April 2014, and then changes will start to be rolled through it around 4 weeks after that
  • Changes to the switch will be respected within 24 hours – you can switch First Release on/off for your tenancy as you like
  • If you opt-out, any changes already deployed will not be pulled back but future updates will no longer be applied early to your tenant
• Types of updates:
  • Updates which do get pushed through will be supported/vetted/documented and end-user facing
  • Not all updates will be pushed through First Release – I wasn’t 100% clear on what is/isn’t, but I believe something like storage increases (e.g. for OneDrive, or general site collections) would not be
• Timing:
  • You’ll get a warning of at least 7 days alerting you that a change is going be rolled out to First Release
  • An update will be in First Release for a minimum of 2 weeks before standard rollout – however, for most tenants it could work out to be around 1 month until the update lands
  • N.B. at the time of writing, the Product Group are currently working on the ability to know for sure when an update will hit a specific tenant (and consider that for some updates this could actually be different for individual site collections and/or users!). Obviously this is crucial to implementers (like us), because sometimes we may need to deploy a code change to "match up" with a change in Office 365 (otherwise there will be a period where something is not working properly

Here’s a mock-up of how the First Release switch might appear (apologies for the low-quality image):

A note on how I expect WE will use First Release

As I discuss in my Office 365 developer decisions, tips and tricks presentation, we long ago decided to use multiple tenants for each client we work with (representing dev, test and production at least). With the introduction of First Release, I expect we will enable First Release on dev and/or test but leave it off for our “production” tenants. I have some thoughts on whether *both* dev/test should be enabled

“NDA Preview” for Office 365

NDA preview is another useful option for early access to changes – here, Microsoft’s changes are rolled out to a subset of users in your tenant. So whereas First Release affects an entire tenancy, NDA Preview affects only nominated users. There is more involved than just flicking a switch here – I don’t yet know for sure whether it will be open to everyone, but it is a TAP-like program where the organization needs to be able to dedicate time to providing good information to MSFT engineering and working together on issues. Just like a TAP, contracts have to be signed etc. 

Some more details:

• Up to 100 users (TBC) can be nominated
• All changes going through  First Release will also go through NDA Preview
  • BUT, some new changes will go through NDA Preview only, and NOT First Release – an example could be the storage increase change I mentioned earlier
• Sign up at http://prereleaseprograms-public.sharepoint.com
  • Microsoft will then be in touch at a later date – as I say, contracts need to be signed (possibly because of the different nature of some changes pushed through NDA Preview)

A note on how I expect WE will use NDA Preview:

Even with First Release, I think the NDA Preview option will be very valuable. and I expect we WILL enable it for each of our production tenants and nominate some users from at least the implementation team. The production tenant is sometimes the only environment which truly “has everything” – directory synchronization, federated authentication, Yammer SSO/integration to the Yammer Enterprise network, two-way hybrid config (for hybrid deployments) are all examples of things which may not be in place elsewhere if you run multiple tenants. As such, the option of testing Microsoft’s updates in production before full rollout is a very good thing.

Timelines and NDA Preview/First Release

The following diagram gives a sense of how the two programs will work in terms of the timeline for updates:

Summary

I’m really happy to see Microsoft start addressing the issue of Office 365 change management. My fear had been that the platform had not been engineered to release updates to tenants in different ways (and you get a sense of that when the Product Manager mentions that big back-end changes are required for Microsoft to predict when a patch will hit a certain tenant). However, it seems Microsoft *do* appreciate that there is a huge need for a better process around Office 365 patches and updates – and indeed Microsoft’s message these days is “we do expect you to build customizations on Office 365” (but no doubt the usual caveats about what is sensible apply). This is positive for organizations using Office 365 and partners who support them.