5

语境

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

1 回答 1

-1

我对 Azure 和 Heroku 都不熟悉，所以我无法就这些特定的部署选项提供任何想法。

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

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

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

  • 当您的团队中有多个开发人员（意外地）运行构建过程并提交代码时，您将有一个疯狂的冲突列表。但是，它可以通过在合并其他人的所有更改后再次运行构建过程来解决。这更多的是关于工作流程
  • 您的存储库会更大。考虑到我的捆绑和缩小文件的额外 MB 数，我个人认为这不是一个大问题。如果您的前端 javascript 足够大，足以成为一个问题，那就是另一回事了
于 2015-03-29T19:17:25.470 回答