In his video, Daniel Kogan - Principal Group Program Manager on the SharePoint engineering team - introduces us to the SharePoint Framework. He shows us how it works and how you can build solutions on it. Towards the end of his presentation, he also shows how we can use the upload-cdn task to publish the latest changes and update all existing Web Parts. Is this the ALM story for SharePoint Framework customizations?

A new model for new demands

SharePoint Framework is the new model for building customizations on the SharePoint platform. It accompanies modern Team Sites and helps developers extend SharePoint’s capabilities beyond what is available out of the box.

Modern Team Sites are Microsoft’s answer to the ever-increasing demand for productivity tools supporting the mobile-first cloud-first world. Built with that philosophy in mind, modern Team Sites work great both on desktop computers and mobile devices. Using the SharePoint Framework we will be able to add more capabilities to Team Sites and ensure, that everything we build works great not only on desktop computers and mobile devices but also in the SharePoint mobile app to be released soon.

SharePoint solutions ALM - a never-ending story

Back in 2007 Microsoft introduced the Solution Framework for helping us structure our customizations and deploy them in a repeatable way. While it helped standardizing SharePoint solutions, updating them remained complex.

SharePoint is a rich platform with many capabilities that developers use when building customizations. Once the customization has been deployed and users started working with it, it’s hard to update it and all its references using the declarative approach.

Partly because of that, Microsoft has been advocating for the last few years using remote provisioning techniques instead. But there is another wave of changes happening to how we design and build SharePoint customizations.

SharePoint: a service or a platform?

With the introduction of the SharePoint Add-in model, it was for the first time that Microsoft started recommending integrating with SharePoint using its remote APIs. Hosting customizations outside of SharePoint servers has many benefits with regards to platform hygiene and performance, not to mention it’s the only way to customize SharePoint Online.

Building Farm solutions is still perfectly supported and many organizations continue to do it. While SharePoint Add-ins have their own set of limitations, one thing is clear: building solutions that integrate with SharePoint using its remote APIs is the future.

SharePoint Framework solutions - it’s all about JavaScript

The recently announced SharePoint Framework is the next step in how we will be customizing SharePoint. It’s based on open source tooling and uses only client-side code for building the UI. Depending on the requirements, SharePoint Framework customizations can communicate with SharePoint using JSOM or REST, or they can have remote server-side components connect to SharePoint using CSOM or REST for them.

When registering Client-Side Web Parts and Applications, built using the SharePoint Framework, with SharePoint, the key piece of information is the URL where the JavaScript code of the particular component is hosted. Everything else, like styles, images or other scripts loaded on-demand, is loaded by the component itself. You are free to choose whether you want to host these assets in SharePoint or outside.

If you think about it, this minimalistic contract between the customization and SharePoint simplifies managing the lifecycle customizations a lot. In case of an update, the only thing that you need to do, is to update the JavaScript file at the URL where it’s hosted and the next time users will load the page, they will see the update version of the Web Part or Application. We’ve seen this work in Daniel Kogan’s video and Vesa and I discussed that in the recent Office Dev PnP podcast as well. But is it truly as easy as that?

SharePoint Framework solutions ALM

If you’ve built SharePoint solutions and Single Page Applications in the past, you might wonder of at least a few things related to managing the lifecycle of SharePoint Framework solutions.

Can developers push updates to production using the upload-cdn task?

This is exactly what we see in Daniel Kogan’s video: you apply a change to the Web Part, test it in the Workbench, verify that it’s working correctly and then use the upload-cdn Gulp task to push the update to CDN. After refreshing the page, users immediately see the latest version of the Web Part.

What we see in the video is an oversimplified idea of the capabilities at our disposal when building SharePoint Framework solutions. And while technically possible, you will very likely not allow your developers to directly update production code.

The upload-cdn task uses parameters from a configuration file, specifying the Azure Blob Storage account and its credentials to upload the assets to. When working with a team on a project, this location might be used in continuous integration scenarios for testing the Web Part on a test server.

The pre-release version of the SharePoint Framework tooling allows us to specify only one URL, but what if we could specify multiple URLs instead? What if we could use them in the different stages of the release process (like dev, test, UAT, prod) or even have different release rings (like first release and general availability) to better support adoption in organizations? What if credentials to non-dev storage accounts could be passed as parameters and wouldn’t be available to developers? What if deploying to the storage account used in production was only allowed upon administrator approval?

It’s still early to say how exactly the upload-cdn task will work but it has a great potential of being a valuable asset supporting the SharePoint Framework ALM story.

How does it deal with cache?

By default, SharePoint Framework solutions are bundled using Webpack. Webpack allows you to easier manage dependencies and assets required by your solution. The downside is, that, depending on your customization, these bundles can get pretty big.

Even though SharePoint Framework solution bundles are static, you would very likely want to have them cached on clients, both to save network bandwidth and improve performance. The thing is, that if you cache them for too long, users won’t get the updates and if you cache them too shortly, then there will be little to no benefit of doing it. The solution to this might be using far-future expiration cache.

Usually, when using far-future expiration cache, you also include a version string in the URL and change that with each release to invalidate the cache on clients. But isn’t this URL stored in the Web Part and wouldn’t updating it mean having to update all instances of the particular Web Part across the whole tenant?

Each Client-Side Web Part stores a reference to the manifest where the URL is specified rather than the URL itself. That way, if you would want to change the URL, you would only need to do it once, in the App Catalog, rather than having to do it separately for every instance of the Web Part.

Although the pre-release version of the SharePoint Framework tooling doesn’t offer any support for managing customization versions, it’s not unimaginable to think, that it might do it in the future. And since it’s all open source the developer community might come up with some other ways of including the customization version number in the URL.

One thing to keep in mind is, that in order to control how static files are cached, you have to host them outside of SharePoint. If you choose to deploy your assets to SharePoint, you won’t need to worry about hosting the assets but you will be fully dependent on the caching settings Microsoft uses for SharePoint Online which are probably not the most optimal settings for your application.

How do I setup different URL for different ALM stage?

When moving your customizations through the different ALM stages like test, UAT or production, you might want to use different locations to host your solution’s code. The URL of where the code is located, is specified in the Web Part manifest which is included in the package. So if you need to use different URLs for different ALM stages, using the pre-release SharePoint Framework tooling, you would need to build a different version of the package for every stage, which might feel counterintuitive from the ALM point of view.

Even though the solution’s code isn’t a part of the package and is hosted separately, the package itself contains more information about the solution which theoretically might different between builds. If you prefer to promote the same version of the package to the different stages of ALM then you might need some custom tooling to help you update the script URL corresponding to the particular ALM stage.

What do you think?

SharePoint Framework hasn’t been released yet and we are still to see what support for ALM it will offer. Still, you can already start thinking about what would be required for it to support your organization’s ALM requirements.

Based on what you know about SPAs, SharePoint Solutions and the SharePoint Framework, do you think these are all valid considerations or do you already have the answers based on your previous experience? Is there perhaps anything else that you haven’t heard about and which concerns you?