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应用程序目录。