GIT 部署 +配置文件 +赫罗库
我使用 Heroku 托管 Rails 应用程序,这意味着使用 Git 部署到 Heroku。由于 Heroku 上的“纯 Git 工作流程”,任何需要上游到服务器的内容都必须在我的本地机器上进行相同的配置。
但是,我需要使某些配置文件有所不同,具体取决于我是在本地设置中还是部署在 Heroku 上。同样,由于 Heroku 使用的部署方法,我无法使用 .gitignore 和模板(正如我多次看到的建议,并在其他项目中使用过)。
我需要的是 git 以某种方式跟踪文件上的更改,但有选择地告诉 git 在从特定存储库中提取时不要覆盖某些文件 - 基本上只是单向进行某些更改。
这可以做到吗?我将不胜感激任何建议!
I'm using Heroku to host a Rails app, which means using Git to deploy to Heroku. Because of the "pure Git workflow" on Heroku, anything that needs to go upstream to the server has to be configured identically on my local box.
However I need to have certain configuration files be different depending on whether I'm in the local setup or deployed on Heroku. Again, because of the deployment method Heroku uses I can't use .gitignore and a template (as I have seen suggested many times, and have used in other projects).
What I need is for git to somehow track changes on a file, but selectively tell git not to override certain files when pulling from a particular repo -- basically to make certain changes one-way only.
Can this be done? I'd appreciate any suggestions!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可以将配置变量持久存储在每个 heroku 应用程序的本地设置中,这样它们就不必出现在您的代码中!因此相同的代码可以在多个 heroku 站点上运行,但具有不同的配置。它非常简单、容易、优雅......
这就是我们使用的方法。 (我们用它来做同样的事情……我们在 Heroku 上有同一个应用程序的多个克隆,但我们只想要 github 上的一个源代码,在我们的开发本地目录中,我们将 PUSH 到 ORIGIN (github),然后当我们有按照我们喜欢的方式,我们 CD 到 prod 本地目录,该目录转到相同的 github 存储库,并且我们仅从 GITHUB 拉入此目录,从不推送(例如,所有推送到 github 的都来自从我们的 dev 目录来看,prod 目录只是其他 heroku 应用程序的暂存区域。)
通过在不同的 HEROKU 站点上使用不同的配置(如下所述),完全相同的相同代码 适用于两个 heroku 站点。
所以我们的工作流程是:(关键是两个目录都指向相同的 github 存储库)
。
现在就是如何保持站点特定的配置变量打开 heroku 站点:
http://docs.heroku.com/config-vars
在本地命令行上,对于每个您的两个本地目录,请执行以下操作:
查看您定义的目录:
然后 cd 到您的其他目录 myPRODdir 并执行相同的操作,仅将相同的远程 heroku 变量设置为 fooheroku2 和 barheroku2。
然后在您的 Rails 应用程序中,您可以像这样简单地引用它们:
一个应用程序将读取“fooheroku1”,另一个应用程序将读取“fooheroku2”
最后,在您以 DEV 模式运行的本地目录 myDEVdir 上,将相同的配置命令放入您的 config/environment/development.rb 文件中您的“dev”版本的配置变量将被设置为应有的样子:
简单、优雅。谢谢,赫罗库!
You can have config vars persistently stored ON each heroku app's local setup so they do not have to be in your code at all! so the same code can run on multiple heroku sites but with different configuration. It very simple, easy, elegant...
It's the approach we used. (We used it for the SAME thing... we have multiple clones of the SAME app at Heroku, but we want only ONE source at github, in our dev local directory we do the PUSH to ORIGIN (github), then when we have it the way we like it, we CD to the prod local directory, which goes to the SAME github repository, and we ONLY PULL from GITHUB into this directory, never push (eg, all pushes to github come from our dev directory, the prod directory is just a staging area for the other heroku app.)
By having the different configs ON the different HEROKU sites (as explained below), the EXACT SAME CODE works on BOTH heroku sites.
So our workflow is: (the key is that BOTH directories point to SAME github repo)
that's it!
Now here's how you keep your site-specific config vars ON the heroku site:
http://docs.heroku.com/config-vars
on your local command line, for EACH of your two local directories, do:
to see the ones you have defined:
then cd to your other directory myPRODdir and do the SAME thing, only set the same remote heroku vars to fooheroku2 and barheroku2.
then in your rails app you simple refer to them like so:
One app will read 'fooheroku1' the other app will read 'fooheroku2'
And finally, on your LOCAL directory myDEVdir, where you run in DEV mode, put the same config commands in your
config/environment/development.rb
file your 'dev' version of the config vars will be set to whatever they should be:Easy, elegant. Thanks, Heroku!
以下是一些解决方案:
1)如果您只想忽略heroku上的文件,请使用 slugignore
2) 如果您的更改较小,请保持 DRY 并使用通用配置文件,为特定于服务器的行为插入开关
3) 如果您的更改较大,请编写一个配置文件并 将“涂抹文件”添加到每个附加服务器的配置/初始化程序中。基本上,您将使用 (2) 中的技术获得单独的文件。
4) 如果您的更改是彻底的(不太可能),则为每个服务器维护单独的分支。
5) 此脚本可以完全按照您的要求执行,但可能有点过头了。
我希望这有帮助。
Here are a few solutions:
1) If you want to ignore files only on heroku, use slugignore
2) If your changes are minor, stay DRY and use universal config files, inserting switches for server-specific behavior
3) If your changes are major, write one config file and add a "smudge file" to config/initializers for each additional server. Basically, you would have separate files using the technique in (2).
4) If your changes are SWEEPING (unlikely), then maintain separate branches for each server.
5) This script can do exactly what you requested, but may be overkill.
I hope that helped.