node.js - 在部署之前还是之后构建 Web 应用程序？

Question

上下文

• Web 应用程序项目有一个 /build(或 /dist)文件夹，其中包含构建期间生成的前端文件(由 Gulp )。此文件夹不在源代码管理之下(例如: React.js Starter Kit )
• 服务器端代码不需要捆绑或编译步骤，因此可以按原样部署项目中的 /src 文件夹(这些源文件用于运行 Node.js 或ASP.NET vNext 服务器)
• Web 应用程序通过 Git 部署(请参阅 Heroku 或 Windows Azure 中基于 Git 的部署选项作为示例)

问题

1. 在部署之前还是之后构建(捆绑和缩小)前端文件哪个更好？
   • 如果是以前，您最终可能会拥有一个单独的存储库(或分支)，其中 /build 文件夹与其余项目文件一起位于源代码管理之下。此存储库仅用于部署目的。
   • 如果之后，部署时间可能会增加 - 下载构建过程中使用的其他 npm 模块所需的时间，服务器的 CPU 可能会在构建过程中飙升至 100%，从而可能会损害网络应用的响应能力。
2. 在运行 KuduSync 命令之前还是之后在远程服务器上构建前端文件哪个更好？
3. 如果您使用 Kudu 将 Web 应用程序部署到 Windows Azure ，部署脚本是否应该仅将 /build 文件夹的内容(包含 .js、.html、.css 等公共(public)前端文件)复制到 /wwwroot ？与默认情况下复制所有项目文件(服务器端源代码和前端包)相反。
4. 默认情况下，Azure 的部署脚本会将所有项目文件从 D:\home\site\repository 文件夹复制到 D:\home\site\wwwroot 文件夹，并且然后 Node.js 应用程序从那里启动。这是必要的步骤吗？为什么不从 D:\home\site\repository 文件夹启动 Node.js(或 ASP.NET vNext)应用程序？如果确实应该将其复制到单独的文件夹，为什么源文件放置在 wwwroot 中，也许最好将它们复制到 wwwroot 之外的另一个文件夹？

Answer 1

我对 Azure 和 Heroku 都不熟悉，因此无法给出有关这些特定部署选项的任何想法。

我正在使用(4 个专用服务器，其中 2 个仅用于提供静态文件)，构建捆绑和缩小的 javascript 文件(用于前端)并将所有这些文件添加到主存储库的选项有几个优点

• 您只需运行一次(在您的开发计算机上或在临时服务器上，无论您想要什么方式)。当您必须运行多个静态服务器时，这特别有用，因为您不必在每个服务器上运行构建命令。有人可能会争辩说，他们可以使用 Glusterfs 之类的东西将文件从一台静态服务器同步到所有其他服务器，并且构建过程只需运行一次。然而，当涉及到这种设置时，情况就完全不同了
• 它使您的部署过程变得简单，只需提取新代码并在必要时重新启动服务器(假设您有某种机制来增加静态文件版本，以便所有客户端都将收到最新版本)
• 避免对生产服务器不必要的依赖。对于某些人来说这可能听起来很奇怪，但我只是不想在我的生产服务器上安装任何额外的库，除非它们是绝对必要的。由于构建过程在我的开发计算机上本地运行，我的生产服务器仅具有运行生产代码所需的内容，而没有其他内容

但是这种方法也有一些缺点:

• 当您团队中的多个开发人员(意外地)运行构建过程并提交代码时，您将看到一系列疯狂的冲突。但是，在合并其他人的所有更改后，只需再次运行构建过程即可解决此问题。这是有关工作流程的更多信息
• 您的存储库将会更大。考虑到我的捆绑和缩小文件的额外 MB 数，我个人认为这不是一个大问题。如果你的前端 JavaScript 足够大，这会成为一个问题，那么那就是另一个故事了