你应该如何从源代码控制构建你的数据库?

问题描述

在 SO 社区 wiki 上有一些关于是否应该对数据库对象进行版本控制的讨论.但是，我还没有看到太多关于为数据库对象创建构建自动化过程的最佳实践的讨论.

There has been some discussion on the SO community wiki about whether database objects should be version controlled. However, I haven't seen much discussion about the best-practices for creating a build-automation process for database objects.

这对我的团队来说一直是一个有争议的讨论点 - 特别是因为在评估数据库部署自动化方法的好处和风险时，开发人员和 DBA 通常有不同的目标、方法和关注点.

This has been a contentious point of discussion for my team - particularly since developers and DBAs often have different goals, approaches, and concerns when evaluating the benefits and risks of an automation approach to database deployment.

我想听听 SO 社区关于哪些实践在现实世界中有效的想法.

我意识到哪种做法​​真的最好是有点主观的，但我认为关于哪些工作可以对许多人有帮助的良好对话.

I realize that it is somewhat subjective which practices are really best, but I think a good dialog about what work could be helpful to many folks.

以下是我关于该主题关注领域的一些预告问题.这些并不意味着是一个明确的列表 - 而是人们帮助理解我在寻找什么的起点.

1. 测试和生产环境都应该从源代码管理中构建吗?
   
   • 两者都应该使用自动化来构建 - 还是应该通过从稳定的最终测试环境中复制对象来构建生产?
   • 您如何处理部署脚本中测试环境和生产环境之间的潜在差异?
   • 您如何测试部署脚本是否能像在测试中一样有效地用于生产?

• 只是代码(过程、包、触发器、java 等)?
• 索引?
• 限制?
• 表格定义?
• 表更改脚本?(例如，ALTER 脚本)
• 一切?

• 序列?
• 赠款?
• 用户帐户?

• 您如何处理转换脚本或 ALTER 脚本等一次性问题?
• 您如何处理从数据库中淘汰的对象?
• 谁应该负责提升对象从开发到测试级别?
• 您如何协调多个开发者的变更?
• 您如何处理多个系统使用的数据库对象的分支?

• How do you deal with one-time things like conversion scripts or ALTER scripts?
• How do you deal with retiring objects from the database?
• Who should be responsible for promoting objects from development to test level?
• How do you coordinate changes from multiple developers?
• How do you deal with branching for database objects used by multiple systems?

• 安全问题?
• 具有去标识化问题的数据?
• 无法完全自动化的脚本?

• 开发人员错误?
• 到意想不到的环境问题?
• 用于灾难恢复?

• 轶事证据?
• 行业研究?
• 行业最佳实践建议?
• 向公认的当局上诉?
• 成本/收益分析?

• 开发人员?
• DBA?
• 数据分析师?
• 不止一个?

推荐答案

以下是您问题的一些答案:

1. 测试和生产环境都应该从源代码管理中构建吗?是
   • 两者都应该使用自动化来构建 - 还是应该通过从稳定的最终测试环境中复制对象来构建生产?
   • 两者的自动化.不要在环境之间复制数据
   • 您如何处理部署脚本中测试环境和生产环境之间的潜在差异?
   • 使用模板，以便您实际上可以为每个环境生成不同的脚本集(例如，对外部系统的引用、链接的数据库等)
   • 您如何测试部署脚本是否能像在测试中一样有效地用于生产?
   • 您在预生产环境中测试它们:在生产环境(数据库和可能的其他系统)的精确副本上测试部署

• 只是代码(过程、包、触发器、java 等)?
• 索引?
• 限制?
• 表格定义?
• 表更改脚本?(例如，ALTER 脚本)
• 一切?
• 一切，以及:
  • 不要忘记静态数据(查找列表等)，因此您无需在环境之间复制任何数据
  • 仅保留当前版本的数据库脚本(当然是受版本控制的)，并且
  • 存储 ALTER 脚本:1 个 BIG 脚本(或名为 like 001_AlterXXX.sql 的脚本目录，以便按自然排序顺序运行它们将从版本 A 升级到 B)
  • 序列?
  • 赠款?
  • 用户帐户?
  • 参见 2.如果您的用户/角色(或技术用户名)在不同环境中不同，您仍然可以使用模板编写它们的脚本(参见 1.)
  • 您如何处理转换脚本或 ALTER 脚本等一次性问题?
  • 见 2.
  • 您如何处理从数据库中淘汰的对象?
  • 从数据库中删除，从源代码管理主干/提示中删除
  • 谁应该负责将对象从开发级别提升到测试级别?
  • 开发/测试/发布时间表
  • 您如何协调多个开发者的变更?
  • 尽量不要为每个开发人员创建一个单独的数据库.你使用源代码控制，对吗?在这种情况下，开发人员更改数据库并签入脚本.为了完全安全，请在每晚构建期间从脚本重新创建数据库
  • 您如何处理多个系统使用的数据库对象的分支?
  • 难点:不惜一切代价尽量避免.
  • 安全问题?
  • 不要为测试/生产存储密码.您可以允许它用于开发，特别是如果您每天/每晚自动重建数据库
  • 具有去标识化问题的数据?
  • 无法完全自动化的脚本?
  • 记录并存储发布信息/ALTER 脚本
  • 开发人员错误?
  • 每天从头开始构建测试，并将结果与​​增量升级(使用 ALTER 从版本 A 到 B)进行比较.比较结果模式和静态数据
  • 到意想不到的环境问题?
  • 使用版本控制和备份
  • 将 PROD 数据库架构与您认为的进行比较，尤其是在部署之前.SuperDuperCool DBA 可能修复了您的工单系统中从未出现过的错误 :)
  • 用于灾难恢复?
  • 轶事证据?
  • 行业研究?
  • 行业最佳实践建议?
  • 向公认的当局上诉?
  • 成本/收益分析?
  • 如果开发人员和 DBA 同意，我认为您不需要说服任何人(除非您需要钱来购买像 dbGhost 用于 MSSQL)
  • 开发人员?
  • DBA?
  • 数据分析师?
  • 不止一个?
  • 通常 DBA 会批准模型(在签入之前或作为代码审查的一部分之后).他们绝对拥有与性能相关的对象.但总的来说，团队拥有它[当然还有雇主:)]

  这篇关于你应该如何从源代码控制构建你的数据库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！