Details on updating SharePoint Framework solutions
New SharePoint, new way of customizing sites: the SharePoint Framework. There’s a complete wiki on the Office365 developer site explaining how to develop and deploy webparts. But how does it work behind the scenes?
SharePoint Framework solutions are deployed in three parts:
- Code files
- Application package for tenant’s app catalog (.sppkg)
- Application instance on each site
For a quick how to, there’s a complete page on the official wiki.
The generated solution handles code files generation out of the box: gulp –ship command. Gulp tasks are contained in the node package @microsoft/sp-build-web. Webpack is the bundling tool in the process.
Two folders are generated:
- Dist, with webpack’s bundled code
- Temp/deploy with files that will be deployed
Here is an important part to understand. Files are deployed to a CDN, so updating webparts in your solution would require some time before users can see your update. Common solution is to change files names with each release. But you then force a reload of all files, even if there was no change. The final solution is described in this article on long term caching of static assets with webpack.
A different bundle is generated for each webpart, and a hash is added in the end of each bundle. You can generate the project multiple times: the hash will remain the same as long as there is no change in the code.
You end up with a CDN where you have a file for each version of each webpart :
That brings an important step in updates: Application package must be updated even if there was no change in webpart’s manifest. We will see how it works in the next step.
Application package is generated with the gulp package-solution –ship command. It is a .sppkg which, when renamed to .zip and extracted, contains solution’s and webparts manifests.
If you look at any webpart’s manifest, you will find that the complete code file name (with hash) is referenced.
That’s why you need to load your new version into the app catalog.
Once an updated version of your package is available in the app catalog, site administrators can then update the version installed in their site. That’s where the magic happens: new webparts version will only be used once this update is done.
My thoughts on this system
This system seems great:
- Files are cached in the CDN for performance
- You are not bothered by cache when doing updates
- You can have multiple versions of your solution coexisting, with each client or each site administrator choosing when to get the latest update
And while you usually should set up this kind of system in every new project, it is now handled out of the box. Clever work by SharePoint Dev Team!
Then you can set up continuous deployment. Close from everything can be automated with great stuff from the community:
- Code files updated in Azure CDN by default gulp task or in Office365 CDN with this task
- App Catalog updated thanks to this task
- Application instances is the only thing that can’t actually be automatically updated. I tried the same solution than with old .app packages, but SharePoint refuses it.