经过漫长而艰难的一个月尝试不同的事情,每次我意识到都会被咬,
仅仅因为 Heroku 使用 git 存储库作为部署机制,你不应该将其视为 git 存储库
也可以是 rsync,他们选择了 git,不要因此而分心
如果你这样做,你就会对各种伤害敞开心扉。所有上述解决方案都在某处惨遭失败:
- 它需要每次或定期执行某些操作,或发生意外事件(推送子模块、同步子树……)
- 如果你使用引擎来模块化你的代码,Bundler 会把你活活吃掉,无法描述我在寻找一个好的解决方案的过程中对该项目的挫败感
- 您尝试将引擎添加为 git repo 链接 +
bundle deploy - 失败,您需要每次都捆绑更新
- 您尝试将引擎添加为
:path + bundle deploy - 失败,开发团队将 :path 选项视为“您没有使用带有此 gem 选项的 Bundler”,因此它不会捆绑用于生产
- 此外,引擎的每次刷新都希望更新您的 Rails 堆栈 -_-
- 我找到的唯一解决方案是在开发中使用引擎作为
/vendor 符号链接,并实际复制文件以用于生产
解决方案
有问题的应用在 git root 中有 4 个项目:
- api - 根据配置文件将在 2 个不同的 heroku 主机上运行 - 上传和 api
- 网络 - 网站
- web-old - 旧网站,仍在迁移中
- common - 在引擎中提取的通用组件
所有项目都有一个vendor/common 符号链接,指向common 引擎的根。在编译源代码以部署到 heroku 时,我们需要删除符号链接并将其代码同步到物理上位于每个单独主机的供应商文件夹中。
- 接受主机名列表作为参数
- 在您的开发存储库中运行 git push,然后在单独的文件夹中运行干净的 git pull,确保不会自动将脏(未提交的)更改推送到主机
- 并行部署主机 - 提取每个 heroku git repo,将新代码同步到正确的位置,在 git commit 注释中提交基本推送信息,
- 最后,我们发送一个带有 curl 的 ping 来告诉爱好主机醒来并跟踪日志以查看是否一切正常
- 与 jenkins 也很好玩 :D(成功测试后自动将代码推送到测试服务器)
现在 6 个月在野外工作得非常好,问题很少(不是?)
这是脚本https://gist.github.com/bbozo/fafa2bbbf8c7b12d923f
更新 1
@AdamBuczynski,从未如此简单。
首先,您至少将始终拥有一个生产和测试环境 - 更糟糕的是一堆特定于功能的集群 - 突然 1 个文件夹需要映射到 n 个 heroku 项目,这是一个非常基本的要求,而且这一切都需要组织起来不知何故,脚本“知道”你想在哪里部署什么源,
第二个你会想要在项目之间共享代码 - 现在是sync_common 部分,开发中的符号链接的恶作剧被 Heroku 上的实际 rsynced 代码取代,因为 Heroku 需要一定的文件夹结构和捆绑器和 rubygems 真的真的真的如果您想将公共线程提取到 gem 中,事情会非常糟糕
第三,你会想要插入 CI,它会稍微改变子文件夹和 git repo 的组织方式,最后在最简单的用例中你最终会得到上述要点。
在我需要插入 Java 构建的其他项目中,当向多个客户销售软件时,您需要根据安装要求等过滤安装的模块,
我真的应该考虑探索将东西捆绑到 Rakefile 或其他东西中,然后以这种方式做所有事情......