SOLVED

Testing an updated web part, on a live SharePoint site, without affecting the existing version

Brass Contributor

Hi

 

Modern experience.

 

I have an updated version of a web part that I need to test on a live SharePoint site. This needs to be done without affecting the existing version of the web part. The workbench is not suitable as I need to test it alongside existing content.

 

I suppose that I need to make the updated web part look like a new web part for testing. Then back like the existing web part when it's ready to go live, but with an updated version number. What do I need to change to achieve this, or is there a better way?

 

Thanks.

 

9 Replies

Why don't you use a tool to create a test tenant and copy the items to it so you can do a test before releasing it on a production tenant.

Hi @Deleted

 

I don't have a test tenant (I did have an Office 365 Developer account, but it's expired), but I do have a test site collection. However, web parts are installed at the tenant level. I know site collection app catalogs are on the way, but I don't think they are released yet.

Hi Alan,

 

but you could create a trail to test it in the tenant with real data copied.

just create a trial account here you can also test your scenario for the new app.

Hi Paul

 

I could create a trial, but I'd also like to know how to do it by changing values against the web part.

Hi @Alan Trafford,

 

In such situations, we use local workbench and target requests to SharePoint REST Proxy.

This allows request real SharePoint data within local workbench without publishing app to app catalog.

 

I'm going to write a detailed blog post how this can be done (UPD: Here is the link to the article.). Meanwhile in a few words:

 

1. Install SharePoint REST Proxy in SPFx solution project

npm install sp-rest-proxy --save-dev

2. Create `proxy.js` file in a root or wherever in the project with the following content:

const CertificateStore = require('@microsoft/gulp-core-build-serve/lib/CertificateStore');
const RestProxy = require('sp-rest-proxy');

const settings = {
  configPath: './config/private.json',
  port: 4323,
  protocol: 'https',
  ssl: {
    cert: CertificateStore.default.instance.certificateData,
    key: CertificateStore.default.instance.keyData
  }
};

const restProxy = new RestProxy(settings);
restProxy.serve();

3. Create `npm` task to execute, e.g. `"proxy": "node ./proxy"`

4. Run and configure proxy's connection to the environment by `npm run proxy`

5. Configure a task to start proxy and `gulp serve` at the same time, e.g. using `concurrently` or `npm-run-all`

6. In SPFx webpart use detection of a local mode with:

import { Environment, EnvironmentType } from '@microsoft/sp-core-library';
if (Environment.type === EnvironmentType.Local) {
  // Local mode
}

7. If local mode, target request to proxy's endpoint

Example for `sp-pnp-js`:

if (Environment.type === EnvironmentType.Local) {
  this.web = new pnp.Web('https://localhost:4323/sites/site/web');
} else {
  pnp.setup({ spfxContext: this.context });
  this.web = new pnp.Web(this.context.pageContext.web.absoluteUrl);
}

 

Hope this helps.

best response confirmed by Alan Trafford (Brass Contributor)
Solution

The Site collection app catalog should help when it becomes available, but until then you can deploy a Test version of the App to the app catalog and your cdn and deploy the test version to your test site.

 

in package-solution.json change the  solution name  to test-yourappname and the id  to a new guid and the zipped package name to solution/test-yourappname. This will make the app unique.

 

in write-manifests.json change the cdnbasepath to a new folder where you will deploy you deploy your test code so that it does not interfere with the production code.

 

for each of your webparts  in the webpart.manifest.json change the Id to a new guid. You cant have two webparts in a tenat with the same id.

 

then gulp clean; gulp bundle --ship,  gulp package-solution --ship. This will create a new sppkg file for your test app , with a different name (test-yourappname) that references the different cdn location you specified in write-manifests.json.

note: for each of these files, I keep a .production and a .test version  in my project so I can just copy  the contents from either file when I am ready to deploy. It would be awesome if we could have gulp do that for us!

 

then  upload the test sppkg to your app catalog  (solution/test-yourappname.sppkj) and deploy the files in temp deploy to the folder you specified in write-manifests.json to your cdn. You can then deploy your test app to your test site without interfering with production. You can even have the two versions running side-by-side in the same site collection,

 

Its a bit of work, but it has been working consistently for me for months now.

 

 

 

 

Hi @Russell Gove

 

Thanks, I did what you suggested and it worked perfectly.  Between @Andrew Koltyakov and yourself I have two great solutions.

Thanks to all this previous information, it led me to find that the site collection app catalog is now available and so I was able to set up an app catalog for a test site collection and an app catalog for the live production site so I could keep the updated web part in the separate site collection and have testers test without impacting production (we still have to duplicate some of the list data that's causing bugs in our web parts but ShareGate can help in some cases).  In case this helps anyone else: https://docs.microsoft.com/en-us/sharepoint/dev/general-development/site-collection-app-catalog

1 best response

Accepted Solutions
best response confirmed by Alan Trafford (Brass Contributor)
Solution

The Site collection app catalog should help when it becomes available, but until then you can deploy a Test version of the App to the app catalog and your cdn and deploy the test version to your test site.

 

in package-solution.json change the  solution name  to test-yourappname and the id  to a new guid and the zipped package name to solution/test-yourappname. This will make the app unique.

 

in write-manifests.json change the cdnbasepath to a new folder where you will deploy you deploy your test code so that it does not interfere with the production code.

 

for each of your webparts  in the webpart.manifest.json change the Id to a new guid. You cant have two webparts in a tenat with the same id.

 

then gulp clean; gulp bundle --ship,  gulp package-solution --ship. This will create a new sppkg file for your test app , with a different name (test-yourappname) that references the different cdn location you specified in write-manifests.json.

note: for each of these files, I keep a .production and a .test version  in my project so I can just copy  the contents from either file when I am ready to deploy. It would be awesome if we could have gulp do that for us!

 

then  upload the test sppkg to your app catalog  (solution/test-yourappname.sppkj) and deploy the files in temp deploy to the folder you specified in write-manifests.json to your cdn. You can then deploy your test app to your test site without interfering with production. You can even have the two versions running side-by-side in the same site collection,

 

Its a bit of work, but it has been working consistently for me for months now.

 

 

 

 

View solution in original post