既然要说 Ruby 那肯定是离不开 Rails 的，毕竟
Ruby 只是 Ruby on Rails 的一套框架，才不是什么程序语言呢！
话不多说先新建一个 Rails 项目：
$ rails new app --B
默认情况下，Rails 提供了三个环境：development，test 和 production，其定义是在 app/config/environments 目录下，以后的配置都是要考虑这三个环境的（手动修改过相关配置的可能不一定是三个）。重点要说的是 app/config/secrets.yml 这个文件
# app/config/secrets.yml
development:
secret_key_base: 5734127d4e3ebf07d9d7af9aed02b869448faf4afefc7bb7abbfdb9979ed92546ee84edbc37e0e50b5469c0d43923faf2d2d9e46d5f5f0d1d997f47b656dbd45
test:
secret_key_base: 35469501039e3c1abc7f4b76d8184df2c6ed0491a6b4f522be84ae5c52d4cf7e5ef31e50f5f063794d076d25e78ce76e8533e72ea20171193c59de861e861b1a
# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
其中 production 的值是 <%= ENV["SECRET_KEY_BASE"] %> （至于为什么 yaml 文件中可以使用ERB，可以点这个链接查看原因下面也会提到一点具体代码），那么问题就来了，这个 ENV 到底是个啥子东东呢？
ruby-doc 上是这么解释的：
ENV is a hash-like accessor for environment variables.
由此可知，生产环境下的这个 secret_key_base 是一个很 隐私？ 私密？机密？ 敏感？的数据，不能让其出现在代码仓库之中，而要将其放在环境变量 ENV 中（很多非 Rails 项目，更准确的讲是 Rubygem 项目都没有注意到这个，就我个人而言，即使是测试环境下的外部测试帐号信息也是敏感数据）。具体做法 Railscast 上也有一节是专门讲这个的（不过好像是 revised 的）。
那么，在 Ruby 项目中这又是如何实现的呢？
显然，纯 Ruby 项目没有 Rails 考虑的那么周到，从 Rails 到 Ruby 其感觉就像是一夜回到解放前，不过自从有 bundle 工具之后，起码可以说回到解放后了。
下面以 JPush API Ruby Client （这是一个 gem 包，即为 Ruby SDK，为方便起见，下文统一称为 SDK）为例来说道说道。
首先细化一下这个 SDK 的使用场景：有一个使用 Rails 作为后台的项目，现在需要使用极光推送为手机客户端提供消息推送服务，那么在服务端就需要集成 JPush 的 Ruby SDK。首先要安装这个 gem，得益于 bundle 工具，只需要在 Gemfile 里面添加相应的配置即可：
# Gemfile
gem 'jpush'
然后运行
$ bundle install
DONE！
JPush SDK 便已经成功安装到 app 项目中。
在 Rails 项目中有三个环境，对于不同的环境可能需要给 SDK 不同的帐号信息。比如微信就存在微信公众平台接口测试帐号一说，不过很多其他的服务（包括极光推送）并不存在测试帐号一说。不论如何去做，可以确定的是，处于生产环境中的 SDK 的敏感信息可以交由 Rails （即 使用这个 SDK 的项目本身）来管理，并不需要 SDK 来做，但是在 SDK 开发测试过程中的敏感信息就要 SDK 自己来管理了。
根据以上的结论，在 SDK 项目的代码里面应该有一个下面这样的类
module JPush
class Client
def initialize(app_key, master_secret)
xxx
end
end
end
来管理账户信息，这个类的实例化，留给使用这个 SDK 的开发者在自己的项目中去做。
在单元测试中，需要在 test_helper.rb 中实例化这个 Client 类，但是帐号信息哪里来，这是个问题。在这里有几种方案（偷师 Rails）：
- 设置系统级环境变量，然后从 ENV 中读取
- 将需要的变量写入一个 yaml 文件，在初始化测试的时候写进 ENV 中，再读取
等等，既然可以写进 yaml 文件中，Ruby 本身又能方便的处理 yaml，那为什么还要写进 ENV 里面呢。
所以结论是新建一个 config.yml 将需要填写的信息模板写进去，比如：
# test/config.yml.example
app_key: APP_KEY
master_secret: MASTER_SECRET
tags:
tag0: TAG_0
tag1: TAG_1
然后在 test_helper.rb 中处理
# test/test_helper.rb
# symbolize_keys 是在其他地方实现的解析嵌套 Hash 的方法
cnf =
if File.exists? cnf_file = File.expand_path('../config.yml', __FILE__)
require "yaml"
YAML.load_file(cnf_file).symbolize_keys
else
raise 'No Config File Found!!'
end
app_key = cnf[:app_key]
master_secret = cnf[:master_secret]
@@client = JPush::Client.new(app_key, master_secret)
当然这里省略了一些细节。需要把 config.yml 加入到 .gitignore 中，在项目中只能有一个 config.yml.example 文件，这样的话，参与开发的流程就应该是
- fork 项目
- $ cp test/config.yml.example test/config.yml
- 编辑 test/config.yml ，填写所需的信息
- $ bundle exec rake test
然而，持续集成那边 Travis CI build 出错，原因也很清楚，可以写脚本让其复制 config.yml 但是无法做到填写数据。各种数据都是 example 的数据，没有任何意义，好在 Travis 可以为其设置环境变量，这样的话，只要稍微改一改就可以完成。因此上面说的那句话
Ruby 本身又能方便的处理 yaml，那为什么还要写进 ENV 里面呢
我收回。
# test/config.yml
app_key: <%= APP_KEY %>
master_secret: <%= MASTER_SECRET %>
tags:
tag0: <%= TAG_0 %>
tag1: <%= TAG_1 %>
# test/test_helper.rb
# symbolize_keys 是在其他地方实现的解析嵌套 Hash 的方法
cnf =
if File.exists? cnf_file = File.expand_path('../config.yml', __FILE__)
require "yaml"
require "erb"
template = File.read(cnf_file)
erb_result = ERB.new(template).result
YAML.load(erb_result).symbolize_keys
else
raise 'No Config File Found!!'
end
这样的话，开发流程其实并没有怎么变，只不过多了一个选择，可以选择编辑 test/config.yml 或者设置相应的环境变量，关于 Tiavis CI 的话，只需添加相应的环境变量，便能顺利的构建。
OVER
