四度空间

专注.NET、SharePoint

SharePoint Framework 基于团队的开发(五)

博客地址:http://blog.csdn.net/FoxDave

升级SharePoint Framework项目

部署SharePoint自定制解决方案到生产环境并不意味着生命周期的结束,因为还有有新的需求或变更。在升级项目时需要考虑以下一些事情。

语义化版本(SemVer)

SPFx项目使用SemVer来跟踪版本号,其实就是我们通常所说的版本,如1.0.1,它由三部分组成:主要版本.次要版本.补丁。对于SPFx项目来说,由如下约定:

主要版本:修改不是向下兼容的

次要版本:新增向下兼容的新功能

补丁:向下兼容的bug修复

关于SemVer的更多信息可以戳这里

增长版本号

在升级SPFx解决方案时,开发者应该提升所修改部分的版本号来表明是哪个部分进行了修改。

>增长package.json文件中的包版本

SPFx包的结构跟Node.js包类似,它的依赖关系和元数据存储在项目文件夹的package.json文件中,其中就有一个version属性来表示整个项目的版本号。默认情况下,解决方案中的所有组件都继承这个版本。开发者在每次发布新版本时应该修改这个属性。

>增长package-solution.json文件中的包版本

SPFx解决方案使用.sppkg文件进行部署,该文件安装在SharePoint中的应用程序目录网站上。.sppkg文件跟SharePoint add-in包类似,将四段版本号(主版本.次版本.修订版本.编译版本)存储在config/package-solution.json文件中。为了清晰可见,开发者应该保持该版本和package.json文件的版本同步。

更新依赖引用

试想如果Angular发布了一个新版本,修复了bug并提升了性能,这时我们就需要更新我们的项目了。更新时使用命令nmp install <package>@<version> --save。注意不要手动修改package.json文件中依赖引用的版本号,这会带来不必要的麻烦和不好排插的错误。

>注意项目结构的变更

有时项目的升级可能会带来结构的变更和配置文件的变更。通常在更新项目之前,如果碰到这种情况就一定要好好比对,避免项目出现损坏。

>谨防使用npm outdated命令

找出项目中哪些依赖引用需要升级的方法之一是执行npm outdated命令。该命令会扫描你的依赖引用树并提示哪个包可以升级,很方便的命令,但是我们需要小心使用。

从举个例子。版本1.3开始,SharePoint Framework Yeoman生成器允许开发者在创建时选择项目是只在Online上运行还是Onpremise上也要运行。但是SharePoint本地的SPFx要比Online的旧,这时如果在一个需要兼容本地的项目上使用npm outdated命令,它会提示你升级到最新版本。然而,这样你的项目就无法在本地运行了。

以发布模式编译和打包项目

一旦项目通过测试,可以使用gulp bundle --ship命令以release模式编译项目。然后使用gulp package-solution --ship命令打包。注意在打包之前一定要先执行编译命令,否则包里会包含旧版本的内容。

部署解决方案的新版本

编译打包项目之后的下一步就是部署了。首先部署项目中./temp/deploy文件夹里的web部件bundle,再发布解决方案之前版本的其他文件。注意暂时不要将旧版解决方案的内容移除,因为可能会有正在使用的。每个版本的bundle文件都有唯一的名称,移除先前版本后再升级web部件会损坏当前正在使用的那些。

最后部署新的解决方案包到SharePoint应用程序目录。

posted on 2017-12-25 08:54  月飘冥  阅读(...)  评论(...编辑  收藏

My Links

Blog Stats