Sp-dev-docs: REQUEST: gulp deploy-solution --ship

[BenGWeeks]

Category

• [ ] Question
• [ ] Typo
• [ ] Bug
• [x] Enhancement / Suggestion
• [ ] Additional article idea

Expected or Desired Behavior

Be able to run the following:

gulp deploy-solution --ship

This would deploy the app to the app gallery, as well as assets to their CDN location (most likely Azure or SharePoint SiteAssets folder for example).

Observed Behavior

No such functionality currently built in (if you search you can find an 'spsave' but that doesn't copy assets to the site assets / CDN.

This would really help speed up development.

[chakkaradeep]

The problem we dont have this, that is, deploy the package directly to app catalog is that it is somewhat impossible to accomplish this scenario via connect, authorize and authenticate with Office 365 using OAuth from NodeJS.

We are keeping an eye on the Azure CLI Tools to see how far we can accomplish this scenario.

Thanks for posting this request :)

[andrewconnell]

When we built the Office Add-in yeoman generator for Office Add-ins, we looked to expand it to SharePoint Add-ins. When researching feasibility, we were able to get everything to work *except( the part about creating the *.wsp file in the add-in package. Since WSP's are really CAB's but the tech for that is proprietary to MSFT and hasn't been updated in over 20yrs, there was only a Windows solution so we ditched the generator as it would have only worked on Windows.

But it seems like everything else was possible and those same things (packaging everything up & uploading to the App Catalog) apply to SPFx... so I'm wondering if that project could be resurrected and applied here as a custom gulp task?

So @chakkaradeep, can you share what the "somewhat impossible" part is about this that introduces an unforseen blocker?

[chakkaradeep]

The "somewhat impossible" part is not within SharePoint packaging. The sppkg uses open packaging convention model and don't use any .wsp (even if you want to include lists and libraries to provision along with your solution).

There are many aspects to this feature. Before diving deep, here is a scenario that we have been thinking for a while that could work:
Package deployment has the following stages: upload, trust and deploy. Deploy will enable the package and will be available to sites. So certainly if all we seek is that you use the app catalog List REST APIs to upload & forget and then have a tenant admin to manually deploy the package - you can do that in various ways today already. Remember that there isn't an error management or reportability back to the CLI client in this model.

Now to the deep dive:

First, the available tools: AFAIKN, you cannot create an AAD app (aka service principal) from the CLI tool. You atleast need one in your tenant so you can use that for all of your package deployments to SharePoint Online. If the experience you want is that the developer registers the app in AAD, gets the client-id, secret and then updates the config, and use the script to auth and deploy the package to SharePoint online - that is possible. You can probably update this task from @wictorwilen to do this, but I have not looked into it yet.

Second, dealing with AAD tokens: There are still issues around dealing with tokens and I am not entirely convinced that a CLI would help developers to be productive here. So, certainly there are areas to improve here. And lets not forget SharePoint on-premises as well. Happy to be proven wrong here. For example: What will be the case say, you work on a project today, go for vacation for a few weeks, come back, update the code and use the script to deploy?

Third, deployment experience, aka package and deployment APIs for developers: Unlike pushing a bunch of CSS/JS files to a CDN server, package deployment has various stages: upload, trust and deploy. Each of those steps could fail, especially around trust and deploy. We need a better way to handle such scenarios and good API support to manage the package for example: deploy, if fails report appropriately to the client or retract - etc.,

Fourth, managing new deployment capabilities: Today, deployment just deploys the package to the tenant app catalog and makes it available for sites to use. What if there are plans around introducing new capabilities here. How will we or how much we bring those down to the CLI? This is an unknown today but I would like to see a design that can at least help us get here.

The current approach, uploading the package to app catalog via browser works and doesn't block anyone and hence the chosen path. Once we improvise this, I think there will be a good use case to build deploy-solution task.

[chakkaradeep]

And just to be clear, I am not rejecting or opposed to @webtechy 's request. It is already in our backlog and we are actively looking into it every time we think about whats next for package and deployment feature crew.

Thanks!

[BenGWeeks]

Thanks for the detailed info :-)

I think this comes about as well, because the local workbench is of limited use for development since it's not (well, mine, and examples I've seen) pulling data from/to a SharePoint [dev] site. The examples I have seen use mock data and deploy to SP for "real" data.

In practical terms therefore, apart from initial look and feel, most real world SPFx webparts need to be developed by deploying to the SP dev site each time (which is time consuming). Therefore, related to this, would be some examples of retrieving SP info (i.e. authenticating a dev SP site which I assume should be possible but I haven't looked into it in to much detail as of yet) to be able to make the local workbench more productive.

[chakkaradeep]

We have the hosted SP Workbench for exactly those reasons. You don't need to deploy your package to test web parts in different sites. If you navigate to:

https://your-site.sharepoint.com/_layouts/workbench.aspx

That will load your web part with the appropriate context. Then you can use our helper classes to load mock and SP context depending on that. The React Todo Basic sample highlights that as well: https://github.com/SharePoint/sp-dev-fx-webparts/blob/master/samples/react-todo-basic/README.md

[BenGWeeks]

I had assumed that the online workbench was pretty much the same as adding it to a page, i.e. you need to deploy to the app catalog and copy assets across each time you rebuild ...

[chakkaradeep]

@webtechy here is a tutorial for you :) - Connect to SharePoint

And no, you just gulp serve locally and it will load the web parts available in the local server without needing them to be deployed.

[amishra0909]

Hi @webtechy, as @chakkaradeep explained that workbench works with gulp serve locally, I am closing this request here. If there is still some enhancement suggestions you have, please use our UserVoice to post your request. Here is the link to UserVoice : https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues