是的。代码就是代码。我的经验法则是，我需要能够从头构建和部署应用程序，而不需要查看开发或生产机器。

数据库本身?没有

创建它们的脚本，包括静态数据插入、存储过程等;当然可以。它们是文本文件，它们包含在项目中，像其他东西一样签入和签出。

当然，在理想情况下，您的数据库管理工具可以做到这一点;但你必须遵守纪律。

The most successful scheme I've ever used on a project has combined backups and differential SQL files. Basically we would take a backup of our db after every release and do an SQL dump so that we could create a blank schema from scratch if we needed to as well. Then anytime you needed to make a change to the DB you would add an alter scrip to the sql directory under version control. We would always prefix a sequence number or date to the file name so the first change would be something like 01_add_created_on_column.sql, and the next script would be 02_added_customers_index. Our CI machine would check for these and run them sequentially on a fresh copy of the db that had been restored from the backup.

我们还准备了一些脚本，开发人员可以用一个命令将本地db重新初始化到当前版本。

是的，我们的源代码控制我们的sql脚本也与subversion。这是一个很好的实践，您可以在需要时使用默认数据重新创建模式。

我已经在http://dbdeploy.com/上使用了ThoughtWorks的dbdeploy工具。它鼓励使用迁移脚本。在每个版本中，我们将更改脚本合并到一个文件中，以简化理解，并允许dba“支持”更改。

我使用SchemaBank来版本控制我所有的数据库模式更改:

从第一天开始，我将我的db模式转储导入其中 我开始用网络浏览器改变我的模式设计(因为它们是基于SaaS /云的) 当我想更新我的db服务器时，我从它生成更改(SQL)脚本并应用到db。在Schemabank中，它们要求我在生成更新脚本之前将工作提交为版本。我喜欢这种练习，这样当我需要的时候，我就可以随时追溯。

我们的团队规则是，在没有存储设计工作之前，永远不要直接接触db服务器。但它发生了，有人可能会被诱惑打破规则，为了方便。我们将再次将模式转储导入到模式银行中，并让它执行diff，如果发现不一致，则对某人进行攻击。虽然我们可以从它生成alter脚本，使我们的db和模式设计同步，但我们讨厌这样做。

顺便说一下，它们还允许我们在版本控制树中创建分支，这样我就可以维护一个用于登台，一个用于生产。还有一个用于编码沙盒。

一个非常整洁的基于web的模式设计工具，带有版本控制和变更管理。