手动部署 Meter 应用程序 VS mup答案

【问题标题】：Deploying meter app manually VS mup手动部署 Meter 应用程序 VS mup
【发布时间】：2016-08-18 01:47:19
【问题描述】：

谁能帮我了解meteor app的部署流程？

我使用 Meter 很长时间了，一旦我开始在我想用来托管应用程序的同一台机器 (VPS) 上从头开始开发流星应用程序。我还在本地构建了另一个应用程序，并在完成后将整个应用程序复制/粘贴到另一台机器上进行托管。

这两种方式都按预期工作。

有人可以解释一下 MUP 的需求是什么吗？和类似的东西上传。还有捆绑文件，它是做什么用的？它不只是您应用程序的“zip”文件吗？我的意思是如果我只是手动压缩它（例如用rar），结果会不一样？？

而且我认为自己为流星应用程序设置服务器很简单。

提前谢谢你。

【问题讨论】：

标签： javascript meteor deploying

【解决方案1】：

是的，您只需调用源文件夹中的meteor CLI 即可运行meteor，但实际上构建和部署有几件事情要做。

首先，在“开发模式”下运行会导致代码不断寻找要重新部署的代码中的更改。这会占用资源......当部署在 AWS 或其他云服务之类的东西上时，这些资源会花费真金白银，更不用说它会占用资源来完成实际工作。

最重要的是，构建正在优化代码、运行最小化程序、转译器等。这是在开发模式下运行时实时完成的，这又会占用资源。

最后，开发模式运行一个内部 MongoDB，与完整的 MongoDB 安装相反。据我所知，完整安装将优于“嵌入式”版本，而且它允许您在单独的服务器上运行它，这再次释放了资源。

抛开性能不谈，自动构建和部署优于手动复制/粘贴。任何时候人类必须手动设置某些东西，它一定会在某个时候失败。从长远来看，我们不擅长重复性任务。在我作为专业开发人员的 17 岁以上的时间里，我参与了许多安装，包括生产和非生产。我可以告诉你，自动化安装随着时间的推移而失败的可能性比肉类安装（需要一个人实际执行的安装）更不可能。我们往往不会一遍又一遍地执行相同的步骤，因此每次都不同。

在我个人的 Meteor 开发中，我什至已经开始使用自动化的持续集成服务器来完成我的所有部署，包括 Dev 和 Prod。我设置了一次脚本，将我的 CI 服务器指向我的存储库，并监视它的更改。当我更新代码并推送到我的 GIT 存储库时……砰！ CI服务器接管，拉下新代码，构建它，测试它，如果一切看起来都不错，就部署它。 MUP 在使该过程自动化方面发挥了重要作用，因为它处理了很多繁重的工作。如果在构建或部署中出现任何问题，我会收到一封电子邮件通知，然后只需仔细阅读日志以查看发生了什么。我使用通过 Docker 映像部署的最新实验性 MUP 构建，这很好，因为现在我可以随时轻松地将服务器添加到我的集群中。

而且由于我已经弄清楚如何通过 MUP 和 Jenkins（我的 CI 服务器）自动化一个项目，所以它主要是复制/粘贴和更新我的其他项目的一些配置。

【讨论】：

我忘了说：MUP 和 MUPX 不是您可以用来自动化部署的唯一工具，顺便说一句。它们是最容易为 Meteor 设置的，恕我直言，因为它们“知道”流星。其他需要考虑的有 Grunt、Gulp，甚至 Webpack 等等。 Grunt 和 Gulp 更像是脚本工具，而对我来说，Webpack 更像 Meteor 自己的安装/构建 api，因为它试图将东西打包，而不是简单地运行各种脚本。
感谢您的回答。您能否提供一些关于如何实现“CI 服务器接管、拉下新代码、构建它”的说明或链接，我的意思是如何设置 CI 服务器以更新应用程序。这实际上是我避免“构建”命令的原因之一。在所有内容都被缩小后，我不知道如何对应用程序进行更改。
嗯，我使用 Jenkins，但那里有很多 CI 服务器应用程序。在我的例子中，我设置了一个轮询触发器来监视我的 GIT 存储库的特定分支，然后我使用一个简单的 SSH 构建步骤调用 MUP 来执行构建。我有 2 个 MUP 设置文件，一个用于开发，一个用于生产。我还有一个运行 Sonar 进行自动代码审查的构建步骤。所有这些在网上都有很好的记录，整本书都已经写好了。如果您打算进行咨询，我强烈建议您采用这样的全自动流程。