8

Currently, the SharePoint Framework solutions are deployed as tenant wide app packages. Thereby, all instances of the web parts refer the JavaScript files from the CDN location specified in the packaged that is deployed in the app catalog. We need the ability to run Development, Staging and Production environments as different Site Collections in the same tenant. Is there a workaround for this?

I have tried deploying the app package to catalog, but updating only the instances I need (e.g. in Dev Site). But, the app instance update doesn't seem to do anything. The manifests are reflected in all sites, as soon as the new app package is uploaded to the catalog.

5

OK, I asjed this in the PNP-JS-COre meeting. Vesa said you can just change the settings in the config files to create a new package. So in config/package solution you can change the solution id and solution name to make it a distict package. Also change the paths Zipped-Package to give it a different file name so that you can have two versions in the app catalog.

Then you can set up an alternate cdnBasePath in write-manifest.json to point to the dev bundle.

  • Thanks for following up on this. This is exactly what I ended up doing. I am yet to test this end-to-end, but I did some gulp tasks to automate most of these. I will push it to a GitHub repo and share the link soon. I also posted this on uservoice link – user2560429 Jun 13 '17 at 23:15
  • 1
    cool, thanks. i'm testing this out my self, but manually. i'll be looking for your gulp task. btw: vesa also mentioned that they are working on a site collection level app catalog. sounds like that will help. – russellg Jun 14 '17 at 0:53
  • Did you guys ever iron this one out? If I change the app name, id, filename and CDN base path in both my dev + test packages, they can be installed into the app catalog side-by-side just fine, but the test web parts will randomly serve up the dev versions on every second or third page refresh (by loading their scripts instead), and vice versa. Ensuring the dev + test packages have different versions doesn't fix the issue either. Any ideas? Do the web parts IDs need to be different too? Note: my dev + test packages are even installed to different site collections – Nick Larter Jul 5 '17 at 9:32
  • did you run gulp clean before bundling your second deployment. If you don't do a clean it keeps old versions of the code in the bundle. – russellg Jul 5 '17 at 20:34
  • Yep, but still no luck. I ultimately ended up having to change all the web part IDs too — once I did this, the web parts stopped randomly loading bundles from different packages / environments. This isn't ideal, as the web part IDs are referenced in our PnP provisioning scripts so they need to be updated each time we do a dev/test/prod build too. – Nick Larter Jul 6 '17 at 1:14
2

Microsoft has now released a site collection app catalog -

enter image description here

The only limitation appears to be a lack of Application Lifecycle Management API support.

0

To solve your problem you can do following workaround:

For Development:
I'll recommend here to use SharePoint workbench to develop your web part. This will pick webpart and scripts directly from your localhost, so you can modify scripts without impacting your App deployed in app catalog. You can access the workbench using following URL pattern:

https://[path_to_your_site]/_layouts/workbench.aspx

Staging/Production
Bundle the SPFx web part into .sppkg package and upload it to your App Catalog. Also, update the CDN with latest scripts files.

Using this way you can have two environment in same tenant for development as well as for production.

  • but we would need to deploy the updated package to the app catalog to let users test it. also would need to deploy the test bundle to the cdn. how can we let users test the new version?.. we can create a separate folder in the cdn for the bundle, but can we have dev and test versions in the app catalog? – russellg Jun 1 '17 at 23:27
  • I read your post and want to suggest that App version works in this case. I do have the same environment. In such case, I maintain app version. For me its working fine. The only thing is, you need to have a different scripts file. When you upload files to CDN make sure each app version will refer to its own scripts file. Check your <code>temp/deploy</code> where you can find the JS file. I am still trying to figure out how to use <code> gulp bundle --ship </code> to create each time a separate JS file. – ThinkB4Code Jun 2 '17 at 5:29
  • ok, i think i see. so you only ever have one version in the app catalog, right? – russellg Jun 2 '17 at 10:42
  • I have tried changing the app version, but it doesn't work for me. As soon as i upload the new package with newer version to the app catalog, all web part instances across all site collections refer the newer version. Basically, updating individual app instances has no effect. – user2560429 Jun 2 '17 at 22:27
  • And the workbench approach suggested by ThinkB4Code doesn't work for me either. Because, I need some of my business stakeholders to be able to see the development environment to get some feedback. – user2560429 Jun 2 '17 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.