博客地址：http://blog.csdn.net/FoxDave
构建关于SPFx自定义的计划
在SPFx引入的时候，你就需要对它进行规划了。规划要从介绍SPFx解决方案使用的新的技术栈开始。开发者可能需要对于使用TypeScript作为主要的开发语言进行培训来编写SPFx代码，取决于开发者之前的技术背景。另一个SPFx开发者可能需要学习的方面是SPFx的工具链，包括node.js，npm和Gulp，以及如何使用不同的Gulp任务来构建，打包和部署解决方案。推荐从下面的链接开始：Official SharePoint Framework documentation或SharePoint Github repositories。
开发者可能会想要为组织标准化一个特定的客户端框架，或标准化不同的框架。客户端框架包含但不限于React，Knockout，Angular，Handlebars和JQuery等。标准化一个框架是有优势的，可以让开发者构建重用性更高的代码并在他们构建和维护解决方案的过程中保持一致性。另一方面，允许多框架是有好处的，因为每一种客户端框架都有它的优点、缺点和用例。但是，这同样也会碎片化你的企业解决方案，更不用说会增加页面的加载时间了，因为每一种框架都需要加载很多额外的类库。
拆箱即用，SharePoint Framework Yeoman生成器拥有两个客户端框架模版：React和Knockout。随着时间的推移，社区会添加更多的生成器或子生成器来使用其他的客户端框架。选择React作为你偏爱的客户端框架是有优势的，因为微软创建了React版本的Office UI Fabric，因此你可以轻易做出Office和Office 365体验的界面。
要计划的第四件事情是如何、在何处部署你的解决方案组件，也就是存储你生成的脚本和资产的CDN存储位置。在工具链中的Gulp任务所支持的拆箱即用的存储有Azure Blob和Azure CDN。如果你有Azure订阅的话那是最好了，也可以跨多个租户分享你的资产。另一种常见的场景是使用SharePoint Online，也有CDN的功能。但是这需要你修改工具链，有选择地创建自定义Gulp任务来管理。
最后，开发者需要去思考应用程序周期管理（ALM）。你管理源代码和版本、自动编译、测试和部署等的方式。大部分常见的源代码版本管理系统都可以使用，如Git、Github或Visual Studio Team Systems。对于持续集成是没有默认的工具的，你可以使用你喜欢的支持node.js的工具，如VSTS、Travis CI或Jenkins。使用这些工具你可以自动化编译和测试过程甚至自动部署到CDN路径。