Node.js部署，在使用Jenkins和Chef的企业环境中使用什么方法？
让我先解释一下上下文。
上下文
目前我们正在使用Jenkins服务器，并使用Chef Server来进行configurationpipe理。 我们正朝着更持续的部署环境迈进，这是我一直在努力的工作stream程：
- 代码被GIT检入
- Gitlab触发Jenkins运行一个新的版本
- jenkins拉最新的代码，并运行npm安装
- Jenkins使用FPM创build一个RPM
- RPM被上传到RPM存储库
- Jenkins将应用程序的git存储库中的厨师部署食谱上传到Chef Server。
- Jenkins通过运行厨师客户端触发应用程序的新部署。
- 新的RPM由部署食谱安装。
在（手动触发）升级到舞台和生产环境中，我没有可用的互联网连接。 RPM克服了这个问题。 食谱是使用Berkshelf开发的。
以这种方式部署的Node.js应用程序有时使用编译的本地库（一个项目有3个以上的依赖项编译本机代码）。
我对这些types的部署过程知之甚less，但我听说的一个缺点是，只有在编译环境（当前是Jenkins本身）应该与部署环境具有相同的体系结构时，才使用RPM并编译它。 通过使用RPM的奖金是神器保持完全相同的所有环境，它不需要重新编译，并没有从各地拉动成百上千的依赖。
尽pipe如此，工作stream程似乎有点复杂，不得不坚持相同的架构，我觉得不太灵活。
对于我们的用例，我们需要以下内容：
- 快速部署在云上（可能是亚马逊）
- 快速部署在我们自己的基础设施上（目前没有互联网连接，但如果有充分的理由，可能允许某些访问）
- 应用程序更新尽pipe不太常见，但应该可以轻松自动部署; 应该可以连续部署
- 他们正在开发的软件体系结构是一个微服务体系结构，我希望在各种服务器上部署几十个Node.js应用程序（为简单起见，可能在同一服务器上进行多个部署）。
对于我自己的项目，我大部分时间都在使用Heroku，不需要花费任何精力来设置。 上述工作stream程需要两周的时间才能创build（第一次）。
问题
pipe理这一切的努力使我不得不质疑上面的一些步骤：
- 是rsyncing和使用npm安装坏听起来，牵引所有这些依赖关系，并重新编译在每个环境？ 这真的和我想的一样不稳定吗？ （我有一个Java和PHP的背景，在PHP中没有任何编译和FTP的是在当天的规范，而在Java中，一切都整齐地打包）。
- 为什么使用RPM来说Tarbal？ （直到一个星期前，我从来没有手动build立一个RPM，我知道它的能力很less，什么也不用在这里）。
- 我一直在研究Chef中的“部署食谱”，主要安装部署目录，监控configuration，初始化脚本和（可选）nginx代理configuration。 这个部署指南的版本与部署本身相同，并在原始的git仓库代码中提供。 在厨师界我还没有find任何有关这方面的最佳做法，我曾预料它会非常普遍。 这是不是要走的路甚至是反模式？
- 在同一台服务器上部署多个微服务（不同的端口号说），这真的很糟糕？ 是否有意义？ （我简单地看了一下Docker，但是认为它会引入太多的复杂性，作为逻辑分离微服务的手段，我们仍然在努力设置这个东西）。
您可能能够分享的任何经验将不胜感激！
1）更好地发送你的应用程序的所有依赖和npm在目标机器上重build它们。 或者，如果你想去企业，你可以重build构build服务器上的模块，并打包到tarball / docker或lxc容器/ VM镜像/你的名字。 没有银弹。 我个人更喜欢普通的LXC容器。 但一般的行为是：在应用程序中绑定模块，并在目标平台上重build二进制模块。
2）对于简单的脚本应用程序，最好使用tarball甚至git clone。 不，在这种情况下，你真的不需要系统pipe理器的所有这些能力和复杂性。 但是如果你打算使用定制的nginx或者某种系统级的库或者类似的东西，你最好使用RPM或者DEB，并且为你的定制软件包设置合适的repo。
3）我没有使用Chef，但是最好将部署脚本分成独立的任何types的大型项目。 我的意思是你的部署代码不是你的应用程序的代码。 这就像在一个回购有两个单独的应用程序。 可能但不是一个好的做法。
4）很好。 缩放是可以的，因为您可以从一台物理机器开始，随着时间的推移而增长（但是，嘿，这听起来很简单，我花了很多时间让我现在的项目可以扩展）。 但是集成testing总是非常好的。 你可以产生整个环境，运行集成testing，获取结果，并在新鲜的环境中开始新的testing。