rails 功能十分强大, 我个人认为最好的地方是解决了process中遇到的问题。
一般的webbase 项目会遇到什么问题呢?
1. 如果team 用同一个数据库进行开发,另外一个数据库进行测试, 很有可能由于数据问题,造成开发之中出现冲突。
(以前常常听到,“谁把我造的数据清除了?!”)
2. 对于单元测试,有时候需要往数据库里面insert 一些数据, 最笨的办法就是手工在数据库造数据,而且如果测试会破坏数据的话,
在每次测试之前都要修改数据库中的数据。 这些都是重复劳动, 坚决反对.
3.在项目的开发过程中,如果有n个release, 每一个release有可能有不同的数据库版本。
通过SVN, 我们可以拿到不同时期数据库的schema, 但这是不够的。
假设你的系统release1已经在production上跑了, 这时候需要发布release2的版本,你能拿着release2的schema脚本去更新数据库吗?
当然不能,客户非杀了你不可。 因为线上的系统已经有很多真实的数据了,生产数据是不能丢的。所以我们要保存每个数据库版本之间的差异的部分。 rails提供可database版本之间的migration机制。
4.如果你想拿出程序里的一段代码,看看它的执行结果是什么,怎么办呢?
传统的方式是打日志,但如果需要修改以前的程序看结果呢?
rails 提供rails console, 可以直接输入代码,看执行结果,很方便。
5.经常会遇到系统的远程部署问题, 我还记得以前部署的过程,
连接VPN,更新数据库, 连接linux console, 敲用户名密码,ftp程序.........
say no to duplicated work!!!!
ruby rails 提供了 自动部署的机制。
6.现在越来越强调单元测试,如果要做单元测试,就要有一套mock框架来模拟依赖关系。
RSpec是很好的mock框架。 为了保存测试数据不被破坏,测试数据库要和开发数据库分开,rails提供了很好的机制。
7.另外,functional test也很重要,结合thoughtworks 的 selenium 平台, functional test 很容易实现。
针对以上的种种问题, rails 有相应的结构来处理
--root
--app #ruby 代码,包括MVC结构的内容
--module
--controller
--view
--config # rails默认提供了3种运行环境:development,test,production, 所以对应了3个数据库,由此保证了测试的数据
#不会被破坏。
--enviroment # 提供了每种环境的运行参数
--database.yml # 提供每种数据库类型、用户名密码等数据库访问配置
--db
--migrate #
-- 20080803043520_create_products.rb #migration 文件,用于把新的变化部分的数据结构发布到
#当前版本数据库。
--schema.rb # #当前版本的数据库结构
--lib
--task #自定义的rake文件可以放在这里
--public #包括静态页面和javascript、css文件
--script #启动web server, rails console, generate code
--server
--generate
--console
--test
-- fixtrures #包含了开发需要的数据(以YML数据的形式存在)
-- functional #功能测试的代码
-- integreation#集成测试的代码
-- unit #自己写的单元测试的代码
--vendor
-- plugins #第三方的代码,以插件的形式加入rails工程
以上的数据库结构脚本和YML数据可以应用到development,test,production中的任何一种数据库。
只需要运行:
rake db:reset RAILS_ENV #默认是development 环境
rake db:reset RAILS_ENV=test
rake db:reset RAILS_ENV=production
同理,load 数据库数据数据
rake test:fixtures:load RAILS_ENV=production
一般的webbase 项目会遇到什么问题呢?
1. 如果team 用同一个数据库进行开发,另外一个数据库进行测试, 很有可能由于数据问题,造成开发之中出现冲突。
(以前常常听到,“谁把我造的数据清除了?!”)
2. 对于单元测试,有时候需要往数据库里面insert 一些数据, 最笨的办法就是手工在数据库造数据,而且如果测试会破坏数据的话,
在每次测试之前都要修改数据库中的数据。 这些都是重复劳动, 坚决反对.
3.在项目的开发过程中,如果有n个release, 每一个release有可能有不同的数据库版本。
通过SVN, 我们可以拿到不同时期数据库的schema, 但这是不够的。
假设你的系统release1已经在production上跑了, 这时候需要发布release2的版本,你能拿着release2的schema脚本去更新数据库吗?
当然不能,客户非杀了你不可。 因为线上的系统已经有很多真实的数据了,生产数据是不能丢的。所以我们要保存每个数据库版本之间的差异的部分。 rails提供可database版本之间的migration机制。
4.如果你想拿出程序里的一段代码,看看它的执行结果是什么,怎么办呢?
传统的方式是打日志,但如果需要修改以前的程序看结果呢?
rails 提供rails console, 可以直接输入代码,看执行结果,很方便。
5.经常会遇到系统的远程部署问题, 我还记得以前部署的过程,
连接VPN,更新数据库, 连接linux console, 敲用户名密码,ftp程序.........
say no to duplicated work!!!!
ruby rails 提供了 自动部署的机制。
6.现在越来越强调单元测试,如果要做单元测试,就要有一套mock框架来模拟依赖关系。
RSpec是很好的mock框架。 为了保存测试数据不被破坏,测试数据库要和开发数据库分开,rails提供了很好的机制。
7.另外,functional test也很重要,结合thoughtworks 的 selenium 平台, functional test 很容易实现。
针对以上的种种问题, rails 有相应的结构来处理
--root
--app #ruby 代码,包括MVC结构的内容
--module
--controller
--view
--config # rails默认提供了3种运行环境:development,test,production, 所以对应了3个数据库,由此保证了测试的数据
#不会被破坏。
--enviroment # 提供了每种环境的运行参数
--database.yml # 提供每种数据库类型、用户名密码等数据库访问配置
--db
--migrate #
-- 20080803043520_create_products.rb #migration 文件,用于把新的变化部分的数据结构发布到
#当前版本数据库。
--schema.rb # #当前版本的数据库结构
--lib
--task #自定义的rake文件可以放在这里
--public #包括静态页面和javascript、css文件
--script #启动web server, rails console, generate code
--server
--generate
--console
--test
-- fixtrures #包含了开发需要的数据(以YML数据的形式存在)
-- functional #功能测试的代码
-- integreation#集成测试的代码
-- unit #自己写的单元测试的代码
--vendor
-- plugins #第三方的代码,以插件的形式加入rails工程
以上的数据库结构脚本和YML数据可以应用到development,test,production中的任何一种数据库。
只需要运行:
rake db:reset RAILS_ENV #默认是development 环境
rake db:reset RAILS_ENV=test
rake db:reset RAILS_ENV=production
同理,load 数据库数据数据
rake test:fixtures:load RAILS_ENV=production