上下文
web应用程序项目具有 /build （或 /dist )包含前端文件的文件夹，在生成期间生成（通过gulp）。此文件夹不在源代码管理下（例如，请参阅：react.js starter kit）
服务器端代码不需要绑定或编译步骤，因此 /src 可以按原样部署项目中的文件夹（这些源文件用于运行node.js或asp.net vnext server）
web应用程序是通过git部署的（以heroku或WindowsAzure中基于git的部署选项为例）
问题
在部署之前还是之后构建（捆绑和缩小）前端文件更好？
如果是以前，您可能会有一个单独的存储库（或分支），其中 /build 源代码管理下的文件夹以及其他项目文件。此回购仅用于部署目的。
如果之后，部署时间可能会增加—下载生成过程中使用的其他npm模块所需的时间，则在生成过程中服务器的cpu可能会达到100%，这可能会损害web应用程序的响应性。
在运行kudusync命令之前还是之后在远程服务器上构建前端文件更好？
如果使用kudu将web应用程序部署到windowsazure，那么部署脚本是否应该只复制 /build 文件夹（带有公共前端文件，如.js、.html、.css）到 /wwwroot ? 与复制所有项目文件（服务器端源代码和前端捆绑包）不同，默认情况下会这样做。
默认情况下，azure的部署脚本从 D:\home\site\repository 文件夹到 D:\home\site\wwwroot 文件夹，然后从那里启动node.js应用程序。这是必要的步骤吗？为什么不从服务器启动node.js（或asp.net vnext）应用程序 D:\home\site\repository 文件夹？如果它确实应该被复制到一个单独的文件夹中，为什么源文件被放在 wwwroot ，也许最好把它们复制到另一个文件夹，在外面 wwwroot ?
1条答案
按热度按时间xienkqul1#
我对azure和heroku都不熟悉，所以我不能给出关于这些特定部署选项的任何想法。
我使用的是（4台专用服务器，其中2台仅用于服务静态文件），构建捆绑和缩小的javascript文件（用于前端）并将所有这些文件添加到主存储库的选项有几个优点
您只需要运行一次（无论是在您的开发机器上还是在临时服务器上，无论您想用什么方式）。这在必须运行多个静态服务器时特别有用，因为不必在每个服务器上运行build命令。有人可能会说他们可以用
Glusterfs要将文件从一个静态服务器同步到所有其他服务器，构建过程只需运行一次。然而，这是一个完全不同的故事，当谈到这种设置它使您的部署过程变得简单，只需提取新代码并在必要时重新启动服务器（假设您有某种机制来增加静态文件版本，以便您的所有客户机都将收到最新版本）
避免对生产服务器产生不必要的依赖。这对某些人来说可能听起来很奇怪，但我只是不想在我的生产服务器上安装任何额外的库，除非它们是绝对必要的。由于构建过程在我的dev机器上本地运行，我的生产服务器只拥有运行生产代码所需的内容，而没有其他内容
然而，这种方法也有一些缺点：
当您的团队中有多个开发人员（意外地）运行构建过程并提交代码时，您将有一个疯狂的冲突列表。但是，只要在合并其他人的所有更改后再次运行构建过程，就可以解决这个问题。这是关于工作流的更多信息
你的仓库会更大。我个人不认为这是一个大问题，考虑到我的捆绑和缩小文件很少额外的mb。如果您的前端javascript足够大，足以让这成为一个问题，那么就另当别论了