让我们的CI服务器自动运行rails迁移并提交schema.rb是一个好主意吗?

时间:2014-10-25 00:04:00

标签: ruby-on-rails database commit rails-migrations schema.rb

在我的公司,我们看到字段出现/消失,出现错误表格以及我们的schema.rb文件中存在冲突的间歇性问题。这些问题一直在发生,浪费我们的时间。

我很难说服我的同事,只需使用标准工作流程即可解决我们的迁移/ schema.rb问题。

首先,事实:

  • 我们在源代码管理下schema.rb
  • 我们知道schema.rb应该是我们数据库的真实来源
  • 我们在生产/ QA和Postgresql中使用SqlServer进行开发/测试
  • 这意味着我们实际上有两个schema.rb个文件:一个用于SqlServer,另一个用于Postgresql。
  • 我们当前的schema.rb文件与我们的生产数据库不同步,因为我们允许开发人员通过本地更改来污染它。

我相信(大部分)我们的迁移/ schema.rb问题将通过遵循以下简单规则来解决:

  

在运行迁移之前,请始终将架构加载到新创建的数据库中:

     

rake db:drop db:create db:schema:load db:migrate

     

然后,请仔细检查您的更改,以确保只将迁移中的更改提交给schema.rb

我的同事认为最好不允许开发人员更改schema.rb,而是在我们的Jenkins服务器上执行一项任务,该任务将运行迁移并自动将更改提交到schema.rb。他说我们应该从我们的流程中删除人为因素并使工作自动化,这不会让问题在未来发生。

虽然我相信自动化工作,但我不相信这是最好的解决方案,因为它只针对症状,而不是原因。自动化git提交让我感到紧张,因为很多事情都可能出错。更重要的是,将迁移及其相应的schema.rb更改分离对我来说似乎是一个非常糟糕的想法。我们不应该继续让开发人员忽视污染schema.rb的负面影响。我们应该教他们一个更好的工作流程,避免污染schema.rb,并在将来发生问题时为他们提供调试问题的知识。

人们可以权衡并推荐我们的哪种解决方案更好吗?还是我们还没有想到的更好的解决方案?

0 个答案:

没有答案