在部署之前或之后构建 Web 应用程序？

Question

上下文

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

问题

1. 在部署之前还是之后构建（捆绑和缩小）前端文件更好？
   • 如果之前，您最终可能会拥有一个单独的存储库（或分支），在源代码控制下的 /build 文件夹以及其余项目文件。此 repo 仅用于部署目的。
   • 如果之后，部署时间可能会增加 - 下载构建过程中使用的其他 npm 模块所需的时间，服务器的 CPU 可能会在构建过程中飙升至 100%，可能会损害您的 Web 应用程序的响应能力。
2. 在运行 KuduSync 命令之前还是之后在远程服务器上构建前端文件更好？
3. 如果使用 Kudu 将 Web 应用程序部署到 Windows Azure，部署脚本是否应该仅将 /build 文件夹的内容（带有公共的前端文件，如 .js、.html、.css）复制到/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 足够大，足以成为一个问题，那就是另一回事了