8 ms·

- "You cannot update your server’s configuration without committing and deploying new code" I admit while I agree with many parts of 12-factor, I have never fu

by jwiley 12y ago

- "You cannot update your server’s configuration without committing and deploying new code" I admit while I agree with many parts of 12-factor, I have never full understood the rational for this. What is the rationale of moving from versioned, concise config files, to un-versioned ENV variables? - "Due to Ruby’s lack of type checking, the following code has a full code path that is not tested." Add this to your specs: Rails.stub(:env).and_return('staging') ? - "Bundler won’t install ‘production’ grouped gems on your staging server" Use identical gems under staging, or override Capistrano's bundle install - "It’s easy to make mistakes when configuring code by environment." How about defining a new config value in staging.rb? Your::Application.config.mount_admin I may be missing something, but how can ENV variables scale beyond a few config variables? I can see an argument that we should all be striving for fleets of micro-services that will only require a few, but many codebases cannot and won't ever realistically meet this goal.

josegonzalez 12y ago
No one says your env vars need be unversioned. For instance, at SeatGeek we version all env vars in our chef cookbook repository as databags and reference them in the application infrastructure. It does require more fancy footwork when deploying new features that need environment variables, but it also lets us share our codebase with non-technical users and the occasional freelancer/potential FT hire without needing to scrub confidential information.
- jwiley 12y ago
  So why not just move the confidential stuff to ENV, and use the traditional Rails methods? What does ENV vs config get you?
sjtgraham 12y ago
> Add this to your specs: Rails.stub(:env).and_return('staging') ? allow(Rails).to receive(:env).and_return 'staging'.inquiry This preserves the Rails.env.staging? behaviour. Rails.env is an ActiveSupport::StringInquirer
flog 12y ago
I've found a good use case is feature switches. If something goes flakey in production I can quickly disable a feature without editing files, and the full process around that.

by jwiley 12y ago

josegonzalez 12y ago

No one says your env vars need be unversioned. For instance, at SeatGeek we version all env vars in our chef cookbook repository as databags and reference them in the application infrastructure. It does require more fancy footwork when deploying new features that need environment variables, but it also lets us share our codebase with non-technical users and the occasional freelancer/potential FT hire without needing to scrub confidential information.

jwiley 12y ago
So why not just move the confidential stuff to ENV, and use the traditional Rails methods? What does ENV vs config get you?

sjtgraham 12y ago

> Add this to your specs: Rails.stub(:env).and_return('staging') ? allow(Rails).to receive(:env).and_return 'staging'.inquiry This preserves the Rails.env.staging? behaviour. Rails.env is an ActiveSupport::StringInquirer

flog 12y ago

I've found a good use case is feature switches. If something goes flakey in production I can quickly disable a feature without editing files, and the full process around that.