根据最佳实践,出于安全原因,我的开发团队不会将应用程序配置文件存储在仓库中(我们使用config/application.yml
文件来存储配置)。但是,当我们实际开发和部署时,这会导致一些问题:
开发人员需要根据运行应用程序的环境添加不同的新外部URL。由于repo中没有配置文件,因此无法更新在另一个开发人员时同步的单个文件拉代码。为了实现这一点,他更新了他的本地config/application.yml
文件,然后每个其他开发人员更新他们的本地文件,然后我们必须将新的ENV变量添加到服务器的config/application.yml
。必须是一个更好的解决方案。
如果我们将config/application.yml
文件存储在repo中并在每个人和服务器之间共享它,这就解决了共享/更新全局配置的问题,但它开启了开发人员可能意外发生的可能性在生产模式下启动本地应用程序,并通过测试电子邮件触摸实时数据或垃圾邮件真实用户(已经发生了这就是为什么这是一个问题)。
是否有解决这些类型问题的标准最佳做法?看来我要么牺牲生产力来保障安全,又不能真正兼得。
我一直在考虑在repo中创建一个所有开发人员共享的config/development.yml
文件,它存储除生产之外的所有环境。这样他们就可以共享config / ENV项目以进行开发并进行同步。但在生产中,我会有一个config/production.yml
文件只能存在于服务器上。
如果应用程序在生产环境以外的任何地方启动,则会加载development.yml
文件。如果它在生产中启动,则会加载production.yml
文件。但由于production.yml
文件不存在于repo中(仅在服务器上),因此开发人员不可能意外触摸实时数据或垃圾邮件真实用户等...
有没有专业开发人员试过这样的计划?我做了很多谷歌搜索,但确实没有找到满意的解决方案。
答案 0 :(得分:1)
查看RailsConfig宝石。这样你就可以完全按照自己的意思行事,但是可以轻松获得宝石。这也允许您和您的开发团队拥有覆盖设置的本地yaml文件。
config/settings.yml
config/settings/#{environment}.yml
config/environments/#{environment}.yml
config/settings.local.yml
config/settings/#{environment}.local.yml
config/environments/#{environment}.local.yml
然后您的config/settings/production.yml
中只有.gitignore
,以便不会将其检入源代码管理中。