Webpack绝对不是VS2015和VSTS的一流公民。在我的情况下,为了使webpack适用于CI/CD,我必须进行优化,这真的让我头疼,特别是因为webpack被匆忙引入以解决大型单体SPA(ASP.NET 4.6,Kendo,15,000个文件,2000个文件夹)的可怕性能问题。简而言之,在尝试了许多场景后,为了确保新构建的捆绑包最终出现在IIS和Azure Web应用程序中,我进行了两次构建。 VSTS任务序列如下:npm install global,npm install local,npm webpack install local,npm webpack install global,build pass 1,webpack,build pass 2等...这适用于托管和私有代理,只要您提供webpack的正确路径,因为webpack在主机和私有代理中安装在不同的位置(没有找到选择webpack安装位置以实现一致性的方法)。在开始构建之前,我会清除所有内容。还需要在VS2015解决方案中执行以下操作:(1)卸载“built”文件夹,(2)在项目文件中添加Content Include =“Built \ StarStar”。“built”文件夹包含捆绑包,应该显示为灰色,否则会有更多的坏惊喜和不稳定性要处理...
VSTS BUILD 中的 Build-Pass #2 任务允许收集由 Build-Pass #1 生成的新包,并自动将它们包含在要发布的包中。
如果没有第二个构建步骤,收集包并将它们合并到 zip 包中是一场噩梦,特别是当您需要解压然后重新压缩 15,000 个文件时(每个文件需要 300 毫秒!!)。我没有找到可以在 VSTS 中方便使用的文件合并功能。
我正在关注是否有人提出更有效的 webpack CI/CD 方案。与此同时,我的两次构建解决方法运行良好,但确实很慢。
我预计 ASP.NET Core、Angular 2 和 webpack 的进步将会优雅地解决这个问题。