And*_*c ॐ 10 cloud deployment database-management dev-to-production scalr
很长一段时间以来,我们已将数据保存在项目的存储库中.我们只是将所有内容保存在data/sql下,每个表都有自己的create_tablename.sql和data_tablename.sql文件.
我们现在刚刚将第二个项目部署到Scalr上,我们意识到它有点乱.
我们的部署方式:
我们有一个"packageup"脚本集合,将项目拆分为3个档案(数据,代码,静态文件),然后我们将其存储在S3上的3个独立存储桶中.
每当角色启动时,它会下载其中一个文件(取决于角色:data,nfs或web),然后"unpackage"脚本为每个角色设置所有内容,将数据加载到mysql,设置nfs等等.
我们这样做是因为我们不想保存服务器映像,我们总是从vanilla实例开始,我们使用各种内部构建的脚本从头开始安装所有内容.启动时间不是问题(我们在9分钟内准备好使用农场).
问题是,每当我们尝试设置新的开发构建时,尝试找到正确版本的数据库是一件痛苦的事情(在任何时候,我们都有大约4个开发版本用于项目).此外,一旦我们投入生产,git就会开始窒息,因为sql文件最终总计大约500mb.
问题是:
其他人如何管理数据库？我一直在寻找能够轻松地将数据从生产中转移到开发中,并将数据从开发人员迁移到生产中的东西,但是没有发现任何事情.
您应该认真查看 dbdeploy (dbdeploy.com)。它被移植到多种语言，主要是 Java 和 PHP。它集成在 Ant 和 Phing 等构建工具中，并允许轻松共享所谓的增量文件。
增量文件始终包含部署部分，但也可以包含撤消部分。当您提交增量文件并且另一位开发人员检查它时，他只需运行 dbdeploy 即可，所有新更改都会自动应用到他的数据库。
我在我的开源博客中使用 dbdeploy，因此您可以查看增量文件的组织方式： http: //site.svn.dasprids.de/trunk/sql/deltas/
| 归档时间： |
|
| 查看次数： |
363 次 |
| 最近记录： |